Subject: [eap] Another shot at resolving Issue 83: Invalid Packet handling

From: [email-masked] (Bernard Aboba)
Date: Mon, 7 Apr 2003 23:36:12 -0700 (PDT)

Issue 83 dealt with how to allow a RADIUS authentication server to
silently discard an invalid EAP packet. The current text of Section 2.2
can be found in draft-aboba-radius-rfc2869bis-12.txt.

Here is an alternative resolution that avoids allocation of an additional
Service-Type value, and also is less likely to result in a timeout
on legacy NASes. Complete text is available at:

http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-13.txt

Comments welcome.

------------------------------------------------------------------------
2.2.  Invalid packets

While acting as a pass-through, the NAS MUST validate the EAP header
fields (Code, Identifier, Length) prior to forwarding an EAP packet to
the RADIUS server. However, since EAP method fields (Type, Type-Data)
are typically not validated by a NAS operating as a pass-through, it is
possible for a NAS to forward an invalid EAP packet to the RADIUS
server.

A RADIUS server receiving EAP-Message attribute(s) it does not
understand SHOULD make the determination of whether the error is fatal
or non-fatal based on the EAP Type. A RADIUS server determining that a
fatal error has occurred MUST send an Access-Reject containing an EAP-
Message attribute encapsulating EAP-Failure.

In order for the RADIUS server to communicate to the NAS that an invalid
EAP packet has been forwarded to it, but that the error is non-fatal,
the RADIUS server MAY send an Access-Challenge encapsulating the last
EAP-Request with an unchanged Identifier value, within EAP-Message
attribute(s), along with an Error-Cause attribute (defined in [DynAuth])
of value 202, "Invalid EAP Packet (Ignored)".  On receiving this
message, a legacy NAS will decapsulate the EAP-Request and send it to
the EAP peer.  This will result in the EAP peer retransmitting the EAP-
Response.

A NAS compliant with this specification, on receiving an Access-
Challenge with an Error-Cause attribute containing a value of "Invalid
EAP Packet (Ignored)" SHOULD discard the current EAP-Response packet,
and check whether additional EAP-Response packets have been received
with an Identifier matching that of the last Request. If so, a new EAP-
Response packet, if available, MUST be sent to the RADIUS server within
an Access-Request.  If no EAP-Response packet is available, then the
encapsulated EAP-Request is sent to the EAP peer, and the retransmission
timer is reset.  Once the RADIUS server responds with a packet containing
a non-null EAP-Message attribute, the NAS updates the Identifier value,
and any pending Responses that do not match this value can be discarded.

In order to provide protection against Denial of Service (DoS) attacks,
it is advisable for the NAS to allocate a finite buffer for Responses,
and to discard packets according to an appropriate policy once that
buffer has been exceeded. Also, the RADIUS server is advised to support
only a modest number of invalid EAP packets within a single session,
prior to terminating the session with an Access-Reject.