Dynamic EAP fragment_size for low MTU

[Jouni Malinen]

On Wed, Dec 06, 2023 at 11:55:16AM +0000, Samuel Melrose wrote:
> Now this I didn't realise - I (apparently wrongly) assumed that the
> RADIUS attributes made it from the AP/switch to wpa_supplicant, thanks
> for setting me straight here!

Only the reassembled contents of the EAP-Message attributes is delivered
in EAPOL frames to supplicant.

> Love your idea here - try to detect the fragment size the server is
> using and match it.

In theory, this might work, but it is a bit more complex than one might
hope and not exactly perfect for all cases.. One thing to keep in mind
is related to the contents differences in the RADIUS messages. It is
quite likely that the Access-Request (i.e., EAP client to server) has
significantly more extra information (additional RADIUS attributes)
compared to Access-Challenge. As such, the EAP client might need to
actually drop the fragment size to something like 200 bytes shorter than
the one the server used to get the RADIUS messages to be of about the
same size. The exact difference depends on the APs and network
configuration and there is no mechanism for the supplicant to know all
the details..

> It shouldn't matter if it's EAP method specific, as EAP-TLS is the one
> that mainly suffers due to client certificate exchange and as you say,
> I would imagine in most situations where the client certificate
> payload is too big to fit into a single packet, the server is going to
> have the same problem in it's certificate exchange, so it's a good
> fit.
> 

EAP-TLS, or any other TLS-based method when using a client certificate,
are indeed the most likely cases that would trigger this. There are some
other use cases as well like use of EAP-TNC within a TLS tunnel even if
client certificate is not used.

> If I can manage to get a patch together that does this (probably just
> for EAP-TLS specifically), would you be willing to consider it for
> inclusion?

Sure, I would consider, but it depends on what exactly this would end up
doing in the end before I could estimate what is the likelihood of that
consideration resulting in actually applying the changes.. This is a bit
inconvenient area since there is risk of breaking something else or
resulting in really bad choice in some cases.

I would also limit this to a case where EAP-TLS is used without
encapsulation, i.e., would not address the cases where EAP-TLS is the
phase 2 method with PEAP/TTLS/FAST/TEAP. It is only the phase 1 method
that should really do EAP method specific fragmentation.

> Would you probably want it configurable as an option, perhaps with the
> default being turned on?

If the design seems to work relatively nicely and reliably and has some
checks for avoiding the most obvious bad cases, I'd prefer to do this
type of things automatically without the user having to know about the
mechanism and when to enable or disable it.. I would use the existing
fragment_size configuration option as means for disabling, i.e., if the
configuration includes the fragment_size parameter, I would not try to
override it, but if that is not included, the EAP method should be
allowed to try to figure out the best value on its own.

Looking for the largest received EAP-TLS message fragment with more
fragments bit set to 1 should be robust enough mechanism for determining
what the EAP server is doing. This would then need to be adjusted based
on the guesses on how much extra stuff the AP adds to Access-Request. If
the outcome would be really small, I would not drop the default fragment
size, though, since that can result in other issues like some APs having
a limit on the number of allowed EAP round trips.. In addition, I would
not increase the fragment size from its current value regardless of how
large a fragment the EAP server is using.

It should also be kept in mind that if the IP network has a more
reasonable MTU and/or support for fragmentation (or RADIUS is over TCP
or if there is AP-internal authentication server), all the changes to the
fragment size of the EAP client are actually reducing performance and
this could be quite undesired as the default behavior.. As an example, I
would not have any issues with splitting a 2000 byte EAP-TLS message
into two 1000 byte fragments instead of 1400 and 600 byte fragments, but
I would not really like to see it to be split into three fragments (900,
900, 200 bytes). As such, I might actually recommend not doing anything
automatically by default if that automatic determination would result in
increasing the number of EAP round trips.

-- 
Jouni Malinen                                            PGP id EFC895FA