Re: Ordered delivery of EAP messages

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.


>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-pa
na-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


____________________________________________________________
_____
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 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-pa
na-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
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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