RE: DISCUSS: draft-ietf-radext-fixes

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

Alan DeKok <> allegedly scribbled on Monday, July 02, 2007 6:20 AM:

...

>> Section 2.2.2., paragraph 0:
>>> 2.2.2.  Duplicate detection and orderly delivery.
>> 
>>   DISCUSS: This section is all about duplicate detection at the
>>   server due to client retransmissions. But any UDP packet can be
>>   duplicated in the network. This section should hence also discuss
>>   detection of duplicate responses at the client.
> 
>   Proposed added text:
> 
>   RADIUS clients do not have to perform duplicate detection.  When a
> client sends a request, it processes the first reponse that has a
> valid Response Authenticator as defined in Section 3 of [RFC2865]. 
> Any duplicate responses MUST be silently discarded.  

This paragraph sound self-contradictory to me: haw can a client silently
discard duplicate responses if it doesn't detect that they _are_
duplicate responses?
 
> 
>> 
>> Section 2.2.2., paragraph 2:
>>>       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.
>> 
>>   DISCUSS: I could not find a discussion in RFC2865 on how the
>>   Identifier field is to be managed. For duplicate detection, it
>>   should be monotonically increasing or similar. If RFC2865 doesn't
>>   specify how the Identifier fields is to be used, this document
>>   needs to do so if it wants to base duplicate detection  on it.
> 
>   In general, Identifier management hasn't been an issue.  Clients
> don't re-use Identifiers that have not yet received responses. 
> That's simple enough that almost everybody gets it right.  Clients
> re-use Identifiers that have received responses.  The order in which
> they re-use identifiers matters only for requests that have timed
> out.     
> 
>   Proposed text:
> 
>   When sending requests, RADIUS clients MUST NOT re-use Identifiers
> for a source IP address and source UDP port until either a valid
> response has been received, or the request has timed out.  Clients
> SHOULD allocate Identifiers via a least recently used (LRU) method
> for a particular source IP address and source UDP port. 

This doesn't seem to address the issue of the Identifier being
essentially useless for duplicate detection if not monotonically
increasing...
   
...

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