[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [eap] Ordered delivery of EAP messages
Yoshihiro Ohba <mailto:yohba@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@tari.toshiba.com]
>> Sent: Wednesday, March 07, 2007 7:15 PM
>> To: Avi Lior
>> Cc: Bernard Aboba; alper.yegin@yegin.org; radiusext@ops.ietf.org;
>> eap@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@hotmail.com]
>>> Sent: Tuesday, March 06, 2007 11:55 PM
>>> To: alper.yegin@yegin.org
>>> Cc: radiusext@ops.ietf.org; eap@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@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
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>