Dynamic EAP fragment_size for low MTU

[Alan DeKok]

On Dec 6, 2023, at 5:53 AM, Samuel Melrose <sam.melrose at a1comms.com> wrote:
> I'm struggling with a low MTU network and EAP-TLS not working due to
> the RADIUS Auth-Request packets being too large - they are fragmented
> at layer 4 (UDP), but dropped in the network path due to fragmentation
> not being correctly supported by the firewall devices.

  RFC 6613 was published in 2012, and says:

      *  Packet fragmentation.  [RFC2865], Section 3, permits RADIUS
         packets up to 4096 octets in length.  These packets are larger
         than the common Internet MTU (576), resulting in fragmentation
         of the packets at the IP layer when they are proxied over the
         Internet.  Transport of fragmented UDP packets appears to be a
         poorly tested code path on network devices.  Some devices
         appear to be incapable of transporting fragmented UDP packets,
         making it difficult to deploy RADIUS in a network where those
         devices are deployed.

  You can't really control fragmentation at the supplicant side.  So you're stuck with that.

  Which means that you're limited in how small the RADIUS packets can get.  Think EAPoL packet size plus maybe 100 bytes.

  Which should really be fine for most networks.  If it isn't working, then one of two things is happening:

1) the AP is adding a lot of other RADIUS attributes so that the UDP packet is larger than ethernet MTU

2) your local network has something like multiple layers of MPLS / VPN / etc., which shrinks the ethernet MTU to something which causes issues

  The only real solution here is to switch transport protocols.  Many access points support RADIUS/TLS (or RadSec).  That uses TCP, which handles MTU / fragmentation issues.

> I've spent nearly a week searching for a solution here, and while the
> RADIUS standard supports the Framed-MTU attribute to adjust the
> maximum packet size, this only appears to be supported in the Client
> -> Server direction: this isn't helpful in our instance, as the
> wpa_supplicant isn't doing PMTUD, it's just hard coding a value of
> 1400.

  Fixing that would be the simplest approach.  Set that lower, and it will work around the problems.

  I'm surprised that you can't change the configuration on a Chromebox.  They're supposed to be centrally managed.  Why not do that?

  It looks like you're running into a "perfect storm" of issues where the local network has lower than normal MTU, *and* you can't modify the supplicant configuration to lower its fragment size.  That's likely to be a rare configuration.

> There are plenty of examples of people online suffering the same
> problems and as far as I can tell, very few solutions are found,
> beyond people giving up - at-least, none are posted.

  Lower the supplicant fragment size.  Don't artificially lower the network MTU with layers of MPLS / VPNs.  Use TLS / TCP transport.

> A lot of people mention how impractical it is to be required to tune
> the fragment_size value in the configuration of each client, rather
> than having it pushed centrally.

  Why not just change the MTU centrally to 1300?  Or 1200?  There is pretty much zero side effect.

  Maybe in some cases the EAP authentication will take one or more packets.  Who cares?  It's just network traffic.  Is saving those bytes so important that it's worth spending days of admin time trying to come up with a perfect solution?

  I would say "no".

  As for the difference between PEAP vs EAP-TLS, it's simple.  With PEAP, the client sends small amounts of data to the server in each packet.  So fragmentation doesn't come up.  With EAP-TLS, the client has to send the client certificate, which then increases the size of the EAPoL packet, and then results in fragmentation.

  The simple fixes are:

* switch from UDP to RADIUS/TLS

* change all supplicants to use a smaller fragment size

  I would be wary of auto-detecting fragment size on the supplicant side.  The TLS protocol is complex, and it's common for TLS-based EAP methods to send small packets as part of TLS round trips.  How does the supplicant determine the maximum MTU from a wide variety of EAP packet sizes?  It's a non-trivial problem.

  What *might* work is looking at the TLS fragment length in the EAP-TLS Request packet:  https://datatracker.ietf.org/doc/html/rfc5216#section-3.1

  IF the TLS fragment length is included
  AND it's more than 1500
  AND the EAP fragment is larger than 1012
  THEN try to guess the fragment size from the size of the EAP packet

  But this is fragile, and prone to being wrong.  If you're going to add this as a patch to hostap, and then also have it hidden behind a configuration flag, why not just update the existing configuration to use a smaller fragment size?  It's less effort, and it's guaranteed to work.

  Alan DeKok.