diff options
Diffstat (limited to 'doc/rfc/rfc9390.txt')
| -rw-r--r-- | doc/rfc/rfc9390.txt | 1165 |
1 files changed, 1165 insertions, 0 deletions
diff --git a/doc/rfc/rfc9390.txt b/doc/rfc/rfc9390.txt new file mode 100644 index 0000000..2932d0b --- /dev/null +++ b/doc/rfc/rfc9390.txt @@ -0,0 +1,1165 @@ + + + + +Internet Engineering Task Force (IETF) M. Jones +Request for Comments: 9390 Individual +Category: Standards Track M. Liebsch +ISSN: 2070-1721 NEC + L. Morand + Orange + April 2023 + + + Diameter Group Signaling + +Abstract + + In large network deployments, a single Diameter node can support over + a million concurrent Diameter sessions. In some use cases, Diameter + nodes need to apply the same operation to a large group of Diameter + sessions concurrently. The Diameter base protocol commands operate + on a single session so these use cases can result in many thousands + of command exchanges enforcing the same operation on each session in + the group. In order to reduce signaling, it is desirable to enable + bulk operations on all (or part of) the sessions managed by a + Diameter node using a single or a few command exchanges. This + document specifies the Diameter protocol extensions to achieve this + signaling optimization. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9390. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Protocol Overview + 3.1. Building and Modifying Session Groups + 3.2. Issuing Group Commands + 3.3. Permission Considerations + 4. Protocol Description + 4.1. Session Grouping Capability Discovery + 4.1.1. Capability Discovery Based on the Application Id + 4.1.2. Capability Discovery Based on AVP Presence + 4.2. Session Grouping + 4.2.1. Group Assignment at Session Initiation + 4.2.2. Removing a Session from a Session Group + 4.2.3. Mid-session Group Assignment Modifications + 4.3. Deleting a Session Group + 4.4. Performing Group Operations + 4.4.1. Sending Group Commands + 4.4.2. Receiving Group Commands + 4.4.3. Error Handling for Group Commands + 4.4.4. Single-Session Fallback + 5. Operation with Proxy Agents + 6. Commands Formatting + 6.1. Formatting Example: Group Re-Auth-Request + 7. Attribute-Value Pairs (AVPs) + 7.1. Session-Group-Info AVP + 7.2. Session-Group-Control-Vector AVP + 7.3. Session-Group-Id AVP + 7.4. Group-Response-Action AVP + 7.5. Session-Group-Capability-Vector AVP + 8. Result-Code AVP Values + 9. IANA Considerations + 9.1. AVP Codes + 9.2. New Registries + 10. Security Considerations + 11. Normative References + Appendix A. Session Management -- Exemplary Session State Machine + A.1. Use of Groups for the Authorization Session State Machine + Acknowledgments + Authors' Addresses + +1. Introduction + + In large network deployments, a single Diameter node can support over + a million concurrent Diameter sessions. In some use cases, Diameter + nodes need to apply the same operation to a large group of Diameter + sessions concurrently. For example, a policy decision point may need + to modify the authorized quality of service for all active users + having the same type of subscription. The Diameter base protocol + commands operate on a single session so these use cases can result in + many thousands of command exchanges enforcing the same operation on + each session in the group. In order to reduce signaling, it is + desirable to enable bulk operations on all (or part of) the sessions + managed by a Diameter node using a single or a few command exchanges. + + This document describes mechanisms for grouping Diameter sessions and + applying Diameter commands, such as performing re-authentication, re- + authorization, termination, and abortion of sessions to a group of + sessions. This document does not define a new Diameter application. + Instead, it defines mechanisms, commands, and Attribute-Value Pairs + (AVPs) that may be used by any Diameter application that requires + management of groups of sessions. + + These mechanisms take the following design goals and features into + account: + + * minimal impact to existing applications + + * extension of existing commands' Command Code Format (CCF) with + optional AVPs to enable grouping and group operations + + * fallback to single-session operation + + * implicit discovery of capability to support grouping and group + operations in case no external mechanism is available to discover + a Diameter peer's capability to support session grouping and + session group operations + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This document uses terminology defined in [RFC6733]. + +3. Protocol Overview + +3.1. Building and Modifying Session Groups + + In order to accommodate bulk operations on Diameter sessions, the + concept of session groups is introduced. Once sessions are added to + a group, a command acting on the group will affect all the member + sessions. + + The client and the server can assign a new Diameter session to a + group, e.g., in case the subscription profile of the associated user + has similar characteristics as the profile of other users whose + Diameter session has been assigned to one or multiple groups. A + single command can be issued and applied to all sessions associated + with one or more such groups, e.g., to adjust common profile or + policy settings. + + The assignment of a Diameter session to a group can be changed during + an ongoing session (mid-session). For example, if a user's + subscription profile changes mid-session, a Diameter server may + remove a session from an existing group and assign this session to a + different group that is more appropriate for the new subscription + profile. + + In the case of mobile users, the user's session may get transferred + mid-session to a new Diameter client during handover and assigned to + a different group, which is maintained at the new Diameter client. + + It may be required to delete a session group, e.g., at the expiry of + a promotional period that applied to multiple subscriber profiles. + Deletion of such group requires subsequent individual treatment of + each of the assigned sessions. A node may decide to assign some of + these sessions to any other existing or new group. + +3.2. Issuing Group Commands + + Changes in the network condition may result in the Diameter server's + decision to close all sessions in a given group. For example, the + server issues a single Session Termination Request (STR) command, + including the identifier of the group of sessions that are to be + terminated. The Diameter client treats the STR as a group command + and initiates the termination of all sessions associated with the + identified group. Subsequently, the client confirms the successful + termination of these sessions to the server by sending a single + Session Termination Answer (STA) command, which includes the + identifier of the group. + +3.3. Permission Considerations + + Permission considerations in the context of this document apply to + the permission of Diameter nodes to build new session groups, to + assign/remove a session to/from a session group, and to delete an + existing session group. + + When a client or server decides to create a new session group, e.g., + to group all sessions that share certain characteristics, this node + builds a session group identifier according to the rules described in + Section 7.3 and becomes the owner of the group. + + After the creation of a session group, a session can be added to this + session group by either the client or the server. However, a session + can only be removed from a session group by the Diameter node (client + or server) that has assigned this session to the session group. + + A session group can only be deleted by the owner of the session + group, resulting in individual treatment of the sessions that were + assigned to this session group. + + Diameter applications with implicit support for session groups MAY + define a more constrained permission model. For example, a more + constrained model could require that a client not remove a session + from a group that is owned by the server. Details about enforcing a + more constrained permission model are out of scope of this + specification. + +4. Protocol Description + +4.1. Session Grouping Capability Discovery + + Diameter nodes SHOULD NOT perform group operations with peer nodes + unless the node has advertised support for session grouping and group + operations. + +4.1.1. Capability Discovery Based on the Application Id + + Newly defined Diameter applications may intrinsically support + Diameter session grouping and group operations. In these cases, + there is no need of a specific discovery mechanism for the support of + session grouping capability besides the discovery of the Application + Id assigned to the application advertised during the capability + exchange phase described in Section 5.3 of [RFC6733]. + + System-specific and deployment-specific means, as well as out-of-band + mechanisms for capability discovery, can be used to announce nodes' + support for session grouping and session group operations. In such + case, the optional Session-Group-Capability-Vector AVP, as described + in Section 4.1.2, can be omitted in Diameter messages being exchanged + between nodes. + +4.1.2. Capability Discovery Based on AVP Presence + + If no other mechanism for capability discovery is deployed to enable + Diameter nodes to learn about nodes' capability to support session + grouping and group commands for a given application, a Diameter node + SHOULD append the Session-Group-Capability-Vector AVP to any Diameter + application messages exchanged with the other Diameter nodes to + announce its capability to support session grouping and session group + operations for the advertised application. Implementations following + the specification as per this document MUST set the + BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability- + Vector AVP. + + When a Diameter node receives at least one Session-Group-Capability- + Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag + set, the receiving Diameter node discovers the supported session + grouping capability of the sending Diameter node for the advertised + application and MUST cache this information for the lifetime of the + routing table entry associated with the peer identity / Application + Id pair (see Section 2.7 of [RFC6733]). + +4.2. Session Grouping + + This specification does not limit the number of session groups to + which a single session is assigned. It is left to the implementation + of an application to determine such limitations. If an application + facilitates a session to belong to multiple session groups, the + application MUST maintain consistency of associated application + session states for these multiple session groups. + + Either Diameter node (client or server) can initiate the assignment + of a session to a single or multiple session groups. Modification of + a group by removing or adding a single or multiple user sessions can + be initiated and performed mid-session by either Diameter node + responsible for the session assignment to this group. Although + Diameter is a peer-to-peer protocol, Diameter Authentication, + Authorization, and Accounting (AAA) applications typically assign the + role of a "Diameter client" to the Diameter node initiating the + Diameter session and the role of "Diameter server" to the node + authorizing the Diameter session. This specification does not + restrict group creation, assignment, or deletion actions to a + specific role. In the following sections, "Diameter node" is used to + refer to either role. Section 5 describes particularities about + session grouping and performing group commands when relay agents or + proxies are deployed. + + Any Diameter node that has advertised support of session grouping and + group operations MUST store and maintain the group assignment as part + of the session's state. A list of all known session groups is + locally maintained on each node, with each group pointing to + individual sessions being assigned to the group. Each Diameter node + MUST also keep a record about sessions that it has assigned to a + session group. + +4.2.1. Group Assignment at Session Initiation + + To assign a session to a group at session initiation, a Diameter + client sends a service-specific request, e.g., Network Access Server + Requirements (NASREQ) AA-Request [RFC7155], containing one or more + session group identifiers. Each of these groups MUST be identified + by a unique Session-Group-Id contained in a separate Session-Group- + Info AVP, as specified in Section 7. + + The client may choose one or multiple session groups from a list of + existing session groups. Alternatively, the client may decide to + create a new group to which the session is assigned and identify + itself in the <DiameterIdentity> portion of the Session-Group-Id AVP, + as per Section 7.3. For all assignments of a session to an active + session group made by the client or the server, the + SESSION_GROUP_STATUS flag in the Session-Group-Info AVP, which + identifies the session group, MUST be set. A set + SESSION_GROUP_STATUS flag indicates that the identified session group + has just been created or is still active. + + The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the + Session-Group-Control-Vector AVP in each appended Session-Group-Info + AVP to indicate that the session contained in the request should be + assigned to the identified session group. + + The client may also indicate in the request that it supports + assignment of the session to one or more groups by the server. In + such case, the client MUST include the Session-Group-Info AVP in the + request, including the Session-Group-Control-Vector AVP with the + SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP. + + If the Diameter server receives a command request from a Diameter + client and the command includes at least one Session-Group-Info AVP + with the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group- + Control-Vector AVP set, the server can accept or reject the request + for group assignment. Reasons for rejection may be, e.g., lack of + resources for managing additional groups. When rejected, the session + MUST NOT be assigned to any session group. + + If the Diameter server accepts the client's request for a group + assignment, the server MUST assign the new session to each (one or + more) of the identified session groups when present in the Session- + Group-Info AVP. If one or multiple identified session groups are not + already stored by the server, the server MUST store the one or more + newly identified groups to its local list of known session groups. + When sending the response to the client, e.g., a service-specific + authorization response, as per NASREQ AA-Answer [RFC7155], the server + MUST include all Session-Group-Info AVPs received in the client's + request. + + In addition to the one or multiple session groups identified in the + client's request, the server may decide to assign the new session to + one or multiple additional groups. In such case, the server MUST add + to the response the additional Session-Group-Info AVPs, each + identifying a session group to which the new session is assigned by + the server. Each of the Session-Group-Info AVPs added by the server + MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the + Session-Group-Control-Vector AVP. + + If the Diameter server rejects the client's request for a group + assignment, the server sends the response to the client, e.g., a + service-specific authorization response, as per NASREQ AA-Answer + [RFC7155], and MUST include all Session-Group-Info AVPs received in + the client's request (if any) while clearing the + SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- + Vector AVP. The server MAY still accept the client's request for the + identified session to proceed despite rejecting the group assignment. + The response sent to the client will then indicate success in the + result code. In this case, the session is treated as a single + session without assignment to any session group by the Diameter + nodes. + + If the assignment of the session to one or some of the multiple + identified session groups fails, the session group assignment is + treated as a failure. In such case, the session is treated as a + single session without assignment to any session group by the + Diameter nodes. The server sends the response to the client and MAY + include those Session-Group-Info AVPs for which the group assignment + failed. The SESSION_GROUP_ALLOCATION_ACTION flag of included + Session-Group-Info AVPs MUST be cleared. + + If the Diameter server receives a command request from a Diameter + client and the command includes a Session-Group-Info AVP that does + not include a Session-Group-Id AVP, the server MAY decide to assign + the session to one or multiple session groups. For each session + group to which the server assigns the new session, the server + includes a Session-Group-Info AVP with the Session-Group-Id AVP, + identifying a session group in the response sent to the client. Each + of the Session-Group-Info AVPs included by the server MUST have the + SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- + Vector AVP set. + + If the Diameter server receives a command request from a Diameter + client and the command does not contain any Session-Group-Info AVPs, + the server MUST NOT assign the new session to any session group but + treat the request the same as for a single session. The server MUST + NOT return any Session-Group-Info AVP in the command response. + + If the Diameter client receives a response to its previously issued + request from the server and the response includes at least one + Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag + of the associated Session-Group-Control-Vector AVP set, the client + MUST add the new session to all session groups as identified in one + or multiple Session-Group-Info AVPs. If the Diameter client fails to + add the session to one or more session groups as identified in one or + multiple Session-Group-Info AVPs, the client MUST terminate the + session. The client MAY send a subsequent request for session + initiation to the server without requesting the assignment of the + session to a session group. + + If the Diameter client receives a response to its previously issued + request from the server and one or more Session-Group-Info AVPs have + the SESSION_GROUP_ALLOCATION_ACTION flag of the associated Session- + Group-Control-Vector AVP cleared, the client MUST terminate the + assignment of the session to one or multiple groups. If the response + from the server indicates success in the result code but only the + assignment of the session to a session group has been rejected by the + server, the client treats the session as a single session without + group assignment. + + If a Diameter client sends a request for session initiation + containing one or more Session-Group-Info AVPs but the response from + the Diameter server does not contain a Session-Group-Info AVP, the + Diameter client MUST proceed as if the request was processed without + group assignments. The Diameter client MUST NOT retry to request + group assignment for this session but MAY try to request group + assignment for other new sessions. + +4.2.2. Removing a Session from a Session Group + + When a Diameter client decides to remove a session from a particular + session group, the client sends a service-specific re-authorization + request to the server and adds one Session-Group-Info AVP to the + request for each session group from which the client wants to remove + the session. The session that is to be removed from a group is + identified in the Session-Id AVP of the command request. The + SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- + Vector AVP in each Session-Group-Info AVP MUST be cleared to indicate + removal of the session from the session group identified in the + associated Session-Group-Id AVP. + + When a Diameter client decides to remove a session from all session + groups to which the session has been previously assigned, the client + sends a service-specific re-authorization request to the server and + adds a single Session-Group-Info AVP to the request that has the + SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id + AVP omitted. The Session-Id AVP in the re-authorization request + identifies the session that is to be removed from all groups to which + it had been previously assigned. + + If the Diameter server receives a request from the client that has at + least one Session-Group-Info AVP appended with the + SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove + the session from the session group identified in the associated + Session-Group-Id AVP. If the request includes at least one Session- + Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared + and no Session-Id AVP present, the server MUST remove the session + from all session groups to which the session has been previously + assigned. The server MUST include in its response to the requesting + client all Session-Group-Id AVPs received in the request. + + When the Diameter server decides to remove a session from one or + multiple particular session groups or from all session groups to + which the session has been assigned beforehand, the server sends a + Re-Auth-Request (RAR) or a service-specific server-initiated request + to the client, indicating the session in the Session-Id AVP of the + request. The client sends a Re-Auth-Answer (RAA) or a service- + specific answer to respond to the server's request. The client + subsequently sends a service-specific re-authorization request + containing one or multiple Session-Group-Info AVPs, each indicating a + session group to which the session had been previously assigned. To + indicate removal of the indicated session from one or multiple + session groups, the server sends a service-specific authorization + response to the client, containing a list of Session-Group-Info AVPs + with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the + Session-Group-Id AVP identifying the session group from which the + session should be removed. The server MAY include with the service- + specific authorization response a list of Session-Group-Info AVPs + with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session- + Group-Id AVP identifying session groups to which the session remains + subscribed. If the server decides to remove the identified session + from all session groups to which the session has been previously + assigned, the server includes in the service-specific authorization + response at least one Session-Group-Info AVP with the + SESSION_GROUP_ALLOCATION_ACTION flag cleared and Session-Group-Id AVP + absent. + +4.2.3. Mid-session Group Assignment Modifications + + Either Diameter node (client or server) can modify the group + membership of an active Diameter session according to the specified + permission considerations. + + To update an assigned group mid-session, a Diameter client sends a + service-specific re-authorization request to the server, containing + one or multiple Session-Group-Info AVPs with the + SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP + present, identifying the session group to which the session should be + assigned. With the same message, the client MAY send one or multiple + Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag + cleared and the Session-Group-Id AVP identifying the session group + from which the identified session is to be removed. To remove the + session from all previously assigned session groups, the client + includes at least one Session-Group-Info AVP with the + SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id + AVP present. When the server received the service-specific re- + authorization request, it MUST update its locally maintained view of + the session groups for the identified session according to the + appended Session-Group-Info AVPs. The server sends a service- + specific authorization response to the client containing one or + multiple Session-Group-Info AVPs with the + SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP + identifying the new session group to which the identified session has + been assigned. + + When a Diameter server decides to update assigned groups mid-session, + it sends a Re-Auth-Request (RAR) message or a service-specific + request to the client identifying the session for which the session + group lists are to be updated. The client responds with a Re-Auth- + Answer (RAA) message or a service-specific answer. The client + subsequently sends a service-specific re-authorization request + containing one or multiple Session-Group-Info AVPs with the + SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP + identifying the session group to which the session had been + previously assigned. The server responds with a service-specific + authorization response and includes one or multiple Session-Group- + Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the + Session-Group-Id AVP identifying the session group to which the + identified session is to be assigned. With the same response + message, the server MAY send one or multiple Session-Group-Info AVPs + with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the + Session-Group-Id AVP identifying the session groups from which the + identified session is to be removed. When a server wants to remove + the session from all previously assigned session groups, it sends at + least one Session- Group-Info AVP with the response having the + SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id + AVP present. + +4.3. Deleting a Session Group + + To explicitly delete a session group and release the associated + Session-Group-Id value, the owner of a session group appends a single + Session-Group-Info AVP with the SESSION_GROUP_STATUS flag cleared and + the Session-Group-Id AVP identifying the session group that is to be + deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated + Session-Group-Control-Vector AVP MUST be cleared. + + A session group is implicitly deleted and its identifier is released + after the last session has been removed from this session group. + +4.4. Performing Group Operations + +4.4.1. Sending Group Commands + + Either Diameter node (client or server) can request the recipient of + a request to process an associated command for all sessions assigned + to one or multiple groups by identifying these groups in the request. + The sender of the request appends for each group to which the command + applies a Session-Group-Info AVP including the Session-Group-Id AVP + to identify the associated session group. Both the + SESSION_GROUP_ALLOCATION_ACTION flag and the SESSION_GROUP_STATUS + flag MUST be set. + + If the Command Code Format (CCF) of the request mandates a Session-Id + AVP, the Session-Id AVP MUST identify one of the single sessions that + is assigned to at least one of the groups being identified in the + appended Session-Group-Id AVPs. + + The sender of the request MUST indicate to the receiver how multiple + resulting transactions associated with a group command are to be + treated by appending a single instance of a Group-Response-Action + AVP. For example, when a server sends a Re-Auth-Request (RAR) or a + service-specific server-initiated request to the client, it indicates + to the client to follow the request according to one of three + possible procedures. When the server sets the Group-Response-Action + AVP to ALL_GROUPS (1), the client sends a single RAR message for all + identified groups. When the server sets the Group-Response-Action + AVP to PER_GROUP (2), the client sends a single RAR message for each + identified group individually. When the server sets the Group- + Response-Action AVP to PER_SESSION (3), the client follows up with a + single RAR message per impacted session. If a session is included in + more than one of the identified session groups, the client sends only + one RAR message for that session. + + If the sender sends a request including the Group-Response-Action AVP + set to ALL_GROUPS (1) or PER_GROUP (2), it has to expect some delay + before receiving one or more corresponding answers, as the answers + will only be sent back when the request is processed for all the + sessions or all the sessions of a session group. If the processing + of the request is delay sensitive, the sender SHOULD NOT set the + Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the + answer can be sent before the complete process of the request for all + the sessions or if the request timeout timer is high enough, the + sender MAY set the Group-Response-Action AVP to ALL_GROUPS (1) or + PER_GROUP (2). + + If the sender wants the receiver of the request to process the + associated command for a single session, the sender does not append + any group identifier; it identifies only the relevant session in the + Session-Id AVP. + +4.4.2. Receiving Group Commands + + A Diameter node receiving a request to process a command for a group + of sessions identifies the relevant groups according to the included + Session-Group-Id AVP in the Session-Group-Info AVP and processes the + group command according to the included Group-Response-Action AVP. + If the received request identifies multiple groups in multiple, + included Session-Group-Id AVPs, the receiver SHOULD process the + associated command for each of these groups. If a session has been + assigned to more than one of the identified groups, the receiver MUST + process the associated command only once per session. + +4.4.3. Error Handling for Group Commands + + When a Diameter node receives a request to process a command for one + or more session groups and the result of processing the command is an + error that applies to all sessions in the identified groups, an + associated protocol error MUST be returned to the source of the + request. In such case, the sender of the request MUST fall back to + single-session processing and the session groups, which have been + identified in the group command, MUST be deleted according to the + procedure described in Section 4.3. + + When a Diameter node receives a request to process a command for one + or more session groups and the result of processing the command + succeeds for some sessions identified in one or multiple session + groups but fails for one or more sessions, the Result-Code AVP in the + response message SHOULD indicate DIAMETER_LIMITED_SUCCESS, as per + Section 7.1.2 of [RFC6733]. + + In the case of limited success, the sessions for which the processing + of the group command failed MUST be identified by including their + Session-Id AVP in the Failed-AVP AVP, as per Section 7.5 of + [RFC6733]. The sender of the request MUST fall back to single- + session operation for each of the identified sessions for which the + group command failed. In addition, each of these sessions MUST be + removed from all session groups to which the group command applied. + To remove sessions from a session group, the Diameter client performs + the procedure described in Section 4.2.2. + +4.4.4. Single-Session Fallback + + Either Diameter node can fall back to single-session operation by + ignoring and omitting the optional group-session-specific AVPs. + Fallback to single-session operation is performed by processing the + Diameter command solely for the session identified in the mandatory + Session-Id AVP. In such case, the response to the group command MUST + NOT include any group identifier but only the Session-Id identifying + the session for which the command has been processed. + +5. Operation with Proxy Agents + + In the case of a present stateful Proxy Agent between a Diameter + client and a Diameter server, the Proxy Agent MUST perform the same + mechanisms per this specification to advertise session grouping and + group operation capabilities towards the client and the server, + respectively. The Proxy Agent MUST update and maintain consistency + of its local session states as per the result of the group commands + that are operated between a Diameter client and a server. In such + case, the Proxy Agent MUST act as a Diameter server in front of the + Diameter client and MUST act as a Diameter client in front of the + Diameter server. Therefore, the client and the server behavior + described in Section 4 applies respectively to the stateful Proxy + Agent. + + If a stateful Proxy Agent manipulates session groups, it MUST + maintain consistency of session groups between a client and a server. + This applies to a deployment where the Proxy Agent utilizes session + grouping and performs group operations with, for example, a Diameter + server, whereas the Diameter client is not aware of session groups. + In such case, the Proxy Agent must reflect the states associated with + the session groups as individual session operations towards the + client and ensure the client has a consistent view of each session. + The same applies to a deployment where all nodes, the Diameter client + and server, as well as the Proxy Agent are group aware, but the Proxy + Agent manipulates groups, e.g., to adopt different administrative + policies that apply to the client's domain and the server's domain. + + Stateless Proxy Agents do not maintain any session states (only + transaction states are maintained). Consequently, the notion of a + session group is transparent for any stateless Proxy Agent present + between a Diameter client and a Diameter server handling session + groups. Session-group-related AVPs being defined as an optional AVP + are ignored by stateless Proxy Agents and should not be removed from + the Diameter commands. If they are removed by the Proxy Agent for + any reason, the Diameter client and Diameter server will discover the + absence of the session-group-related AVPs and will fall back to + single-session processing, as described in Section 4. + +6. Commands Formatting + + This document does not specify new Diameter commands to enable group + operations but relies on command extensibility and capability + provided by the Diameter Base protocol. This section provides the + guidelines to extend the CCF of existing Diameter commands with + optional AVPs to enable the recipient of the command to apply the + command to all sessions associated with the identified group or + groups. + +6.1. Formatting Example: Group Re-Auth-Request + + A request for re-authentication of one or more groups of users is + issued by appending one or multiple Session-Group-Id AVPs, as well as + appending a single instance of a Group-Response-Action AVP to the Re- + Auth-Request (RAR). One or multiple Session-Group-Id AVPs identify + one or more associated groups for which group re-authentication has + been requested. The Group-Response-Action AVP identifies the + expected means to perform and respond to the group command. The + recipient of the group command initiates re-authentication for all + users associated with the identified group or groups. Furthermore, + the sender of the group re-authentication request appends a Group- + Response-Action AVP to provide more information to the receiver of + the command about how to accomplish the group operation. + + The value of the mandatory Session-Id AVP MUST identify a session + associated with a single user, which is assigned to at least one of + the groups being identified in the appended Session-Group-Id AVPs. + + <RAR> ::= < Diameter Header: 258, REQ, PXY > + < Session-Id > + { Origin-Host } + { Origin-Realm } + { Destination-Realm } + { Destination-Host } + { Auth-Application-Id } + { Re-Auth-Request-Type } + [ User-Name ] + [ Origin-State-Id ] + * [ Proxy-Info ] + * [ Route-Record ] + [ Session-Group-Capability-Vector ] + * [ Session-Group-Info ] + [ Group-Response-Action ] + * [ AVP ] + +7. Attribute-Value Pairs (AVPs) + + +=================================+==========+====================+ + | Attribute Name |AVP Code |AVP Flag rules | + +=================================+Value Type+====+===+======+====+ + | | |MUST|MAY|SHOULD|MUST| + | | | | |NOT |NOT | + +=================================+==========+====+===+======+====+ + | Session-Group-Info |671 | |P | |V | + | |Grouped | | | | | + +---------------------------------+----------+----+---+------+----+ + | Session-Group-Control-Vector |672 | |P | |V | + | |Unsigned32| | | | | + +---------------------------------+----------+----+---+------+----+ + | Session-Group-Id |673 | |P | |V | + | |UTF8String| | | | | + +---------------------------------+----------+----+---+------+----+ + | Group-Response-Action |674 | |P | |V | + | |Unsigned32| | | | | + +---------------------------------+----------+----+---+------+----+ + | Session-Group-Capability-Vector |675 | |P | |V | + | |Unsigned32| | | | | + +---------------------------------+----------+----+---+------+----+ + + Table 1: AVPs for the Diameter Group Signaling + +7.1. Session-Group-Info AVP + + The Session-Group-Info AVP (AVP Code 671) is of type Grouped. It + contains the identifier of the session group, as well as an + indication of the node responsible for session group identifier + assignment. + + Session-Group-Info ::= < AVP Header: 671 > + < Session-Group-Control-Vector > + [ Session-Group-Id ] + * [ AVP ] + +7.2. Session-Group-Control-Vector AVP + + The Session-Group-Control-Vector AVP (AVP Code 672) is of type + Unsigned32 and contains a 32-bit flag field to control the group + assignment at session-group-aware nodes. For defined flags, only + numeric values that are 2^x (power of two, where 0<=x<32) are + allowed. + + The following control flags are defined in this document: + + SESSION_GROUP_ALLOCATION_ACTION (0x00000001) + + This flag indicates the action to be performed for the identified + session. When this flag is set, it indicates that the identified + Diameter session is to be assigned to the session group identified + by the Session-Group-Id AVP or the session's assignment to the + session group identified in the Session-Group-Id AVP is still + valid. When the flag is cleared, the identified Diameter session + is to be removed from at least one session group. When the flag + is cleared and the Session-Group-Info AVP identifies a particular + session group in the associated Session-Group-Id AVP, the session + is to be removed solely from the identified session group. When + the flag is cleared and the Session-Group-Info AVP does not + identify a particular session group (Session-Group-Id AVP is + absent), the identified Diameter session is to be removed from all + session groups to which it has been previously assigned. + + SESSION_GROUP_STATUS (0x00000010) + + This flag indicates the status of the session group identified in + the associated Session-Group-Id AVP. The flag is set when the + identified session group has just been created or is still active. + If the flag is cleared, the identified session group is deleted + and the associated Session-Group-Id is released. If the Session- + Group-Info AVP does not include a Session-Group-Id AVP, this flag + is meaningless and MUST be ignored by the receiver. + +7.3. Session-Group-Id AVP + + The Session-Group-Id AVP (AVP Code 673) is of type UTF8String and + identifies a group of Diameter sessions. + + The Session-Group-Id MUST be globally unique. The Session-Group-Id + includes a mandatory portion and an implementation-defined portion + delimited by the ";" character. The Session-Group-Id MUST begin with + the identity of the Diameter node that owns the session group. The + remainder of the Session-Group-Id is implementation defined and MAY + follow the format recommended for the implementation-defined portion + of the Session-Id AVP in Section 8.8 of [RFC6733]. + +7.4. Group-Response-Action AVP + + The Group-Response-Action AVP (AVP Code 674) is of type Unsigned32 + and contains a 32-bit address space representing values indicating + how the node SHOULD issue follow-up exchanges in response to a + command that impacts multiple sessions. The following values are + defined by this document: + + ALL_GROUPS (1) + Follow-up message exchanges associated with a group command should + be performed with a single message exchange for all impacted + groups. + + PER_GROUP (2) + Follow-up message exchanges associated with a group command should + be performed with a separate message exchange for each impacted + group. + + PER_SESSION (3) + Follow-up message exchanges associated with a group command should + be performed with a separate message exchange for each impacted + session. + +7.5. Session-Group-Capability-Vector AVP + + The Session-Group-Capability-Vector AVP (AVP Code 675) is of type + Unsigned32 and contains a 32-bit flag field to indicate capabilities + in the context of session-group assignment and group operations. For + defined flags, only numeric values that are 2^x (power of two, where + 0<=x<32) are allowed. The value of (0) is reserved. + + The following capability is defined in this document: + + BASE_SESSION_GROUP_CAPABILITY (0x00000001) + + This flag indicates the capability to support session grouping and + session group operations according to this specification. + +8. Result-Code AVP Values + + This document does not define new Result-Code [RFC6733] values for + existing applications, which are extended to support group commands. + Documents specifying new applications, which will have intrinsic + support for group commands, may specify new Result-Codes. + +9. IANA Considerations + + This section contains the namespaces that have either been created in + this specification or had their values assigned to existing + namespaces managed by IANA. + +9.1. AVP Codes + + IANA has registered the following new AVPs from the "AVP Codes" + registry defined in [RFC6733]. The AVPs are defined in Section 7. + + * Session-Group-Info + + * Session-Group-Control-Vector + + * Session-Group-Id + + * Group-Response-Action + + * Session-Group-Capability-Vector + +9.2. New Registries + + IANA has created the following two new registries. + + * The "Session-Group-Control-Vector AVP Values (code 672)" registry + for control bits. Two initial assignments are described in + Section 7.2. The registration assignment policy is Specification + Required. + + * The "Session-Group-Capability-Vector AVP Values (code 675)" + registry. One initial assignment is described in Section 7.5. + The registration assignment policy is Standards Action. + +10. Security Considerations + + The security considerations of the Diameter protocol itself are + discussed in [RFC6733]. Use of the AVPs defined in this document + MUST take into consideration the security issues and requirements of + the Diameter base protocol. In particular, the Session-Group-Info + AVP (including the Session-Group-Control-Vector and the Session- + Group-Id AVPs) should be considered as a security-sensitive AVP in + the same manner as the Session-Id AVP in the Diameter base protocol + [RFC6733]. + + The management of session groups relies upon the existing trust + relationship between the Diameter client and the Diameter server + managing the groups of sessions. This document defines a mechanism + that allows a client or a server to act on multiple sessions at the + same time using only one command. If the Diameter client or server + is compromised, an attacker could launch DoS attacks by terminating + or applying change operations to a large number of sessions with a + limited set of commands using the session group management concept. + + According to the Diameter base protocol [RFC6733], transport + connections between Diameter peers are protected by TLS/TCP, DTLS / + Stream Control Transmission Protocol (SCTP), or alternative security + mechanisms that are independent of Diameter, such as IPsec. However, + the lack of end-to-end security features makes it difficult to + establish trust in the session-group-related information received + from non-adjacent nodes. Any Diameter agent in the message path can + potentially modify the content of the message and therefore the + information sent by the Diameter client or the server. There is + ongoing work on the specification of end-to-end security features for + Diameter. Such features would enable the establishment of a trust + relationship between non-adjacent nodes, and the security required + for session group management would normally rely on this end-to-end + security. However, there is no assumption in this document that such + end-to-end security mechanism will be available. It is only assumed + that the solution defined on this document relies on the security + framework provided by the Diameter-based protocol. + + In some cases, a Diameter Proxy Agent can act on behalf of a client + or a server. In such case, the security requirements that normally + apply to a client (or a server) apply equally to the Proxy Agent. + +11. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, + Ed., "Diameter Base Protocol", RFC 6733, + DOI 10.17487/RFC6733, October 2012, + <https://www.rfc-editor.org/info/rfc6733>. + + [RFC7155] Zorn, G., Ed., "Diameter Network Access Server + Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, + <https://www.rfc-editor.org/info/rfc7155>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +Appendix A. Session Management -- Exemplary Session State Machine + +A.1. Use of Groups for the Authorization Session State Machine + + Section 8.1 of [RFC6733] defines a set of finite state machines that + represent the life cycle of Diameter sessions, which must be observed + by all Diameter implementations that make use of the authentication + and/or authorization portion of a Diameter application. This section + defines, for example, additional state transitions related to the + processing of the group commands that may impact multiple sessions. + + The group membership is a session state, and therefore only those + state machines from [RFC6733] in which the server is maintaining + session state are relevant in this document. As in [RFC6733], the + term 'service-specific' below refers to a message defined in a + Diameter application (e.g., Mobile IPv4 or NASREQ). + + The following state machine is observed by a client when the state is + maintained on the server. State transitions that are unmodified from + [RFC6733] are not repeated here. + + The Diameter group command in the following tables is differentiated + from a single-session-related command by a preceding 'G' (Group). A + Group Re-Auth Request, which applies to one or multiple session + groups, has been exemplarily described in Section 6.1. Such Group + RAR command is denoted as 'GRAR' in the following table. The same + notation applies to other commands, as per [RFC6733]. + + Additionally, the following acronyms are used in the tables below. + + GASR: Group-Abort-Session-Request + + GASA: Group-Abort-Session-Answer + + GSTA: Group-Session-Termination-Answer + + GSTR: Group-Session-Termination-Request + + +=================================================================+ + | CLIENT, STATEFUL | + +=========+==========================+==================+=========+ + | State | Event | Action | New | + | | | | State | + +=========+==========================+==================+=========+ + | Idle | Client or Device | Send service- | Pending | + | | Requests access | specific | | + | | | authorization | | + | | | req optionally | | + | | | including groups | | + +---------+--------------------------+------------------+---------+ + | Open | GASR received with | Send GASA | Discon | + | | Group-Response-Action = | Result-Code = | | + | | ALL_GROUPS, session is | SUCCESS, Send | | + | | assigned to received | GSTR | | + | | group(s) and client will | | | + | | comply with request to | | | + | | end the session | | | + +---------+--------------------------+------------------+---------+ + | Open | GASR received with | Send GASA with | Discon | + | | Group-Response-Action = | Result-Code = | | + | | PER_GROUPS, session is | SUCCESS, Send | | + | | assigned to received | GSTR per group | | + | | group(s) and client will | | | + | | comply with request to | | | + | | end the session | | | + +---------+--------------------------+------------------+---------+ + | Open | GASR received with | Send GASA with | Discon | + | | Group-Response-Action = | Result-Code = | | + | | PER_SESSION, session is | SUCCESS, Send | | + | | assigned to received | STR per session | | + | | group(s) and client will | | | + | | comply with request to | | | + | | end the session | | | + +---------+--------------------------+------------------+---------+ + | Open | GASR received, client | Send GASA with | Open | + | | will not comply with | Result-Code != | | + | | request to end all | SUCCESS | | + | | sessions in received | | | + | | group(s) | | | + +---------+--------------------------+------------------+---------+ + | Discon | GSTA received | Discon. user/ | Idle | + | | | device | | + +---------+--------------------------+------------------+---------+ + | Open | GRAR received with | Send GRAA, Send | Pending | + | | Group-Response-Action = | service-specific | | + | | ALL_GROUPS, session is | group re-auth | | + | | assigned to received | req | | + | | group(s) and client will | | | + | | perform subsequent re- | | | + | | auth | | | + +---------+--------------------------+------------------+---------+ + | Open | GRAR received with | Send GRAA, Send | Pending | + | | Group-Response-Action = | service-specific | | + | | PER_GROUP, session is | group re-auth | | + | | assigned to received | req per group | | + | | group(s) and client will | | | + | | perform subsequent re- | | | + | | auth | | | + +---------+--------------------------+------------------+---------+ + | Open | GRAR received with | Send GRAA, Send | Pending | + | | Group-Response-Action = | service-specific | | + | | PER_SESSION, session is | re-auth req per | | + | | assigned to received | session | | + | | group(s) and client will | | | + | | perform subsequent re- | | | + | | auth | | | + +---------+--------------------------+------------------+---------+ + | Open | GRAR received and client | Send GRAA with | Idle | + | | will not perform | Result-Code != | | + | | subsequent re-auth | SUCCESS, Discon. | | + | | | user/device | | + +---------+--------------------------+------------------+---------+ + | Pending | Successful service- | Provide service | Open | + | | specific group re- | | | + | | authorization answer | | | + | | received | | | + +---------+--------------------------+------------------+---------+ + | Pending | Failed service-specific | Discon. user/ | Idle | + | | group re-authorization | device | | + | | answer received | | | + +---------+--------------------------+------------------+---------+ + + Table 2: Group Authorization Session State Machine for Stateful + Client + + The following state machine is observed by a server when it is + maintaining the state for the session. State transitions that are + unmodified from [RFC6733] are not repeated here. + + +================================================================+ + | SERVER, STATEFUL | + +=========+========================+===================+=========+ + | State | Event | Action | New | + | | | | State | + +=========+========================+===================+=========+ + | Idle | Service-specific | Send successful | Open | + | | authorization request | service-specific | | + | | received, and user is | answer optionally | | + | | authorized | including groups | | + +---------+------------------------+-------------------+---------+ + | Open | Server wants to | Send GASR | Discon | + | | terminate group(s) | | | + +---------+------------------------+-------------------+---------+ + | Discon | GASA received | Cleanup | Idle | + +---------+------------------------+-------------------+---------+ + | Any | GSTR received | Send GSTA, | Idle | + | | | Cleanup | | + +---------+------------------------+-------------------+---------+ + | Open | Server wants to reauth | Send GRAR | Pending | + | | group(s) | | | + +---------+------------------------+-------------------+---------+ + | Pending | GRAA received with | Update session(s) | Open | + | | Result-Code = SUCCESS | | | + +---------+------------------------+-------------------+---------+ + | Pending | GRAA received with | Cleanup | Idle | + | | Result-Code != SUCCESS | session(s) | | + +---------+------------------------+-------------------+---------+ + | Open | Service-specific group | Send successful | Open | + | | re-authorization | service-specific | | + | | request received and | group re-auth | | + | | user is authorized | answer | | + +---------+------------------------+-------------------+---------+ + | Open | Service-specific group | Send failed | Idle | + | | re-authorization | service-specific | | + | | request received and | group re-auth | | + | | user is not authorized | answer, Cleanup | | + +---------+------------------------+-------------------+---------+ + + Table 3: Group Authorization Session State Machine for + Stateful Server + +Acknowledgments + + The authors of this document want to thank Ben Campbell and Eric + McMurry for their valuable comments to early draft versions of this + document. Furthermore, the authors thank Steve Donovan and Mark + Bales for the thorough review and comments on advanced versions of + the WG document, which helped a lot to improve this specification. + +Authors' Addresses + + Mark Jones + Individual + Email: mark@azu.ca + + + Marco Liebsch + NEC Laboratories Europe GmbH + Kurfuersten-Anlage 36 + D-69115 Heidelberg + Germany + Email: marco.liebsch@neclab.eu + + + Lionel Morand + Orange Labs + 38/40 rue du General Leclerc + 92794 Issy-Les-Moulineaux Cedex 9 + France + Email: lionel.morand@orange.com |