Mark Townsley (townsley) <> allegedly scribbled on Thursday, March 08,
2007 8:32 AM:
> Bernard Aboba wrote:
>>>>> 1. PANA must have a reliable transport option for some set of
>>>>> messages 2. Creating an unreliable transport with packet order
>>>>> preservation over IP adds significant complexity due to the
>>>>> overhead needed to prevent DOS attacks.
>>>>>
>>
>> After some substantial discussion on the EAP and RADEXT WG lists, I
>> think we have concluded that since EAP is an ACK/NAK protocol, if the
>> lower layer transport provides for duplicate detection then it will
>> also provide for in-order delivery of EAP packets.
>>
Hmm, that's not at all the conclusion that I have reached. My
conclusion (based upon the actual text of the relevant RFCs rather than
anecdotal evidence regarding "well-behaved" RADIUS implementations) is
that "well-behaved" EAP implementations do NOT require duplicate
detection in the transport any more than do "well-behaved" RADIUS
implementations. If I understand the pathological case used to justify
the "MUST" requirement for transport layer duplicate detection in RFC
3738, one simple scenario that satisfies the case looks like this:
Peer Authenticator
---- -------------
<-- Send: Request1,
Identifier=0
<-- Send: Request2,
Identifier=0 (retransmission)
Recv: Request2, Identifier=0
Send: Response, Identifier=0 -->
Recv: Response,
Identifier=0
<-- Send: Request,
Identifier=1
Recv: Request, Identifier=1
Send: Response, Identifier=1 -->
Recv: Response,
Identifier=1
Recv: Request1, Identifier=0
If you like, replace "peer" with "client" and "authenticator" with
"server" & apply this same scenario to RADIUS, since UDP doesn't
guarantee in order delivery any more than RADIUS does. As Bernard has
pointed out, RADIUS works fine if an implementation obeys certain
constraints, none of which are required by the standard. RFC 3748
mentions most of the same constraints & should exhibit the same
behavior.
> Thank you, this is rather significant. In fact, perhaps it should be
> a part of an update to RFC3748.
>
> - Mark
>> For example, RADIUS meets the ordering requirement even though it
>> offers only simple minded UDP transport, assuming that the RADIUS
>> server implements a duplicate detection cache as described in RFC
>> 2865.
>>
>>
>
> _______________________________________________
> Pana mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pana
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
