RE: [eap] Ordered delivery of EAP messages

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

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

Hmmm... It appears like 2a alone is not sufficient, but it also needs to be
coupled with "reliable delivery" at the EAP lower layer. Or, in other words,
2a makes sense only when we have a reliable lower layer.


If the retransmissions are not generated by the lower layer, there is no
"duplicates" that can be caught and eliminated by the lower layer.

So, I think 2a should read:

2a- EAP-layer retransmissions is disabled, EAP lower layer is reliable and
eliminates duplicates



Alper









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