RE: DISCUSS: draft-ietf-radext-fixes

["David B. Nelson" <dnelson@elbrysnetworks.com>]

> Lars Eggert wrote:

> >   DISCUSS: "Jitter" is not the correct term.

I have no investment is this particular word, but I disagree that it is
incorrect.  "Jitter" has been used in the industry to describe this kind of
behavior for decades, and I think it is well understood.
 
>   Proposed replacement text:
> 
> [a] Randomization. 

I like this work less than "Jitter".  The retry times are not random, they
are merely random within a small delta.  I don't know that this is an
improvement.

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

Adding a RECOMMENDED method for achieving the desired jitter/randomization
of retry times is probably a good thing.  I think we need to be careful to
avoid adding normative requirements in this area, however.  Out charter is
to extend RADIUS, and clarify some documentation errors.  We don't have
leave to introduce non-backwards compatible normative requirements.  While
new protocols would have a higher barrier to publication, we need to recall
that RADIUS is a widely deployed, legacy protocol.  Some of the behaviors
are "grandfathered".

> >   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 response that has a valid
> Response Authenticator as defined in Section 3 of [RFC2865].  Any
> duplicate responses MUST be silently discarded.

This seems OK, to me, as this is the behavior of all of the RADIUS clients
I'm aware of.

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

I'm, OK with this.

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

Agreed.



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