eap Mailing List: Re: Ordered delivery of EAP messages

[Peter Deacon (peterd]

On Wed, 7 Mar 2007, Avi Lior wrote:

> I don't agree that the RECOMMENDED part should be a MUST.
> You have to prove that this property is required for Correct Secure
> Operation.

Sec 1.3 says:

   EAP is a lock-step protocol which only supports a single packet in
   flight.  As a result, EAP cannot efficiently transport bulk data,
   unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960].

   While EAP provides support for retransmission, it assumes ordering
   guarantees provided by the lower layer, so out of order reception is
   not supported.

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba [at] tari.toshiba.com]
> Sent: Wednesday, March 07, 2007 7:15 PM
> To: Avi Lior
> Cc: Bernard Aboba; alper.yegin [at] yegin.org; radiusext [at] ops.ietf.org;
> eap [at] frascone.com
> Subject: Re: [eap] Ordered delivery of EAP messages
>
> I agree that there is some ambiguity, but I'd rather think that the
> RECOMMENDED part should be a MUST from operational perspective, not the
> other way around.
>
> Yoshihiro Ohba
>
> On Wed, Mar 07, 2007 at 11:53:40AM -0500, Avi Lior wrote:
> > I think this is an interesting discussion on RADIUS but we seem to
> > have diverted from the original question posed.
> >
> > RFC 3748, section 3.1 says:
> >
> > [6] Ordering guarantees.  EAP does not require the Identifier to be
> >        monotonically increasing, and so is reliant on lower layer
> >        ordering guarantees for correct operation.
> >
> > Lower layer transports for EAP MUST preserve ordering between a
> >        source and destination at a given priority level (the ordering
> >        guarantee provided by [IEEE-802]).
> >
> > I don't think that the "MUST" above is true!
> >
> > A little further down it says:
> >
> > "It is RECOMMENDED that EAP only be run over lower layers that provide
>
> > ordering guarantees; "
> >
> > Isn't that a requirement contradiction of the previous statement, or
> > am I missing something?
> >
> >
> >
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com]
> > Sent: Tuesday, March 06, 2007 11:55 PM
> > To: alper.yegin [at] yegin.org
> > Cc: radiusext [at] ops.ietf.org; eap [at] frascone.com
> > Subject: Re: [eap] Ordered delivery of EAP messages
> >
> > > 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.
> >
> > That advice seems sensible; if implemented, I think it would address
> > the FRTO scenarios we have been discussing, wouldn't it?  Given client
>
> > backoff, it seems highly unlikely that an Access-Request would be
> > reordered outside of a "short span of time" (e.g. say, 1 minute).
> >
> > > 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?
> >
> > Yes, I think that the RADIUS client will drop a duplicate response.
> > The problem occurs more on the RADIUS server side, where the server
> > could potentially send an Access-Reject if it wasn't doing duplicate
> > detection as referred to above, and as a result the EAP method got
> mixed up.
> > _________________________________________________________________
> > 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 [at] ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap