Re-transmits arriving via a different proxy / EAP duplicate detection

[Phil Mayers]

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