idnits 2.17.1 draft-ietf-dime-group-signaling-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 982 has weird spacing: '...ly with wit...' == Line 1021 has weird spacing: '... answer servi...' == Line 1025 has weird spacing: '... answer user/...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the Diameter server receives a command request from a Diameter client and the command does not contain any Session-Group-Info AVP, the server MUST not assign the new session to any session group but treat the request as for a single session. The server MUST return any Session-Group-Info AVP in the command response. -- The document date (March 21, 2016) is 2956 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) M. Jones 3 Internet-Draft 4 Intended status: Standards Track M. Liebsch 5 Expires: September 22, 2016 6 L. Morand 7 March 21, 2016 9 Diameter Group Signaling 10 draft-ietf-dime-group-signaling-06.txt 12 Abstract 14 In large network deployments, a single Diameter node can support over 15 a million concurrent Diameter sessions. Recent use cases have 16 revealed the need for Diameter nodes to apply the same operation to a 17 large group of Diameter sessions concurrently. The Diameter base 18 protocol commands operate on a single session so these use cases 19 could result in many thousands of command exchanges to enforce the 20 same operation on each session in the group. In order to reduce 21 signaling, it would be desirable to enable bulk operations on all (or 22 part of) the sessions managed by a Diameter node using a single or a 23 few command exchanges. This document specifies the Diameter protocol 24 extensions to achieve this signaling optimization. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 22, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Building and Modifying Session Groups . . . . . . . . . . 4 64 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4 65 3.3. Permission Considerations . . . . . . . . . . . . . . . . 4 66 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Session Grouping Capability Discovery . . . . . . . . . . 7 68 4.1.1. Explicit Capability Discovery . . . . . . . . . . . . 7 69 4.1.2. Implicit Capability Discovery . . . . . . . . . . . . 7 70 4.2. Session Grouping . . . . . . . . . . . . . . . . . . . . 7 71 4.2.1. Group assignment at session initiation . . . . . . . 8 72 4.2.2. Removing a session from a session group . . . . . . . 10 73 4.2.3. Mid-session group assignment modifications . . . . . 11 74 4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 12 75 4.4. Performing Group Operations . . . . . . . . . . . . . . . 12 76 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 12 77 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 13 78 4.4.3. Error Handling for Group Commands . . . . . . . . . . 14 79 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 14 80 5. Operation with Proxies Agents . . . . . . . . . . . . . . . . 14 81 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 15 82 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 15 83 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 16 84 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 16 85 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 17 86 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 17 87 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 18 88 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 18 89 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 18 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 94 12. Normative References . . . . . . . . . . . . . . . . . . . . 20 95 Appendix A. Session Management -- Exemplary Session State 96 Machine . . . . . . . . . . . . . . . . . . . . . . 20 97 A.1. Use of groups for the Authorization Session State Machine 20 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 100 1. Introduction 102 In large network deployments, a single Diameter node can support over 103 a million concurrent Diameter sessions. Recent use cases have 104 revealed the need for Diameter nodes to apply the same operation to a 105 large group of Diameter sessions concurrently. For example, a policy 106 decision point may need to modify the authorized quality of service 107 for all active users having the same type of subscription. The 108 Diameter base protocol commands operate on a single session so these 109 use cases could result in many thousands of command exchanges to 110 enforce the same operation on each session in the group. In order to 111 reduce signaling, it would be desirable to enable bulk operations on 112 all (or part of) the sessions managed by a Diameter node using a 113 single or a few command exchanges. 115 This document describes mechanisms for grouping Diameter sessions and 116 applying Diameter commands, such as performing re-authentication, re- 117 authorization, termination and abortion of sessions to a group of 118 sessions. This document does not define a new Diameter application. 119 Instead it defines mechanisms, commands and AVPs that may be used by 120 any Diameter application that requires management of groups of 121 sessions. 123 These mechanisms take the following design goals and features into 124 account: 126 o Minimal impact to existing applications 128 o Extension of existing commands' Command Code Format (CCF) with 129 optional AVPs to enable grouping and group operations 131 o Fallback to single session operation 133 o Implicit discovery of capability to support grouping and group 134 operations in case no external mechanism is available to discover a 135 Diameter peer's capability to support session grouping and session 136 group operations 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 This document uses terminology defined [RFC6733]. 146 3. Protocol Overview 148 3.1. Building and Modifying Session Groups 150 Client and Server can assign a new Diameter session to a group, e.g. 151 in case the subscription profile of the associated user has similar 152 characteristics as the profile of other users whose Diameter session 153 has been assigned to one or multiple groups. A single command can be 154 issued and applied to all sessions associated with such group(s), 155 e.g. to adjust common profile or policy settings. 157 The assignment of a Diameter session to a group can be changed mid- 158 session. For example, if a user's subscription profile changes mid- 159 session, a Diameter server may remove the session from its current 160 group and assign the session to a different group that is more 161 appropriate for the new subscription profile. 163 In case of mobile users, the user's session may get transferred to a 164 new Diameter client during handover and assigned to a different 165 group, which is maintained at the new Diameter client, mid-session. 167 A session group, which has sessions assigned, can be deleted, e.g. 168 due to a change in multiple users' subscription profile so that the 169 group's assigned sessions do not share certain characteristics 170 anymore. Deletion of such group requires subsequent individual 171 treatment of each of the assigned sessions. A node may decide to 172 assign some of these sessions to any other existing or new group. 174 3.2. Issuing Group Commands 176 Changes in the network condition may result in the Diameter server's 177 decision to close all sessions in a given group. The server issues a 178 single Session Termination Request (STR) command , identifying the 179 group of sessions which are to be terminated. The Diameter client 180 treats the STR as group command and initiates termination of all 181 sessions associated with the identified group. Subsequently, the 182 client confirms successful termination of these sessions to the 183 server by sending a single Session Termination Answer (STA) command, 184 which includes the identifier of the group. 186 3.3. Permission Considerations 188 Permission considerations in the context of this draft apply to the 189 permission of Diameter nodes to build new session groups, to assign/ 190 remove a session to/from a session group and to delete an existing 191 session group. 193 This specification follows the most flexible model where both, a 194 Diameter client and a Diameter server can create a new group and 195 assign a new identifier to that session group. When a Diameter node 196 decides to create a new session group, e.g. to group all sessions 197 which share certain characteristics, the node builds a session group 198 identifier according to the rules described in Section 7.3 and 199 becomes the owner of the group. This specification does not 200 constrain the permission to add or remove a session to/from a session 201 group to the group owner, instead each node can add a session to any 202 known group or remove a session from a group. A session group is 203 deleted and its identifier released after the last session has been 204 removed from the session group. Also the modification of groups in 205 terms of moving a session from one session group to a different 206 session group is permitted to any Diameter node. A Diameter node can 207 delete a session group and its group identifier mid-session, 208 resulting in individual treatment of the sessions which have been 209 previously assigned to the deleted group. Prerequisite for deletion 210 of a session group is that the Diameter node created the session 211 beforehand, hence the node became the group owner. 213 The enforcement of more constrained permissions is left to the 214 specification of a particular group signaling enabled Diameter 215 application and compliant implementations of such application must 216 enforce the associated permission model. Details about enforcing a 217 more constraint permission model are out of scope of this 218 specification. For example, a more constrained model could require 219 that a client MUST NOT remove a session from a group which is owned 220 by the server. 222 The following table depicts the permission considerations as per the 223 present specification: 225 +-------------------------------------------------+--------+--------+ 226 | Operation | Server | Client | 227 +-------------------------------------------------+--------+--------+ 228 | Create a new Session Group (Diameter node | X | X | 229 | becomes the group owner) | | | 230 +-------------------------------------------------+--------+--------+ 231 | Assign a Session to an owned Session Group | X | X | 232 +-------------------------------------------------+--------+--------+ 233 | Assign a Session to a non-owned Session Group | X | X | 234 +-------------------------------------------------+--------+--------+ 235 | Remove a Session from an owned Session Group | X | X | 236 +-------------------------------------------------+-----------------+ 237 | Remove a Session from a non-owned Session Group | X | X | 238 +-------------------------------------------------+--------+--------+ 239 | Remove a Session from a Session Group where the | X | X | 240 | Diameter node created the assignment | | | 241 +-------------------------------------------------+--------+--------+ 242 | Remove a Session from a Session Group where a | | | 243 | different Diameter node created the assignment | | | 244 +-------------------------------------------------+--------+--------+ 245 | Overrule a different Diameter node's | | | 246 | group assignment *) | | | 247 +-------------------------------------------------+--------+--------+ 248 | Delete a Session Group which is owned by the | X | X | 249 | Diameter node | | | 250 +-------------------------------------------------+--------+--------+ 251 | Delete a Session Group which is not owned by | | | 252 | the Diameter node | | | 253 +-------------------------------------------------+--------+--------+ 255 Default Permission as per this Specification 257 *) Editors' note: The protocol specification in this document does 258 not consider overruling a node's assignment of a session to a session 259 group. Here, overruling is to be understood as a node changing the 260 group(s) assignment as per the node's request. Group signaling 261 enabled applications may take such protocol support and associated 262 protocol semantics into account in their specification. One 263 exception is adopted in this specification, which allows a Diameter 264 server to reject a group assignment as per the client's request. 266 4. Protocol Description 267 4.1. Session Grouping Capability Discovery 269 Diameter nodes should assign a session to a session group and perform 270 session group operations with a node only after having ensured that 271 the node announced associated support beforehand. 273 4.1.1. Explicit Capability Discovery 275 New Diameter applications may consider support for Diameter session 276 grouping and for performing group commands during the standardization 277 process. Such applications provide intrinsic discovery for the 278 support of group commands and announce this capability through the 279 assigned application ID. 281 System- and deployment-specific means, as well as out-of-band 282 mechanisms for capability exchange can be used to announce nodes' 283 support for session grouping and session group operations. In such 284 case, the optional Session-Group-Capability-Vector AVP, as described 285 in Section 4.1.2 can be omitted in Diameter messages being exchanged 286 between nodes. 288 4.1.2. Implicit Capability Discovery 290 If no explicit mechanism for capability discovery is deployed to 291 enable Diameter nodes to learn about nodes' capability to support 292 session grouping and group commands, a Diameter node SHOULD append 293 the Session-Group-Capability-Vector AVP to any Diameter messages 294 exchanged with its nodes to announce its capability to support 295 session grouping and session group operations. Implementations 296 following the specification as per this document set the 297 BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability- 298 Vector AVP. 300 When a Diameter node receives at least one Session-Group-Capability- 301 Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag 302 set, the Diameter node maintains a log to remember the node's 303 capability to support group commands. 305 4.2. Session Grouping 307 This specification does not limit the number of session groups, to 308 which a single session is assigned. It is left to the application to 309 determine the policy of session grouping. In case an application 310 facilitates a session to belong to multiple session groups, the 311 application must maintain consistency of associated application 312 session states for these multiple session groups. 314 Either Diameter node (client or server) can initiate the assignment 315 of a session to a single or multiple session groups. Modification of 316 a group by removing or adding a single or multiple user sessions can 317 be initiated and performed mid-session by either Diameter node. 318 Diameter AAA applications typically assign client and server roles to 319 the Diameter nodes, which are referred to as relevant Diameter nodes 320 to utilize session grouping and issue group commands. Section 5 321 describes particularities about session grouping and performing group 322 commands when relay agents or proxies are deployed. 324 Diameter nodes, which are group-aware, must store and maintain an 325 entry about the group assignment together with a session's state. A 326 list of all known session groups should be locally maintained on each 327 node, each group pointing to individual sessions being assigned to 328 the group. A Diameter node must also keep a record about sessions, 329 which have been assigned to a session group by itself. 331 4.2.1. Group assignment at session initiation 333 To assign a session to a group at session initiation, a Diameter 334 client sends a service specific request, e.g. NASREQ AA-Request 335 [RFC4005], containing one or more session group identifiers. Each of 336 these groups needs to be identified by a unique Session-Group-Id 337 contained in a separate Session-Group-Info AVP as specified in 338 Section 7. 340 The client may choose one or multiple session groups from a list of 341 existing session groups. Alternatively, the client may decide to 342 create a new group to which the session is assigned and identify 343 itself in the portion of the Session-Group-Id AVP 344 as per Section 7.3 346 The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the 347 Session-Group-Control-Vector AVP in each appended Session-Group-Info 348 AVP to indicate that the session contained in the request should be 349 assigned to the identified session group. 351 The client may also indicate in the request that the server is 352 responsible for the assignment of the session in one or multiple 353 sessions owned by the server. In such a case, the client MUST 354 includes in the request the Session-Group-Info AVP in the request 355 including the Session-Group-Control-Vector AVP with 356 SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP. 358 If the Diameter server receives a command request from a Diameter 359 client and the command comprises at least one Session-Group-Info AVP 360 having the SESSION_GROUP_ALLOCATION_ACTION flag set in the Session- 361 Group-Control-Vector AVP set, the server can accept or reject the 362 request for group assignment. Reasons for rejection may be e.g. lack 363 of resources for managing additional groups. When rejected, the 364 session must not be assigned to any session group but be treated as 365 single session. 367 If the Diameter server accepts the client's request for a group 368 assignment, the server must assign the new session to each of the one 369 or multiple identified session groups when present in the Session- 370 Group-Info AVP. In case one or multiple identified session groups 371 are not already stored by the server, the server must store the new 372 identified group(s) to its local list of known session groups. When 373 sending the response to the client, e.g. a service-specific auth 374 response as per NASREQ AA-Answer [RFC4005], the server must include 375 all Session-Group-Info AVPs as received in the client's request. 377 In addition to the one or multiple session groups identified in the 378 client's request, the server may decide to assign the new session to 379 one or multiple additional groups. In such a case, the server adds 380 to the response the additional Session-Group-Info AVPs, each 381 identifying a session group to which the new session is assigned by 382 the server. Each of the Session-Group-Info AVP added by the server 383 must have the SESSION_GROUP_ALLOCATION_ACTION flag set in the 384 Session-Group-Control-Vector AVP set. 386 If the Diameter server rejects the client's request for a group 387 assignment, the server sends the response to the client, e.g. a 388 service-specific auth response as per NASREQ AA-Answer [RFC4005], and 389 must include all Session-Group-Info AVPs as received in the client's 390 request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION 391 flag of the Session-Group-Control-Vector AVP. 393 If the Diameter server receives a command request from a Diameter 394 client and the command comprises one or multiple Session-Group-Info 395 AVPs and none of them including a Session-Group-Id AVP, the server 396 MAY decide to assign the session to one or multiple session groups. 397 For each session group, to which the server assigns the new session, 398 the server includes a Session-Group-Info AVP with the Session-Group- 399 Id AVP identifying a session group in the response sent to the 400 client. Each of the Session-Group-Info AVPs included by the server 401 must have the SESSION_GROUP_ALLOCATION_ACTION flag of the Session- 402 Group-Control-Vector AVP set. 404 If the Diameter server receives a command request from a Diameter 405 client and the command does not contain any Session-Group-Info AVP, 406 the server MUST not assign the new session to any session group but 407 treat the request as for a single session. The server MUST return 408 any Session-Group-Info AVP in the command response. 410 If the Diameter client receives a response to its previously issued 411 request from the server and the response comprises at least one 412 Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION 413 flag of the associated Session-Group-Control-Vector AVP set, the 414 client MUST add the new session to all session groups as identified 415 in the one or multiple Session-Group-Info AVPs. 417 If the Diameter client receives a response to its previously issued 418 request from the server and the one or more Session-Group-Info AVPs 419 have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated 420 Session-Group-Control-Vector AVP cleared, the client MUST terminate 421 the assignment of the session to the one or multiple groups and 422 continue to treat the session as single session without group 423 assignment. 425 A Diameter client, which sent a request for session initiation to a 426 Diameter server and appended a single or multiple Session-Group-Id 427 AVPs but cannot find any Session-Group-Info AVP in the associated 428 response from the Diameter server proceeds as if the request was 429 processed for a single session. 431 4.2.2. Removing a session from a session group 433 When a Diameter client decides to remove a session from a particular 434 session group, the client sends a service-specific re-authorization 435 request to the server and adds one Session-Group-Info AVP to the 436 request for each session group, from which the client wants to remove 437 the session. The session, which is to be removed from a group, is 438 identified in the Session-Id AVP of the command request. The 439 SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- 440 Vector AVP in each Session-Group-Info AVP must be cleared to indicate 441 removal of the session from the session group identified in the 442 associated Session-Group-id AVP. 444 When a Diameter client decides to remove a session from all session 445 groups, to which the session has been previously assigned, the client 446 sends a service-specific re-authorization request to the server and 447 adds a single Session-Group-Info AVP to the request which has the 448 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 449 AVP omitted. The session, which is to be removed from all groups, to 450 which the session has been previously assigned, is identified in the 451 Session-Id AVP of the command request. 453 If the Diameter server receives a request from the client which has 454 at least one Session-Group-Info AVP appended with the 455 SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server must remove 456 the session from the session group identified in the associated 457 Session-Group-Id AVP. If the request comprises at least one Session- 458 Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared 459 and no Session-Id AVP present, the server must remove the session 460 from all session groups to which the session has been previously 461 assigned. The server must include in its response to the requesting 462 client all Session-Group-Id AVPs as received in the request. 464 When the Diameter server decides to remove a session from one or 465 multiple particular session groups or from all session groups to 466 which the session has been assigned beforehand, the server sends a 467 Re-Authorization Request (RAR) or a service-specific server-initiated 468 request to the client, indicating the session in the Session-Id AVP 469 of the request. The client sends a Re-Authorization Answer (RAA) or 470 a service-specific answer to respond to the server's request. The 471 client subsequently sends service-specific re-authorization request 472 containing one or multiple Session-Group-Info AVPs, each indicating a 473 session group, to which the session had been previously assigned. To 474 indicate removal of the indicated session from one or multiple 475 session groups, the server sends a service-specific auth response to 476 the client, containing a list of Session-Group-Info AVPs with the 477 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 478 AVP identifying the session group, from which the session should be 479 removed. The server MAY include to the service-specific auth 480 response a list of Session-Group-Info AVPs with the 481 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 482 identifying session groups to which the session remains subscribed. 483 In case the server decides to remove the identified session from all 484 session groups, to which the session has been previously assigned, 485 the server includes in the service-specific auth response at least 486 one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION 487 flag cleared and Session-Group-Id AVP absent. 489 4.2.3. Mid-session group assignment modifications 491 Either Diameter node (client or server) can modify the group 492 membership of an active Diameter session according to the specified 493 permission considerations. 495 To update an assigned group mid-session, a Diameter client sends a 496 service-specific re-authorization request to the server, containing 497 one or multiple Session-Group-Info AVPs with the 498 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 499 present, identifying the session group to which the session should be 500 assigned. With the same message, the client may send one or multiple 501 Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag 502 cleared and the Session-Group-Id AVP identifying the session group 503 from which the identified session is to be removed. To remove the 504 session from all previously assigned session groups, the client 505 includes at least one Session-Group-Info AVP with the 506 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 507 AVP present. When the server received the service-specific re- 508 authorization request, it must update its locally maintained view of 509 the session groups for the identified session according to the 510 appended Session-Group-Info AVPs. The server sends a service- 511 specific auth response to the client containing one or multiple 512 Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag 513 set and the Session-Group-Id AVP identifying the new session group to 514 which the identified session has been assigned. 516 When a Diameter server enforces an update to the assigned groups mid- 517 session, it sends a Re-Authorization Request (RAR) message to the 518 client identifying the session, for which the session group lists are 519 to be updated. The client responds with a Re-Authorization Answer 520 (RAA) message. The client subsequently sends service-specific re- 521 authorization request containing one or multiple Session-Group-Info 522 AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the 523 Session-Group-Id AVP identifying the session group to which the 524 session had been previously assigned. The server responds with a 525 service-specific auth response and includes one or multiple Session- 526 Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and 527 the Session-Group-Id AVP identifying the session group, to which the 528 identified session is to be assigned. With the same response 529 message, the server may send one or multiple Session-Group-Info AVPs 530 with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the 531 Session-Group-Id AVP identifying the session groups from which the 532 identified session is to be removed. When server wants to remove the 533 session from all previously assigned session groups, it send at least 534 on Session-Group-Info AVP with the response having the 535 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 536 AVP present. 538 4.3. Deleting a Session Group 540 To delete a session group and release the associated Session-Group-Id 541 value, the owner of a session group appends a single Session-Group- 542 Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the 543 Session-Group-Id AVP identifying the session group, which is to be 544 deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated 545 Session-Group-Control-Vector AVP MUST be cleared. 547 4.4. Performing Group Operations 549 4.4.1. Sending Group Commands 551 Either Diameter node (client or server) can request the recipient of 552 a request to process an associated command for all sessions being 553 assigned to one or multiple groups by identifying these groups in the 554 request. The sender of the request appends for each group, to which 555 the command applies, a Session-Group-Info AVP including the Session- 556 Group-Id AVP to identify the associated session group. Both, the 557 SESSION_GROUP_ALLOCATION_ACTION flag as well as the 558 SESSION_GROUP_STATUS_IND flag must be set. 560 If the CCF of the request mandates a Session-Id AVP, the Session-Id 561 AVP MUST identify one of the single sessions which is assigned to at 562 least one of the groups being identified in the appended Session- 563 Group-Id AVPs. 565 The sender of the request MUST indicate to the receiver how follow up 566 message exchanges should be performed by appending a single instance 567 of the Group-Response-Action AVP. Even if the request includes 568 multiple instances of a Session-Group-Info AVP, the request MUST NOT 569 comprise more than a single instance of a Group-Response-Action AVP. 570 If the sender wants the receiver to perform follow up exchanges with 571 a single command for all impacted groups, the sender sets the value 572 of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up 573 message exchanges should be performed on a per-group basis in case 574 multiple groups are identified in the group command, the value of the 575 Group-Response-Action AVP is set to PER_GROUP (2). A value set to 576 PER_SESSION (3) indicates to the receiver that all follow up 577 exchanges should be performed using a single message for each 578 impacted session. 580 If the sender sends a request including the Group-Response-Action AVP 581 set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delays 582 before receiving the corresponding answer(s) as the answer(s) will 583 only be sent back when the request is processed for all the sessions 584 or all the session of a session group. If the process of the request 585 is delay-sensitive, the sender SHOULD NOT set the Group-Response- 586 Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be 587 sent before the complete process of the request for all the sessions 588 or if the request timeout timer is high enough, the sender MAY set 589 the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). 591 If the sender wants the receiver of the request to process the 592 associated command solely for a single session does not append any 593 group identifier, but identifies the relevant session in the Session- 594 Id AVP. 596 4.4.2. Receiving Group Commands 598 A Diameter node receiving a request to process a command for a group 599 of sessions identifies the relevant groups according to the appended 600 Session-Group-Id AVP in the Session-Group-Info AVP and processes the 601 group command according to the appended Group-Response-Action AVP . 603 If the received request identifies multiple groups in multiple 604 appended Session-Group-Id AVPs, the receiver should process the 605 associated command for each of these groups. if a session has been 606 assigned to more than one of the identified groups, the receiver must 607 process the associated command only once per session. 609 The Diameter node receiving a request which requests performing the 610 command to at least on session group SHOULD perform follow up message 611 exchanges according to the value identified in the Session-Group-Info 612 AVP. 614 4.4.3. Error Handling for Group Commands 616 When a Diameter node receives a request to process a command for one 617 or more session groups and the result of processing the command is an 618 error that applies to all sessions in the identified groups, an 619 associated protocol error must be returned to the source of the 620 request. In such case, the sender of the request MUST fall back to 621 single-session processing and the session groups, which have been 622 identified in the group command, MUST be deleted according to the 623 procedure described in Section 4.3. 625 When a Diameter node receives a request to process a command for one 626 or more session groups and the result of processing the command 627 succeeds for some sessions identified in one or multiple session 628 groups, but fails for one or more sessions, the Result-Code AVP in 629 the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per 630 Section 7.1.2 of [RFC6733]. In case of limited success, the 631 sessions, for which the processing of the group command failed, MUST 632 be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733]. 634 4.4.4. Single-Session Fallback 636 Either Diameter node can fall back to single session operation by 637 ignoring and omitting the optional group session-specific AVPs. 638 Fallback to single-session operation is performed by processing the 639 Diameter command solely for the session identified in the mandatory 640 Session-Id AVP. The response to the group command must not identify 641 any group but identify solely the single session for which the 642 command has been processed. 644 5. Operation with Proxies Agents 646 In case of a present stateful Proxy Agent between a Diameter client 647 and a Diameter server, this specification assumes that the Proxy 648 Agent is aware of session groups and session group handling. The 649 Proxy MUST update and maintain consistency of its local session 650 states as per the result of the group commands which are operated 651 between a Diameter client and a server. 653 In case a Proxy Agent manipulates session groups, it MUST maintain 654 consistency of session groups between a client and a server. This 655 applies to a deployment where the Proxy Agent utilizes session 656 grouping and performs group operations with, for example, a Diameter 657 server, whereas the Diameter client is not aware of session groups. 658 In such case the Proxy Agent must reflect the states associated with 659 the session groups as individual session operations towards the 660 client and ensure the client has a consistent view of each session. 661 The same applies to a deployment where all nodes, the Diameter client 662 and server, as well as the Proxy Agent are group-aware but the Proxy 663 Agent manipulates groups, e.g. to adopt different administrative 664 policies that apply to the client's domain and the server's domain. 666 6. Commands Formatting 668 This document does not specify new Diameter commands to enable group 669 operations, but relies on command extensibility capability provided 670 by the Diameter Base protocol. This section provides the guidelines 671 to extend the CCF of existing Diameter commands with optional AVPs to 672 enable the recipient of the command applying the command to all 673 sessions associated with the identified group(s). 675 6.1. Formatting Example: Group Re-Auth-Request 677 A request for re-authentication of one or more groups of users is 678 issued by appending one or multiple Session-Group-Id AVP(s), as well 679 as a single instance of a Group-Response-Action AVP to the Re-Auth- 680 Request (RAR). The one or multiple Session-Group-Id AVP(s) identify 681 the associated group(s) for which the group re-authentication has 682 been requested. The Group-Response-Action AVP identifies the 683 expected means to perform and respond to the group command. The 684 recipient of the group command initiates re-authentication for all 685 users associated with the identified group(s). Furthermore, the 686 sender of the group re-authentication request appends a Group- 687 Response-Action AVP to provide more information to the receiver of 688 the command about how to accomplish the group operation. 690 The value of the mandatory Session-Id AVP MUST identify a session 691 associated with a single user, which is assigned to at least one of 692 the groups being identified in the appended Session-Group-Id AVPs. 694 ::= < Diameter Header: 258, REQ, PXY > 695 < Session-Id > 696 { Origin-Host } 697 { Origin-Realm } 698 { Destination-Realm } 699 { Destination-Host } 700 { Auth-Application-Id } 701 { Re-Auth-Request-Type } 702 [ User-Name ] 703 [ Origin-State-Id ] 704 * [ Proxy-Info ] 705 * [ Route-Record ] 706 [ Session-Group-Capability-Vector ] 707 * [ Session-Group-Info ] 708 [ Group-Response-Action ] 709 * [ AVP ] 711 7. Attribute-Value-Pairs (AVP) 713 +--------------------+ 714 | AVP Flag rules | 715 +----+---+------+----+ 716 AVP | | |SHOULD|MUST| 717 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 718 +-------------------------------------------------+----+---+------+----+ 719 |Session-Group-Info TBD1 Grouped | | P | | V | 720 |Session-Group-Control-Vector TBD2 Unsigned32 | | P | | V | 721 |Session-Group-Id TBD3 OctetString | | P | | V | 722 |Group-Response-Action TBD4 Unsigned32 | | P | | V | 723 |Session-Group-Capability-Vector TBD5 Unsigned32 | | P | | V | 724 +-------------------------------------------------+----+---+------+----+ 726 AVPs for the Diameter Group Signaling 728 7.1. Session-Group-Info AVP 730 The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It 731 contains the identifier of the session group as well as an indication 732 of the node responsible for session group identifier assignment. 734 Session-Group-Info ::= < AVP Header: TBD1 > 735 < Session-Group-Control-Vector > 736 [ Session-Group-Id ] 737 * [ AVP ] 739 7.2. Session-Group-Control-Vector AVP 741 The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type 742 Unsigned32 and contains a 32-bit flags field to control the group 743 assignment at session-group aware nodes. 745 The following capabilities are defined in this document: 747 SESSION_GROUP_ALLOCATION_ACTION (0x00000001) 749 This flag indicates the action to be performed for the identified 750 session. When this flag is set, it indicates that the identified 751 Diameter session is to be assigned to the session group as 752 identified by the Session-Group-Id AVP or the session's assignment 753 to the session group identified in the Session-Group-Id AVP is 754 still valid. When the flag is cleared, the identified Diameter 755 session is to be removed from at least one session group. When 756 the flag is cleared and the Session-Group-Info AVP identifies a 757 particular session group in the associated Session-Group-Id AVP, 758 the session is to be removed solely from the identified session 759 group. When the flag is cleared and the Session-Group-Info AVP 760 does not identify a particular session group (Session-Group-Id AVP 761 is absent), the identified Diameter session is to be removed from 762 all session groups, to which it has been previously assigned. 764 SESSION_GROUP_STATUS_IND (0x00000010) 766 This flag indicates the status of the session group identified in 767 the associated Session-Group-Id AVP. The flag is set when the 768 identified session group has just been created or is still active. 769 If the flag is cleared, the identified session group is deleted 770 and the associated Session-Group-Id is released. If the Session- 771 Group-Info AVP does not comprise a Session-Group-Id AVP, this flag 772 is meaningless and MUST be ignored by the receiver. 774 7.3. Session-Group-Id AVP 776 The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and 777 identifies a group of Diameter sessions. 779 The Session-Group-Id MUST be globally and eternally unique, as it is 780 meant to uniquely identify a group of Diameter sessions without 781 reference to any other information. 783 The default format of the Session-Group-id MUST comply to the format 784 recommended for a Session-Id, as defined in the section 8.8 of the 785 [RFC6733]. The portion of the Session-Group-Id 786 MUST identify the Diameter node, which owns the session group. 788 7.4. Group-Response-Action AVP 790 The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 791 and contains a 32-bit address space representing values indicating 792 how the node SHOULD issue follow up exchanges in response to a 793 command which impacts multiple sessions. The following values are 794 defined by this application: 796 ALL_GROUPS (1) 797 Follow up exchanges should be performed with a single message 798 exchange for all impacted groups. 800 PER_GROUP (2) 801 Follow up exchanges should be performed with a message exchange 802 for each impacted group. 804 PER_SESSION (3) 805 Follow up exchanges should be performed with a message exchange 806 for each impacted session. 808 7.5. Session-Group-Capability-Vector AVP 810 The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type 811 Unsigned32 and contains a 32-bit flags field to indicate capabilities 812 in the context of session-group assignment and group operations. 814 The following capabilities are defined in this document: 816 BASE_SESSION_GROUP_CAPABILITY (0x00000001) 818 This flag indicates the capability to support session grouping and 819 session group operations according to this specification. 821 8. Result-Code AVP Values 823 This document does not define new Result-Code [RFC6733] values for 824 existing applications, which are extended to support group commands. 825 Specification documents of new applications, which will have 826 intrinsic support for group commands, may specify new Result-Codes. 828 9. IANA Considerations 830 This section contains the namespaces that have either been created in 831 this specification or had their values assigned to existing 832 namespaces managed by IANA. 834 9.1. AVP Codes 836 This specification requires IANA to register the following new AVPs 837 from the AVP Code namespace defined in [RFC6733]. 839 o Session-Group-Info 841 o Session-Group-Control-Vector 843 o Session-Group-Id 845 o Group-Response-Action 847 o Session-Group-Capability-Vector 849 The AVPs are defined in Section 7. 851 10. Security Considerations 853 The security considerations of the Diameter protocol itself are 854 discussed in [RFC6733]. Use of the AVPs defined in this document 855 MUST take into consideration the security issues and requirements of 856 the Diameter base protocol. In particular, the Session-Group-Info 857 AVP (including the Session-group-Control-Vector and the Session- 858 Group-Id AVPs) should be considered as a security-sensitive AVPs in 859 the same manner than the Session-Id AVP in the Diameter base protocol 860 [RFC6733]. 862 The management of session groups relies upon the existing trust 863 relationship between the Diameter client and the Diameter server 864 managing the groups of sessions. This document defines a mechanism 865 that allows a client or a server to act on multiple sessions at the 866 same time using only one command. if the Diameter client or server is 867 compromised, an attacker could launch DoS attacks by terminating a 868 large number of sessions with a limited set of commands using the 869 session group management concept. 871 According to the Diameter base protocol [RFC6733], transport 872 connections between Diameter peers are protected by TLS/TCP, DTLS/ 873 SCTP or alternative security mechanisms that are independent of 874 Diameter, such as IPsec. However, the lack of end-to-end security 875 features makes it difficult to establish trust in the session group 876 related information received from non-adjacent nodes. Any Diameter 877 agent in the message path can potentially modify the content of the 878 message and therefore the information sent by the Diameter client or 879 the server. The DIME working group is currently working on solutions 880 for providing end-to-end security features. When available, these 881 features should enable the establishment of trust relationship 882 between non-adjacent nodes and the security required for session 883 group management would normally rely on this end-to-end security. 884 However, there is no assumption in this document that such end-to-end 885 security mechanism will be available. It is only assume that the 886 solution defined on this document relies on the security framework 887 provided by the Diameter based protocol. 889 In some cases, a Diameter Proxy agent can act on behalf of a client 890 or server. In such a case, the security requirements that normally 891 apply to a client (or a server) apply equally to the Proxy agent. 893 11. Acknowledgments 895 The authors of this document want to thank Ben Campbell and Eric 896 McMurry for their valuable comments to early versions of this draft. 897 Furthermore, authors thank Steve Donovan for the thorough review and 898 comments on the adopted WG document, which helped a lot to improve 899 this specification. 901 12. Normative References 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, 905 DOI 10.17487/RFC2119, March 1997, 906 . 908 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 909 "Diameter Network Access Server Application", RFC 4005, 910 DOI 10.17487/RFC4005, August 2005, 911 . 913 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 914 Ed., "Diameter Base Protocol", RFC 6733, 915 DOI 10.17487/RFC6733, October 2012, 916 . 918 Appendix A. Session Management -- Exemplary Session State Machine 920 A.1. Use of groups for the Authorization Session State Machine 922 Section 8.1 in [RFC6733] defines a set of finite state machines, 923 representing the life cycle of Diameter sessions, and which MUST be 924 observed by all Diameter implementations that make use of the 925 authentication and/or authorization portion of a Diameter 926 application. This section defines, as example, additional state 927 transitions related to the processing of the group commands which may 928 impact multiple sessions. 930 The group membership is session state and therefore only those state 931 machines from [RFC6733] in which the server is maintaining session 932 state are relevant in this document. As in [RFC6733], the term 933 Service-Specific below refers to a message defined in a Diameter 934 application (e.g., Mobile IPv4, NASREQ). 936 The following state machine is observed by a client when state is 937 maintained on the server. State transitions which are unmodified 938 from [RFC6733] are not repeated here. 940 The Diameter group command in the following tables is differentiated 941 from a single-session related command by a preceding 'G' (Group). A 942 Group Re-Auth Request, which applies to one or multiple session 943 groups, has been exemplarily described in Section 6.1. Such Group 944 RAR command is denoted as 'GRAR' in the following table. The same 945 notation applies to other commands as per [RFC6733]. 947 CLIENT, STATEFUL 948 State Event Action New State 949 --------------------------------------------------------------- 950 Idle Client or Device Requests Send Pending 951 access service 952 specific 953 auth req 954 optionally 955 including 956 groups 958 Open GASR received with Send GASA Discon 959 Group-Response-Action with 960 = ALL_GROUPS, Result-Code 961 session is assigned to = SUCCESS, 962 received group(s) and Send GSTR. 963 client will comply with 964 request to end the session 966 Open GASR received with Send GASA Discon 967 Group-Response-Action with 968 = PER_GROUPS, Result-Code 969 session is assigned to = SUCCESS, 970 received group(s) and Send GSTR 971 client will comply with per group 972 request to end the session 973 Open GASR received with Send GASA Discon 974 Group-Response-Action with 975 = PER_SESSION, Result-Code 976 session is assigned to = SUCCESS, 977 received group(s) and Send STR 978 client will comply with per session 979 request to end the session 981 Open GASR received, Send GASA Open 982 client will not comply with with 983 request to end all session Result-Code 984 in received group(s) != SUCCESS 986 Discon GSTA Received Discon. Idle 987 user/device 989 Open GRAR received with Send GRAA, Pending 990 Group-Response-Action Send 991 = ALL_GROUPS, service 992 session is assigned to specific 993 received group(s) and group 994 client will perform re-auth req 995 subsequent re-auth 997 Open GRAR received with Send GRAA, Pending 998 Group-Response-Action Send 999 = PER_GROUP, service 1000 session is assigned to specific 1001 received group(s) and group 1002 client will perform re-auth req 1003 subsequent re-auth per group 1005 Open GRAR received with Send GRAA, Pending 1006 Group-Response-Action Send 1007 = PER_SESSION, service 1008 session is assigned to specific 1009 received group(s) and re-auth req 1010 client will perform per session 1011 subsequent re-auth 1013 Open GRAR received and client will Send GRAA Idle 1014 not perform subsequent with 1015 re-auth Result-Code 1016 != SUCCESS, 1017 Discon. 1018 user/device 1020 Pending Successful service-specific Provide Open 1021 group re-authorization answer service 1022 received. 1024 Pending Failed service-specific Discon. Idle 1025 group re-authorization answer user/device 1026 received. 1028 The following state machine is observed by a server when it is 1029 maintaining state for the session. State transitions which are 1030 unmodified from [RFC6733] are not repeated here. 1032 SERVER, STATEFUL 1033 State Event Action New State 1034 --------------------------------------------------------------- 1036 Idle Service-specific authorization Send Open 1037 request received, and user successful 1038 is authorized service 1039 specific 1040 answer 1041 optionally 1042 including 1043 groups 1045 Open Server wants to terminate Send GASR Discon 1046 group(s) 1048 Discon GASA received Cleanup Idle 1050 Any GSTR received Send GSTA, Idle 1051 Cleanup 1053 Open Server wants to reauth Send GRAR Pending 1054 group(s) 1056 Pending GRAA received with Result-Code Update Open 1057 = SUCCESS session(s) 1059 Pending GRAA received with Result-Code Cleanup Idle 1060 != SUCCESS session(s) 1062 Open Service-specific group Send Open 1063 re-authoization request successful 1064 received and user is service 1065 authorized specific 1066 group 1067 re-auth 1068 answer 1070 Open Service-specific group Send Idle 1071 re-authorization request failed 1072 received and user is service 1073 not authorized specific 1074 group 1075 re-auth 1076 answer, 1077 cleanup 1079 Authors' Addresses 1081 Mark Jones 1083 Email: mark@azu.ca 1085 Marco Liebsch 1087 Email: marco.liebsch@neclab.eu 1089 Lionel Morand 1091 Email: lionel.morand@orange.com