Re-transmits arriving via a different proxy / EAP duplicate detection
All, Bit of an odd one here. Not sure where best to bring it up... if anyone has a more suitable discussion forum, please point me that way! As I iterate through our logging config, I'm gaining increasing visibility of all kinds of peculiar stuff. This one I spotted today - we are seeing remote RADIUS servers (eduroam visited sites) sending retransmits via different intermediate proxies. This goes wrong in two ways. First, the FreeRADIUS duplicate detect / retransmit logic doesn't apply because the source IP, shared secret, Proxy-State and Message-Authenticator are all different, even though all other attributes are identical. This is correct behaviour AFAICT from the RFCs. Second, because the retransmits aren't eaten by the duplicate detection, they arrive as real packets in the server core, but are rejected because the "State" attribute is no longer valid - this is because FR mutates "State" on every round-trip, mixing in the EAP type/id/exchange number. This latter (being reprocessed) is a problem two ways. The first is that these retransmits always generate a "reject" due to invalid "State". If the original "accept" was dropped (thereby causing the remote server to move to another intermediate proxy, and trigger this issue), we're effectively cancelling that "accept" and issuing a "reject". We're also generating a lot of logging and noise, though that's an internal problem. Does anyone have any thoughts on the matter? Absent RADIUS-over-TCP, this seems like a really tricky one... Cheers, Phil
Hi,
As I iterate through our logging config, I'm gaining increasing visibility of all kinds of peculiar stuff. This one I spotted today - we are seeing remote RADIUS servers (eduroam visited sites) sending retransmits via different intermediate proxies.
I've seen this a couple of times int he past - and recently too. the recent one was fixed by ensuring that the RADIUS server was listening only on a particular IPv6 address - by default it was binding to all available interfaces...and having 2 NICs, it has 2 IPv4 addresses and 2 IPv6 addresses... the IPv4 had been bound to just eth1 as reuqired...but the IPv6 hadnt.... thus, whilst the request was arriving at eth1, responses were going out via eth0
First, the FreeRADIUS duplicate detect / retransmit logic doesn't apply because the source IP, shared secret, Proxy-State and Message-Authenticator are all different, even though all other attributes are identical. This is correct behaviour AFAICT from the RFCs.
correct.....and the EAP session gets really broken
We're also generating a lot of logging and noise, though that's an internal problem.
thats a side effect of more 802.!x action - and one we too are dealing with locally (locally, a campus site deals with far more traffic than other systems that I deal with....the difference is that you have direct control over your NAS kit and local infrastructure and can fix things..). we've already gone through several iterations of optimising PGSQL, indexing, clearing and having 1st-line access what they need etc. doing dot1x/mab/webauth on switches just adds to the noise/mix. ...and the hundreds of misconfigured devices... certificate errors...TLS issues, wifi causing problems with failed EAP etc. alan
On 09/10/12 19:17, alan buxey wrote:
Hi,
As I iterate through our logging config, I'm gaining increasing visibility of all kinds of peculiar stuff. This one I spotted today - we are seeing remote RADIUS servers (eduroam visited sites) sending retransmits via different intermediate proxies.
I've seen this a couple of times int he past - and recently too. the recent one was fixed by ensuring that the RADIUS server was listening only
The pattern we see is quite odd. I suspect the core issue is being exacerbated by misbehaving clients or visited-site radius servers. The reason I suspect this is that, if it were genuine packet loss, you'd expect to see retransmits at all stages of the EAP session. But we almost exclusive see retransmits in response to a reject (very common) or an accept (rarely). In particular, there seem to be some sites where retransmits come in if we send a reject. I don't know if this is a particular supplicant or a particular radius server. Or maybe I'm mis-reading the evidence. But it does seem odd... I'm wondering whether to open a JRS support ticket or not (any suggestions ;o)
Phil Mayers wrote:
First, the FreeRADIUS duplicate detect / retransmit logic doesn't apply because the source IP, shared secret, Proxy-State and Message-Authenticator are all different, even though all other attributes are identical. This is correct behaviour AFAICT from the RFCs.
Second, because the retransmits aren't eaten by the duplicate detection, they arrive as real packets in the server core, but are rejected because the "State" attribute is no longer valid - this is because FR mutates "State" on every round-trip, mixing in the EAP type/id/exchange number.
There is a solution. But it involves new code.
Does anyone have any thoughts on the matter? Absent RADIUS-over-TCP, this seems like a really tricky one...
Nah. Create a new "state tracking" module. a) runs before sending reply, and caches State -> request/reply b) runs on receiving packet, and looks for duplicate state if found, and request looks similar, send duplicate reply That would bypass all of the EAP code, and add another layer of duplicate detection after the "packets are duplicate" code. There should really also be a state tracking API in the server core. Certain modules (i.e. securid) roll their own, and it's not overly efficient. Alan DeKok.
participants (3)
-
alan buxey -
Alan DeKok -
Phil Mayers