eap Mailing List: Re: Issues & Fixes: Ordered delivery of EAP messages

[Glen Zorn (gwz) (gwz]

Bernard Aboba <mailto:bernard_aboba [at] hotmail.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?