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:gwzcisco.com]
>> Sent: Wednesday, March 07, 2007 8:17 AM
>> To: Alper Yegin; Bernard Aboba; peterdiea-software.com
>> Cc: Pasi.Eronennokia.com; eapfrascone.com; radiusextops.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 or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
