________________________________________ 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