[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Request for Review: "Issues and Fixes" changes

Here is my review of the "Issues and Fixes" changes (taken from a diff of -04 and -05): 

<    A State attribute is REQUIRED in Access-Request packets neither
<    including an authentication attribute nor a Service-Type attribute
<    with the value Call Check (10).
<
<
<
---

   As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
   contain a State attribute.  We extend that definition here, to say
   that Access-Request packets that contain an authentication attribute
   or a Service-Type attribute with the value Call Check (10) MAY
   contain a State attribute.  Access-Request packets not matching the
   above description MUST contain a State attribute.


Does it make sense to include a State attribute in an Access-Request with
a Service-Type attribute with value Call Check (10)? Typically in these cases there 
is no state to encode.

I'd rewrite this as follows:

As noted [RFC 2865] Table 5.44, Access-Request packets MAY
contain a State attribute.  An Access-Request packet not containing
an authentication attribute or a Service-Type attribute with a value of
Call Check (10) MUST contain a State attribute.   If an authentication
attribute is present, then a State Attribute MAY be included.

Section 2.2.1
I think this section needs to note that the suggested algorithms apply not only to a RADIUS client, but also to a Dynamic Authorization Client, defined in RFC 3576bis. Either that, or the algorithm text needs to be transplanted into RFC 3576bis. 

    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.

    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.
Is the retransmission algorithm OPTIONAL or RECOMMENDED? The first paragraph seems to suggest that only congestive backoff is RECOMMENDED, and that the rest of the text is non-normative. Is that what is intended? I'd suggest that we say something like "A potential retransmission algorithm is included below" to make that that clear, if that is what is meant. 

    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.
This could have some unforseen (and potentially adverse) impacts on RADIUS accounting. Today, some RADIUS accounting clients continue to retransmit for long periods of time, intentionally, in order to improve reliability. If there is an upper bound on the number of times a sender may retransmit an accounting message, then accounting messages could be lost in situations where today they would be delivered. So I think this needs to be changed. 

Section 2.5
The issue that this section is attempting to address is the seeming contradiction between 
[RFC2865] Section 1.1 which states:

     A NAS that does not implement a given service MUST NOT implement
     the RADIUS attributes for that service.  For example, a NAS that
     is unable to offer Apple Remote Access Protocol (ARAP) service
     MUST NOT implement the RADIUS attributes for ARAP.  A NAS MUST
     treat a RADIUS access-accept authorizing an unavailable service as
     an access-reject instead.

and [RFC2865] Section 5 which states:

     A RADIUS server MAY ignore Attributes with an unknown Type.
     A RADIUS client MAY ignore Attributes with an unknown Type.
As I recall, the conclusion was that the advice of Section 1.1 applies to known attributes, so that if a NAS receives an attribute that is known and represents a service, but is not implemented, it is treated as an Access-Reject. Whereas if the attribute is not known, then it MAY be ignored.
The question was then what the behavior is for a NAS encountering an unknown attribute. Given the MAY in Section 5, behavior can only be recommended, not mandated, because of backward compatibility. 

  It is possible for either a standard attribute or VSA to represent a
  request for an unavailable service.  However, where the Type or
  Vendor-ID is unknown, a RADIUS client will not know whether the
  attribute defines a service or not.
[BA] Actually the problem could also arise if the Vendor-ID is known, but the Vendor Type is not, right? 

  In general, it is best for RADIUS clients to err on the side of
  caution.  On receiving an Access-Accept including an attribute of
  unknown Type, a RADIUS client SHOULD assume that it is a potential
  service definition, and treat it as an Access-Reject.  Unknown VSAs
  SHOULD be ignored by RADIUS clients.
[BA] My recommendation would be to add a clarification of the meaning of Section 1.1:
In general, it is best for a RADIUS clients to err on the side of caution. On receiving an Access-Accept including an attribute of known Type for an unimplemented service, a RADIUS client MUST treat it as an Access-Reject, as directed in [RFC2865] Section 1.1. On receiving an Access-Accept including an attribute of unknown Type, a RADIUS client SHOULD assume that it is a potential service definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be ignored by RADIUS clients. 

  As there may be interoperability issues with the above suggestion,
  client implementations SHOULD make the suggested behavior
  configurable.  A configuration flag such as "treat unknown attributes
  as reject" can be exposed to the system administrator.  If the flag
  is set to true, then Access-Accepts containing unknown attributes are
  treated as Access-Rejects.  If the flag is set to false, then unknown
  attributes in Access-Accepts are be silently ignored. The default
  value for the flag SHOULD be set to true.
I think what we are trying to say here is that existing implementations that ignore unknown attributes should probably not change to treating them as an Access-Reject by default, or else on upgrading the NAS, the users could see an unexpected change in behavior. In this situation, configuration would be helpful, but the legacy behavior should be the default, probably. However, where the existing implementation already implements the recommended behavior, there is no point in introducing configuration. Here is a recommended rewrite:
In order to avoid introducing changes in default behavior, existing implementations that do not obey this recommendation should make the behavior configurable, with the legacy behavior being enabled by default. A configuration flag such as "treat unknown attributes as reject" can be exposed to the system administrator. If the flag is set to true, then Access-Accepts containing unknown attributes are treated as Access-Rejects. If the flag is set to false, then unknown 
attributes in Access-Accepts are be silently ignored.



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