RE: [eap] Ordered delivery of EAP messages

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Alper Yegin <mailto:alper.yegin@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@cisco.com]
>> Sent: Wednesday, March 07, 2007 8:17 AM
>> To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
>> Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@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

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