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

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 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/>