|
RFC 3748, section 3.1 says
[6] Ordering guarantees. EAP does not require the Identifier to be
monotonically increasing, and so is reliant on lower layer
ordering guarantees for correct operation. 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."
Lower layer transports for EAP MUST preserve ordering between a
source and destination at a given priority level (the ordering
guarantee provided by [IEEE-802]).
Reordering, if it occurs, will typically result in an EAP
authentication failure, causing EAP authentication to be re-run.
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.
My question is, since EAP is also a lockstep protocol, under what conditions could EAP messages be delivered out of order, regardless of lower layer behavior WRT in-order delivery?
|
Back then (October 2003), I wrote:
Lower layer ordering guarantees are needed because the
Identifier
field is not required to be ordered. If messages can be
reordered,
the peer can't necessarily distinguish a new EAP Request
from a
reordered retransmission of an old request.
See