...

while using EAPTLS via RADIUS for authentication of a PPP/L2TP/IPSec VPN (Microsoft style), I discovered that the generated EAPTLS packets are a little bit to large. If you take Framed-MTU serious, most of the EAPTLS header is not accounted for. Result: PPP communication with max. possible IPSec MTU fails silently, because the EAPTLS packets (esp. those with long certificates) are silently discarded.

Framed-MTU works, BUT of course you need to set fragment_size in eap.conf to a value larger than possible MTUs, otherwise you just get fragment_size'd chunks of the TLS conversation in multiple EAP_MESSAGE attributes, as you can see in the code: ssn->length_flag = inst->conf->include_length; /* * We set a default fragment size, unless the Framed-MTU * tells us it's too big. */ ssn->offset = inst->conf->fragment_size; /* * Framed-MTU is the whole packet, so we cut off the * EAPOW header (4 bytes) to be prepended by the NAS. * NOTE: This does not account for other protocols and * purposes like wired PPP, which has 8 bytes overhead. */ vp = pairfind(handler->request->packet->vps, PW_FRAMED_MTU); if (vp && ((vp->lvalue - 4) < ssn->offset)) { ssn->offset = vp->lvalue - 4; } /* * And even more for the EAP TLS header: * code + id + length + type + flags + TLS len * 1 + 1 + 2 + 1 + 1 + 4 = 10 */ ssn->offset -= 10; Actually, I discussed that a little with Alan last year: =========================================================== In addition, we had a little problem with fragment_size and Framed-MTU in eap_tls.c. Somehow the EAP headers were forgotten in the calculation, such that EAP packets 10 bytes too large were furnished. We are also testing this with MS IAS, which takes the Frame-MTU very literally. In FreeRadius, fragment_size is by default set to 1024, which is nicely conservative. Setting it to higher values or using a lower MTU, though, shows that while some 4 bytes are subtracted (802.1x header ?), the actual EAP header (code, id, len, type, flags and TLS len) is not accounted for. This depends, of course, also on the meaning of fragment_size: It seems to implemented as just the TLS fragment size, such that the calculation from Framed-MTU to fragment_size (or ssn->offset) should also subtract these 10 bytes of the full EAP header. Actually, the fixed subtract of 4 bytes should also look at Framed-Protocol, since PPP uses max. 8 bytes overhead (header = 4, FCS and flag bytes = 2+1+1, sum: 8). Having looked at some definitions and implementations, I'm currently quite confused about this MTU vs MRU issue. Perhaps it would have been better to have a Framed-MRU instead of a -MTU, and have the NAS figure out how much packet space he can give to EAP-TLS/TTLS/PEAP. At some point, it's

difficult for an application to know what MTU to use, because it doesn't now what protocol is being used to encapsulate it.

After my 'excursion' in what-the-heck-is-the-right-MTU land, I'm just more confused. After glancing through the relevant RFCs, I have the impression that Framed-MTU is not the MTU of the encaps. RADIUS reply, but the overall MTU to be used by the NAS. Which, as you agree, does not make much sense... =============================================================== ... which would mean that fragment_size needs to be adjusted depending on what Framed-Protocol is in use... (any other than EAPOW and PPP?) It's probably better to just reduce it by some "safety" value, to be on the right side, like another 10 bytes or so. Why PPP? My scenario is high-security VPN a la Microsoft, using PPP with EAPTLS over L2TP over IPSec. The intention is to have at least the server side also running free software, using RADIUS for authentication and rp-l2tpd with pppd as NAS. In the mean time, using EAPTLS patches for client PPP, we also have an experimental client using smartcard authentication for Linux. Michael PS: The next days I'm updating the X509 extensions I also created, will make an announcement for discussion to catch some ideas I've seen popping up in this list the last year. Regards, Michael