[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: Question on client retransmit behavior
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2024-04-25 22:17:28
Message-ID: 089DDFB5-D93A-4D0A-A2C7-41B668508C51 () deployingradius ! com
[Download RAW message or body]

On Apr 25, 2024, at 5:41 PM, Brian Julin <BJulin@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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]