idnits 2.17.1 draft-ietf-dime-group-signaling-10.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 1023 has weird spacing: '...ly with wit...' == Line 1062 has weird spacing: '... answer servi...' == Line 1066 has weird spacing: '... answer user/...' -- The document date (January 8, 2018) is 2299 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 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: July 12, 2018 6 L. Morand 7 January 8, 2018 9 Diameter Group Signaling 10 draft-ietf-dime-group-signaling-10.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 https://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 July 12, 2018. 43 Copyright Notice 45 Copyright (c) 2018 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 (https://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 . . . . . . . 11 73 4.2.3. Mid-session group assignment modifications . . . . . 12 74 4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 13 75 4.4. Performing Group Operations . . . . . . . . . . . . . . . 13 76 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 13 77 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 14 78 4.4.3. Error Handling for Group Commands . . . . . . . . . . 14 79 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 15 80 5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 15 81 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16 82 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16 83 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17 84 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 17 85 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 18 86 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 18 87 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 19 88 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 19 89 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 19 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 93 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 94 12. Normative References . . . . . . . . . . . . . . . . . . . . 21 95 Appendix A. Session Management -- Exemplary Session State 96 Machine . . . . . . . . . . . . . . . . . . . . . . 21 97 A.1. Use of groups for the Authorization Session State Machine 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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 in [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 [RFC7155], containing one or more session group identifiers. Each of 336 these groups MUST 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 include the Session-Group-Info AVP in the request including the 355 Session-Group-Control-Vector AVP with the 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 in the Session-Group- 361 Control-Vector AVP set, the server can accept or reject the request 362 for group assignment. Reasons for rejection may be e.g. lack of 363 resources for managing additional groups. When rejected, the session 364 MUST NOT be assigned to any session group. 366 If the Diameter server accepts the client's request for a group 367 assignment, the server MUST assign the new session to each of the one 368 or multiple identified session groups when present in the Session- 369 Group-Info AVP. In case one or multiple identified session groups 370 are not already stored by the server, the server MUST store the new 371 identified group(s) to its local list of known session groups. When 372 sending the response to the client, e.g. a service-specific auth 373 response as per NASREQ AA-Answer [RFC7155], the server MUST include 374 all Session-Group-Info AVPs as received in the client's request. 376 In addition to the one or multiple session groups identified in the 377 client's request, the server may decide to assign the new session to 378 one or multiple additional groups. In such a case, the server MUST 379 add to the response the additional Session-Group-Info AVPs, each 380 identifying a session group to which the new session is assigned by 381 the server. Each of the Session-Group-Info AVP added by the server 382 MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the 383 Session-Group-Control-Vector AVP set. 385 If the Diameter server rejects the client's request for a group 386 assignment, the server sends the response to the client, e.g. a 387 service-specific auth response as per NASREQ AA-Answer [RFC7155], and 388 MUST include all Session-Group-Info AVPs as received in the client's 389 request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION 390 flag of the Session-Group-Control-Vector AVP. The server MAY accept 391 the client's request for the identified session but refuse the 392 session's assignment to any session group. The server sends the 393 response to the client indicating success in the result code. In 394 such case the session is treated as single session without assignment 395 to any session group by the Diameter nodes. 397 If the Diameter server accepts the client's request for a group 398 assignment, but the assignment of the session to one or some of the 399 multiple identified session groups fails, the session group 400 assignment is treated as failure. In such case the session is 401 treated as single session without assignment to any session group by 402 the Diameter nodes. The server sends the response to the client and 403 MAY include as information to the client only those Session-Group- 404 Info AVPs for which the group assignment failed. The 405 SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group-Info 406 AVPs MUST be cleared. 408 If the Diameter server receives a command request from a Diameter 409 client and the command comprises one or multiple Session-Group-Info 410 AVPs and none of them includes a Session-Group-Id AVP, the server MAY 411 decide to assign the session to one or multiple session groups. For 412 each session group, to which the server assigns the new session, the 413 server includes a Session-Group-Info AVP with the Session-Group-Id 414 AVP identifying a session group in the response sent to the client. 415 Each of the Session-Group-Info AVPs included by the server MUST have 416 the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group- 417 Control-Vector AVP set. 419 If the Diameter server receives a command request from a Diameter 420 client and the command does not contain any Session-Group-Info AVP, 421 the server MUST NOT assign the new session to any session group but 422 treat the request as for a single session. The server MUST NOT 423 return any Session-Group-Info AVP in the command response. 425 If the Diameter client receives a response to its previously issued 426 request from the server and the response comprises at least one 427 Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION 428 flag of the associated Session-Group-Control-Vector AVP set, the 429 client MUST add the new session to all session groups as identified 430 in the one or multiple Session-Group-Info AVPs. If the Diameter 431 client fails to add the session to one or more session groups as 432 identified in the one or multiple Session-Group-info AVPs, the client 433 MUST terminate the session. The client MAY send a subsequent request 434 for session initiation to the server without requesting the 435 assignment of the session to a session group 437 If the Diameter client receives a response to its previously issued 438 request from the server and the one or more Session-Group-Info AVPs 439 have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated 440 Session-Group-Control-Vector AVP cleared, the client MUST terminate 441 the assignment of the session to the one or multiple groups. If the 442 response from the server indicates success in the result code but 443 solely the assignment of the session to a session group has been 444 rejected by the server, the client treats the session as single 445 session without group assignment. 447 A Diameter client, which sent a request for session initiation to a 448 Diameter server and appended a single or multiple Session-Group-Id 449 AVPs but cannot find any Session-Group-Info AVP in the associated 450 response from the Diameter server proceeds as if the request was 451 processed for a single session. When the Diameter client is 452 confident that the Diameter server supports session grouping and 453 group signaling, the Diameter client SHOULD NOT retry to request 454 group assignment for this session, but MAY try to request group 455 assignment for other new sessions. 457 4.2.2. Removing a session from a session group 459 When a Diameter client decides to remove a session from a particular 460 session group, the client sends a service-specific re-authorization 461 request to the server and adds one Session-Group-Info AVP to the 462 request for each session group, from which the client wants to remove 463 the session. The session, which is to be removed from a group, is 464 identified in the Session-Id AVP of the command request. The 465 SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- 466 Vector AVP in each Session-Group-Info AVP MUST be cleared to indicate 467 removal of the session from the session group identified in the 468 associated Session-Group-id AVP. 470 When a Diameter client decides to remove a session from all session 471 groups, to which the session has been previously assigned, the client 472 sends a service-specific re-authorization request to the server and 473 adds a single Session-Group-Info AVP to the request which has the 474 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 475 AVP omitted. The session, which is to be removed from all groups, to 476 which the session has been previously assigned, is identified in the 477 Session-Id AVP of the command request. 479 If the Diameter server receives a request from the client which has 480 at least one Session-Group-Info AVP appended with the 481 SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove 482 the session from the session group identified in the associated 483 Session-Group-Id AVP. If the request comprises at least one Session- 484 Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared 485 and no Session-Id AVP present, the server MUST remove the session 486 from all session groups to which the session has been previously 487 assigned. The server MUST include in its response to the requesting 488 client all Session-Group-Id AVPs as received in the request. 490 When the Diameter server decides to remove a session from one or 491 multiple particular session groups or from all session groups to 492 which the session has been assigned beforehand, the server sends a 493 Re-Authorization Request (RAR) or a service-specific server-initiated 494 request to the client, indicating the session in the Session-Id AVP 495 of the request. The client sends a Re-Authorization Answer (RAA) or 496 a service-specific answer to respond to the server's request. The 497 client subsequently sends service-specific re-authorization request 498 containing one or multiple Session-Group-Info AVPs, each indicating a 499 session group, to which the session had been previously assigned. To 500 indicate removal of the indicated session from one or multiple 501 session groups, the server sends a service-specific auth response to 502 the client, containing a list of Session-Group-Info AVPs with the 503 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 504 AVP identifying the session group, from which the session should be 505 removed. The server MAY include to the service-specific auth 506 response a list of Session-Group-Info AVPs with the 507 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 508 identifying session groups to which the session remains subscribed. 509 In case the server decides to remove the identified session from all 510 session groups, to which the session has been previously assigned, 511 the server includes in the service-specific auth response at least 512 one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION 513 flag cleared and Session-Group-Id AVP absent. 515 4.2.3. Mid-session group assignment modifications 517 Either Diameter node (client or server) can modify the group 518 membership of an active Diameter session according to the specified 519 permission considerations. 521 To update an assigned group mid-session, a Diameter client sends a 522 service-specific re-authorization request to the server, containing 523 one or multiple Session-Group-Info AVPs with the 524 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 525 present, identifying the session group to which the session should be 526 assigned. With the same message, the client may send one or multiple 527 Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag 528 cleared and the Session-Group-Id AVP identifying the session group 529 from which the identified session is to be removed. To remove the 530 session from all previously assigned session groups, the client 531 includes at least one Session-Group-Info AVP with the 532 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 533 AVP present. When the server received the service-specific re- 534 authorization request, it MUST update its locally maintained view of 535 the session groups for the identified session according to the 536 appended Session-Group-Info AVPs. The server sends a service- 537 specific auth response to the client containing one or multiple 538 Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag 539 set and the Session-Group-Id AVP identifying the new session group to 540 which the identified session has been assigned. 542 When a Diameter server enforces an update to the assigned groups mid- 543 session, it sends a Re-Authorization Request (RAR) message to the 544 client identifying the session, for which the session group lists are 545 to be updated. The client responds with a Re-Authorization Answer 546 (RAA) message. The client subsequently sends a service-specific re- 547 authorization request containing one or multiple Session-Group-Info 548 AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the 549 Session-Group-Id AVP identifying the session group to which the 550 session had been previously assigned. The server responds with a 551 service-specific auth response and includes one or multiple Session- 552 Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and 553 the Session-Group-Id AVP identifying the session group, to which the 554 identified session is to be assigned. With the same response 555 message, the server may send one or multiple Session-Group-Info AVPs 556 with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the 557 Session-Group-Id AVP identifying the session groups from which the 558 identified session is to be removed. When server wants to remove the 559 session from all previously assigned session groups, it sends at 560 least one Session-Group-Info AVP with the response having the 561 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 562 AVP present. 564 4.3. Deleting a Session Group 566 To delete a session group and release the associated Session-Group-Id 567 value, the owner of a session group appends a single Session-Group- 568 Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the 569 Session-Group-Id AVP identifying the session group, which is to be 570 deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated 571 Session-Group-Control-Vector AVP MUST be cleared. 573 4.4. Performing Group Operations 575 4.4.1. Sending Group Commands 577 Either Diameter node (client or server) can request the recipient of 578 a request to process an associated command for all sessions being 579 assigned to one or multiple groups by identifying these groups in the 580 request. The sender of the request appends for each group, to which 581 the command applies, a Session-Group-Info AVP including the Session- 582 Group-Id AVP to identify the associated session group. Both, the 583 SESSION_GROUP_ALLOCATION_ACTION flag as well as the 584 SESSION_GROUP_STATUS_IND flag MUST be set. 586 If the CCF of the request mandates a Session-Id AVP, the Session-Id 587 AVP MUST identify one of the single sessions which is assigned to at 588 least one of the groups being identified in the appended Session- 589 Group-Id AVPs. 591 The sender of the request MUST indicate to the receiver how follow up 592 message exchanges should be performed by appending a single instance 593 of the Group-Response-Action AVP. Even if the request includes 594 multiple instances of a Session-Group-Info AVP, the request MUST NOT 595 comprise more than a single instance of a Group-Response-Action AVP. 596 If the sender wants the receiver to perform follow up exchanges with 597 a single command for all impacted groups, the sender sets the value 598 of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up 599 message exchanges should be performed on a per-group basis in case 600 multiple groups are identified in the group command, the value of the 601 Group-Response-Action AVP is set to PER_GROUP (2). A value set to 602 PER_SESSION (3) indicates to the receiver that all follow up 603 exchanges should be performed using a single message for each 604 impacted session. 606 If the sender sends a request including the Group-Response-Action AVP 607 set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delay 608 before receiving the corresponding answer(s) as the answer(s) will 609 only be sent back when the request is processed for all the sessions 610 or all the session of a session group. If the process of the request 611 is delay-sensitive, the sender SHOULD NOT set the Group-Response- 612 Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be 613 sent before the complete process of the request for all the sessions 614 or if the request timeout timer is high enough, the sender MAY set 615 the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). 617 If the sender wants the receiver of the request to process the 618 associated command solely for a single session, the sender does not 619 append any group identifier, but identifies the relevant session in 620 the Session-Id AVP. 622 4.4.2. Receiving Group Commands 624 A Diameter node receiving a request to process a command for a group 625 of sessions, identifies the relevant groups according to the appended 626 Session-Group-Id AVP in the Session-Group-Info AVP and processes the 627 group command according to the appended Group-Response-Action AVP . 628 If the received request identifies multiple groups in multiple 629 appended Session-Group-Id AVPs, the receiver SHOULD process the 630 associated command for each of these groups. If a session has been 631 assigned to more than one of the identified groups, the receiver MUST 632 process the associated command only once per session. 634 4.4.3. Error Handling for Group Commands 636 When a Diameter node receives a request to process a command for one 637 or more session groups and the result of processing the command is an 638 error that applies to all sessions in the identified groups, an 639 associated protocol error MUST be returned to the source of the 640 request. In such case, the sender of the request MUST fall back to 641 single-session processing and the session groups, which have been 642 identified in the group command, MUST be deleted according to the 643 procedure described in Section 4.3. 645 When a Diameter node receives a request to process a command for one 646 or more session groups and the result of processing the command 647 succeeds for some sessions identified in one or multiple session 648 groups, but fails for one or more sessions, the Result-Code AVP in 649 the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per 650 Section 7.1.2 of [RFC6733]. 652 In case of limited success, the sessions, for which the processing of 653 the group command failed, MUST be identified using a Failed-AVP AVP 654 as per Section 7.5 of [RFC6733]. The sender of the request MUST fall 655 back to single-session operation for each of the identified sessions, 656 for which the group command failed. In addition, each of these 657 sessions MUST be removed from all session groups to which the group 658 command applied. To remove sessions from a session group, the 659 Diameter client performs the procedure described in Section 4.2.2. 661 4.4.4. Single-Session Fallback 663 Either Diameter node can fall back to single session operation by 664 ignoring and omitting the optional group session-specific AVPs. 665 Fallback to single-session operation is performed by processing the 666 Diameter command solely for the session identified in the mandatory 667 Session-Id AVP. In such case, the response to the group command MUST 668 NOT identify any group but identify solely the single session for 669 which the command has been processed. 671 5. Operation with Proxy Agents 673 In case of a present stateful Proxy Agent between a Diameter client 674 and a Diameter server, this specification assumes that the Proxy 675 Agent is aware of session groups and session group handling. The 676 Proxy MUST update and maintain consistency of its local session 677 states as per the result of the group commands which are operated 678 between a Diameter client and a server. In such case, the Proxy 679 Agent MUST act as a Diameter server in front of the Diameter client 680 and MUST act as a Diameter client in front of the Diameter server. 681 Therefore, the client and server behavior described in Section 4 682 applies respectively to the stateful Proxy Agent. 684 In case a stateful Proxy Agent manipulates session groups, it MUST 685 maintain consistency of session groups between a client and a server. 686 This applies to a deployment where the Proxy Agent utilizes session 687 grouping and performs group operations with, for example, a Diameter 688 server, whereas the Diameter client is not aware of session groups. 689 In such case the Proxy Agent must reflect the states associated with 690 the session groups as individual session operations towards the 691 client and ensure the client has a consistent view of each session. 692 The same applies to a deployment where all nodes, the Diameter client 693 and server, as well as the Proxy Agent are group-aware but the Proxy 694 Agent manipulates groups, e.g. to adopt different administrative 695 policies that apply to the client's domain and the server's domain. 697 Stateless Proxy Agents do not maintain any session state (only 698 transaction state are maintained). Consequently, the notion of 699 session group is transparent for any stateless Proxy Agent present 700 between a Diameter client and a Diameter server handling session 701 groups. Session group related AVPs being defined as optional AVP 702 SHOULD be ignored by stateless Proxy Agents and SHOULD NOT be removed 703 from the Diameter commands. If they are removed by the Proxy Agent 704 for any reason, the Diameter client and Diameter server will discover 705 the absence the related session group AVPs and will fall back to 706 single-session processing, as described in Section 4. 708 6. Commands Formatting 710 This document does not specify new Diameter commands to enable group 711 operations, but relies on command extensibility capability provided 712 by the Diameter Base protocol. This section provides the guidelines 713 to extend the CCF of existing Diameter commands with optional AVPs to 714 enable the recipient of the command applying the command to all 715 sessions associated with the identified group(s). 717 6.1. Formatting Example: Group Re-Auth-Request 719 A request for re-authentication of one or more groups of users is 720 issued by appending one or multiple Session-Group-Id AVP(s), as well 721 as a single instance of a Group-Response-Action AVP to the Re-Auth- 722 Request (RAR). The one or multiple Session-Group-Id AVP(s) identify 723 the associated group(s) for which the group re-authentication has 724 been requested. The Group-Response-Action AVP identifies the 725 expected means to perform and respond to the group command. The 726 recipient of the group command initiates re-authentication for all 727 users associated with the identified group(s). Furthermore, the 728 sender of the group re-authentication request appends a Group- 729 Response-Action AVP to provide more information to the receiver of 730 the command about how to accomplish the group operation. 732 The value of the mandatory Session-Id AVP MUST identify a session 733 associated with a single user, which is assigned to at least one of 734 the groups being identified in the appended Session-Group-Id AVPs. 736 ::= < Diameter Header: 258, REQ, PXY > 737 < Session-Id > 738 { Origin-Host } 739 { Origin-Realm } 740 { Destination-Realm } 741 { Destination-Host } 742 { Auth-Application-Id } 743 { Re-Auth-Request-Type } 744 [ User-Name ] 745 [ Origin-State-Id ] 746 * [ Proxy-Info ] 747 * [ Route-Record ] 748 [ Session-Group-Capability-Vector ] 749 * [ Session-Group-Info ] 750 [ Group-Response-Action ] 751 * [ AVP ] 753 7. Attribute-Value-Pairs (AVP) 755 +--------------------+ 756 | AVP Flag rules | 757 +----+---+------+----+ 758 AVP | | |SHOULD|MUST| 759 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 760 +-------------------------------------------------+----+---+------+----+ 761 |Session-Group-Info TBD1 Grouped | | P | | V | 762 |Session-Group-Control-Vector TBD2 Unsigned32 | | P | | V | 763 |Session-Group-Id TBD3 OctetString | | P | | V | 764 |Group-Response-Action TBD4 Unsigned32 | | P | | V | 765 |Session-Group-Capability-Vector TBD5 Unsigned32 | | P | | V | 766 +-------------------------------------------------+----+---+------+----+ 768 AVPs for the Diameter Group Signaling 770 7.1. Session-Group-Info AVP 772 The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It 773 contains the identifier of the session group as well as an indication 774 of the node responsible for session group identifier assignment. 776 Session-Group-Info ::= < AVP Header: TBD1 > 777 < Session-Group-Control-Vector > 778 [ Session-Group-Id ] 779 * [ AVP ] 781 7.2. Session-Group-Control-Vector AVP 783 The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type 784 Unsigned32 and contains a 32-bit flags field to control the group 785 assignment at session-group aware nodes. 787 The following capabilities are defined in this document: 789 SESSION_GROUP_ALLOCATION_ACTION (0x00000001) 791 This flag indicates the action to be performed for the identified 792 session. When this flag is set, it indicates that the identified 793 Diameter session is to be assigned to the session group as 794 identified by the Session-Group-Id AVP or the session's assignment 795 to the session group identified in the Session-Group-Id AVP is 796 still valid. When the flag is cleared, the identified Diameter 797 session is to be removed from at least one session group. When 798 the flag is cleared and the Session-Group-Info AVP identifies a 799 particular session group in the associated Session-Group-Id AVP, 800 the session is to be removed solely from the identified session 801 group. When the flag is cleared and the Session-Group-Info AVP 802 does not identify a particular session group (Session-Group-Id AVP 803 is absent), the identified Diameter session is to be removed from 804 all session groups, to which it has been previously assigned. 806 SESSION_GROUP_STATUS_IND (0x00000010) 808 This flag indicates the status of the session group identified in 809 the associated Session-Group-Id AVP. The flag is set when the 810 identified session group has just been created or is still active. 811 If the flag is cleared, the identified session group is deleted 812 and the associated Session-Group-Id is released. If the Session- 813 Group-Info AVP does not comprise a Session-Group-Id AVP, this flag 814 is meaningless and MUST be ignored by the receiver. 816 7.3. Session-Group-Id AVP 818 The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and 819 identifies a group of Diameter sessions. 821 The Session-Group-Id MUST be globally and eternally unique, as it is 822 meant to uniquely identify a group of Diameter sessions without 823 reference to any other information. 825 The default format of the Session-Group-id MUST comply to the format 826 recommended for a Session-Id, as defined in the section 8.8 of the 827 [RFC6733]. The portion of the Session-Group-Id 828 MUST identify the Diameter node, which owns the session group. 830 7.4. Group-Response-Action AVP 832 The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 833 and contains a 32-bit address space representing values indicating 834 how the node SHOULD issue follow up exchanges in response to a 835 command which impacts multiple sessions. The following values are 836 defined by this application: 838 ALL_GROUPS (1) 839 Follow up exchanges should be performed with a single message 840 exchange for all impacted groups. 842 PER_GROUP (2) 843 Follow up exchanges should be performed with a message exchange 844 for each impacted group. 846 PER_SESSION (3) 847 Follow up exchanges should be performed with a message exchange 848 for each impacted session. 850 7.5. Session-Group-Capability-Vector AVP 852 The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type 853 Unsigned32 and contains a 32-bit flags field to indicate capabilities 854 in the context of session-group assignment and group operations. 856 The following capabilities are defined in this document: 858 BASE_SESSION_GROUP_CAPABILITY (0x00000001) 860 This flag indicates the capability to support session grouping and 861 session group operations according to this specification. 863 8. Result-Code AVP Values 865 This document does not define new Result-Code [RFC6733] values for 866 existing applications, which are extended to support group commands. 867 Specification documents of new applications, which will have 868 intrinsic support for group commands, may specify new Result-Codes. 870 9. IANA Considerations 872 This section contains the namespaces that have either been created in 873 this specification or had their values assigned to existing 874 namespaces managed by IANA. 876 9.1. AVP Codes 878 This specification requires IANA to register the following new AVPs 879 from the AVP Code namespace defined in [RFC6733]. 881 o Session-Group-Info 883 o Session-Group-Control-Vector 885 o Session-Group-Id 887 o Group-Response-Action 889 o Session-Group-Capability-Vector 891 The AVPs are defined in Section 7. 893 10. Security Considerations 895 The security considerations of the Diameter protocol itself are 896 discussed in [RFC6733]. Use of the AVPs defined in this document 897 MUST take into consideration the security issues and requirements of 898 the Diameter base protocol. In particular, the Session-Group-Info 899 AVP (including the Session-group-Control-Vector and the Session- 900 Group-Id AVPs) should be considered as a security-sensitive AVPs in 901 the same manner than the Session-Id AVP in the Diameter base protocol 902 [RFC6733]. 904 The management of session groups relies upon the existing trust 905 relationship between the Diameter client and the Diameter server 906 managing the groups of sessions. This document defines a mechanism 907 that allows a client or a server to act on multiple sessions at the 908 same time using only one command. if the Diameter client or server is 909 compromised, an attacker could launch DoS attacks by terminating a 910 large number of sessions with a limited set of commands using the 911 session group management concept. 913 According to the Diameter base protocol [RFC6733], transport 914 connections between Diameter peers are protected by TLS/TCP, DTLS/ 915 SCTP or alternative security mechanisms that are independent of 916 Diameter, such as IPsec. However, the lack of end-to-end security 917 features makes it difficult to establish trust in the session group 918 related information received from non-adjacent nodes. Any Diameter 919 agent in the message path can potentially modify the content of the 920 message and therefore the information sent by the Diameter client or 921 the server. The DIME working group is currently working on solutions 922 for providing end-to-end security features. When available, these 923 features should enable the establishment of trust relationship 924 between non-adjacent nodes and the security required for session 925 group management would normally rely on this end-to-end security. 926 However, there is no assumption in this document that such end-to-end 927 security mechanism will be available. It is only assume that the 928 solution defined on this document relies on the security framework 929 provided by the Diameter based protocol. 931 In some cases, a Diameter Proxy agent can act on behalf of a client 932 or server. In such a case, the security requirements that normally 933 apply to a client (or a server) apply equally to the Proxy agent. 935 11. Acknowledgments 937 The authors of this document want to thank Ben Campbell and Eric 938 McMurry for their valuable comments to early versions of this draft. 939 Furthermore, authors thank Steve Donovan and Mark Bales for the 940 thorough review and comments on advanced versions of the WG document, 941 which helped a lot to improve this specification. 943 12. Normative References 945 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 946 Requirement Levels", BCP 14, RFC 2119, 947 DOI 10.17487/RFC2119, March 1997, 948 . 950 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 951 Ed., "Diameter Base Protocol", RFC 6733, 952 DOI 10.17487/RFC6733, October 2012, 953 . 955 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 956 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 957 . 959 Appendix A. Session Management -- Exemplary Session State Machine 961 A.1. Use of groups for the Authorization Session State Machine 963 Section 8.1 in [RFC6733] defines a set of finite state machines, 964 representing the life cycle of Diameter sessions, and which MUST be 965 observed by all Diameter implementations that make use of the 966 authentication and/or authorization portion of a Diameter 967 application. This section defines, as example, additional state 968 transitions related to the processing of the group commands which may 969 impact multiple sessions. 971 The group membership is session state and therefore only those state 972 machines from [RFC6733] in which the server is maintaining session 973 state are relevant in this document. As in [RFC6733], the term 974 Service-Specific below refers to a message defined in a Diameter 975 application (e.g., Mobile IPv4, NASREQ). 977 The following state machine is observed by a client when state is 978 maintained on the server. State transitions which are unmodified 979 from [RFC6733] are not repeated here. 981 The Diameter group command in the following tables is differentiated 982 from a single-session related command by a preceding 'G' (Group). A 983 Group Re-Auth Request, which applies to one or multiple session 984 groups, has been exemplarily described in Section 6.1. Such Group 985 RAR command is denoted as 'GRAR' in the following table. The same 986 notation applies to other commands as per [RFC6733]. 988 CLIENT, STATEFUL 989 State Event Action New State 990 --------------------------------------------------------------- 991 Idle Client or Device Requests Send Pending 992 access service 993 specific 994 auth req 995 optionally 996 including 997 groups 999 Open GASR received with Send GASA Discon 1000 Group-Response-Action with 1001 = ALL_GROUPS, Result-Code 1002 session is assigned to = SUCCESS, 1003 received group(s) and Send GSTR. 1004 client will comply with 1005 request to end the session 1007 Open GASR received with Send GASA Discon 1008 Group-Response-Action with 1009 = PER_GROUPS, Result-Code 1010 session is assigned to = SUCCESS, 1011 received group(s) and Send GSTR 1012 client will comply with per group 1013 request to end the session 1014 Open GASR received with Send GASA Discon 1015 Group-Response-Action with 1016 = PER_SESSION, Result-Code 1017 session is assigned to = SUCCESS, 1018 received group(s) and Send STR 1019 client will comply with per session 1020 request to end the session 1022 Open GASR received, Send GASA Open 1023 client will not comply with with 1024 request to end all session Result-Code 1025 in received group(s) != SUCCESS 1027 Discon GSTA Received Discon. Idle 1028 user/device 1030 Open GRAR received with Send GRAA, Pending 1031 Group-Response-Action Send 1032 = ALL_GROUPS, service 1033 session is assigned to specific 1034 received group(s) and group 1035 client will perform re-auth req 1036 subsequent re-auth 1038 Open GRAR received with Send GRAA, Pending 1039 Group-Response-Action Send 1040 = PER_GROUP, service 1041 session is assigned to specific 1042 received group(s) and group 1043 client will perform re-auth req 1044 subsequent re-auth per group 1046 Open GRAR received with Send GRAA, Pending 1047 Group-Response-Action Send 1048 = PER_SESSION, service 1049 session is assigned to specific 1050 received group(s) and re-auth req 1051 client will perform per session 1052 subsequent re-auth 1054 Open GRAR received and client will Send GRAA Idle 1055 not perform subsequent with 1056 re-auth Result-Code 1057 != SUCCESS, 1058 Discon. 1059 user/device 1061 Pending Successful service-specific Provide Open 1062 group re-authorization answer service 1063 received. 1065 Pending Failed service-specific Discon. Idle 1066 group re-authorization answer user/device 1067 received. 1069 The following state machine is observed by a server when it is 1070 maintaining state for the session. State transitions which are 1071 unmodified from [RFC6733] are not repeated here. 1073 SERVER, STATEFUL 1074 State Event Action New State 1075 --------------------------------------------------------------- 1077 Idle Service-specific authorization Send Open 1078 request received, and user successful 1079 is authorized service 1080 specific 1081 answer 1082 optionally 1083 including 1084 groups 1086 Open Server wants to terminate Send GASR Discon 1087 group(s) 1089 Discon GASA received Cleanup Idle 1091 Any GSTR received Send GSTA, Idle 1092 Cleanup 1094 Open Server wants to reauth Send GRAR Pending 1095 group(s) 1097 Pending GRAA received with Result-Code Update Open 1098 = SUCCESS session(s) 1100 Pending GRAA received with Result-Code Cleanup Idle 1101 != SUCCESS session(s) 1103 Open Service-specific group Send Open 1104 re-authoization request successful 1105 received and user is service 1106 authorized specific 1107 group 1108 re-auth 1109 answer 1111 Open Service-specific group Send Idle 1112 re-authorization request failed 1113 received and user is service 1114 not authorized specific 1115 group 1116 re-auth 1117 answer, 1118 cleanup 1120 Authors' Addresses 1122 Mark Jones 1124 Email: mark@azu.ca 1126 Marco Liebsch 1128 Email: marco.liebsch@neclab.eu 1130 Lionel Morand 1132 Email: lionel.morand@orange.com