Subject: Re: [Emu] RFC5216 - L-Flag in the fragment packets (fwd)

From: Jonathan Rausch <[email-masked]>
Date: Tue, 5 May 2009 13:26:42 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, May 05, 2009 4:11 AM
To: [email-masked]
Subject: [Emu] RFC5216 - L-Flag in the fragment packets (fwd)

 ________________________________________
 From: Murat Sezgin [[email-masked]]
 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