Subject: [eap] preserving packet order in EAP?

From: [email-masked] ([email-masked])
Date: Mon, 20 Jan 2003 18:13:45 +0200

One possible solution for this problem is to require the Authenticatee to remember the ID numbers inside the EAP method (message id's between the initial request and  Success/Failure msgs). This would imply that no EAP method should produce more than 256 requests per authentication.

Another solution to this problem is to prohibit simultaneous *same type* of authentications. Currently in the -10 spec:

"Once a peer has sent a Response of the same Type as a Request, some
existing peer implementations might expect the method to run to
completion. As a result, these implementations silently discard EAP
Requests of a Type different from the method in progress, despite the
requirement for a Response in section 2.2.1. For this reason, EAP
authenticators that must interoperate with these peers are discouraged
from switching methods before the final round of a given method has
completed."

I couldn't find section 2.2.1?

So, the Authenticatee could drop the duplicate request (1) because it would restart the authentication method and thus the "first" method would not "run to completion".

Anyway, I think this should be fixed in the EAP protocol simply because it is standardized here in the IETF. A new issue perhaps? EAP already provides retransmission and "duplicate" detection. Making the duplicate detection work within this example, would make EAP suitable for carriers such as UDP, ICMP, and IP. This would increase the possibilities for EAP in the Internet.

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

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 20 January, 2003 16:17
> To: Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [eap] preserving packet order in EAP?
>
>
> 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:
> > 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
> > _______________________________________________
> > eap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/eap
> >
>

---

From: [email-masked] (James Carlson)
Date: Thu, 23 Jan 2003 08:09:26 -0500

[email-masked] writes:
> One possible solution for this problem is to require the
> Authenticatee to remember the ID numbers inside the EAP method
> (message id's between the initial request and  Success/Failure
> msgs). This would imply that no EAP method should produce more than
> 256 requests per authentication.

That doesn't work because of rechallenge.  (Well, unless you're
willing to drop the link when you run out of ID space for rechallenges
...)

> Anyway, I think this should be fixed in the EAP protocol simply
> because it is standardized here in the IETF. A new issue perhaps?
> EAP already provides retransmission and "duplicate"
> detection. Making the duplicate detection work within this example,
> would make EAP suitable for carriers such as UDP, ICMP, and IP. This
> would increase the possibilities for EAP in the Internet.

EAP has no problem with retransmission or duplicates (or other bad
packets, for that matter).  It does have a problem with reordering,
and that can't actually be fixed without making the "new" version
incompatible with the old.  If you're going to make it incompatible,
I'd suggest starting with a blank slate.

EAP just wasn't designed to be used as you suggest.  It needs an
order-preserving peer-to-peer link.

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