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
