eap Mailing List: Re: Ordered delivery of EAP messages

[Glen Zorn (gwz) (gwz]

Alper Yegin <mailto:alper.yegin [at] yegin.org> allegedly scribbled on
Thursday, March 08, 2007 1:41 PM:

> EAP gets confused if it ever receives packets out of order.

So does RADIUS, unless it takes the same steps as recommended in RFC3748
for EAP.

> 
> Given that EAP is a lock-step protocol, any one of the three remedies
> is sufficient to ensure packets never get out of order: 
> 
> 1-  EAP lower layer ensures ordering
> 2a- EAP lower layer eliminates duplicates
> 2b- EAP eliminates duplicates
> 
> Having more than one of the remedies is not necessary.
> 
> Correct?

Yes.

> 
> RADIUS does not talk about 1, does not properly mandate 2a.
> 
> EAP mandates 2a. It talks about 2b, but falls short of using
> normative language (no MUSTs or SHOULDs). 
> 
> 
> If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile,
> can we assume all of the current RADIUS implementations are already
> supporting 2a, so that in the absence of 1 and 2b EAP works well? 

No, not all.
 
> 
> If we decide to go with 2b, we need to fix EAP spec. Meanwhile, can
> we assume all of the current EAP implementations are already
> supporting 2b, so that in the absence of 1 and 2a EAP works well? 

Again, not all; however in both cases the implementations that don't can
reasonably be considered to be broken, I think.
 
> 
> If we decide to go with 1, we need to fix RADIUS spec. Meanwhile, can
> we assume all of the current RADIUS implementations are already
> supporting 1, so that in the absence of 2a and 2b EAP works well? 

If we go with either 1 or 2b for EAP, then it still doesn't fix the
problem because the transport under RADIUS doesn't guarantee ordered
delivery, either.
 
> 
> 
> ...
> 
> We have at least two on-going designs that are gated on this
> decision. One in WiMAX Forum, and another PANA. 
> 
> 
> Alper
> 
> 
> 
>> -----Original Message-----
>> From: Glen Zorn (gwz) [mailto:gwz [at] cisco.com]
>> Sent: Thursday, March 08, 2007 4:01 AM
>> To: Alper Yegin; Bernard Aboba; peterd [at] iea-software.com
>> Cc: Pasi.Eronen [at] nokia.com; eap [at] frascone.com; radiusext [at] 
>> ops.ietf.org
>> Subject: RE: [eap] Ordered delivery of EAP messages
>> 
>> Alper Yegin <mailto:alper.yegin [at] yegin.org> allegedly scribbled on
>> Wednesday, March 07, 2007 3:39 AM:
>> 
>>>> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
>>>> well?
>>> 
>>> With the appropriate normative text in the RFC covering both end
>>> points this could be used. But we don't have such text in RFC 3748.
>> 
>> OK, so what is the real purpose of the Identifier in EAP?  I would
>> have thought that this would be one:
>> 
>>    [5] Possible duplication.  Where the lower layer is reliable, it
>>        will provide the EAP layer with a non-duplicated stream of
>>        packets. However,  while it is desirable that lower layers
>>        provide for non-duplication, this is not a requirement.  The
>>        Identifier field provides both the peer and authenticator
>> with the ability to        detect duplicates. 
>> 
>> But I'm hearing that this is N/A because somebody didn't bother to
>> implement it... 
>> 
>>> 
>>> Alper
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Glen Zorn (gwz) [mailto:gwz [at] cisco.com]
>>>> Sent: Wednesday, March 07, 2007 8:17 AM
>>>> To: Alper Yegin; Bernard Aboba; peterd [at] iea-software.com
>>>> Cc: Pasi.Eronen [at] nokia.com; eap [at] frascone.com; radiusext [at] 
>>>> ops.ietf.org
>>>> Subject: RE: [eap] Ordered delivery of EAP messages
>>>> 
>>>> Alper Yegin <> allegedly scribbled on Tuesday, March 06, 2007 3:25
>>>> PM: 
>>>> 
>>>>>> Both EAP and RADIUS do not detect duplicates arriving out of
>>>>>> order; they depend on the underlying lower layer to provide
>>>>>> in-order delivery so as to enable duplicate detection.
>>>>> 
>>>>> 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.
>>>> 
>>>> Agree.
>>>> 
>>>>> 
>>>>> 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? 
>>>> 
>>>> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
>>>> well? 
>>>> 
>>>>> 
>>>>> 
>>>>> Alper