[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [eap] Ordered delivery of EAP messages



The problem scenario requires EAP-layer retransmission, correct?
Authentication server does not perform such retransmission. So, I don't see
equivalence between the two legs of the EAP transport.

Alper

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Tuesday, March 06, 2007 4:35 PM
> To: gwz@cisco.com; Pasi.Eronen@nokia.com; eap@frascone.com
> Cc: radiusext@ops.ietf.org
> Subject: Re: [eap] Ordered delivery of EAP messages
> 
> Glen Zorn said:
> 
> "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."
> 
> I think you are correct.  If the RADIUS retransmission timer were
> under-estimated, RADIUS can deliver EAP messages out of order.  That is,
> the
>   NAS could retransmit an Access-Request, and then could receive an
> Access-Challenge in response to an earlier Access-Request.  The NAS would
> then send a new Access-Request, which could cross paths with the
> retransmitted one.
> 
> Note that if an Event-Timestamp attribute were to be included in the
> RADIUS
> Access-Request, then the Identifier would change on the retransmitted
> Access-Request.  The NAS would then be able to determine that a False
> Retransmission (FRTO) had occurred.  But from the point of view of the
> RADIUS server, I don't think it matters, since it won't be checking that
> the
> Event-Timestamp attribute is monotonically increasing.
> 
> 
> _________________________________________________________________
> 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 send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>