Re: Ordered delivery of EAP messages
From: Bernard Aboba (bernard_abobahotmail.com)
Date: Thu, 8 Mar 2007 14:46:40 -0800 (PST)
Alper Yegin said:

"EAP gets confused if it ever receives packets out of order.

Given that EAP is a lock-step protocol, any one of the three remedies is
sufficient to ensure packets never get out of order:

1-  EAP lower layer ensures ordering
2a- EAP lower layer eliminates duplicates
2b- EAP eliminates duplicates

Having more than one of the remedies is not necessary.

Correct?"

[BA] Yes.

"RADIUS does not talk about 1, does not properly mandate 2a...
If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile, can we
assume all of the current RADIUS implementations are already supporting 2a,
so that in the absence of 1 and 2b EAP works well?"

[BA] Yes, I think we can assume this. Alan's proposed language will mandate 2a.

Glen Zorn said:

"The arguments have been that 'well-behaved' RADIUS implementations
exhibit what amounts to in-order delivery despite the fact that
it is not required by the RFCs..."

[BA] As Alan DeKok noted, most currently shipping RADIUS products
are well-behaved.  As a result, he has proposed text to make
this a MUST.  That should cover the issue.

"My basic argument is that EAP _does_ work over a transport that doesn't
guarantee in-order delivery (the example being RADIUS) except in a deep,
dark, cobweb-filled corner case."

[BA] Wasn't the conclusion that RADIUS without duplicate detection
could reorder EAP packets, causing authentication failures?

Yoshi Ohba said:

This is what I don't understand.  Correctness and security are two
separate things.

I can show you a typical example, TLS.  TLS requires reliable
transport for its correct operation.  Without use of reliable
transport, TLS session will be immediately shutdown when a packet is
lost, but it is still secure.  This does not mean that TLS requires
reliable transport for its secure operation.

Note that DTLS does not require reliable transport, because it
modifies TLS to correcly work over unreliable transport.

For the same reason, if we want to remove the orderly delivery
requirement from EAP, we would need to modify EAP to correctly work
with non-orderly delivery.


Results generated by Tiger Technologies using MHonArc.