idnits 2.17.1 draft-ietf-dime-group-signaling-01.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 383 has weird spacing: '...ly with wit...' == Line 422 has weird spacing: '... answer servi...' == Line 426 has weird spacing: '... answer user/...' -- The document date (July 15, 2013) is 3931 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 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) Summary: 2 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 M. Jones 3 Extensions (DIME) M. Liebsch 4 Internet-Draft L. Morand 5 Intended status: Standards Track July 15, 2013 6 Expires: January 16, 2014 8 Diameter Group Signaling 9 draft-ietf-dime-group-signaling-01.txt 11 Abstract 13 In large network deployments, a single Diameter peer can support over 14 a million concurrent Diameter sessions. Recent use cases have 15 revealed the need for Diameter peers to apply the same operation to a 16 large group of Diameter sessions concurrently. The Diameter base 17 protocol commands operate on a single session so these use cases 18 could result in many thousands of command exchanges to enforce the 19 same operation on each session in the group. In order to reduce 20 signaling, it would be desirable to enable bulk operations on all (or 21 part of) the sessions managed by a Diameter peer using a single or a 22 few command exchanges. This document specifies the Diameter protocol 23 extensions to achieve this signaling optimization. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 16, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Group assignment at session initiation . . . . . . . . . . 5 63 3.2. Mid-session group assignment modifications . . . . . . . . 5 64 3.2.1. Client-initiated group assignment changes . . . . . . 6 65 3.2.2. Server-initiated group assignment changes . . . . . . 6 66 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Session Grouping and implicit Capability Discovery . . . . 7 68 4.2. Performing Group Operations . . . . . . . . . . . . . . . 8 69 4.2.1. Sending Group Commands . . . . . . . . . . . . . . . . 8 70 4.2.2. Receiving Group Commands . . . . . . . . . . . . . . . 8 71 4.2.3. Single-Session Fallback . . . . . . . . . . . . . . . 9 72 4.3. Session Management . . . . . . . . . . . . . . . . . . . . 9 73 4.3.1. Authorization Session State Machine . . . . . . . . . 9 74 5. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Group Re-Auth-Request . . . . . . . . . . . . . . . . . . 13 76 6. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 14 77 6.1. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 14 78 6.2. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 14 79 7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 15 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 84 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 In large network deployments, a single Diameter peer can support over 90 a million concurrent Diameter sessions. Recent use cases have 91 revealed the need for Diameter peers to apply the same operation to a 92 large group of Diameter sessions concurrently. For example, a policy 93 decision point may need to modify the authorized quality of service 94 for all active users having the same type of subscription. The 95 Diameter base protocol commands operate on a single session so these 96 use cases could result in many thousands of command exchanges to 97 enforce the same operation on each session in the group. In order to 98 reduce signaling, it would be desirable to enable bulk operations on 99 all (or part of) the sessions managed by a Diameter peer using a 100 single or a few command exchanges. 102 This document describes mechanisms for grouping Diameter sessions and 103 applying Diameter commands, such as performing re-authentication, re- 104 authorization, termination and abortion of sessions to a group of 105 sessions. This document does not define a new Diameter application. 106 Instead it defines mechanisms, commands and AVPs that may be used by 107 any Diameter application that requires management of groups of 108 sessions. 110 These mechanisms take the following design goals and features into 111 account: 113 o Minimal impact to existing applications 115 o Extension of existing commands' CCF with optional AVPs to enable 116 grouping and group operations 118 o Fallback to single session operation 120 o Implicit discovery of capability to support grouping and group 121 operations 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 This document uses terminology defined [RFC3588]. 131 3. Grouping User Sessions 133 Either Diameter peer may assign a session to a group. Diameter AAA 134 applications typically assign client and server roles to the Diameter 135 peers. 137 3.1. Group assignment at session initiation 139 Assignment of a new session to a group is accomplished by the 140 Diameter server when requested by the Diameter client. Without being 141 explicitly requested by the client, the Diameter server can assign a 142 new session to a server-assigned group based on its own decision. 143 When a new session is to be assigned to a group by the Diameter 144 server, the server assigns a new session to at least one server- 145 assigned group. To complement server-assigned grouping, a Diameter 146 client can assign a session to a client-assigned group. 148 To assign a session to a group at session initiation, a Diameter 149 client sends a service specific request, e.g. NASREQ AAR [RFC4005], 150 containing one or more group identifiers. The Diameter client can 151 assign the session to a client-assigned group and identify the 152 associated group with an appended client-assigned group identifier. 153 The client can append multiple client-assigned group identifiers if 154 the client assigns the new session to more than one group. If the 155 Diameter client does not send a client-assigned group identifier, the 156 client may receive one or multiple server-assigned group identifiers 157 in the server's response, which identify the server-assigned groups 158 to which the new session has been assigned. The Diameter client can 159 explicitly request the Diameter server to perform grouping of the new 160 session. 162 Assuming the user has been successfully authenticated and/or 163 authorized, the Diameter server responds with service-specific auth 164 response, e.g. NASREQ AAA [RFC4005], containing both the client- 165 assigned group identifiers (if sent with the request) and one or more 166 server-assigned group identifiers. 168 Both peers, the Diameter client and the Diameter server, must keep a 169 list of all group identifiers which identify all client- and server- 170 assigned groups to which the session has been assigned. 172 3.2. Mid-session group assignment modifications 174 Either Diameter peer may modify the group membership of an active 175 Diameter session. A Diameter client MAY remove the group(s) assigned 176 to the active session by the Diameter server and vice versa. 178 This document does not define a permission model that limits removal 179 of a session from a group by the same peer that added the session to 180 the group. However, applications which re-use the commands and 181 methods defined in this document may impose their own permission 182 model. For example, an application could require that the server 183 MUST NOT remove a session from a group assigned by the client. 185 3.2.1. Client-initiated group assignment changes 187 To update the assigned groups mid-session, a Diameter client sends a 188 service specific re-authorization request containing the updated list 189 of group identifiers. Assuming the user is successfully 190 authenticated and/or authorized, the Diameter server responds with a 191 service-specific auth response containing the updated list of group 192 identifiers received in the request. 194 3.2.2. Server-initiated group assignment changes 196 To update the assigned groups mid-session, a Diameter server sends a 197 Re-authorization Request (RAR) message requesting re-authorization 198 and the client responds with a Re-authorization Answer (RAA) message. 199 The Diameter client sends a service specific re-authorization request 200 containing the current list of group identifiers and the Diameter 201 server responds with a service-specific auth response containing the 202 updated list of group identifiers. 204 4. Protocol Description 206 4.1. Session Grouping and implicit Capability Discovery 208 Either Diameter peer, a Diameter client or server, can initiate 209 assigning a session to a single or multiple session groups according 210 to the procedure described in Section 3. Modification of a group by 211 removing or adding a single or multiple user sessions can be 212 initiated and performed at runtime by either Diameter peer. 214 A Diameter client as sender of a command for session initiation can 215 determine one or multiple groups to which the new session should be 216 assigned. Each of these groups need to be identified in a separate 217 Session-Group-Id AVP as specified in Section 6. In each appended 218 Session-Group-Id AVP which carries a client-assigned group 219 identifier, a flag must indicate that the carried group identifier is 220 not a server-assigned but a client-assigned one. If the Diameter 221 client does not determine the group to which the new session should 222 be assigned, the client can set a flag in an appended 223 Session-Group-Id AVP to explicitly request the Diameter server as 224 recipient of the message to assign the new session to one or multiple 225 groups. 227 By appending at least one Session-Group-Id AVP, the Diameter client 228 announces its capability to support group operations according to the 229 specification in this document to the addressed Diameter server. If 230 the Diameter client supports group operations, it MUST append at 231 least one Session-Group-Id AVP to announce its capability to support 232 group operations. 234 A Diameter server receiving a command for session initiation which 235 includes at least one Session-Group-Id AVP learns about the sender's 236 capability to support group operations. If a flag in the appended 237 Session-Group-Id AVPs identifies a client-assigned group, the server 238 must store the one or multiple identifiers and associate the new 239 session with these groups. 241 If a flag in a received Session-Group-Id AVP indicates that the 242 Diameter client explicitly requests the Diameter server to assign the 243 new session to a server-assigned group, the Diameter server should 244 assign the new session to one or multiple groups. The Diameter 245 server identifies each of these server-assigned groups in a Session- 246 Group-Id AVP, which are appended to the response to the received 247 command. Each of these Session-Group-Id AVPs must indicate in a flag 248 that the carried identifier is a server-assigned group identifier. 250 If a flag in a received Session-Group-Id AVP indicates that the 251 Diameter client does not explicitly request the Diameter server to 252 assign the new session to a server-assigned group, the Diameter 253 server may assign the new session to one or multiple groups. The 254 Diameter server identifies each of these server-assigned groups in a 255 Session-Group-Id AVP, which are appended to the response to the 256 received command. Each of these Session-Group-Id AVPs must indicate 257 in a flag that the carried identifier is a server-assigned group 258 identifier. 260 By appending at least one Session-Group-Id AVP, the Diameter server 261 announces its capability to support group operations according to the 262 specification in this document to the addressed Diameter client. 264 A Diameter server receiving a command for session initiation which 265 includes at least one Session-Group-Id AVP but the server does not 266 understand the semantics of this optional AVP because it does not 267 support group operations according to the specification in this 268 document, MUST ignore the optional group operations specific AVPs and 269 proceed with processing the command for a single session. 271 A Diameter client, which sent a request for session initiation to a 272 Diameter server and appended a single or multiple Session-Group-Id 273 AVPs but cannot find any Session-Group-Id AVP in the associated 274 response from the Diameter server proceeds with processing the 275 command for a single session. Furthermore, the client keeps a log to 276 remember that the server is not able to perform group operations. 278 4.2. Performing Group Operations 280 4.2.1. Sending Group Commands 282 Either Diameter peer can request the recipient of a request to 283 process an associated command for all sessions being assigned to one 284 or multiple groups by identifying these groups in the request. The 285 sender of the request appends for each group, to which the command 286 applies, a Session-Group-Id AVP and indicates in a flag whether the 287 identifier represents a server- or a client-assigned group. If the 288 CCF of the request mandates a Session-Id AVP, the Session-Id AVP MUST 289 identify a single session which is assigned to at least one of the 290 groups being identified in the appended Session-Group-Id AVPs. If 291 the sender wants the receiver of the request to process the 292 associated command solely for a single session does not append any 293 group identifier, but identifies the relevant session in the 294 Session-Id AVP. 296 4.2.2. Receiving Group Commands 298 A Diameter peer receiving a request to process a command for a group 299 of sessions identifies the relevant groups according to the appended 300 Session-Group-Id AVP. If the received request identifies multiple 301 groups in multiple appended Session-Group-Id AVPs, the receiver 302 should process the associated command for each of these groups. if a 303 session has been assigned to more than one of the identified groups, 304 the receiver must process the associated command only once per 305 session. 307 4.2.3. Single-Session Fallback 309 Either Diameter peer, a Diameter client or a Diameter server, can 310 fall back to single session operation by ignoring and omitting the 311 optional and group session-specific AVPs. Fallback to single-session 312 operation is performed by processing the Diameter command solely for 313 the session identified in the mandatory Session-Id AVP. The response 314 to the group command must not identify any group but identify solely 315 the single session for which the command has been processed. 317 4.3. Session Management 319 Editor's note: This first document revision adopts the WG's current 320 view on how Diameter commands can be formatted to enable group 321 signaling. The required change in the formatting and protocol 322 operation has not yet been considered in this Section 4.3 , which 323 still reflects the formatting as per version 0 of this specification. 324 The described session state machines still need revision to reflect 325 the generalized formatting and the adopted protocol operation. 327 4.3.1. Authorization Session State Machine 329 Section 8.1 in [RFC3588] defines a set of finite state machines, 330 representing the life cycle of Diameter sessions, and which MUST be 331 observed by all Diameter implementations that make use of the 332 authentication and/or authorization portion of a Diameter 333 application. This section defines the additional state transitions 334 related to the processing of the new commands which may impact 335 multiple sessions. 337 The group membership is session state and therefore only those state 338 machines from [RFC3588] in which the server is maintaining session 339 state are relevant in this document. As in [RFC3588], the term 340 Service-Specific below refers to a message defined in a Diameter 341 application (e.g., Mobile IPv4, NASREQ). 343 The following state machine is observed by a client when state is 344 maintained on the server. State transitions which are unmodified 345 from [RFC3588] are not repeated here. 347 CLIENT, STATEFUL 348 State Event Action New State 349 --------------------------------------------------------------- 350 Idle Client or Device Requests Send Pending 351 access service 352 specific 353 auth req 354 optionally 355 including 356 groups 358 Open GASR received with Send GASA Discon 359 Session-Group-Action with 360 = ALL_GROUPS, Result-Code 361 session is assigned to = SUCCESS, 362 received group(s) and Send GSTR. 363 client will comply with 364 request to end the session 366 Open GASR received with Send GASA Discon 367 Session-Group-Action with 368 = PER_GROUPS, Result-Code 369 session is assigned to = SUCCESS, 370 received group(s) and Send GSTR 371 client will comply with per group 372 request to end the session 374 Open GASR received with Send GASA Discon 375 Session-Group-Action with 376 = PER_SESSION, Result-Code 377 session is assigned to = SUCCESS, 378 received group(s) and Send STR 379 client will comply with per session 380 request to end the session 382 Open GASR received, Send GASA Open 383 client will not comply with with 384 request to end all session Result-Code 385 in received group(s) != SUCCESS 387 Discon GSTA Received Discon. Idle 388 user/device 390 Open GRAR received with Send GRAA, Pending 391 Session-Group-Action Send 392 = ALL_GROUPS, service 393 session is assigned to specific 394 received group(s) and group 395 client will perform re-auth req 396 subsequent re-auth 398 Open GRAR received with Send GRAA, Pending 399 Session-Group-Action Send 400 = PER_GROUP, service 401 session is assigned to specific 402 received group(s) and group 403 client will perform re-auth req 404 subsequent re-auth per group 406 Open GRAR received with Send GRAA, Pending 407 Session-Group-Action Send 408 = PER_SESSION, service 409 session is assigned to specific 410 received group(s) and re-auth req 411 client will perform per session 412 subsequent re-auth 414 Open GRAR received and client will Send GRAA Idle 415 not perform subsequent with 416 re-auth Result-Code 417 != SUCCESS, 418 Discon. 419 user/device 421 Pending Successful service-specific Provide Open 422 group re-authorization answer service 423 received. 425 Pending Failed service-specific Discon. Idle 426 group re-authorization answer user/device 427 received. 429 The following state machine is observed by a server when it is 430 maintaining state for the session. State transitions which are 431 unmodified from [RFC3588] are not repeated here. 433 SERVER, STATEFUL 434 State Event Action New State 435 --------------------------------------------------------------- 437 Idle Service-specific authorization Send Open 438 request received, and user successful 439 is authorized service 440 specific 441 answer 442 optionally 443 including 444 groups 446 Open Server wants to terminate Send GASR Discon 447 group(s) 449 Discon GASA received Cleanup Idle 451 Any GSTR received Send GSTA, Idle 452 Cleanup 454 Open Server wants to reauth Send GRAR Pending 455 group(s) 457 Pending GRAA received with Result-Code Update Open 458 = SUCCESS session(s) 460 Pending GRAA received with Result-Code Cleanup Idle 461 != SUCCESS session(s) 463 Open Service-specific group Send Open 464 re-authoization request successful 465 received and user is service 466 authorized specific 467 group 468 re-auth 469 answer 471 Open Service-specific group Send Idle 472 re-authorization request failed 473 received and user is service 474 not authorized specific 475 group 476 re-auth 477 answer, 478 cleanup 480 5. Commands Formatting 482 This document does not specify new Diameter commands to enable group 483 operations, but relies on command extensibility capability provided 484 by the Diameter Base protocol. This section provides the guidelines 485 to extend the CCF of existing Diameter commands with optional AVPs to 486 enable the recipient of the command to perform the command to all 487 sessions associated with the identified group(s). 489 5.1. Group Re-Auth-Request 491 A request that one or more groups of users are re-authentication is 492 issues by appending one or multiple Session-Group-Id AVP(s) to the 493 Re-Auth-Request (RAR). The one or multiple Session-Group-Id AVP(s) 494 identify the associated group(s) for which the group re- 495 authentication has been requested. The recipient of the group 496 command initiates re-authentication for all users associated with the 497 identified group(s). Furthermore, the sender of the group re- 498 authentication request appends a Session-Group-Action AVP to provide 499 more information to the receiver of the command about how to 500 accomplish the group operation. 502 The value of the mandatory Session-Id AVP MUST identify a session 503 associated with a single user, which is assigned to at least one of 504 the groups being identified in the appended Session-Group-Id AVPs. 506 ::= < Diameter Header: 258, REQ, PXY > 507 < Session-Id > 508 { Origin-Host } 509 { Origin-Realm } 510 { Destination-Realm } 511 { Destination-Host } 512 { Auth-Application-Id } 513 { Re-Auth-Request-Type } 514 [ User-Name ] 515 [ Origin-State-Id ] 516 * [ Proxy-Info ] 517 * [ Route-Record ] 518 * [ Session-Group-Id ] 519 [ Session-Group-Action ] 520 * [ AVP ] 522 6. Attribute-Value-Pairs (AVP) 524 +--------------------+ 525 | AVP Flag rules | 526 +----+---+------+----+ 527 AVP | | |SHOULD|MUST| 528 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 529 +---------------------------------------+----+---+------+----+ 530 |Session-Group-Id TBD OctetString | | P | | V | 531 |Session-Group-Action TBD Enumerated | | P | | V | 532 +---------------------------------------+----+---+------+----+ 534 AVPs for the Diameter Group Signaling 536 6.1. Session-Group-Id AVP 538 The Session-Group-Id AVP (AVP Code TBD) is of type OctetString and 539 identifies a group of sessions. This uniqueness scope of this AVP is 540 specified by the Diameter application which makes use of group 541 signaling commands. 543 6.2. Session-Group-Action AVP 545 The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and 546 specifies how the peer SHOULD issue follow up exchanges in response 547 to a command which impacts mulitple sessions. The following values 548 are supported: 550 ALL_GROUPS (0) 551 Follow up exchanges should be performed with a single message 552 exchange for all impacted groups. 554 PER_GROUP (1) 555 Follow up exchanges should be performed with a message exchange 556 for each impacted group. 558 PER_SESSION (2) 559 Follow up exchanges should be performed with a message exchange 560 for each impacted session. 562 7. Result-Code AVP Values 564 This section defines new Result-Code [RFC3588] values that MUST be 565 supported by all Diameter implementations that conform to this 566 specification. 568 [Editor's Note: Group specific error values may need to be added 569 here.] 571 8. IANA Considerations 573 This section contains the namespaces that have either been created in 574 this specification or had their values assigned to existing 575 namespaces managed by IANA. 577 8.1. AVP Codes 579 This specification requires IANA to register the following new AVPs 580 from the AVP Code namespace defined in [RFC3588]. 582 o Session-Group-Id 584 o Session-Group-Action 586 The AVPs are defined in Section 6. 588 9. Security Considerations 590 TODO 592 10. Acknowledgments 593 11. Normative References 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, March 1997. 598 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 599 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 601 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 602 "Diameter Network Access Server Application", RFC 4005, 603 August 2005. 605 Authors' Addresses 607 Mark Jones 609 Email: mark@azu.ca 611 Marco Liebsch 613 Email: marco.liebsch@neclab.eu 615 Lionel Morand 617 Email: lionel.morand@orange.com