Re: [Emu] EAP and Fragmentation
On Mar 15, 2019, at 12:51 PM, slon v sobstvennom palto wrote: > > >That is probably the correct behavior to standardize, i.e., something like > >"Implementations MUST NOT set the L bit in unfragmented messages, but MUST > >accept unfragmented messages with and without the L bit set." > > I'm for the strict approach. Anyway some implementations don't adhere it. The > sentence above narrows the behaviour to a non-ambiguous while requires to > support all kinds of existing behaviours thus it looks like the most exact > form of the requirement. I agree. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP and Fragmentation
Alan wrote: >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. That is probably the correct behavior to standardize, i.e., something like "Implementations MUST NOT set the L bit in unfragmented messages, but MUST accept unfragmented messages with and without the L bit set." Cheers, John ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP and Fragmentation
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 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
