RE: [eap] Ordered delivery of EAP messages

["Alper Yegin" <alper.yegin@yegin.org>]

> Seems reasonable.  So why wouldn't this reasoning apply to EAP as well?

With the appropriate normative text in the RFC covering both end points this
could be used. But we don't have such text in RFC 3748.

Alper







> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
> Sent: Wednesday, March 07, 2007 8:17 AM
> To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
> Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
> Subject: RE: [eap] Ordered delivery of EAP messages
> 
> 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 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/>