Subject: [Fwd: [eap] Re: preserving packet order in EAP]

From: Subir Das <[email-masked]>
Date: Mon, 20 Jan 2003 17:53:21 -0500

-------- Original Message --------
Subject: [eap] Re: preserving packet order in EAP
Date: Mon, 20 Jan 2003 12:46:19 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
CC: [email-masked]

On Monday, January 20, 2003 Dan Forsberg wrote:

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

Those transports are illegal, because they don't preserve order,
correct.

> TCP/SCTP would be another option to carry EAP, but EAP detects
> duplicates and does re-transmissions already.

Yes, those transports would be fine, providing that they provide the
appropriate security -- namely per-packet integrity and authentication.

> Another comment/question:
> Isn't EAP request-response style protocol, so what are the
> possibilites/consequences for packet order mismatch?

The issue comes up since RFC 2284 doesn't require the Identifier space
to
be monotonically increasing. That means that if a Request packet with ID
1
were retransmitted, and arrived *after* a Request packet with ID 2, it
could be erroneously thought by the peer to represent a new Request,
rather than a retransmission.

> 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 would be incompatible with existing implementations, would
impact re-authentication and would enable new DoS attacks.

> Another solution to this problem is to prohibit simultaneous *same type* of
> authentications.

Again, that is incompatible with existing implementations, which can
authenticate multiple users at a time.

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