Protocols and Dependencies (What Must Work)

1. Core protocols in the chain

RADIUS (UDP)

RADIUS is a client/server AAA protocol. It is connectionless and relies on the client (NAD) to handle retransmissions, server availability, and timeouts. This is why a small RTT increase can translate into aggressive retry storms if the NAD timeout is poorly tuned. RADIUS core spec: RFC 2865.

EAP

EAP is an authentication framework often used over IEEE 802 links and encapsulated in RADIUS for AAA. EAP includes duplicate elimination and retransmission mechanisms and relies on lower-layer ordering guarantees. EAP core spec: RFC 3748.

LDAP

LDAP is typically used for directory lookups and some authentication-related operations, including user/group queries and identity attribute retrieval. LDAP core protocol: RFC 4511.

Kerberos

Kerberos is a network authentication protocol used heavily in AD environments. Kerberos is time-sensitive and depends on reliable name resolution and synchronized clocks. Kerberos V5 spec: RFC 4120.

DNS

DNS is the glue: service discovery, DC location (SRV), reverse lookups, and name resolution for identity and posture components. If DNS resolution is slow or incorrect, “latency” becomes “timeouts”.

NTP (Time Synchronization)

Time synchronization is required for Kerberos validity windows, certificate validation expectations, and consistent policy logging correlation. NTPv4 spec: RFC 5905.

X.509 Certificates / Revocation Checking

Certificate-based authentication depends on PKI semantics and revocation status. CRLs are profiled in RFC 5280 and OCSP in RFC 6960. Any remote CRL/OCSP dependency can become a high-latency choke point.


2. Dependency map (practical)

Interaction
Protocol / Purpose

NAD ↔ ISE

RADIUS (UDP), EAP encapsulated in RADIUS

ISE ↔ AD

LDAP, Kerberos (often with DC locator)

Any ↔ DNS

SRV/A records, reverse lookups

Any ↔ NTP

Time synchronization / validity

Certificates

CRL / OCSP validation

Posture

Endpoint posture module ↔ ISE posture services (HTTPS)


3. The hidden multiplier: multi-round-trip methods

A single “authentication attempt” can contain many back-and-forth messages, including:

  • EAP identity exchange

  • EAP method negotiation

  • TLS handshake (EAP-TLS)

  • Inner authentication (PEAP with MSCHAPv2)

  • Authorization decision

  • Posture evaluation and CoA

In WAN or hybrid environments, each round trip amplifies end-user wait time and increases the likelihood that one or more timers expire.


4. What “healthy” looks like (conceptually)

A healthy authentication and posture environment typically exhibits the following characteristics:

  • DNS queries resolve locally and consistently (correct SRV/DC selection)

  • NTP is stable and within expected clock skew

  • NAD timeout and retransmit values account for measured RTT and backend latency

  • ISE nodes are placed close to endpoints and identity stores

  • Posture services are available locally or via low-latency paths

  • Certificate validation does not depend on distant CRL/OCSP endpoints


Use this document as a checklist when troubleshooting perceived “ISE latency” issues.


Last updated