Subject: [eap] Issue 60: Ordering guarantees

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 12:27:36 -0800 (PST)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 7, 2003
Document: RFC2284bis-08
Comment type: T
Priority: S
Section: 3.1
Rationale/Explanation of issue:

As noted by James Carlson, there is an implicit ordering requirement in
EAP due to its PPP heritage. This is not recognized in the current draft.

Change Section 3.1 from:

"[4]  Possible reordering. EAP provides its own mechanisms to detect
     reordering and so does not assume that the lower layer provides
     ordering guarantees. EAP is a "lockstep" protocol, so that the
     Authenticator MUST NOT send a new Request until a Response is
     received to an outstanding Request. Since the Peer should not
     expect a new Request until it has sent a Response, if it receives a
     new Request with a different Identifier before sending a Response
     to the outstanding Request, the new Request MUST be silently
     discarded. Similarly, if the Authenticator receives a Response with
     an Identifier that does not match the Identifier in the outstanding
     Request, the Response MUST be silently discarded."

To:

"Ordering guarantees. EAP was originally defined to run on PPP and
[RFC1661] Section 1 has an ordering requirement:

"The Point-to-Point Protocol is designed for simple links which
transport packets between two peers. These links provide full-duplex
simultaneous bi-directional operation, and are assumed to deliver
packets in order."

As a result, any other lower lower transport for EAP MUST preserve
ordering between a source and destination, at a given priority
level (the ordering guarantee provided by IEEE 802)."