Subject: [eap] Re: EAP packet processing

From: [email-masked] (Bernard Aboba)
Date: Fri, 20 Dec 2002 10:10:54 -0800 (PST)

> EAP SIM and EAP AKA are examples of methods that can silently
> discard EAP packets based on an incorrect ICV.

I presume they do silent discard in this case, not terminating the method,
correct?

> This could also
> happen in EAP SIM, where ICV can only be included once
> keys have been derived, so in the very first packets there
> is no ICV.

This is generally true. If the initial packets are spoofed, typically
the ICV will fail later on - but this could take another roundtrip to be
discovered. The way to fix this is for the method to incorporate some DoS
resistance -- such as cookie state. Forking seems complicated.

> Based on these examples, I'm inclined to think that the
> EAP layer should simply pass all EAP packets of a certain
> type to the appropriate method, and let the method
> decide how to process the packets.

To some extent, EAP methods have to be prepared to handle duplicates
anyway. For example a NAS can timeout and send another Request before
receiving the first Response in flight, and as a result, the AAA server
may get multiple Responses. I believe that these will typically be passed
up to the EAP method.

Yet RFC 2284 does seem to mandate other checks, such
as requiring Responses to have the same Identifier as Requests. Where are
these checks supposed to be done? In the method? In the EAP layer?

The question is really whether EAP methods are expecting to run over a
reliable, sequenced transport, or not.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Fri, 20 Dec 2002 22:15:35 -0500

> may get multiple Responses. I believe that these will typically be passed

That, I believe depends on how the EAP switch state machine is
designed.  I think it is possible to design the EAP switch state
machine similar to TCP so that duplicate responses are not passed up
to the application (i.e., the EAP method).

> reliable, sequenced transport, or not.

If EAP methods can expect the EAP switch to provide a reliable,
sequenced transport, that would be fine because total implementation
cost can be reduced in that each method does not have to provide
retransmission and duplicate detection, even the implementation cost
for EAP switch state machine would increase.

There are some Request messages that might require retransmission from
the method (not from the EAP switch) if the Response requires human
intervention (e.g., username, password input) as described in
RFC2284bis, but different Identifier values can be used for such
retransmission and the EAP switch would view them different Requests.
But more investigation might be needed.

Regarding the issue of ICV error, I think how to react when ICV error
occurs (e.g., discard the message or terminate the method) depends on
the method, and thus defining ICV error event in the EAP switch state
machine does not make sence to me.

Yoshihiro Ohba