RE: [eap] Ordered delivery of EAP messages

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Alper Yegin <mailto:alper.yegin@yegin.org> allegedly scribbled on
Tuesday, March 06, 2007 10:10 AM:

> The problem scenario requires EAP-layer retransmission, correct?

Yes, I suppose so.

> Authentication server does not perform such retransmission. 

From the Abstract to RFC 3748 "EAP provides its own support for
duplicate elimination and retransmission..."; the Authenticator is
responsible for all retransmission.

> So, I
> don't see equivalence between the two legs of the EAP transport. 

You are imagining that there are always 2 legs, which is not true; the
quoted portion of RFC 3748 does not state that assumption, either.  But
actually, you are right: it appears that RADIUS would generally be in
far greater peril of the risk then EAP, especially in a proxied network.

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