eap Mailing List: Re: Ordered delivery of EAP messages

[Glen Zorn (gwz) (gwz]

Yoshihiro Ohba <mailto:yohba [at] tari.toshiba.com> allegedly scribbled on
Wednesday, March 07, 2007 9:20 PM:

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

My basic argument is that EAP _does_ work over a transport that doesn't
guarantee in-order delivery (the example being RADIUS) except in a deep,
dark, cobweb-filled corner case.  The arguments have been that
"well-behaved" RADIUS implementations exhibit what amounts to in-order
delivery despite the fact that it is not required by the RFCs but badly
behaved EAP implementations will fail in a contrived, pathological case.
I am saying that a badly-behaved RADIUS implementation would fail in
that same pathological case and the converse.

> 
> 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/>
>>> 
>>> 
>> 
>> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap