skip to content

Why does a certificate-based EAP method's round-trip count, not its byte count, decide whether a login finishes in a ninety-second window?

level: seniorimportance: should knowfreq 31%

answer

  1. lock-step, nothing pipelines
  2. one EAP pair per challenge and request
  3. State (24) stitches the legs together
  4. count exchanges, then multiply by latency
  5. loss costs a timer, not a round trip

basics

~20 s

Each Access-Challenge (Code 11) and the Access-Request (Code 1) answering it carries exactly one EAP Request/Response pair, and the exchange is strictly serialized, so elapsed time tracks the number of exchanges and any retransmission timers rather than the volume of bytes.

solid answer

~50 s

EAP is lock-step: one Request outstanding at a time, answered before the next is generated. Encapsulated in RADIUS, that means one EAP Request/Response pair per `Access-Challenge (Code 11)` / `Access-Request (Code 1)` pair, with `State` (24) echoed by the access device so the server can match the legs. Total time is therefore roughly *N* exchanges multiplied by the path round trip plus server and peer processing — and *N* grows with the method's own fragmentation, so a longer certificate chain buys more exchanges rather than merely more bytes. The bytes inside one packet are close to free. What really eats a short window is loss: a missing packet is not one more round trip but a **retransmission timeout**, and RFC 5080's recommended defaults start at an initial retransmission time of 2 seconds, double toward a maximum of 16 seconds, and give up after a maximum retransmission duration of 30 seconds.

code

pseudocode · 16 lines
pseudocode
peer   -> device : EAP Response, Type 1 (Identity) = "[email protected]"
device -> server : Access-Request  { User-Name(1), EAP-Message(79),
                                     Message-Authenticator(80), Framed-MTU(12) }
server -> device : Access-Challenge{ EAP-Message(79) = EAP Request, Type 13,
                                     State(24), Session-Timeout(27) = 30,
                                     Message-Authenticator(80) }
                                   // here Session-Timeout = wait for the EAP Response
device -> peer   : EAP Request, Type 13
peer   -> device : EAP Response, Type 13   (one method fragment)
device -> server : Access-Request  { User-Name(1), State(24) echoed,
                                     EAP-Message(79), Message-Authenticator(80) }

// ... one more Access-Challenge / Access-Request pair per method fragment ...

server -> device : Access-Accept   { EAP-Message(79) = EAP Success (EAP Code 3),
                                     Message-Authenticator(80) }

go deeper

for a junior

Recall that an EAP login is a back-and-forth of many small exchanges rather than one request, and that each exchange has to wait for the previous answer.

for a middle

Explain the pairing: one EAP Request/Response per Access-Challenge and Access-Request, correlated by State (24), so elapsed time is exchange count multiplied by path latency and processing.

for a senior

Demonstrate the diagnosis: count the exchanges for one conversation, price one leg, look for duplicates that mean a timer fired, and connect a grown chain or a smaller MTU to a longer login.

for a principal

The call a lead owns is where authentication servers sit relative to the sites that depend on them, since exchange count multiplies every millisecond of distance and every forwarding hop you add for administrative convenience.

## The shape of the exchange EAP allows exactly one outstanding Request per conversation. The authentication server sends a Request; the peer must answer it before anything else happens; the server then sends the next. Nothing pipelines, and nothing is speculatively sent ahead. Carried over RADIUS, each of those legs becomes a pair of packets on the device-to-server hop: - the server's EAP Request travels in an `Access-Challenge (Code 11)`, together with a `State` (24) value; - the peer's EAP Response comes back in an `Access-Request (Code 1)` that **echoes that `State` (24)**, which is how the server recognises this as the next leg of the same conversation rather than a new login. So the conversation's length in packets is fixed by the method, not by the network. A certificate-based method spends legs on: the identity exchange, proposing and agreeing a method (a peer that will not run the proposed one answers with a Nak, EAP Type 3), then one leg per fragment of each side's certificate material, then the method's own completion, then the final `Access-Accept (Code 2)` carrying EAP Success (EAP Code 3) or `Access-Reject (Code 3)` carrying EAP Failure (EAP Code 4). ## The arithmetic For *N* exchanges the floor is: **N × (peer-to-device time + device-to-server round trip + server processing + peer processing)** On a local path this is small: a dozen exchanges at 20 ms of path time each is under half a second, and the cryptography on each side usually dominates. On a long path, or through a forwarding server that adds its own hop to a partner organisation, the same dozen exchanges at 150 ms are seconds — and if the server is reached across a link that is itself congested when a dozen vehicles arrive together, the queue is added to every leg of every conversation. Bytes barely register in that sum. A 253-octet attribute or six of them go in one packet; the extra octets cost transmission time measured against link speed, not another exchange. **Where bytes do turn into time is indirectly**: more certificate material means more method fragments, and each fragment is another exchange. ## Loss is the expensive case UDP carries the RADIUS hop, so a lost `Access-Request (Code 1)` or its reply is not detected by the network — it is detected by a timer. RFC 5080 gives recommended retransmission behaviour for a RADIUS client: | Parameter | Recommended default | Effect | |---|---|---| | IRT (initial retransmission time) | 2 seconds | the first wait before resending | | MRT (maximum retransmission time) | 16 seconds | the ceiling the doubling backoff climbs to | | MRC (maximum retransmission count) | 5 | how many attempts before giving up | | MRD (maximum retransmission duration) | 30 seconds | the overall wall-clock bound on trying | One lost packet therefore costs **at least two seconds**, not a round trip, and three losses in one conversation can consume most of a ninety-second window on their own. This is the reason a login that "almost works" on a marginal path fails in a way that looks random: the successful attempts pay *N* × latency and the unlucky ones pay timers. ## The timeout you can actually influence When an `Access-Challenge (Code 11)` carries an `EAP-Message` (79), `Session-Timeout` (27) in that packet is **not** the length of the session being authorised — it is how long the access device should wait for the peer's EAP Response before treating the exchange as failed (RFC 2869). The same attribute in an `Access-Accept (Code 2)` means the ordinary thing: how long the authorised session may last. One attribute, two readings, decided by the packet it is in. ## Diagnosing a window that does not close When a login must complete inside a fixed window and sometimes does not, the useful questions are in this order: 1. **How many exchanges is this method actually taking?** Count `Access-Challenge` / `Access-Request` pairs for one conversation. That number is the multiplier on everything else. 2. **What is one exchange costing?** Split it into path time and server think time; a server that takes 200 ms per leg is a bigger problem at leg twelve than at leg one. 3. **Is anything being retransmitted?** A duplicate `Access-Request` with the same header Identifier is a timer that fired, and each one is seconds rather than milliseconds. 4. **Did the exchange count grow?** An added intermediate certificate, or a smaller link MTU, silently adds fragments — and therefore exchanges — to every login on the estate. The lever with the best return is almost always reducing *N* or the per-leg latency — fewer certificates in the chain, a server closer to the access device, one less forwarding hop — rather than anything about the size of the packets.

  • A single Access-Request in the middle of an EAP conversation is lost. What does that cost?
    A retransmission timer, not a round trip. With RFC 5080's recommended defaults the device waits about 2 seconds before resending and doubles from there toward a 16-second ceiling, bounded overall by 30 seconds. One loss can therefore cost more wall-clock time than the entire successful conversation would have.
  • Why can the access device not run several EAP legs in parallel to save time?
    Because EAP permits one outstanding Request per conversation: the next Request depends on the previous Response, so there is nothing to send ahead. The device is a relay with no method state, so it cannot anticipate a leg either. Parallelism exists only across different peers' conversations, not within one.
  • What ties the legs of one EAP conversation together across the RADIUS hop?
    `State` (24): the server puts it in the `Access-Challenge (Code 11)` and the device echoes it unmodified in the next `Access-Request (Code 1)`. Inside the encapsulated packet, the EAP Identifier separately matches each EAP Request to its Response. Two correlation mechanisms at two layers, and neither substitutes for the other.
  • Does adding an intermediate certificate to the chain cost bandwidth or time?
    Both, but the time is what matters. The extra material usually pushes the method into more fragments, and every fragment is another Access-Challenge and Access-Request pair — a full round trip each, paid by every login on the estate rather than once.

saying these in an interview costs you the question

  • Assumes a larger certificate chain only costs bandwidth.
  • Believes the access device can pipeline EAP legs in parallel.
  • Counts a lost packet as one extra round trip, not a timeout.
  • Reads Session-Timeout (27) in an EAP-bearing challenge as session length.
  • Thinks splitting across EAP-Message (79) attributes adds exchanges.