Subject: Re: [eap] Ordered delivery of EAP messages

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 09 Mar 2007 06:53:54 -0800

>  While all non-toy RADIUS implementations I'm aware of already do
>duplicate detection, this has nothing whatsoever to do with EAP.  There
>are EAP-only servers, and those servers MUST ALSO perform duplicate
>detection, or an approach with similar results.  This mandate needs to
>be part of the EAP specification.

Duplicate detection is part of the EAP specification.  From RFC 3748, 
Section 4.1:

      If a peer receives a valid duplicate Request for which it has
      already sent a Response, it MUST resend its original Response
      without reprocessing the Request....

      The Identifier field of the Response MUST match that of the
      currently outstanding Request.  An authenticator receiving a
      Response whose Identifier value does not match that of the
      currently outstanding Request MUST silently discard the Response...

   The peer is responsible for detecting and handling
   duplicate Request messages before processing them in any way,
   including passing them on to an outside party.  The authenticator is
   also responsible for discarding Response messages with a non-matching
   Identifier value before acting on them in any way, including passing
   them on to the backend authentication server for verification.  Since
   the authenticator can retransmit before receiving a Response from the
   peer, the authenticator can receive multiple Responses, each with a
   matching Identifier.  Until a new Request is received by the
   authenticator, the Identifier value is not updated, so that the
   authenticator forwards Responses to the backend authentication
   server, one at a time.

However, it was not specified that a duplicate detection window greater than 
1 needs to be implemented, because PPP-based implementations of EAP assumed 
ordered delivery and therefore did not need a window larger than that.  That 
was the origin of the ordered delivery requirement --it was inserted at the 
request of authors of existing EAP implementations who did not want RFC 3748 
to make their implementations non-compliant.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 12 Mar 2007 01:48:51 +0200

> 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:[email-masked]]
> > Sent: Thursday, March 08, 2007 4:01 AM
> > To: Alper Yegin; Bernard Aboba; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: [eap] Ordered delivery of EAP messages
> >
> > Alper Yegin <mailto:[email-masked]> 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:[email-masked]]
> > >> Sent: Wednesday, March 07, 2007 8:17 AM
> > >> To: Alper Yegin; Bernard Aboba; [email-masked]
> > >> Cc: [email-masked]; [email-masked]; [email-masked]
> > >> 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