[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 238: Identification of multiple sessions
I went through the text again, and I think that some additional changes are needed as well. IMHO changes of this magnitude will require the document to go through another WG last call.
For example, in several places in the document, the term "a session" is used when in fact multiple sessions could be affected. Affecting multiple sessions also has implications for Diameter/RADIUS translation, since Diameter requires a Session-Id AVP, implying that it can only handle dynamic authorization relating to a single session.
Also, a NAS may not necessarily support multiple session identification, so an Error-Cause value is needed so that it can explain this to the Dynamic Authorization Client.
Sections 2.1 and 2.2 need to be changed to indicate that multiple sessions can be affected:
2.1. Disconnect Messages (DM)
A Disconnect-Request packet is sent by the Dynamic Authorization
Client in order to terminate user session(s) on a NAS and discard all
associated session context. The Disconnect-Request packet is sent to
UDP port 3799, and identifies the NAS as well as the user session(s)
to be terminated by inclusion of the identification attributes
described in Section 3.
+----------+ +----------+
| | Disconnect-Request | |
| | <-------------------- | Dynamic |
| NAS | | Authz |
| | Disconnect-Response | Client |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a Disconnect-Request packet sent by a Dynamic
Authorization Client with a Disconnect-ACK if all associated session
context is discarded and the user session(s) are no longer connected,
or a Disconnect-NAK, if the NAS was unable to disconnect one or more
sessions and discard all associated session context. A Disconnect-
ACK MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866]
with the value set to 6 for Admin-Reset.
2.2. Change-of-Authorization Messages (CoA)
CoA-Request packets contain information for dynamically changing
session authorizations. Typically this is used to change data
filters. The data filters can be of either the ingress or egress
kind, and are sent in addition to the identification attributes as
described in section 3. The port used, and packet format (described
in Section 2.3), are the same as that for Disconnect-Request packets.
The following attributes MAY be sent in a CoA-Request:
Filter-ID (11) - Indicates the name of a data filter list
to be applied for the session(s) that the
identification attributes map to.
NAS-Filter-Rule (92) - Provides a filter list to be applied
for the session(s) that the identification
attributes map to [RFC4849].
+----------+ +----------+
| | CoA-Request | |
| | <-------------------- | Dynamic |
| NAS | | Authz |
| | CoA-Response | Client |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a CoA-Request sent by a Dynamic Authorization
Client with a CoA-ACK if the NAS is able to successfully change the
authorizations for the user session(s), or a CoA-NAK if the CoA-
Request is unsuccessful. A NAS MUST respond to a CoA-Request
including a Service-Type Attribute with an unsupported value with a
CoA-NAK; an Error-Cause Attribute with value "Unsupported Service"
SHOULD be included.
The paragraph in Section 2.3 relating to atomicity needs to be changed to the following to address the possibility
that the NAS will not support multiple session identification:
State changes resulting from a CoA-Request MUST be atomic: if the
CoA-Request is successful for all matching sessions, the NAS MUST
send a CoA-ACK in reply, and all requested authorization changes
MUST be made. If the CoA-Request is unsuccessful for any matching
sessions, the NAS MUST send as CoA-NAK in reply, and the requested
authorization changes MUST NOT be made for any of the matching
sessions. Similarly, a state change MUST NOT occur as a result of
a Disconnect-Request that is unsuccessful with respect to any of
the matching sessions; a NAS MUST send a Disconnect-NAK in reply
if any of the matching sessions cannot be successfully terminated.
A NAS which does not support dynamic authorization changes
applying to multiple sessions MUST send a CoA-NAK or Disconnect-
NAK in reply; an Error-Cause Attribute with value 508 (Multiple
Session Selection Unsupported) SHOULD be included.
Section 3, first paragraph needs to change to the following:
In Disconnect-Request and CoA-Request packets, certain attributes are
used to uniquely identify the NAS as well as user session(s) on the
NAS. All NAS and session identification identification attributes
included in a CoA-Request or Disconnect-Request packet MUST match at
least one session in order for a Request to be successful; otherwise
a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification
attributes match and more than one session matches all of the session
identification attributes, then a CoA-Request or Disconnect-Request
MUST apply to all matching sessions.
The Session Identification table needs to accomodate the potential for multiple sessions as well:
Session identification attributes
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with one or
more sessions.
NAS-Port 5 [RFC2865] The port on which a
session is terminated.
Vendor-Specific 26 [RFC2865] One or more vendor-specific
identification attributes.
Called-Station-Id 30 [RFC2865] The link address to which
a session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
one or more sessions are
connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying a session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Id 87 [RFC2869] String identifying the port
where a session is.
Chargeable-User- 89 [RFC4372] The CUI associated with one
Identity or more sessions. Needed
where a privacy NAI is used,
since in this case the
User-Name (e.g. "anonymous")
may not identify sessions
belonging to a given user.
The following paragraph needs to be changed to reflect the possibility of multiple sessions:
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
present in a CoA-Request or Disconnect-Request, it is possible that
the the User-Name or Chargeable-User-Identity attributes will not be
sufficient to uniquely identify a single session (e.g. if the same
user has multiple sessions on the NAS, or if the privacy NAI is
used). In this case if it is desired to identify a single session,
session identification MAY be performed by using one or more of the
Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id
attributes.
In Section 3.5 an additional Error-Cause value is needed:
508 Multiple Session Selection Unsupported
"Multiple Session Selection Unsupported" is a fatal error sent by
a NAS in response to a CoA-Request or Disconnect-Request whose
session identification attributes match multiple sessions, where
the NAS does not support Requests applying to multiple sessions.
Section 4 Diameter Considerations also needs to take multiple session support into account:
4. Diameter Considerations
Due to differences in handling change-of-authorization requests in
RADIUS and Diameter, it may be difficult or impossible for a
Diameter/RADIUS gateway to successfully translate a Diameter Re-Auth-
Request (RAR) to a CoA-Request and vice versa. For example, since a
CoA-Request only initiates an authorization change but does not
initiate re-authentication, a RAR command containing a Re-Auth-
Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be
directly translated to a CoA-Request. A Diameter/RADIUS gateway
receiving a CoA-Request containing authorization changes will need to
translate this into two Diameter exchanges. First, the
Diameter/RADIUS gateway will issue a RAR command including a Session-
Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY".
Then the Diameter/RADIUS gateway will respond to the ensuing access
request with a response including the authorization attributes
gleaned from the CoA-Request. To enable translation, the CoA-Request
SHOULD include a Acct-Session-Id Attribute. If the Diameter client
uses the same Session-Id for both authorization and accounting, then
the Diameter/RADIUS gateway can copy the contents of the Acct-
Session-Id Attribute into the Session-Id AVP; otherwise, it will
need to map the Acct-Session-Id value to an equivalent Session-Id for
use within a RAR command.
Where an Acct-Session-Id attribute is not present in a CoA-Request or
Disconnect-Request, a Diameter/RADIUS gateway will either need to
determine the appropriate Acct-Session-Id, or if it cannot do so, it
can send a CoA-NAK or Disconnect-NAK in reply, possibly including an
Error-Cause Attribute with value 508 (Multiple Session Identification
Unsupported).
To simplify translation between RADIUS and Diameter, Dynamic
Authorization Clients can include a Service-Type Attribute with value
"Authorize Only" within a CoA-Request, as described in Section 3.2.
A Diameter/RADIUS gateway receiving a CoA-Request containing a
Service-Type with value "Authorize Only" translates this to a RAR
with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". The
received RAA is then translated to a CoA-NAK with a Service-Type
value of "Authorize Only". If the Result-Code AVP in the RAA has a
value in the success category, then an Error-Cause Attribute with
value "Request Initiated" is included in the CoA-NAK. If the
Result-Code AVP in the RAA has a value indicating a Protocol Error or
a Transient or Permanent Failure, then an alternate Error-Cause
Attribute is returned as suggested below.
Within Diameter, a server can request that a session be aborted by
sending an Abort-Session-Request (ASR), identifying the session to be
terminated using Session-ID and User-Name AVPs. The ASR command is
translated to a Disconnect-Request containing Acct-Session-Id and
User-Name attributes. If the Diameter client utilizes the same
Session-Id in both authorization and accounting, then the value of
the Session-ID AVP may be placed in the Acct-Session-Id attribute;
otherwise the value of the Session-ID AVP will need to be mapped to
an appropriate Acct-Session-Id value. To enable translation of a
Disconnect-Request to an ASR, an Acct-Session-Id attribute SHOULD be
present.
If the Diameter client utilizes the same Session-Id in both
authorization and accounting, then the value of the Acct-Session-Id
may be placed into the Session-ID AVP within the ASR; otherwise the
value of the Acct-Session-Id will need to be mapped to an appropriate
Session-ID value.
An Abort-Session-Answer (ASA) command is sent in response to an ASR
in order to indicate the disposition of the request. A
Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to
an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A
Disconnect-NAK received from the NAS is translated to an ASA command
with a Result-Code AVP which depends on the value of the Error-Cause
Attribute.
IANA considerations needs to request allocation of new Error-Cause Attribute values:
5. IANA Considerations
This document uses the RADIUS [RFC2865] namespace, see
. In addition to the
allocations already made in [RFC3575] and [RFC3576], this
specification requests allocation of additional values of the Error-
Cause Attribute (101):
# Value
--- -----
407 Invalid Attribute Value
508 Multiple Session Selection Unsupported
The changes need to be reflected in Appendix A:
o Clarified expected behavior when session identification attributes
match more than one session (Sections 2.3, 3, 3.5, 4).
________________________________
> From: bernard_aboba@hotmail.com
> To: radiusext@ops.ietf.org
> Subject: Issue 238: Identification of multiple sessions
> Date: Sun, 3 Jun 2007 19:51:07 -0700
>
> Issue 238: Identification of Multiple Sessions
> Submitter name: Bernard Aboba
> Submitter email address: aboba@internaut.com
> Date first submitted: June 3, 2007
> Reference:
> Document: RFC3576bis-07
> Comment type: Technical
> Priority: S
> Section: 3
> Rationale/Explanation of issue:
> It has been pointed out that the desired effect of including Session Identification attributes is to affect *all* sessions matching the attributes that are supplied. For example, including a User-Name/CUI Attribute and nothing else in a Disconnect-Request should cause all sessions with that username to be terminated. However, currently Section 3 appears to make the behavior undefined where more than one session can match the session identification attributes. Rather than being "out of scope" it would seem that RFC 3576bis should define the expected behavior.
> The proposed resolution is as follows:
> Change the following text in Section 2.3 from:
> "
> State changes resulting from a CoA-Request MUST be atomic: if the
> CoA-Request is successful, the Dynamic Authorization Server MUST
> send a CoA-ACK in reply, and all requested authorization changes
> MUST be made. If the CoA-Request is unsuccessful, a CoA-NAK MUST
> be sent in reply, and the requested authorization changes MUST NOT
> be made. Similarly, a state change MUST NOT occur as a result of
> an unsuccessful Disconnect-Request; the Dynamic Authorization
> Server MUST send a Disconnect-NAK in reply.
> "
> to:
> "
> State changes resulting from a CoA-Request MUST be atomic: if the
> CoA-Request is successful for all matching sessions, the Dynamic
> Authorization Server MUST send a CoA-ACK in reply, and all
> requested authorization changes MUST be made. If the CoA-Request
> is unsuccessful for any matching sessions, a CoA-NAK MUST
> be sent in reply, and the requested authorization changes MUST NOT
> be made for any of the matching sessions. Similarly, a state change
> MUST NOT occur as a result of a Disconnect-Request that is unsuccessful
> with respect to any of the matching sessions; a Dynamic Authorization
> Server MUST send a Disconnect-NAK in reply if any of the matching
> sessions cannot be successfully terminated.
> "
> Change the following text in Section 3 from:
> "
> In Disconnect-Request and CoA-Request packets, certain attributes are
> used to uniquely identify the NAS as well as a user session on the
> NAS. All NAS identification attributes included in a Request packet
> MUST match in order for a Disconnect-Request or CoA-Request to be
> successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.
> For session identification attributes, the User-Name and Acct-
> Session-Id Attributes, if included, MUST match in order for a
> Disconnect-Request or CoA-Request to be successful; other session
> identification attributes SHOULD match. Where a mismatch of session
> identification attributes is detected, a Disconnect-NAK or CoA-NAK
> SHOULD be sent.
> The ability to use NAS or session identification attributes to map to
> unique/multiple sessions is beyond the scope of this document.
> Identification attributes include NAS and session identification
> attributes, as described below."
> To:
> "
> In Disconnect-Request and CoA-Request packets, certain attributes are
> used to uniquely identify the NAS as well as user session(s) on the
> NAS. All NAS and session identification identification attributes
> included in a CoA-Request or Disconnect-Request packet MUST match
> at least one session in order for a Request to be successful; otherwise
> a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification
> attributes match and more than one session matches all of the
> session identification attributes, then a CoA-Request or Disconnect-Request
> MUST apply to all matching sessions.
> Identification attributes include NAS and session identification
> attributes, as described below."
--
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/>