Issues & Fixes: Ordered delivery of EAP messages

>I've recently been reminded that I can be a bit too
terse at times; it 
>appears that this is one of >those times.  I blame MO
. 
Anyway, part of 
>RFC 3748 that I quoted says
>
>        Encapsulation of EAP within RADIUS [RFC3579]
>        satisfies ordering requirements, since RADIUS is
a "lockstep"
>        protocol that delivers packets in order.
>
>There are a couple of problems with this statement that
I think are 
>pertinent to the question at >hand...

Given the discussion, it would appear to me that RADIUS does
provide for 
ordering and non-duplicate delivery of EAP packets, although
the "lockstep" 
aspect is not as important as the following statement from
RFC 2865, Section 
3:

"The RADIUS server can detect a duplicate request if it
has the same client 
source IP address and source UDP port and Identifier within
a short span of 
time."

Therefore, assuming that the replay window is large enough
in proportion to 
the RTT, and the NAS RTO estimate is in the ballpark and
being backed off, 
then it seems like the problem is covered.

Or am I missing something?


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

Bernard Aboba <mailto:bernard_abobahotmail.com> allegedly
scribbled on
Tuesday, March 06, 2007 9:10 PM:

>> I've recently been reminded that I can be a bit too
terse at times;
>> it appears that this is one of >those times.  I
blame MO . 
>> Anyway, part of RFC 3748 that I quoted says
>> 
>>        Encapsulation of EAP within RADIUS
[RFC3579]
>>        satisfies ordering requirements, since
RADIUS is a "lockstep"
>>        protocol that delivers packets in order.
>> 
>> There are a couple of problems with this statement
that I think are
>> pertinent to the question at >hand...
> 
> Given the discussion, it would appear to me that RADIUS
does provide
> for ordering and non-duplicate delivery of EAP packets,


Ordered delivery & duplicate rejection aren't the same
thing.  

> although the
> "lockstep"  
> aspect is not as important as the following statement
from RFC 2865,
> Section 3:
> 
> "The RADIUS server can detect a duplicate request
if it has the same
> client source IP address and source UDP port and
Identifier within a
> short span of time."  
> 
> Therefore, assuming that the replay window is large
enough in
> proportion to the RTT, and the NAS RTO estimate is in
the ballpark
> and being backed off, then it seems like the problem is
covered.  
> 
> Or am I missing something?

Suppose that the conditions you specify are met for the EAP
peer and
authenticator, as well.  Does that solve the problem?
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap