[RADIATOR] Missing info from error message

[Heikki Vatiainen]

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 <hvn at open.com.au>

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.