eap Mailing List: Re: Ordered delivery of EAP messages

[Yoshihiro Ohba (yohba]

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