Subject: Re: [Emu] EAP and Fragmentation

From: John Mattsson <[email-masked]>
Date: Fri, 15 Mar 2019 10:13:31 +0000

Hi Oleg,

>I remember that some EAP-TLS/PEAP clients rejected not fragmented messages
>without L bit set, probably due to their wrong interpretation of EAP-TLS
>RFC. Would it worth to say something like "Implementation SHOULD accept
>unfragmented messages with and without L bit set" in addition to copying
>the sentence above from RFC 5281?

I added the following text to draft-ietf-emu-eap-tls13-04:

"EAP-TLS fragmentation support is provided through addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a TLS Message Length field of four octets.  Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant)."

I don't know if anything more if needed, but if we add something I think it should be "MUST accept" rather than "SHOULD accept".

The other alternative would be to instead write "Unfragmented messages MUST NOT have the L bit set and include the length of the message (though this information is redundant)."

I think we need to choose one and ensure that implementations following draft-ietf-emu-eap-tls13 can talk to each other. Do anybody have any data on how many implementations out there set the L bit for unfragmented messages and how many implementations do not accept unfragmented messages with the L bit set?

Cheers,
John

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Mar 2019 09:09:42 -0400

> I think we need to choose one and ensure that implementations following draft-ietf-emu-eap-tls13 can talk to each other. Do anybody have any data on how many implementations out there set the L bit…

  I've done a quick check.  On reception, FreeRADIUS accepts the L bit for any type of message.  It doesn't care about fragments, just that the length is correct.

  For sending packets, FreeRADIUS sets the L bit only if it is sending fragments.

  Alan DeKok.