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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
