RE: Issue 226: RFC 3576bis and Renumbering

["David B. Nelson" <d.b.nelson@comcast.net>]

Alan DeKok writes...

>   To clarify: If Acct-Session-Id is improper for any reason, we should
> create a new session identification attribute specifically for this use.

>   How does the CoA client know what to send as session identifiers?  How
> does the recipient of the CoA message know what to do, given that the
> session identifiers you talk about can apply to many sessions?
> 
>   My proposal involves  mandating a new session key.  This key ensures
> that everyone agrees which session the CoA request applies to.  I would
> recommend *also* using Acct-Session-Id, because it applies to the
> individual sessions you want to control.

I find this proposal satisfying, because it regularizes the process, and
makes it much more likely that two implementations will interoperate,
providing exactly the same behavior.

Having expressed that personal preference, I acknowledge that some of our
colleagues envision a more complex and less regular process.

Glen Zorn reminds us that there are implementations in which the NAS
responds to a user request for an additional service, based on the broad
authorization contained in previous Access-Accept, creating a new service
session and a new Acct-Session-Id, without ever sending a new
Access-Request.  Only the RADIUS Accounting server would have seen the new
value of Acct-Session-Id.

Avi Lior reminds us that implementers would like to use identifying
attributes as a set of "match filters" to select a group of sessions (i.e. a
group of Acct-Session-Id values) for action.

Glen Zorn reminds us that the semantics of session attribute identification
is likely to be extended and further defined in documents from non-IETF
SDOs, covering particular application areas.

While only the market can validate whether these extended notions of session
identification are good ideas, it's probably not appropriate to prohibit
them in RFC3576bis.  I recommend that we define some base session
identification attributes for "generic", RFC2865-style RADIUS sessions, and
make them SHOULDs or MAYs in RFC3576bis.  I further recommend that we add
some text indicating that other documents, covering specific areas of
application, may in the future recommend or require different sets of
session identifier attributes.

Making Acct-Session-Id or something very like it a SHOULD, is a good idea.

We should also acknowledge, for the benefit of the reader, that the nature
of RADIUS "session" definition, i.e. concurrent, sequential and nested
service provisioning, is not well standardized, and that the session ID
attribute (whatever its name) included in the Access-Request messages may
not describe all of the actual sessions that CoA-Request or
Disconnect-Request messages may wish to address. The only alternative to
this, IMHO, is to restrict session creation in the NAS to a one-to-one
relationship with Access-Request messages (i.e. vanilla RADIUS as it existed
in the 1980's).  I suspect that will meet with some resistance.

>   If those two keys are NOT sufficient, then I again question how RADIUS
> is being used to control sessions it knows nothing about.

Secret sauce?  That is a very valid question, to which I'm sure there is an
answer.  I'm equally sure that it hasn't been provided in this thread.  :-)




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