eap Mailing List: Re: Ordered delivery of EAP messages

[Yoshihiro Ohba (yohba]

On Wed, Mar 07, 2007 at 11:11:35PM -0500, Avi Lior wrote:
> 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.  

This is what I don't understand.  Correctness and security are two
separate things.

I can show you a typical example, TLS.  TLS requires reliable
transport for its correct operation.  Without use of reliable
transport, TLS session will be immediately shutdown when a packet is
lost, but it is still secure.  This does not mean that TLS requires
reliable transport for its secure operation.

Note that DTLS does not require reliable transport, because it
modifies TLS to correcly work over unreliable transport.

For the same reason, if we want to remove the orderly delivery
requirement from EAP, we would need to modify EAP to correctly work
with non-orderly delivery.

Yoshihiro Ohba

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