RE: [eap] Ordered delivery of EAP messages

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

EAP gets confused if it ever receives packets out of order.

Given that EAP is a lock-step protocol, any one of the three remedies is
sufficient to ensure packets never get out of order:

1-  EAP lower layer ensures ordering
2a- EAP lower layer eliminates duplicates
2b- EAP eliminates duplicates

Having more than one of the remedies is not necessary.

Correct?
 
RADIUS does not talk about 1, does not properly mandate 2a.

EAP mandates 2a. It talks about 2b, but falls short of using normative
language (no MUSTs or SHOULDs).

 
If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile, can we
assume all of the current RADIUS implementations are already supporting 2a,
so that in the absence of 1 and 2b EAP works well?

If we decide to go with 2b, we need to fix EAP spec. Meanwhile, can we
assume all of the current EAP implementations are already supporting 2b, so
that in the absence of 1 and 2a EAP works well?

If we decide to go with 1, we need to fix RADIUS spec. Meanwhile, can we
assume all of the current RADIUS implementations are already supporting 1,
so that in the absence of 2a and 2b EAP works well?


...

We have at least two on-going designs that are gated on this decision. One
in WiMAX Forum, and another PANA. 


Alper



> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
> Sent: Thursday, March 08, 2007 4:01 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 <mailto:alper.yegin@yegin.org> allegedly scribbled on
> Wednesday, March 07, 2007 3:39 AM:
> 
> >> 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.
> 
> OK, so what is the real purpose of the Identifier in EAP?  I would have
> thought that this would be one:
> 
>    [5] Possible duplication.  Where the lower layer is reliable, it will
>        provide the EAP layer with a non-duplicated stream of packets.
>        However,  while it is desirable that lower layers provide for
>        non-duplication, this is not a requirement.  The Identifier field
>        provides both the peer and authenticator with the ability to
>        detect duplicates.
> 
> But I'm hearing that this is N/A because somebody didn't bother to
> implement it...
> 
> >
> > 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/>