[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DISCUSS: draft-ietf-radext-fixes
Lars Eggert wrote:
> Discuss:
> Section 2.2.1., paragraph 6:
>> [a] Jitter. To avoid synchronization, a RADIUS client SHOULD
>> incorporate jitter within its retransmission algorithm.
>
> DISCUSS: "Jitter" is not the correct term. What is suggested here is
> to incorporate a random factor into the retransmission timer
> calculation. This will prevent synchronization, but won't help against
> congestion collapse, because it doesn't reduce the number of
> retransmissions over time. Only [b] will address that. Also, please
> specify how a random factor is to be incorporated into the computation
> - see Section 9 of draft-ietf-pana-pana for an example.
Proposed replacement text:
[a] Randomization. To avoid synchronization, a RADIUS client SHOULD
incorporate a randomization factor within its retransmission algorithm,
as specified below.
> Section 2.2.1., paragraph 7:
>> [b] Congestive backoff. While it is not necessary for RADIUS client
>> implementations to implement complex retransmission algorithms,
>> implementations SHOULD support congestive backoff within the limits
>> suggested by [RFC2865] Section 2.4. For example, an implementation
>> SHOULD double the initial retransmission timer until a maximum
>> retransmission time is reached, after which the client will
>> failover to another RADIUS server. For example, if the initial
>> retransmission timer is one second, a maximum retransmission timer
>> of 16 seconds might be used.
>
> DISCUSS: RFC2865 Section 2.4 does not suggests any timer management
> scheme or timer limits, and I couldn't find this anywhere else in
> RFC2865, either. Consequently, this document needs to specify the
> desired mechanism. See RFC2988 for an example of such a mechanism.
Proposal: Delete the last two sentences (For example...) Then, use
text similar to that in Section 9 of draft-pana-pana. It seems to cover
the RADIUS requirements pretty well. Some RADIUS implementations behave
this way already. Also add an informative reference to RFC 3315, and
note in the acknowledgements that the following text is adapted from
draft-ietf-pana-pana.
...
RADIUS retransmission timers are based on the model used in DHCPv6
[RFC3315]. Variables used here are also borrowed from this
specification. RADIUS is a request/response-based protocol. The
message exchange terminates when the requester successfully
receives the answer or the message exchange is considered to have
failed according to the retransmission mechanism described below.
The retransmission behavior is controlled and described by the
following variables:
RT Retransmission timeout
IRT Initial retransmission time (default 2 seconds)
MRC Maximum retransmission count (default 10 attempts)
MRT Maximum retransmission time (default 16 seconds)
MRD Maximum retransmission duration (default 30 seconds)
RAND Randomization factor
With each message transmission or retransmission, the sender sets
RT according to the rules given below. If RT expires before the
message exchange terminates, the sender recomputes RT and
retransmits the message.
Each of the computations of a new RT include a randomization factor
(RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to
minimize synchronization of messages.
The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different
sequence of random numbers from each invocation.
RT for the first message transmission is based on IRT:
RT = IRT + RAND*IRT
RT for each subsequent message retransmission is based on the
previous value of RT:
RT = 2*RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0,
there is no upper limit on the value of RT. Otherwise:
if (RT > MRT)
RT = MRT + RAND*MRT
MRD specifies an upper bound on the length of time a sender may
retransmit a message. The message exchange fails once MRD seconds
have elapsed since the client first transmitted the message. MRD
MUST be set, and SHOULD have a value between 5 and 30 seconds.
These values mirror the values for a servers duplicate detection
cache, as described in the next section.
MRC specifies an upper bound on the number of times a sender may
retransmit a message. if MRC is zero, the message exchange fails
once MRD seconds have elapsed since the client first transmitted
the message. If MRC is non-zero, the message exchange fails when
the either the sender has transmitted the message MRC times, or
when MRD seconds have elapsed since the client first transmitted
the message.
...
> 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.
>
> 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.
> 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.
RFC 2865 Section 2.4 notes that TCP's reliable delivery of data 2
minutes late is not useful. The timeout of 30 seconds is based on
partially on that, on NAS implementations, and on user patience. Most
NAS implementations will give up on a request after 30 seconds, as will
most users. Therefore, caching duplicates after 30 seconds is unproductive.
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/>