eap Mailing List: Proposed Resolution of Issue 188: Packet ordering

[Bernard Aboba (aboba]

The text of Issue 188 is enclosed below.   The proposed fix is as follows:

Add to Section 3.1, at the end of item [6]:

Reordering, if it occurs, will typically result in an EAP
authentication failure, causing EAP authentication to be
rerun. In an environment in which reordering is likely,
it is therefore expected that EAP authentication failures
will be common. It is RECOMMENDED that EAP only be run
over lower layers that provide ordering guarantees;
running EAP over raw IP or UDP transport is NOT
RECOMMENDED. Encapsulation of EAP within RADIUS
[RFC3579] satisfies ordering requirements, since
RADIUS is a "lockstep" protocol that delivers
packets in order.
----------------------------------------------------------
Issue 188: Packet Ordering
Submitter name: Margaret Wasserman
Submitter email address: Margaret.Wasserman [at] nokia.com
Date first submitted: October 23, 2003
Reference:
Document: RFC 2284bis-06
Comment type: T
Priority: S
Section: 2.3
Rationale/Explanation of issue:

Is the current wording/diagram in the document clear
enough with respect to the need for IP-based
transports to include a mechanism to ensure packet order?
Or do you think that we should add a couple of sentences
to make this more explicit and explain what "/IP" means
in Figure 2?