________________________________________
 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

Reply via email to