Subject: preserving packet order in EAP?

From: <[email-masked]>
Date: Mon, 20 Jan 2003 11:36:59 +0200

Hi,

EAP requires that packet order is maintained by the lower layer. My concern is that EAP can't be carried by UDP or IP alone, because these protocols do not preserve the packet order? This becomes an issue in the PANA wg. TCP/SCTP would be another option to carry EAP, but EAP detects duplicates and does re-transmissions already. Another comment/question: Isn't EAP request-response style protocol, so what are the possibilites/consequences for packet order mismatch?

- Dan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 20 Jan 2003 09:17:14 -0500

Dan,

Let me attach James Carlson's email which contains a good example for
why packet order for EAP must be maintained by the lower layer.

Yoshihiro Ohba

On Mon, Jan 20, 2003 at 11:36:59AM +0200, [email-masked] wrote:
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 

Subject: Re: [eap] Strawman rewrite of Section 4.1
From: James Carlson <[email-masked]>
To: Nick Petroni <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 6 Jan 2003 11:03:31 -0500
List-Id: Discussion list for EAP <eap.frascone.com>

Nick Petroni writes:
> > > In that case, how will the peer know which track the
> > > conversation is following since the original requests could have arrived
> > > out of order?
> >
> > EAP was originally defined to run on PPP and RFC 1661 has the
> > necessary ordering requirement:
> Originally, yes. But, 2284bis extends the applicability of EAP. From
> section 3 of 2284bis:
> [4]  Possible reordering. EAP provides its own mechanisms to detect
>      reordering and so does not assume that the lower layer provides
>      ordering guarantees.

This part is false.  EAP as defined in the draft simply cannot detect
all possible cases of reordering.  Consider the following case:

	Authenticator		Authenticatee
	Request ID=1 >--------> (got req 1)
                          ----< Response ID=1
	(timeout)        /
	Request ID=1 >--/
	               /\
	(got resp 1) <-  |
	Request ID=2 >--------> (got req 2)
	                 |  --< Response ID=2
	                 | /
	(got resp 2) <-----
	                  \
	                   ---> (got req 1)
	(disc bad id) <-------< Response ID=1

At this point, the session is completely scrazzled.  Authenticatee is
unable to tell that the second "Request ID=1" message it got was
actually just a retransmission, so it must treat it as a new Request,
and must reinvoke whatever process was used to generate the Response.
Besides being just wasteful, this also means that (1) any saved state
on the Authenticatee side (e.g., values used to compute shared keys)
is now trashed and (2) the actual Response data may differ from the
original Response data, leading to chaos.

EAP as currently defined can't do what you want here.  If the RFC had
defined a sequence space with a "less than" comparison operation, then
you could probably do it, but that's no longer the same as RFC 2284
EAP.

> 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.

That's not compatible with 2284, which has no such restriction.

> > All that any EAP authenticatee has to do is to respond to the Request
> > messages that come in.  It doesn't have to "track" any conversations.
> Methods may rely on messages being presented to them in a certain order,
> if EAP does not guarantee this order much more work needs to be put into
> method design. I don't think the case can be made that EAP just shouldn't
> be run over out-of-order protocols.

Really?  Why not?  That was the original intent of RFC 2284.  It was
modeled on PPP negotiation, and PPP negotiation most explicitly does
*not* survive out-of-order delivery.  If there's some transport being
planned for EAP that does present the possibility of out-of-order
delivery, then I think that probably needs a little more careful
examination.

> Perhaps method designers can weigh-in
> on this a little, but I would think problems do arise without in-order
> presentation.

Those problems certainly do arise.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap