[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DISCUSS: draft-ietf-radext-fixes
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_
>> 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
> 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
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.