Patch: eaptls packets too large, clash MTU

[Michael Joosten]

> > 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