Welcome and thanks for your comments Oleg! slon v sobstvennom palto <slonvpa...@gmail.com>; wrote:
>Per my experience the existing fragmentation method described in EAP-TLS >RFC 5216 serves good for all fragmentation needs. The method is reused by >PEAP, EAP-FAST, TEAP and EAP-TTLS. There's an ambiguity in EAP-TLS RFC that >doesn't specify whether a not-fragmented message should have the L bit and >the 4 octets length field so different peers treat it differently. However, >for example, EAP-TTLS RFC closed it tightly saying that even a >single-fragment message should have it nevertheless on its redundancy. I cannot find anything in EAP-TTLS (RFC 5281) saying that the L bit should be set. As you have noticed, EAP-TLS (RFC 5216) does not say anything about the L bit in unfragmented messages and my understanding is that the ambiguity is if unfragmented messages can (not should) have the L bit set. As far as I can see, EAP-TTLS (RFC 5281) states that unfragmented messages MAY set the L bit. RFC 5281 Section 9.2.2: “Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant).” I looked through the other TLS-based EAP methods (both RFCs and drafts) and none of them seems to say anything new about the L bit. draft-ietf-emu-eap-tls13 should clarify any ambiguity. Should draft-ietf-emu-eap-tls13-04 just copy the sentence from RFC 5281 or do the group want something different? Cheers, John _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu