On 11/27/2013 07:01 PM, Johnson, Neil M wrote: > It does appear that there are issues cascading RADIATOR servers that are > all using <AuthBy EAPBALANCE> because the RADIUS "State" attribute used to > track the EAP conversations gets mangled as the message progresses through > the chain of servers.
Agreed. If State get mangled for one reason or the other there can be problems like Jethro is seeing. In addition to servers, it could also be clients that have problems handling State. Looking at the RFC, it also appears that multiple instances of State attribute in one message is not even supported. One possible scenario I jotted down is this: Neil's server responds with Access-Challenge with State. Jethro's server does the same. The client gets an Access-Challenge with two State attributes and responds with Access-Request containing just one State which has the value Neil's server set. This value is outside of what Jethro has (e.g., 3 while the possible values for Jethro's next hops are 0-2). Jethro's server then logs the error with empty information. I think the Radiator documentation needs to be augmented to say that State must be supported by all RADIUS clients and servers, and there must be just one server that adds State. This implies that EAPBALANCE within a single organisation should work because the behaviour there is known. Whereas using EAPBALANCE towards eduroam or other system can lead to problems because it is not known if there are devices that add extra State attributes while the others try to enforce the one State for a request rule. As a general case, it might be useful to consider if the eduroam docs should say something about State. If multiple servers on the roaming path depend on adding State, this is not supported by RFC and can cause problems. > To make things work with the US NTLRS servers they graciously stopped > using EAPBALANCE to load balance between our servers and moved to a > traditional primary/backup model, but obviously I can't ask everyone to do > that :-). > > The RADIATOR folks recommended I try HASHBALANCE instead, but I like the > extra assurance that EAP conversations don't get broken up. EAPBALANCE starts the same as HASHBALANCE. The first EAP request gets its next hop chosen by HASHBALANCE. This is by default Calling-Station-Id and User-Name. With EAPBALANCE the next hop gets fixed at this time and with HASHBALANCE it is calculated for the subsequent requests. I think HASHBALANCE should work fine too because Calling-Station-Id and User-Name should not be changing during the EAP authentication session. > I'm not exactly sure how to solve the issue. Would it be possible for > RADIATOR to treat the State attribute as a stack and "push" the Id onto > attribute and then "pop" it off as it goes back and forth through the > chain of servers? That could work as long as there is enough room to push before hitting the maximum length of value. If there is no room left, then things would get tricky (as if they already were not :). Thanks, Heikki -- Heikki Vatiainen <[email protected]> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
