Question on client retransmit behavior

[Alan DeKok]

On Apr 25, 2024, at 5:41 PM, Brian Julin <BJulin at clarku.edu> wrote:
> So an EAP 802.1x supplicant can do one of the following if it receives no response from the NAS:
> 
> 1) Restart EAP from the top.
> 2) Retransmit packets from the ongoing EAP session.
> 3) Just wait and maybe the NAS retransmits for it.
> 4) (Hopefully not) have a really old proxy in the chain that does retransmits for the NAS/client.

  I've also seen:

  (5) retransmit aggressively 100-1000 times a second.  :(

> If anyone has had the time to go down this rabbithole, is there any uniformity of client behavior here?

  IEEE 802.1X defines how all of this should work.  I admit I haven't looked at that in detail in a while.

> That's really all I want to know... just trying to figure out if turning off NAS-initiiated retransmits is a wise move.

  IEEE STD 802.1X-2020 says in part:

		• The higher layer is responsible for re-transmission within a single authentication attempt, and should protect communication with the Authentication Server with retransmissions appropriate to the transport use.

  and

	Correct protocol operation depends upon the use of timer values by the Supplicant higher layer functions that are compatible with those used by the Authenticator’s higher layer functions to retransmit EAP-Requests. There is no automatic means of communicating changes in timer values between Authenticator and Supplicant, so deviation from the default timer values can adversely affect the operation of the protocol.

  Where "authenticator" is the NAS.

  So perhaps it's the responsibility of the NAS to do retransmissions.

> But, if you'd like to hear a scary story, pull up a chair,  I am glad to oblige:
> 
> Lately we've had quite a few eduroam guest clients show up sending to lame servers that do not respond.
> 
> Also, lately, supplicants have seem to have been getting quite aggressive at re-launching frequent authentication attempts after failures.

  IEEE 802.1X also requires that systems send only a small number of packets per second.

> ...the NAS declares our proxy dead.
> 
> It then rolls over to another proxy, and declares it dead as well, if it happens again.
> 
> Despite all that is evident to the naked eye, this NAS does not believe in zombies. 

  <sigh>

  There's also issues with the RADIUS protocol.  When upstream proxies fail, there's no way to return a "reroute this packet" message.  Instead, the packet is dropped. And the NAS has no idea if it's server is down.

  It's really quite terrible.  We're looking at fixing this in the updated RFCs, but it is likely to require TLS.

> So... it won't retry any of the dead servers until a generous timeout goes by.
> 
> Oh yeah, and no Status-Server support.

  It's only been published for a decade.  Why would people implement it?

> Our front-end proxy is a FreeRADIUS server.  This then proxies to... a haunted old house owned by a mysterious vendor. 
> 
> Which... retransmits proxied requests.  Yes.  That old.
> 
> There appears (sigh) to be no way to turn this behavior off.  It also has a maximum 5 second timeout between retransmits, and though it will respond to Status-Server requests, it will not send them to upstream proxies.

  That part is at least fine: not proxying Status-Server.

> Anyway, thank you for patronizing our hanted-house ride.  Remember to collect your belongings as you leave the carts and... try to get a good night's sleep.

  RADIUS isn't a house of cards.  It's a haunted house of brain-eating zombies.  The fact that it works at all is a bit of a miracle.

  There's no real solution here other than faking rejected for the bad users.  A longer term fix is people upgrading their NASes for modern protocol support.  But that might take years,

  Alan DeKok.