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 <h...@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. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
