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

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> 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.

  The Call-Check MAY need to be tied to a previous authentication
request.  This can be done via the State attribute being sent in an
Access-Accept, and used in a later Access-Request with Call Check.

  Suggested text:

...
   As defined in [RFC2865] Table 5.44, Access-Request packets MAY
   contain a State attribute.  The table does not qualify this
   statement, while the text in Section 5.24 says

      This Attribute is available to be sent by the server to the client
      in an Access-Accept that also includes a Termination-Action
      Attribute with the value of RADIUS-Request.  If the NAS performs
      the Termination-Action by sending a new Access-Request upon
      termination of the current session, it MUST include the State
      attribute unchanged in that Access-Request.

   We extend this definition to say that Access-Requests which are part
   of an ongoing authentication process MAY contain a State attribute.
   Access-Requests which are intended to perform authorization checks
   MUST contain a State attribute.  This last requirement often means
   that an Access-Accept will contain a State attribute, so that a later
   authorization check may use that State to tie the authorization check
   to a previous authentication request.

   For example, an Access-Request containing one of the authentication
   attributes User-Password or CHAP-Password MAY contain a State
   attribute.  Other attributes intended to carry authentication
   information include EAP-Message, though this list is not exhaustive,
   and may be extended in future specifications.

   Access-Request packets that contain a Service-Type attribute with
   value Call Chack (10) or Authorize Only (17) MUST contain a State
   attribute.  Any Access-Request that does not contain an
   authentication attribute MUST contain a State attribute.  This list
   of authorization parameters is not exhaustive, and may be extended in
   future specifications.
...

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

  I would simply say that the algorithms apply to any client originating
RADIUS packets, including Disconnect-Requests.  This covers the Dynamic
Authorization Client, without adding a dependency on RFC 3576bis.
Suggested text:

   The following algorithms apply to any client that originates RADIUS
   packets, including but not limited to Access-Request,
   Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576].

  This also adds an informative reference to RFC 3576.

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

  Sure.  It's RECOMMENDED.  We can simply say "... the RECOMMENDED
retransmission algorithm below is..."

[ MRD and MRC]
> 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.

  We can add a note:

   For Accounting-Request packets, the default values for MRC, MRD,
   and MRT SHOULD be zero.  These settings will enable a RADIUS client
   to continue sending accounting requests to a RADIUS server until
   the request is acknowledged.  If any of MRC, MRD, or MRT are non-
   zero, then the accounting information could potentially be
   discarded without being recorded.


> Section 2.5
> 
> The issue that this section is attempting to address is the seeming
> contradiction between
> [RFC2865] Section 1.1 which states:
...
> and [RFC2865] Section 5 which states:
...
> 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.

  It's difficult to know if a new attribute defines a new server.

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

  Yes.  The text in 2.5 use SHOULD, not MUST.

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

  Yes.  We can update it "Type, Vendor-Id, or Vendor-Type".

> [BA] My recommendation would be to add a clarification of the meaning of
> Section 1.1:
>...  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. 

  It's difficult to know that an unknown type is for an unimplemented
service.  But I think I know what you mean.

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

  OK.

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

  Looks good to me.

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