Thanks for the feedback @Jouni Malinen and @Alan DeKok As much as I feel like some automatic compensation for low MTU would be useful in more than just our environment, I accept that your concerns regarding how it might affect existing behaviour are well grounded & that our environment is the perfect storm for exposing the issue & not being able to mitigate it with client side configuration. Alan, on your suggestion, we decided to mitigate with RadSec - neither our APs (UniFi) or switches (Cisco 2960X) supported RadSec natively, but I managed to implement a UDP -> RadSec gateway in Go that it is possible to run on our pfSense firewalls at each local site. On testing, speaking UDP within the local network is fine & converting to TCP with RadSec before the MTU restriction has resolved the issue. I wouldn't have been able to come to that resolution without you, so thank you very much! 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 5:54 PM Jouni Malinen <j@xxxxx> wrote: > > [You don't often get email from j@xxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
