[RADIATOR] duplicate EAP Responses

[Heikki Vatiainen]

On 1.12.2015 0.28, David Zych wrote:

> Perhaps you meant rfc3748?

Yes. The other RFC number I referenced below was incorrect too.

> I do see a couple of very specific discard
> situations in rfc3748#section-4.1, but I wouldn't describe it as "many
> cases" or an overall pattern; in fact I would argue that in general this
> section does *not* encourage discards

That section has most of the cases in that RFC that talk about 
discarding messages. This is why I wrote that the decision to drop the 
request might be based on the above section.

However, I do not mean that this decision can not or should not be 
revised. Instead of discarding, as eap_error currently does by default, 
reject, or some other response, looks like a better choice.

Discarding with IGNORE can be a good choice when, for example, the 
connection to the backend SQL DB is down. This allows the NAS to switch 
to the secondary server that hopefully has better DB connectivity.

> I can certainly see justification here for implementing a behavior of
> IGNORE, and an EAPErrorReject option to REJECT instead, for those two
> specific circumstances (i.e. wrong Length field or unacceptable Type
> field), but I don't think it's appropriate to generalize this behavior
> to "If an EAP error occurs" (the current language in section 5.21.72 of
> the Radiator manual).

I agree that the language in the manual generalises too much. It's also 
not accurate: Using PEAP as an example, reject is usually returned when 
something goes wrong. It's good that you brought up this behaviour so 
that it can be improved on (and ref.pdf fixed).

> I see a number of calls to $self->eap_error in the various EAP_*
> modules; AFAICT all of these will return IGNORE unless EAPErrorReject is
> configured.

Yes, I also noticed those. Fortunately the more widely used PEAP, 
EAP-TLS and EAP-TTLS use it sparingly. We'll take a look at them.

> a. RADIUS sends EAP Request 5 to NAS
> b. NAS sends EAP Request 5 to peer
> c. NAS retransmits EAP Request 5 to peer
> d. peer sends first EAP Response 5
> e. NAS sends first EAP Response 5 to RADIUS
> f. peer sends second EAP Response 5
> g. NAS sends second EAP Response 5 to RADIUS
> h. RADIUS processes first EAP Response 5, replies with EAP Request 6
> i. NAS sends EAP Request 6 to peer
> j. RADIUS processes second EAP Response 5, ???

Thanks for RFC quotes. An option could be to change the current 
eap_error behaviour to step j below. If configured with EAPErrorReject, 
then it could send a reject in case a reject works better with some NASes.

Both options will keep the NAS informed that the server is still 
responding. RFC 3579 compliant NAS might be able to additionally help 
with the recovery to get the dialog back to the correct track.

> j. RADIUS processes second EAP Response 5, replies with same identical
> EAP Request 6 from step h, plus Error-Cause = 202 Invalid EAP Packet
> (Ignored).
> k. NAS sends EAP Request 6 to peer
> l. peer sends EAP Response 6
> m. NAS sends EAP Response 6 to RADIUS
> n. RADIUS processes EAP Response 6, replies with EAP Request 7
> ...
>
> Note: of course, we might now end up getting two copies of EAP Response
> 6 (since the NAS has sent two copies of EAP Request 6 in steps i and k),
> though if we're lucky, NAS won't receive a second EAP Response 6 from
> peer until *after* receiving EAP Request 7 (step m), in which case NAS
> will discard the second Response 6 (non-matching identifier) and we're
> back to normal.  Even if we do have to deal with lock-step duplicates
> for the rest of the conversation, though, it still seems better to move
> forward and complete the authentication rather than having to start over
> from the very beginning.

And in any case all authentications from the NAS would continue to work 
since the NAS doesn't have to consider if the server is dead or 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.