Review of draft-chiba-radius-dynauthor-ext-00.txt

[Bernard Aboba <aboba@internaut.com>]

RFC 3576 introduced the concept of dynamic authorization to RADIUS, where
a session that had previously been authorized can be terminated or
modified by an exchange initiated by the RADIUS server.

In order to be able to utilize the facilities introduced in RFC 3576, it
is necessary for the server initiating a CoA or Disconnect-Request to have
kept state on the session it is looking to modify.  This includes
recording the NAS with which the session was initiated (NAS-IP-Address,
NAS-Identifier, NAS-IPv6-Address) as well as the session itself
(User-Name, NAS-Port, Framed-IP-Address, Called-Station-Id,
Calling-Station-Id, Acct-Session-Id, Acct-Multi-Session-Id, NAS-Port-Type,
NAS-Port-Id, Originating-Line-Info, Framed-Interface-Id,
Framed-IPv6-Prefix).

However, since RADIUS Accounting packets may be lost, it is possible for
the state on the server to have gotten out of sync.  For example, an
accounting server may not receive an Accounting STOP, and therefore may
think that a session continues when in fact it had ended.  It is also
possible for an Accounting Start or Interim message to be lost in which
case the server may not be aware that it had started (until a subsequent
Interim or STOP message is received).

In these circumstances, it is possible for a server initiating a CoA or
Disconnect-Request to receive an error message in response, indicating
that the session did not exist.

Where this occurs, how can the server resynchronize its state?  Note that
to achieve the resynchronization it may not be sufficient just to retrieve
the current state of the NAS that responded with an error;  the session
may have moved elsewhere, and that Accounting message may have been lost
too (e.g. the server knows of no other session on another NAS with the
same multi-session-id).

In order to address this problem, the document introduces a Query-Select
attribute, enabling a server to query for sessions of a given type.

The query syntax is quite general, allowing a number of attributes to be
returned based on whether the service or expression matching.

Since modern NAS devices can be very large, supporting hundreds of
sessions, it does seem necessary to be able to support selective queries,
since a complete dump of NAS session state could easily exceed the maximum
RADIUS packet size of 4096 octets.

However, the query syntax introduces an entirely new "URI"-based model for
RADIUS service types, which has no precedent within previous RADIUS
documents.  The query syntax also appears to be more complex than is
required to solve the problem as stated above.  Many NAS devices remain
short of resources, so that they cannot support complex queries such
as is proposed here.

For example, in order to attempt to locate the sessions of a given user,
an equality query for the User-Name attribute would be sufficient.  The
same could be said of other session attributes; there is no need to do
other types of comparisons on such session identifiers.

The other element this document introduces is the Authorization-Command.
attribute.  The only value of this attribute used is "Query-Only", used
for the query functionality described earlier.

Since there are already multiple RADIUS command codes defined for resource
querying (23 = Resource-Query-Request, 24 = Resource-Query-Response) it is
not clear why this new attribute is needed.  RFC 2882 describes these
commands, but does not provide details on their functionality, and as a
result, it is not clear that whether the functionality provided in this
document already exists.

RFC 3575 includes the following language relating to allocation of new
RADIUS command codes:

Packet
   Type Codes 6-10, 12-13, 21-34, 50-51 have no meaning defined by an
   IETF RFC, but are reserved until a specification is provided for
   them.  This is being done to avoid interoperability problems with
   software that implements non-standard RADIUS extensions that are or
   have been in use on the Internet.  Because a new Packet Type has
   considerable impact on interoperability, a new Packet Type Code
   requires IESG Approval.  The intention is that any allocation will be
   accompanied by a published RFC.  Type Codes 52-249 should be
   allocated first; when these are exhausted, Type Codes 14-20, 35-39,
   46-49 may be allocated.  For a list of Type Codes, see Appendix A.

And Service-Type values:

   The exception to this policy is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be accompanied
   by a published RFC.

Between command codes and Service-Type values, it seems to me that the
functionality required in this document can be covered, so that allocating
a new Authorization-Command attribute is not necessary or desirable.

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