RFC 9390
Diameter Group Signaling
Diameter Group Signaling 💖
okay bestie, this is RFC 9390, and it's a Standards Track doc from the Internet Engineering Task Force (IETF) 🎀. It was written by M. Jones (Individual), M. Liebsch (NEC) and L. Morand (Orange), dated April 2023, ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates ✨
Abstract 🌸
In big network deployments, a single Diameter node can handle over a million concurrent Diameter sessions 😭 Sometimes those nodes need to apply the same operation to a huge group of sessions at once. The Diameter base protocol commands only work on one session at a time, so these cases can turn into many thousands of command exchanges doing the exact same thing to every session in the group 💀 To cut down on signaling, it's way better to run bulk operations on all (or some) of the sessions a Diameter node manages, using one or a few command exchanges. This document specifies the Diameter protocol extensions that make this optimization happen 💅
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.
Info about the current status of this document, any errata, and how to give feedback on it can be found 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, because 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 they 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' Addresses1. Introduction 🌈
In big network deployments, one Diameter node can support over a million concurrent Diameter sessions 🤯 Sometimes Diameter nodes need to apply the same operation to a large group of sessions at the same time. For example, a policy decision point might need to change the authorized quality of service for every active user who has the same type of subscription. The Diameter base protocol commands work on a single session, so these cases can end up with many thousands of command exchanges enforcing the same operation on each session in the group. To reduce signaling, it's super desirable to run bulk operations on all (or part of) the sessions managed by a Diameter node with a single command exchange or just a few 💅
This document describes ways to group Diameter sessions and apply Diameter commands to the whole group. Those commands include re-authentication, re-authorization, termination, and abortion of sessions. This document does not define a new Diameter application. Instead, it defines mechanisms, commands, and Attribute-Value Pairs (AVPs) that any Diameter application can use if it needs to manage groups of sessions 🦋
These mechanisms are built around the following design goals and features:
- 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 🍓
To make bulk operations on Diameter sessions possible, the concept of session groups is introduced. Once sessions are added to a group, a command acting on the group affects all of its member sessions 👑
The client and the server can both assign a new Diameter session to a group. For example, that happens when the subscription profile of the associated user has similar characteristics to the profiles of other users whose sessions were already assigned to one or more groups. A single command can be issued and applied to all sessions associated with one or more such groups, for example to adjust common profile or policy settings 💖
Assigning a Diameter session to a group can change 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 its current group and assign it to a different group that fits the new subscription profile better 🌸
With mobile users, a user's session may get transferred mid-session to a new Diameter client during handover, and then it gets assigned to a different group that is maintained at the new Diameter client 🛸
Sometimes a session group needs to be deleted, for example when a promotional period that applied to several subscriber profiles ends. Deleting such a group requires individual treatment of each of the sessions that were assigned to it afterward. A node may decide to assign some of these sessions to any other existing or new group 🙈
3.2. Issuing Group Commands 🌷
Changes in network conditions may lead the Diameter server to decide to close all sessions in a given group. For example, the server issues a single Session Termination Request (STR) command that includes the identifier of the group of sessions to be terminated. The Diameter client treats the STR as a group command and starts terminating all sessions associated with the identified group. Then the client confirms to the server that these sessions were terminated successfully by sending a single Session Termination Answer (STA) command, which includes the identifier of the group 🥹
3.3. Permission Considerations 🔐
Permission considerations here cover which Diameter nodes are allowed to build new session groups, to assign or remove a session to or from a session group, and to delete an existing session group 🗝️
When a client or server decides to create a new session group, for example to group all sessions that share certain characteristics, that node builds a session group identifier according to the rules in Section 7.3 and becomes the owner of the group 👑
After a session group has been created, either the client or the server can add a session to it. However, a session can only be removed from a session group by the Diameter node (client or server) that assigned that session to the group 🚫
A session group can only be deleted by its owner, which results in individual treatment of the sessions that were assigned to that 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 owned by the server. Details about enforcing a more constrained permission model are out of scope for 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's no need for a specific discovery mechanism for session grouping capability, beyond discovering the Application Id assigned to the application that gets 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 that case, the optional Session-Group-Capability-Vector AVP, described in Section 4.1.2, can be left out of the Diameter messages exchanged between nodes 🦋
4.1.2. Capability Discovery Based on AVP Presence ✨
Okay bestie, so this part is about how nodes figure out who can do session grouping when nothing else is set up for discovery 👀. If no other mechanism is deployed, a Diameter node SHOULD tack the Session-Group-Capability-Vector AVP onto any Diameter application messages it swaps with other nodes. That's how it announces it can do session grouping and session group operations for the advertised application 📣. Implementations following this spec MUST set the BASE_SESSION_GROUP_CAPABILITY flag in that AVP 💅.
When a Diameter node gets at least one Session-Group-Capability-Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag set, the receiver learns what session grouping capability the sender has for that application 🧠. It MUST cache this info for the lifetime of the routing table entry tied to the peer identity / Application Id pair (see Section 2.7 of [RFC6733]) 🗂️🫶.
4.2. Session Grouping 🦋
This spec doesn't cap how many session groups a single session can belong to 🌈. That's up to the application to decide. If an application lets a session belong to multiple session groups, the application MUST maintain consistency of associated application session states for those multiple session groups 🔥.
Either Diameter node (client or server) can kick off assigning a session to one or more session groups 🎀. Changing a group by adding or removing one or more user sessions can happen mid-session too, started by either Diameter node that's responsible for that session's assignment to the group. Diameter is peer-to-peer, but Diameter Authentication, Authorization, and Accounting (AAA) applications usually give the "Diameter client" role to the node that starts the Diameter session, and the "Diameter server" role to the node that authorizes it 👑. This spec doesn't tie group creation, assignment, or deletion to a specific role, so from here on, "Diameter node" means either role 💜. Section 5 covers the particulars of session grouping and group commands when relay agents or proxies are involved 🧚.
Any Diameter node that has advertised support for session grouping and group operations MUST store and maintain the group assignment as part of the session's state 💖. Each node keeps a list of all the session groups it knows about, and each group points to the sessions assigned to it 🍓. On top of that, each Diameter node MUST also keep a record of the sessions it has assigned to a session group 😭.
4.2.1. Group Assignment at Session Initiation 🚀
Here's how a session gets into a group right at the start 🫶. A Diameter client sends a service-specific request, like a Network Access Server Requirements (NASREQ) AA-Request [RFC7155], that includes one or more session group identifiers. Each group MUST be identified by a unique Session-Group-Id inside its own Session-Group-Info AVP, as specified in Section 7 ✨.
The client can pick one or more groups from the list of existing ones 🌸. Or it can create a brand new group for the session and identify itself in the <DiameterIdentity> portion of the Session-Group-Id AVP, as per Section 7.3 💅. For every assignment of a session to an active session group, whether the client or the server made it, the SESSION_GROUP_STATUS flag in the Session-Group-Info AVP that identifies the group MUST be set 🔥. When that flag is set, it means the group was just created or is still active 💫.
The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP in each Session-Group-Info AVP it appends, which tells the server the session in the request should be assigned to that group 🎯. The client can also say it's cool with the server assigning the session to one or more groups on its own. In that case, the client MUST include the Session-Group-Info AVP in the request, with the Session-Group-Control-Vector AVP carrying the SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP 🧁.
If the Diameter server gets a command request from a Diameter client, and the command has at least one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set in its Session-Group-Control-Vector AVP, the server gets to choose 🤔. It can accept or reject the group assignment request. Rejection could happen for stuff like not having enough resources to manage more groups. If it's rejected, the session MUST NOT be assigned to any session group 🙅♀️.
If the server accepts the client's group assignment request, the server MUST assign the new session to each of the identified session groups (one or more) that appear in the Session-Group-Info AVP. If any of the identified groups aren't already stored on the server, the server MUST store those newly identified groups in its local list of known session groups 📝. When it replies to the client (for example, with a service-specific authorization response, as per NASREQ AA-Answer [RFC7155]), the server MUST include all the Session-Group-Info AVPs it got in the client's request 💌.
On top of the groups the client asked for, the server can also decide to put the new session in one or more extra groups 🌟. If it does, the server MUST add those extra Session-Group-Info AVPs to the response, with each one identifying a group the server assigned the new session to. Every Session-Group-Info AVP the server adds MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in its Session-Group-Control-Vector AVP 🦄.
If the server rejects the client's group assignment request, it still replies to the client (with a service-specific authorization response, as per NASREQ AA-Answer [RFC7155]). It MUST include all the Session-Group-Info AVPs it got in the client's request (if there were any), but it MUST clear the SESSION_GROUP_ALLOCATION_ACTION flag in each Session-Group-Control-Vector AVP 🧹. The server MAY still accept the client's request for the session to go ahead even though it rejected the group assignment ✅. In that case, the response to the client shows success in the result code, and the session is treated as a single session with no group assignment from any Diameter node 🦋.
If assigning the session to some or all of the multiple identified groups fails, the whole group assignment counts as a failure 💀. The session is then treated as a single session with no group assignment from any Diameter node. The server sends the response to the client, and it MAY include the Session-Group-Info AVPs for the groups where the assignment failed 🙈. The SESSION_GROUP_ALLOCATION_ACTION flag of any included Session-Group-Info AVPs MUST be cleared 🧼.
If the Diameter server gets a command request from a Diameter client, and the command includes a Session-Group-Info AVP that doesn't have a Session-Group-Id AVP, the server MAY decide to assign the session to one or more session groups 🎲. For each group it assigns the new session to, the server includes a Session-Group-Info AVP with the Session-Group-Id AVP, identifying that group in the response to the client 💜. Each Session-Group-Info AVP the server includes MUST have the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP set ✨.
If the Diameter server gets a command request from a Diameter client, and the command doesn't contain any Session-Group-Info AVPs, the server MUST NOT assign the new session to any session group. It treats the request the same way it would a single session 🙃. The server MUST NOT return any Session-Group-Info AVP in the command response 🚫.
If the Diameter client gets a response to its earlier 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 the session groups identified in one or more Session-Group-Info AVPs 🥰. If the client fails to add the session to one or more of those groups, the client MUST terminate the session 💔. The client MAY send a later session initiation request to the server without asking for a group assignment 🌷.
If the Diameter client gets a response to its earlier 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 group assignment for one or more groups 🛑. If the response shows success in the result code but the server rejected only the group assignment, the client treats the session as a single session with no group assignment 🎀.
If a Diameter client sends a session initiation request with one or more Session-Group-Info AVPs, but the response from the Diameter server doesn't contain a Session-Group-Info AVP, the Diameter client MUST proceed as though the request was processed without group assignments 🫠. The Diameter client MUST NOT retry the group assignment for this session, but it MAY try to request group assignment for other new sessions 🌈✨.
4.2.2. Removing a Session from a Session Group
okay bestie, so when a Diameter client wants to kick a session out of a group 🙅♀️, it sends a service-specific re-authorization request to the server and tacks on one Session-Group-Info AVP for each group it wants the session to leave 💅. The session being removed is named in the Session-Id AVP of that command request. Inside each Session-Group-Info AVP, the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-Control-Vector AVP MUST be cleared to mean "remove," and the group it applies to is whichever one is named in the matching Session-Group-Id AVP 🎀.
when the client wants out of every group the session has joined 😭, it's a little different. It sends the same kind of re-auth request, but this time it adds just one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP left out entirely. The Session-Id AVP in that request is what tells the server which session we're talking about 🦋.
now the server's side ✨. If the server gets a request with at least one Session-Group-Info AVP that has the SESSION_GROUP_ALLOCATION_ACTION flag cleared, it MUST remove the session from the group named in the associated Session-Group-Id AVP. If the request has at least one Session-Group-Info AVP with the flag cleared and there's no Session-Id AVP present, the server MUST remove the session from all session groups it had previously been assigned to. Either way, the server MUST include in its response to the client every Session-Group-Id AVP it received in the request 🫶.
the server can also start this whole thing itself 🧚. When it decides to remove a session from one or more particular groups, or from all the groups the session was already in, it sends a Re-Auth-Request (RAR) or a service-specific server-initiated request to the client, with the session named in the Session-Id AVP. The client replies with a Re-Auth-Answer (RAA) or a service-specific answer. Then the client sends a service-specific re-authorization request holding one or more Session-Group-Info AVPs, each one naming a group the session had been assigned to before 🌸.
to take the session out of one or more specific groups, the server sends a service-specific authorization response with a list of Session-Group-Info AVPs that have the SESSION_GROUP_ALLOCATION_ACTION flag cleared and a Session-Group-Id AVP identifying the group the session should leave. The server MAY also include, in that same response, a list of Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and Session-Group-Id AVPs for the groups the session stays subscribed to 💜. And if the server wants the session gone from all its previously assigned groups 💀, it includes at least one Session-Group-Info AVP with the flag cleared and the Session-Group-Id AVP absent.
4.2.3. Mid-session Group Assignment Modifications
okay so either Diameter node (client or server) is allowed to change the group membership of an active Diameter session 🔥, as long as it follows the permission considerations.
to update an assigned group mid-session, a Diameter client sends a service-specific re-authorization request to the server. That request contains one or more Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP present, naming the group the session should be assigned to 🍓. In that same message, the client MAY also send one or more Session-Group-Info AVPs with the flag cleared and a Session-Group-Id AVP naming a group the session should be removed from. If the client wants the session out of all of its previously assigned groups, it includes at least one Session-Group-Info AVP with the flag cleared and no Session-Group-Id AVP present.
when the server gets that re-auth request, it MUST update its locally maintained view of the session groups for the identified session according to the appended Session-Group-Info AVPs 🧠. Then it sends back a service-specific authorization response containing one or more Session-Group-Info AVPs with the flag set and a Session-Group-Id AVP identifying the new group the session has been assigned to ✨.
the server can start a mid-session update too 🌈. When a Diameter server decides to update the assigned groups, it sends a Re-Auth-Request (RAR) message or a service-specific request to the client, identifying the session whose group lists need updating. The client answers with a Re-Auth-Answer (RAA) message or a service-specific answer. After that, the client sends a service-specific re-authorization request with one or more Session-Group-Info AVPs that have the flag set and a Session-Group-Id AVP naming the group the session had been assigned to before 🦋.
the server then replies with a service-specific authorization response that includes one or more Session-Group-Info AVPs with the flag set and a Session-Group-Id AVP naming the group the session is to be assigned to 🎀. In that same response, the server MAY send one or more Session-Group-Info AVPs with the flag cleared and Session-Group-Id AVPs naming the groups the session is to be removed from. And if the server wants to pull the session out of all its previously assigned groups, it sends at least one Session-Group-Info AVP in the response with the flag cleared and no Session-Group-Id AVP present 😭.
4.3. Deleting a Session Group
okay so to explicitly delete a session group and free up its Session-Group-Id value 🗑️, the owner of the group appends a single Session-Group-Info AVP with the SESSION_GROUP_STATUS flag cleared and a Session-Group-Id AVP identifying the group being deleted. The SESSION_GROUP_ALLOCATION_ACTION flag in the associated Session-Group-Control-Vector AVP MUST be cleared too 💅.
and here's the thing: a session group also gets deleted on its own 🙈. Once the last session has been removed from it, the group is implicitly deleted and its identifier is released. No drama, it just happens 💜.
4.4. Performing Group Operations
4.4.1. Sending Group Commands
so either Diameter node (client or server) can ask the receiver of a request to run a command for every session assigned to one or more groups 🌍. To do that, the sender lists those groups in the request by appending, for each group the command applies to, a Session-Group-Info AVP that includes the Session-Group-Id AVP for that 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, then the Session-Id AVP MUST identify one of the single sessions that is assigned to at least one of the groups named in the appended Session-Group-Id AVPs 🧚.
the sender MUST also tell the receiver how the multiple resulting transactions for a group command should be handled 🫶. It does this 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 tells the client to follow one of three possible procedures:
- When the server sets the
Group-Response-ActionAVP toALL_GROUPS (1), the client sends a single RAR message for all identified groups 🌈. - When the server sets the
Group-Response-ActionAVP toPER_GROUP (2), the client sends a single RAR message for each identified group individually 🍓. - When the server sets the
Group-Response-ActionAVP toPER_SESSION (3), the client follows up with a single RAR message per impacted session 🎀.
if a session shows up in more than one of the identified session groups, the client only sends one RAR message for that session 💖.
heads up, though 😬. If the sender uses ALL_GROUPS (1) or PER_GROUP (2) in the Group-Response-Action AVP, it has to expect some delay before any answers come back, because the answers only get sent once the request has been processed for all the sessions, or for 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) 🙅♀️. But if the answer can go out before the whole request is processed for all sessions, or if the request timeout timer is high enough, the sender MAY set it to ALL_GROUPS (1) or PER_GROUP (2) 🦋.
and if the sender only wants the receiver to run the command for a single session? No groups needed 🌸. The sender doesn't append any group identifier at all, and just names that one session in the Session-Id AVP 💅.
4.4.2. Receiving Group Commands
when a Diameter node gets a request to run a command for a group of sessions, it figures out which groups are relevant from the Session-Group-Id AVP inside each Session-Group-Info AVP ✨. It then runs the group command according to the Group-Response-Action AVP that came with it 🧚.
if the request names multiple groups across multiple Session-Group-Id AVPs, the receiver SHOULD process the associated command for each of those groups 🌈. And here's the important bit 👑: 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. No double-dipping, periodt 💜.
4.4.3. Error Handling for Group Commands 🚨
Okay, bestie, what happens when a group command goes sideways? 😭 If a Diameter node gets a request to process a command for one or more session groups and the processing ends in an error that hits every session in those groups, an associated protocol error MUST be returned to the source of the request. The sender then MUST fall back to single-session processing, and the session groups named in the group command MUST be deleted using the procedure in Section 4.3. Whole group gets cleaned up, no cap 🧹
Now the messier case: partial success 🥲 If the command works for some sessions across one or more groups but fails for others, the Result-Code AVP in the response SHOULD indicate DIAMETER_LIMITED_SUCCESS, as per Section 7.1.2 of [RFC6733]. It's giving "some of you did great, some of you didn't" 💅
In limited success, the sessions that failed MUST be identified by putting their Session-Id AVP inside 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 identified session where the group command failed. On top of that, each of those sessions MUST be removed from all the session groups the group command applied to. To pull sessions out of a session group, the Diameter client does the procedure in Section 4.2.2. Main character energy for the failed ones: they get pulled out and handled solo 🦋
4.4.4. Single-Session Fallback 🧚
Either Diameter node can fall back to single-session operation. It just ignores and omits the optional group-session-specific AVPs. The fallback works by processing the Diameter command only for the session named in the mandatory Session-Id AVP. In that case, the response to the group command MUST NOT include any group identifier. It only carries the Session-Id for the session that got processed 💖
5. Operation with Proxy Agents 🤝
Say there's a stateful Proxy Agent sitting between a Diameter client and a Diameter server. It MUST perform the same mechanisms this specification describes to advertise session grouping and group operation capabilities toward the client and the server, respectively. It MUST also update and maintain consistency of its local session states based on the results of the group commands running between the client and the server. The Proxy Agent MUST act as a Diameter server in front of the client and MUST act as a Diameter client in front of the server. So the client and server behaviour from 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 the client and the server. This covers a setup where the Proxy Agent uses session grouping and runs group operations with, say, a Diameter server, while the Diameter client has no idea session groups exist. In that situation, the Proxy Agent must reflect the states tied to the session groups as individual session operations toward the client, so the client still sees a consistent view of each session 🫶 The same goes for a setup where everyone is group aware (client, server, and Proxy Agent), but the Proxy Agent changes the groups anyway, for example to apply different administrative policies to the client's domain and the server's domain. Policy plot twist 🎭
Stateless Proxy Agents don't keep any session states. They only keep transaction states. So a session group is basically invisible to any stateless Proxy Agent sitting between a Diameter client and a Diameter server that handles session groups 👻 Session-group-related AVPs are defined as optional AVPs, so stateless Proxy Agents ignore them, and they should not be removed from the Diameter commands. If a Proxy Agent removes them for any reason anyway, the Diameter client and Diameter server will notice the missing session-group-related AVPs and fall back to single-session processing, as described in Section 4. Oops, but at least the fallback is built in 🙈
6. Commands Formatting 🎀
This document doesn't define any new Diameter commands for group operations. It leans on command extensibility and the capabilities the Diameter Base protocol already gives us. This section gives the guidelines for extending the CCF of existing Diameter commands with optional AVPs, so the recipient can apply the command to all sessions tied to the identified group or groups 🌸
6.1. Formatting Example: Group Re-Auth-Request 🔁
Here's the vibe: a request to re-authenticate one or more groups of users gets one or more Session-Group-Id AVPs appended, plus a single Group-Response-Action AVP on the Re-Auth-Request (RAR). The Session-Group-Id AVPs name the groups that want group re-authentication. The Group-Response-Action AVP says how the group command is expected to be carried out and responded to. The recipient then starts re-authentication for every user in the named group or groups. The sender can also add a Group-Response-Action AVP to give the receiver more info about how to pull off the group operation 🧠
The value of the mandatory Session-Id AVP MUST identify a session tied to a single user, and that user MUST be assigned to at least one of the groups named in the appended Session-Group-Id AVPs. Here's the grammar:
<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) 💅
Here's the full lineup of AVPs for group signaling. Get ready for the table 📋
+=================================+==========+====================+
| 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 carries the identifier of the session group, plus info on which node is responsible for assigning the session group identifier. It's the whole package 🎁
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. It holds a 32-bit flag field that controls group assignment at session-group-aware nodes. For the flags that are defined, only numeric values that are 2^x (a power of two, where 0<=x<32) are allowed. Math rules, bestie 🔢
This document defines the following control flags:
SESSION_GROUP_ALLOCATION_ACTION (0x00000001)
This flag sets the action for the identified session. When it's set, the identified Diameter session gets assigned to the session group named in the Session-Group-Id AVP, or its existing assignment to that group is still valid. When it's cleared, the identified Diameter session gets removed from at least one session group. If it's cleared and the Session-Group-Info AVP names a particular session group in its Session-Group-Id AVP, the session is removed only from that group. If it's cleared and the Session-Group-Info AVP doesn't name a particular session group (the Session-Group-Id AVP is absent), the identified Diameter session gets removed from every session group it was previously assigned to 🚪
SESSION_GROUP_STATUS (0x00000010)
This flag shows the status of the session group named in the associated Session-Group-Id AVP. It's set when the group has just been created or is still active. If it's cleared, the identified session group is deleted and its Session-Group-Id is released. If the Session-Group-Info AVP doesn't include a Session-Group-Id AVP, this flag is meaningless and MUST be ignored by the receiver. Nothing to see here, just ignore it 🫠
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. It has a mandatory portion and an implementation-defined portion, separated by the ";" character. The Session-Group-Id MUST begin with the identity of the Diameter node that owns the session group. The rest 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]. Unique IDs, no duplicates, periodt 💜
7.4. Group-Response-Action AVP 🎀
okay so the Group-Response-Action AVP (674) is an Unsigned32 and it's basically a 32-bit address space 🌸 holding values that tell the node how it SHOULD send follow-up exchanges after a command hits multiple sessions. bestie, this is giving "who gets the follow-up message and how" 💅 The values defined in this document are:
ALL_GROUPS(1): follow-up message exchanges for a group command should be done with one single message exchange covering all the impacted groups. 🦋PER_GROUP(2): follow-up message exchanges for a group command should be done with a separate message exchange for each impacted group. ✨PER_SESSION(3): follow-up message exchanges for a group command should be done with a separate message exchange for each impacted session. 💜
7.5. Session-Group-Capability-Vector AVP 🧚
the Session-Group-Capability-Vector AVP (675) is Unsigned32 and it's a 32-bit flag field 🌈 that shows what a node can do with session-group assignment and group operations. ngl this one is very organized 😭 For the flags that are defined, only numeric values that are 2^x (a power of two, where 0<=x<32) are allowed, and the value (0) is reserved. 🍓
Only one capability is defined in this document:
BASE_SESSION_GROUP_CAPABILITY(0x00000001): this flag means the node can 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 that get extended to support group commands. 🫶 Documents that specify new applications, which will have intrinsic support for group commands, may specify new Result-Codes. that's their call, not ours 💅
9. IANA Considerations 📋
this section lists the namespaces that were either created in this specification or had their values assigned to existing namespaces managed by IANA. it's the paperwork part, but it's important ✨
9.1. AVP Codes 🌸
IANA registered the following new AVPs from the "AVP Codes" registry defined in [RFC6733]. they're all defined in Section 7:
Session-Group-InfoSession-Group-Control-VectorSession-Group-IdGroup-Response-ActionSession-Group-Capability-Vector
9.2. New Registries 🦋
IANA created the following two new registries, iykyk:
- The
"Session-Group-Control-Vector AVP Values (code 672)"registry is 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 💀
okay this section is serious, bestie 😭 read it all the way through.
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 on the existing trust relationship between the Diameter client and the Diameter server that manage the groups of sessions. this document defines a mechanism that lets a client or a server act on multiple sessions at the same time using only one command. so if the Diameter client or server gets 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. that is not it 🙈
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 hard 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 specifying end-to-end security features for Diameter. those features would enable trust between non-adjacent nodes, and the security required for session group management would normally rely on that end-to-end security. however, this document does not assume that such an end-to-end security mechanism will be available. it is only assumed that the solution defined in 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 that 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
Okay so this is the appendix where the authors show us how groups fit into the Diameter session life cycle, bestie 💜 Section 8.1 of [RFC6733] already defines the finite state machines for Diameter sessions, and every Diameter implementation that does authentication and/or authorization has to observe them 🎀 This section adds extra state transitions for the group commands, which can affect multiple sessions at once ✨
Group membership is a session state, so only the [RFC6733] state machines where the server is keeping session state matter here 🦋 Same as in [RFC6733], "service-specific" means a message defined in a Diameter application (like Mobile IPv4 or NASREQ) 🌸
The client state machine below is what a client follows when the server is keeping state. Any transitions that are unchanged from [RFC6733] are not repeated, because we don't need to say it twice 💅
The group commands get a little "G" (for Group) in front of the regular command name 🍓 A Group Re-Auth Request, which can hit one or many session groups, was described as an example back in Section 6.1 🧚 That one is written as GRAR in the tables, and the same naming goes for every other command, as per [RFC6733] 💖
Here are the acronyms we'll see in the tables 🔥
GASR: Group-Abort-Session-Request
GASA: Group-Abort-Session-Answer
GSTA: Group-Session-Termination-Answer
GSTR: Group-Session-Termination-Request
Table 2 is the Group Authorization Session State Machine for a Stateful Client 👑
+=================================================================+
| 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 | | |
+---------+--------------------------+------------------+---------+The server state machine is next, and this one is for when the server is maintaining state for the session 🫶 Again, transitions that are unchanged from [RFC6733] are skipped 🌈
Table 3 is the Group Authorization Session State Machine for a Stateful Server 🌟
+================================================================+
| 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 | |
+---------+------------------------+-------------------+---------+Acknowledgments 🎀
The authors want to give a huge thank-you to Ben Campbell and Eric McMurry for their valuable comments on the early draft versions of this document 💖 They also thank Steve Donovan and Mark Bales for the thorough review and comments on the more advanced versions of the WG document, which helped a lot to make this spec better 👑✨
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
📦 where this page comes from
- ietf: rfc9390 2023-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms