skip to content

A certificate chain will not fit one RADIUS attribute, so how does one EAP packet cross several EAP-Message (79) attributes?

level: seniorimportance: should knowfreq 37%

answer

  1. two fragmentations, only one costs time
  2. type-length-value with one-octet fields
  3. 253 octets of value, not 255
  4. several attributes, one RADIUS packet
  5. concatenate values in order received

basics

~20 s

A RADIUS attribute's value stops at 253 octets, so the sender splits one EAP packet across consecutive EAP-Message (79) attributes inside the same RADIUS packet, and the receiver concatenates their values in the order received to rebuild the original EAP packet.

solid answer

~50 s

A RADIUS attribute is type-length-value with a one-octet Type and a one-octet Length, so its value tops out at **253 octets** — far less than a certificate. The encapsulation handles this by allowing **several `EAP-Message` (79) attributes in one RADIUS packet**: the sender chops the EAP packet into 253-octet pieces, and the receiver concatenates the values of every `EAP-Message` it finds, in order, into a single EAP packet before handing it to the EAP layer. That costs no extra exchange, because the pieces travel together. A second, independent limit still bites: the RADIUS packet's own Length maximum is 4096 octets, and the peer's link has an MTU the device can advertise with `Framed-MTU` (12). Between them, a full chain does not fit one EAP packet, so the method fragments its own messages — and each of those fragments does cost a round trip.

code

pseudocode · 14 lines
pseudocode
// one received RADIUS packet; attributes are in wire order
function reassemble_eap(packet):

    eap_packet = empty octet string

    for each attribute in packet.attributes:
        if attribute.Type is 79:                  // EAP-Message
            append attribute.Value to eap_packet  // Value is at most 253 octets

    if length of eap_packet is 0:
        return no_eap_in_this_packet

    // eap_packet is ONE EAP packet: Code, Identifier, Length, Type, data
    return eap_packet

go deeper

for a junior

Recall that an EAP packet can be larger than a RADIUS attribute, and that RADIUS handles this by carrying the pieces as several EAP-Message (79) attributes in the same packet.

for a middle

Explain the arithmetic: one-octet Type plus one-octet Length leaves 253 octets of value, and the receiver concatenates values in order with no sequence numbers because nothing can arrive apart.

for a senior

Separate the two fragmentation layers when diagnosing: attribute splitting is free, method fragmentation costs exchanges, and chain size is therefore a latency decision, not just a bandwidth one.

for a principal

The estate-level judgment is about credential shape: how many intermediates a chain carries, and what MTU the field links offer, sets the per-login exchange count for every device you will ever deploy.

## Two different fragmentations, and only one of them is expensive Candidates routinely collapse these into one idea, and the distinction is the whole question. 1. **Attribute-level splitting**, which is RADIUS's problem: one EAP packet is too big for one attribute, so it is split across several `EAP-Message` (79) attributes **inside a single RADIUS packet**. 2. **Method-level fragmentation**, which is EAP's problem: one method message — a certificate chain, say — is too big for one EAP packet, so the method splits it across **several EAP packets**, each of which needs its own exchange. The first is free in time and invisible above the encapsulation. The second is what makes a certificate-based login take many round trips. ## Why 253, and what the receiver does A RADIUS attribute is encoded as type-length-value: **one octet of Type, one octet of Length, then the value**. Because Length counts the whole attribute and is a single octet, its ceiling of 255 leaves **253 octets of value**. `EAP-Message` (79) is an ordinary attribute and inherits that ceiling. The rule that rescues it is a concatenation rule: a RADIUS packet may carry multiple `EAP-Message` attributes, and a receiver treats their values as one octet stream. Concretely, on receipt: - walk the attributes **in the order they appear** in the packet; - append the value of every `EAP-Message` (79) to a buffer; - the buffer is exactly one EAP packet — its own Code, Identifier, Length and Type — which goes to the EAP layer. Order is not negotiable and there is no per-fragment sequence number, because none is needed: the pieces are in one packet, arriving together or not at all. There is nothing to reorder, nothing to acknowledge, and no partial state to hold between packets. ## Where the ceiling really is | Limit | Value | What it constrains | |---|---|---| | One attribute's value | 253 octets | how much of an EAP packet one `EAP-Message` (79) holds | | One RADIUS packet's Length | 20 octets minimum, 4096 maximum | the whole packet — header plus every attribute, EAP and otherwise | | The peer's link | whatever the lower layer carries, advertised by `Framed-MTU` (12) | how big an EAP packet the peer can actually receive | The RADIUS ceiling and the link MTU are separate constraints and in practice the link is usually the binding one, which is why an access device tells the server about it with `Framed-MTU` (12) rather than letting the server assume 4096. Either way, a certificate chain of a few kilobytes exceeds what one EAP packet may be, and the method must break its own message up. ## What method-level fragmentation costs EAP is lock-step: one Request outstanding, one Response answering it. So when EAP-TLS (EAP Type 13, RFC 5216) splits a chain across fragments, each fragment is its own EAP packet and each one rides its own `Access-Challenge (Code 11)` or `Access-Request (Code 1)`. A peer that receives a fragment answers with a short acknowledgement so the sender knows to send the next. **Every fragment is therefore a full round trip over the RADIUS path**, and a chain with an extra intermediate certificate in it costs exchanges, not merely bytes. The same is true of any method that carries a certificate — EAP-TTLSv0 (EAP Type 21) and TEAP (EAP Type 55) run their own protected exchange the same way. ## Reading a capture, and the mistakes it exposes When you look at one of these conversations, three observations separate people who have operated it from people who have read about it: - **Four `EAP-Message` (79) attributes in one `Access-Request` is one EAP packet, not four.** A tool that lists attributes will show four rows; the EAP layer saw one packet. - **The EAP Identifier is not the RADIUS Identifier.** The encapsulated EAP packet carries its own Identifier, matching an EAP Request to its Response within the conversation; the RADIUS header has a separate one for matching a reply to a request on that hop. They advance independently and confusing them makes a capture unreadable. - **`Message-Authenticator` (80) appears once per RADIUS packet**, not once per `EAP-Message` fragment — it covers the packet, and the split pieces are inside it. ## The practical consequence Because attribute splitting is free and method fragmentation is not, the lever that changes how long a certificate-based login takes is the **size and shape of what the method has to send** — the number of certificates in the chain, and how big each is — together with the MTU that decides how many fragments that becomes. Trimming an unnecessary intermediate out of a chain removes round trips from every login on the estate; nothing about the RADIUS attribute encoding does.

  • How many extra round trips does splitting an EAP packet across four EAP-Message (79) attributes cost?
    None. All four attributes travel in the same RADIUS packet and are concatenated on receipt, so the exchange count is unchanged. Extra round trips come from the other layer — the method splitting one of its own messages across several EAP packets, each of which has to be sent and answered.
  • What stops the sender from simply putting the whole chain in one enormous EAP packet?
    Two ceilings. A RADIUS packet's Length field maxes at 4096 octets for the header and all attributes together, and the peer's own link carries only so much — which is what `Framed-MTU` (12) tells the server. Above the smaller of those, the method has to fragment its own messages.
  • Is the Identifier inside the encapsulated EAP packet the same as the RADIUS Identifier?
    No. They are separate spaces: the EAP Identifier matches an EAP Request to its Response within the EAP conversation, while the RADIUS header's Identifier matches a reply to a request on that one device-to-server hop. They advance independently, and reading a capture as though they were one field is a reliable way to mis-diagnose it.

saying these in an interview costs you the question

  • Thinks each EAP-Message (79) attribute costs its own round trip.
  • Says an attribute value can hold 255 octets.
  • Assumes the receiver reorders fragments by a sequence number.
  • Confuses attribute splitting with the method's own fragmentation.
  • Believes a chain of any size fits in one RADIUS packet.
  • Expects one Message-Authenticator (80) per EAP-Message fragment.