Dynamic EAP fragment_size for low MTU

[Samuel Melrose]

Thanks for the reply Jouni,

> Have you tested this with any other clients? Are there some client implementations that would actually dynamically change EAP-TLS fragmentation based on failures?

My next step is to test this against Windows 10/11 and see how it
behaves there - we do have PEAP working on Windows already, but
haven't tested EAP-TLS yet.

I believe PEAP may be working due to the server fragementing correctly
and the client only needing to send a small reply (no client
certificate to exchange) - I'll try to confirm.

> Which fragment_size are you talking about here? The one in hostapd or the one in wpa_supplicant? And if the latter, how would a hint from the server make it to wpa_supplicant?

> I'm not sure I can follow the design here.. Access-Challenge goes from the RADIUS server to the AP/RADIUS client. It does not go to the Supplicant/client/wpa_supplicant, so that use of Framed-MTU attribute on the client feels strange.

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!

> If this network deployment scenario is such that the Supplicant/EAP client needs to somehow probe for the maximum EAP message length, things are quite inconvenient since there is not really any good way for doing that.. If the EAP exchange happens to have a large message from the server first (and EAP-TLS in many cases does), an EAP client might try to figure out that there was a reason for the server to use surprisingly small EAP message for fragmentation purposes and adopt to using a similar fragmentation threshold. This might need to be done separately for each EAP method, though.

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

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.

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?

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

Regards,
Samuel Melrose
[ Senior Systems Engineer ]
Tel: +44 (0) 1332 922429
[ A1 Comms Ltd. Contract House, Turnpike Business Park, Alfreton, DE55 7AD ]

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender and delete the email. Any views or opinions presented in
this email are solely those of the author and do not necessarily
represent those of A1 Comms Ltd. Please check this email and any
attachments for the presence of viruses as we accept no liability for
any damage caused by any virus transmitted by this email. Registered
Company No. 04455131  VAT No. 282 8135 89

Regards,

Samuel Melrose

[ Senior Systems Engineer ]

Tel: +44 (0) 1332 922429




[ A1 Comms Ltd. Contract House, Turnpike Business Park, Alfreton, DE55 7AD ]



This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender and delete the email. Any views or opinions presented in
this email are solely those of the author and do not necessarily
represent those of A1 Comms Ltd. Please check this email and any
attachments for the presence of viruses as we accept no liability for
any damage caused by any virus transmitted by this email. Registered
Company No. 04455131  VAT No. 282 8135 89



On Wed, Dec 6, 2023 at 11:15 AM Jouni Malinen <j at w1.fi> wrote:
>
> [You don't often get email from j at w1.fi. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Wed, Dec 06, 2023 at 10:53:32AM +0000, Samuel Melrose wrote:
> > If I can manage to get a patch together, what is everyone's feelings
> > about being able to dynamically tune the EAP fragment_size setting,
> > based on hints from the server?
>
> Which fragment_size are you talking about here? The one in hostapd or
> the one in wpa_supplicant? And if the latter, how would a hint from the
> server make it to wpa_supplicant?
>
> > On the server side, we've got FreeRADIUS and we've been able to
> > configure it with a low EAP fragment_size value of 1012, however, it
> > isn't possible to configure this on the clients, as they are all
> > running Chrome OS (so using the Linux version of
> > wpa_supplicant/hostapd, but with a read only rootfs where it's
> > impossible to tune the configuration file) for both wireless
> > WPA2-Enterprise & 802.1X.
>
> Have you tested this with any other clients? Are there some client
> implementations that would actually dynamically change EAP-TLS
> fragmentation based on failures?
>
> > 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.
> >
> > My thoughts are accepting Framed-MTU from the server as part of the
> > Access-Challenge response, then tuning the EAP fragement_size based on
> > that (taking into account the additional overheads): would you be
> > willing to accept such a change?
>
> I'm not sure I can follow the design here.. Access-Challenge goes from
> the RADIUS server to the AP/RADIUS client. It does not go to the
> Supplicant/client/wpa_supplicant, so that use of Framed-MTU attribute on
> the client feels strange.
>
> If this network deployment scenario is such that the Supplicant/EAP
> client needs to somehow probe for the maximum EAP message length, things
> are quite inconvenient since there is not really any good way for doing
> that.. If the EAP exchange happens to have a large message from the
> server first (and EAP-TLS in many cases does), an EAP client might try
> to figure out that there was a reason for the server to use surprisingly
> small EAP message for fragmentation purposes and adopt to using a
> similar fragmentation threshold. This might need to be done separately
> for each EAP method, though.
>
> --
> Jouni Malinen                                            PGP id EFC895FA