Hi Oleg,
>I remember that some EAP-TLS/PEAP clients rejected not fragmented messages
>without L bit set, probably due to their wrong interpretation of EAP-TLS
>RFC. Would it worth to say something like "Implementation SHOULD accept
>unfragmented messages with and without L bit set" in addition to
On Mar 15, 2019, at 6:13 AM, John Mattsson wrote:
> I think we need to choose one and ensure that implementations following
> draft-ietf-emu-eap-tls13 can talk to each other. Do anybody have any data on
> how many implementations out there set the L bit for unfragmented messages
> and how many
Alan wrote:
>I've done a quick check. On reception, FreeRADIUS accepts the L bit for any
>type of message. It doesn't care >about fragments, just that the length is
>correct.
>
>For sending packets, FreeRADIUS sets the L bit only if it is sending
>fragments.
That is probably the correct be
John wrote:
>That is probably the correct behavior to standardize, i.e., something like
>"Implementations MUST NOT set the L bit in unfragmented messages, but MUST
accept unfragmented messages with and without the L bit set."
I'm for the strict approach. Anyway some implementations don't adhere i
On Mar 15, 2019, at 12:51 PM, slon v sobstvennom palto
wrote:
>
> >That is probably the correct behavior to standardize, i.e., something like
> >"Implementations MUST NOT set the L bit in unfragmented messages, but MUST
> >accept unfragmented messages with and without the L bit set."
>
> I'm f
