Proposed Resolution to RFC 3576bis Issue 88: VSAs for Session Identification

["Bernard Aboba" <bernard_aboba@hotmail.com>]

The text of Issue 88 s enclosed below.    The proposed resolution is to 
reject the proposed change.

It can probably be argued that RFC 3576 already allows too many session
identification attributes.  For example, in Diameter a RAR requires
a Session-ID AVP (equivalent to Acct-Session-Id) and also allows
a User-Name AVP, but that is it.

If a CoA-Request doesn't include an Account-Session-Id attribute, then
it cannot be easily translated to a Diameter RAR.  If only a User-Name
attribute is included and the user is connected on multiple ports, the
semantics of a Disconnect or CoA-Request is not defined.  In retrospect,
this is probably an argument for making the Acct-Session-Id attribute
mandatory in a CoA-Request or Disconnect-Request, at least in situations
where the intent is to affect a single session.

There would appear to be several issues with enabling use of VSAs
for identification purposes in CoA or Disconnect-Request packets:

1. Since Diameter does not enable use of VSAs for identification within
a RAR or ASR, use of VSAs for identification in a Disconnect or CoA-Request
would seem to be untranslatable within a Diameter/RADIUS gateway.

2. Currently VSAs are assumed to represent authorization changes
within a CoA-Request.  If some VSAs were to represent identification
attributes, and some were to represent authorization changes, then a
NAS would need to keep track of which VSAs were used for which
purposes, for all potential VSAs that it could support.  This seems
like it could dramatically increase implementation complexity.

In this case, the potential downside (difficulties in RADIUs/Diameter
translation, implementation complexity) seems to outweigh the potential
benefits (increased flexibility in session identification.

----------------------------------------------------------------------------------------------------------
Issue 88: VSAs for Session-Identification
Submitter name: Murtaza Chiba
Submitter email address: mchiba@cisco.com
Date first submitted: April 28, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00405.html
Document: RFC3576bis
Comment type: T
Priority: 1
Section: 3
Rationale/Explanation of issue:

Some VSAs could be used for Session-Identification in addition to any 
authorization purpose.

In section 3 under Session Identification attributes, Vendor-Specific
attributes are not mentioned. This should be left to a vendor to decide
which attributes designate session identification and which designate
authorization in the case where ambiguity is clearly eliminated.
That is a subtype and/or contents readily distinguish between session
identification and authorization.

Also in section 3.3 Note 3 mentions that the VSA is only for authorization.
This too should be changed to allow for session identification.

Requested change:

Section 3:

Please add VSA to the list under "Session identification attributes" the 
following text
Vendor-Specific    26   [RFC2865]  The Vendor Specific attribute used
                                  for Session Identification purposes.

Section 3.3:
Modify note 3. from

"When included within a CoA-Request, these attributes
represent an authorization change request"

to

"When included within a CoA-Request, these attributes MAY represent an 
authorization change requests"



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