Hi,
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.
Right; there's next to always a Framed-MTU available, so this limit doesn't "usually" hurt in real life. Then again, if it gets filtered out, then the server should ship with a sane default, right? Looks like the current default isn't: raddb/mods-available/eap -> tls-common: fragment_size = 1024 (and the preceding documentation text speaks about "half of 4096") Here's a pull request: https://github.com/restena-sw/freeradius-server/pull/1 Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66