Re: Ordered delivery of EAP messages

>Assuming that per session there can only be one
outstanding request for an 
>EAP conversation >since the conversation depends on
acks from its peer to 
>continue.

ACK/NAK protocols can have more than one packet in flight,
if you take false 
retransmissions into account.

>Then if new messages and retries are sent out in any
order on the wire they 
>would either be detected by either side as duplicates or
processed and 
>handled accordingly regardless of order of receipt.

Both EAP and RADIUS do not detect duplicates arriving out of
order; they 
depend on the underlying lower layer to provide in-order
delivery so as to 
enable duplicate detection.


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

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

On Tue, 6 Mar 2007, Bernard Aboba wrote:

>> Assuming that per session there can only be one
outstanding request for an
>> EAP conversation >since the conversation depends
on acks from its peer to
>> continue.

> ACK/NAK protocols can have more than one packet in
flight, if you take false
> retransmissions into account.

>> Then if new messages and retries are sent out in
any order on the wire they
>> would either be detected by either side as
duplicates or processed and
>> handled accordingly regardless of order of
receipt.

> Both EAP and RADIUS do not detect duplicates arriving
out of order; they
> depend on the underlying lower layer to provide
in-order delivery so as to
> enable duplicate detection.

A RADIUS server can detect a packet it has already responded
to and 
respond if it wishes with a stored response.

A false retranmission by a NAS is detectable by the RADIUS
server.

The difference between request and packet is significant in
this context.

What I'm saying is in any given RADIUS+EAP exchange there is
head-of-line 
condition that prevents two or more unacknowledge requests
or responses 
that are *not detectable* by the RADIUS server.  At any
given instant one 
or more duplicates may already be known to the RADIUS server
and buzzing 
around the wires however only exactly zero or one new
requests can be 
outstanding (not known to the RADIUS server)

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

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

> Both EAP and RADIUS do not detect duplicates arriving
out of order; they
> depend on the underlying lower layer to provide
in-order delivery so as to
> enable duplicate detection.

RFC 2865 says:

      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.

This, to me, implies duplicate detection on the server side
does not rely on
orderly delivery. Keeping the history for "a short span
of time" allows
duplicate detection irrespective of the order the requests
come in.

As for the responses... Assuming the RADIUS client
transmitted a request
twice (first one timed out), if it receives one of the
responses, would it
still accept the second (duplicate) response if it arrives
as well? Wouldn't
the RADIUS client just drop the second response because
there is no
outstanding request to match anymore?


Alper




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

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

Alper Yegin <> allegedly scribbled on Tuesday, March
06, 2007 3:25 PM:

>> Both EAP and RADIUS do not detect duplicates
arriving out of order;
>> they depend on the underlying lower layer to
provide in-order
>> delivery so as to enable duplicate detection.
> 
> RFC 2865 says:
> 
>       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.
> 
> This, to me, implies duplicate detection on the server
side does not
> rely on orderly delivery. Keeping the history for
"a short span of
> time" allows duplicate detection irrespective of
the order the
> requests come in.   

Agree.

> 
> As for the responses... Assuming the RADIUS client
transmitted a
> request twice (first one timed out), if it receives one
of the
> responses, would it still accept the second (duplicate)
response if
> it arrives as well? Wouldn't the RADIUS client just
drop the second
> response because there is no outstanding request to
match anymore?  

Seems reasonable.  So why wouldn't this reasoning apply to
EAP as well?
  
> 
> 
> Alper
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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