On Jun 25, 2015, at 12:09 PM, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
The size of that fragment, is pretty big, 1398 bytes. I think only fragments up to 1020 bytes are guaranteed to be handled by the authenticator.
Excellent analysis,
The extra debug really helps. There was much cursing when I discovered (at a customer site) that FreeRADIUS didn't print the outbound request IDs, or length of the request packets, or any of the fragmentation information, or the what the various return codes from eaptls_verify meant.
just wondering about that sentence? The RADIUS side of the authenticator has to be prepared to get 4k RADIUS packets (with arbitrarily much of that being EAP-Message), and the EAPoL side of the authenticator needs to support sending the local link's MTU minus EAPoL headers as payload.
TBH I was parroting Alan's analysis of the RFC. If you don't agree that 1020 is the minimum EAP MTU, then you're more than welcome to continue that conversation with him :) RFC 3748 - Extensible Authentication Protocol (EAP) Section 3.1 assumption [4]. EAP methods can assume a minimum EAP MTU of 1020 octets in the absence of other information. EAP methods SHOULD include support for fragmentation and reassembly if their payloads can be larger than this minimum EAP MTU. Taking into account the overhead of EAP-TLS which is 6 or 10 bytes, depending on whether it's the first in a sequence of fragments and the TLS Message Length is included. In the absence of link MTU information the maximum TLS fragment size would be 1010 bytes in the first packet, and 1014 in subsequent ones. If the supplicant did have link MTU information available, then RFC 3748 does hint that the supplicant could send larger packets. IEEE 802.1X-2001 is silent on EAP fragments, other than describing the Framed-MTU attribute, which represents the EAP MTU between the Supplicant and Authenticator. -Arran