eap Mailing List: Re: Ordered delivery of EAP messages

[Glen Zorn (gwz) (gwz]

Bernard Aboba <mailto:bernard_aboba [at] hotmail.com> allegedly scribbled on 
Tuesday, March 06, 2007 5:27 AM:

> The primary situation is one where the RTO maintained by the
> authenticator is under-estimated, and an EAP-Request has been
> retransmitted.  
> 
> In this situation, an EAP-Response could arrive in response to a
> previous 
> EAP-Request (e.g. a false retransmission occurred).   The
> authenticator will 
> move on, choosing a new Identifier for the next EAP-Request.  This
> leaves two EAP-Requests in flight, and they could conceivably cross
> paths.  
> 
> If the new EAP-Request arrives before the retransmitted one, when the
> retransmitted EAP-Request finally arrives, it will be taken as a new
> EAP-Request, which could disrupt the authentication in progress. 

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.  First, RADIUS is a "lockstep" protocol in almost (if 
not exactly) the same way that EAP is: the semantics of the Identifier field in 
the header of RADIUS messages are identical to that of the EAP version (RFC 
2865 only says that the Identifier must change on new requests, not how it must 
change -- in particular, monotonicity is not assured) and requests are 
retransmitted.  The other problem is that neither RADIUS nor the underlying UDP 
transport guarantees in-order delivery of packets.  So, I would claim that this 
sentence is completely false and, given that, the rest of the preceding 
argument vis-à-vis the ordered delivery of EAP packets is rendered of 
theoretical interest at best since there is a certain amount of empirical 
evidence that both RADIUS and EAPoRADIUS work, despite all.

> 
> 
>> Glen Zorn wrote:
>> 
>>> My question is, since EAP is also a lockstep protocol, under what
>>> conditions could EAP messages be delivered out of order, regardless
>>> of lower layer behavior WRT in-order delivery?
>> 
>> This was discussed as part of issue 188 a very long time ago :) Back
>> then (October 2003), I wrote: 
>> 
>>   Lower layer ordering guarantees are needed because the Identifier
>>   field is not required to be ordered. If messages can be reordered,
>>   the peer can't necessarily distinguish a new EAP Request from a
>>   reordered retransmission of an old request.
>> 
>>   See
>>   http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-02.txt,
>> Appendix A for a concrete example. 
>> 
>> Best regards,
>> Pasi
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/eap
>> 
>> Arhives: http://lists.frascone.com/pipermail/eap