Re: DISCUSS: draft-ietf-radext-fixes

[Alan DeKok <aland@nitros9.org>]

Lars Eggert wrote:
> [ timers ]
> -06 specifies such a mechanism, which was the important part of my
> concern. A minor remaining nit is that the "within the limits of
> [RFC2865] Section 2.4" part should be removed, because that section in
> RFC2865 does not actually discuss any such limits.

  OK.

>>> 2.2.2.  Duplicate detection and orderly delivery.
...
> If clients need not perform duplicate detection, how are they supposed
> to silently discard later responses? No duplicate detection = no state
> about packets received in the past, right?

  Yes.  RADIUS is a request / response protocol.  The client sends a
request, and looks for a matching response.  Once it has a matching
response, it effectively forgets about the request.

  If a duplicate response is received by the client, it is no different
than an *unsolicited* response.  Neither one matches a pending request,
so the responses are discarded.

>> Section 2.2.2., paragraph 8:
>>>    Each cache entry SHOULD be purged after a period of time.  This time
>>>    SHOULD be no less than 5 seconds, and no more than 30 seconds.
>>
>>   DISCUSS: The Internet MSL is 2 minutes - choosing this as a lower
>>   bound will prevent late duplicates from remaining undetected.
> 
> This has remained unchanged in -06 AFAICT.

  As does my response: :)

http://ops.ietf.org/lists/radiusext/2007/msg00449.html

  In short, MSL doesn't matter to a server, as it doesn't see round trip
times.  It sees a request, and responds to that request.

  Alan DeKok.

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