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

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

All,

Since we are on the topic of adding items to the WG. I would like to propose that this draft be considered as well.

Some views/comments inline.

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



Besides the above being an excellent justification, it should be noted that, modern networks now include elements such as the web portal. These elements use state information other than the traditional "billable" state that is found in Accounting-Requests.


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.



The URI based model proposed provides a degree of flexibility and is not intended to be used for complex querying.

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.


Agreed. The draft however proposes to give the ability to drill down to a specific detail. For example, many devices now support the notion of 'services' that may be deployed for a given session, with each 'service' affecting a partial/complete data-flow for a given session. For instance, an MP3 'service' would be treated differently from a data 'service' which would itself be treated differently from a video-on-demand 'service'.

Service Providers are now looking at opportunities to generate revenue by providing QoS guarantees on these different 'services' with policies in effect to guarantee SLAs. In order to do this, a greater detail of state information is required besides a need to gain more current information than can be gotten from interim updates.

Also, these 'services' themselves may be comprised of multiple feature sets that may individually need to be targetted.

With all of the above considerations, the draft attempts to provide a flexible querying mechanism. Hopefully, we can agree on a limited scope for this and the authors would definitely appreciate all feedback.

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.


Besides Resource Querying there is a need to start/stop 'services' on demand. The Authorization-Command would eventually include all use cases.


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.



As RADIUS has been adopted for the more recent use cases, beyond that of the original dial world, its values now represent a mixed bag of loosely coupled information. In its original form it was used to denote the type of connection allowed for the user. In more recent times its been used for indicating resource management command "Authorize-Only" and in the RFC3576 a complete behaviour has been encoded(send Access-Request). Hence, it was felt that a new attribute would better serve the draft if its contents had clearly related values.

Regards,
Murtaza

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


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