Subject: [eap] Proposed Resolution of Issue 188: Packet ordering

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Oct 2003 19:18:20 -0800 (PST)

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: [email-masked]
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?

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 28 Oct 2003 13:36:37 +0200

Looks OK. Thanks.

--Jari

---

From: Lauri Tarkkala <[email-masked]>
Date: Wed, 29 Oct 2003 19:05:43 +0200

> to make this more explicit and explain what "/IP" means

Am I missing something here, but the bis specification
is currently stating that EAP is a lock-step protocol.

In this case, assuming nobody is doing optimizations
based on predicting peer responses, there should
be no need for an ordering guarantee. 

That said, requiring that the lower layer provides
an ordering guarantee is a good idea considering the
heritage of EAP. I do not however see this as much
of an issue for new (or upto-date) implementations,
which we would be talking about here.

Lauri

-- 
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap