| Re: Ordered delivery of EAP messages | <– Date –> <– Thread –> |
|
From: Alper Yegin (alper.yegin |
|
| Date: Tue, 6 Mar 2007 10:09:59 -0800 (PST) | |
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 [at] hotmail.com] > Sent: Tuesday, March 06, 2007 4:35 PM > To: gwz [at] cisco.com; Pasi.Eronen [at] nokia.com; eap [at] frascone.com > Cc: radiusext [at] 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
- Re: Ordered delivery of EAP messages, (continued)
-
Re: Ordered delivery of EAP messages Pasi.Eronen, March 6 2007
-
Re: Ordered delivery of EAP messages Bernard Aboba, March 6 2007
- Re: Ordered delivery of EAP messages Glen Zorn (gwz), March 6 2007
- Re: Ordered delivery of EAP messages Bernard Aboba, March 6 2007
- Re: Ordered delivery of EAP messages Alper Yegin, March 6 2007
- Re: Ordered delivery of EAP messages Bernard Aboba, March 6 2007
- Re: Ordered delivery of EAP messages Peter Deacon, March 6 2007
- Re: Ordered delivery of EAP messages Bernard Aboba, March 6 2007
- Re: Ordered delivery of EAP messages Peter Deacon, March 6 2007
-
Re: Ordered delivery of EAP messages Bernard Aboba, March 6 2007
-
Re: Ordered delivery of EAP messages Pasi.Eronen, March 6 2007
Results generated by Tiger Technologies using MHonArc.