eap Mailing List: Re: Ordered delivery of EAP messages

[Avi Lior (avi]

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.  
 

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