In the Juniper Networks implementation of both EAP-TTLS and EAP-TLS, used both in the Steel Belted RADIUS and the UAC NAC products, the L bit is set and the Length field is added only in the first fragment of the EAP-TTLS or EAP-TLS message. All other fragments do not contain the length field and the L bit is not set. There is no option to set the L bit and add the length field on every fragment. In a non-fragmented message the L bit is set and the length field is added. This is in line with what is stated in RFC5281:
"If there are multiple fragments, the first fragment MUST have the L bit set and include the length of the entire raw message prior to fragmentation. Fragments other than the first MUST NOT have the L bit set. Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant)." Juniper's versions of both EAP methods are implemented the same way in regards to the L-bit and length field, and if there is a perceived inconsistency between the two RFCs perhaps it should be clarified. Regards, Jonathan Rausch Software Engineer Service Layer Technologies Business Group Juniper Networks, Inc. ________________________________ From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, May 05, 2009 4:11 AM To: emu@ietf.org Subject: [Emu] RFC5216 - L-Flag in the fragment packets (fwd) ________________________________________ From: Murat Sezgin [msez...@ubicom.com] Sent: Tuesday, May 05, 2009 3:27 AM To: Dan Simon; Bernard Aboba; Ryan Hurst Subject: RFC5216 - L-Flag in the fragment packets Hi Mr.Simon, Mr.Aboba and Mr.Hurst In the "2.1.5 Fragmentation" section of the RFC5216, it is written that "The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages". Here, it is not clear that the other fragments must or must not include this L-flag set. On the other hand, the RFC5281-- EAP-TTLS, indicates that "Fragments other than the first MUST NOT have the L bit set". Is there a L-flag inconsistency between the EAP-TLS and EAP-TTLS fragments. Do you think you need to explicitly put the same statement in the RFC5216? In the FreeRadius implementation, there is an option called "include_length" in the tls module configuration section of eap.conf file, its default value is set to "yes", and with this configuration the server sends the L-flag in each fragment, this is not consistent with the TTLS RFC. FreeRadius's TTLS implementation also uses this option in its TLS handshake phase. Regards, Murat Sezgin Software Engineer www.ubicom.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
