idnits 2.17.1 draft-ietf-dime-group-signaling-13.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 1047 has weird spacing: '...ly with wit...' == Line 1086 has weird spacing: '... answer servi...' == Line 1090 has weird spacing: '... answer user/...' -- The document date (March 9, 2020) is 1506 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: September 10, 2020 6 L. Morand 7 March 9, 2020 9 Diameter Group Signaling 10 draft-ietf-dime-group-signaling-13.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 September 10, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . 5 66 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Session Grouping Capability Discovery . . . . . . . . . . 6 68 4.1.1. Implicit Capability Discovery . . . . . . . . . . . . 6 69 4.1.2. Explicit 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 . . . . . 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 9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 20 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 95 12. Normative References . . . . . . . . . . . . . . . . . . . . 21 96 Appendix A. Session Management -- Exemplary Session State 97 Machine . . . . . . . . . . . . . . . . . . . . . . 22 98 A.1. Use of groups for the Authorization Session State Machine 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Introduction 103 In large network deployments, a single Diameter node can support over 104 a million concurrent Diameter sessions. Recent use cases have 105 revealed the need for Diameter nodes to apply the same operation to a 106 large group of Diameter sessions concurrently. For example, a policy 107 decision point may need to modify the authorized quality of service 108 for all active users having the same type of subscription. The 109 Diameter base protocol commands operate on a single session so these 110 use cases could result in many thousands of command exchanges to 111 enforce the same operation on each session in the group. In order to 112 reduce signaling, it would be desirable to enable bulk operations on 113 all (or part of) the sessions managed by a Diameter node using a 114 single or a few command exchanges. 116 This document describes mechanisms for grouping Diameter sessions and 117 applying Diameter commands, such as performing re-authentication, re- 118 authorization, termination and abortion of sessions to a group of 119 sessions. This document does not define a new Diameter application. 120 Instead it defines mechanisms, commands and AVPs that may be used by 121 any Diameter application that requires management of groups of 122 sessions. 124 These mechanisms take the following design goals and features into 125 account: 127 o Minimal impact to existing applications 129 o Extension of existing commands' Command Code Format (CCF) with 130 optional AVPs to enable grouping and group operations 132 o Fallback to single session operation 134 o Implicit discovery of capability to support grouping and group 135 operations in case no external mechanism is available to discover a 136 Diameter peer's capability to support session grouping and session 137 group operations 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 This document uses terminology defined in [RFC6733]. 149 3. Protocol Overview 151 3.1. Building and Modifying Session Groups 153 Client and Server can assign a new Diameter session to a group, e.g., 154 in case the subscription profile of the associated user has similar 155 characteristics as the profile of other users whose Diameter session 156 has been assigned to one or multiple groups. A single command can be 157 issued and applied to all sessions associated with such group(s), 158 e.g., to adjust common profile or policy settings. 160 The assignment of a Diameter session to a group can be changed during 161 an ongoing session (mid-session). For example, if a user's 162 subscription profile changes mid-session, a Diameter server may 163 remove a session from an existing group and assign this session to a 164 different group that is more appropriate for the new subscription 165 profile. 167 In the case of mobile users, the user's session may get transferred 168 mid-session to a new Diameter client during handover and assigned to 169 a different group, which is maintained at the new Diameter client. 171 A session group, which has sessions assigned, can be deleted, e.g., 172 due to a change in multiple users' subscription profile so that the 173 group's assigned sessions do not share certain characteristics 174 anymore. Deletion of such group requires subsequent individual 175 treatment of each of the assigned sessions. A node may decide to 176 assign some of these sessions to any other existing or new group. 178 3.2. Issuing Group Commands 180 Changes in the network condition may result in the Diameter server's 181 decision to close all sessions in a given group. As example, the 182 server issues a single Session Termination Request (STR) command, 183 including the identifier of the group of sessions which are to be 184 terminated. The Diameter client treats the STR as group command and 185 initiates the termination of all sessions associated with the 186 identified group. Subsequently, the client confirms the successful 187 termination of these sessions to the server by sending a single 188 Session Termination Answer (STA) command, which includes the 189 identifier of the group. 191 3.3. Permission Considerations 193 Permission considerations in the context of this draft apply to the 194 permission of Diameter nodes to build new session groups, to assign/ 195 remove a session to/from a session group and to delete an existing 196 session group. 198 This specification follows the most flexible model where both, a 199 Diameter client and a Diameter server can create a new group and 200 assign a new identifier to that session group. When a client or a 201 server decides to create a new session group, e.g., to group all 202 sessions which share certain characteristics, this node builds a 203 session group identifier according to the rules described in 204 Section 7.3 and becomes the owner of the group. This specification 205 does not restrict the permission to add or remove a session to/from a 206 session group to the group owner. Either the client and the server 207 can assign a session to a group. However, a session can be removed 208 from a session group and/or moved to another session group only by 209 the node that has assigned this session to the session group. A 210 session group is deleted and its identifier released after the last 211 session has been removed from this session group. The owner of a 212 session group can delete a session group and its group identifier 213 mid-session, resulting in individual treatment of the sessions which 214 have been previously assigned to the deleted group. A session group 215 must only be deleted by the Diameter node that created it. 217 Diameter applications with implicit support for session groups MAY 218 define a more constrained permission model. For example, a more 219 constrained model could require that a client must not remove a 220 session from a group which is owned by the server. Details about 221 enforcing a more constraint permission model are out of scope of this 222 specification. 224 The following table depicts the permission considerations as per the 225 present specification: 227 +-------------------------------------------------+--------+--------+ 228 | Operation | Server | Client | 229 +-------------------------------------------------+--------+--------+ 230 | Create a new Session Group (Diameter node | X | X | 231 | becomes the group owner) | | | 232 +-------------------------------------------------+--------+--------+ 233 | Assign a Session to an owned Session Group | X | X | 234 +-------------------------------------------------+--------+--------+ 235 | Assign a Session to a non-owned Session Group | X | X | 236 +-------------------------------------------------+--------+--------+ 237 | Remove a Session from an owned Session Group | X | X | 238 +-------------------------------------------------+-----------------+ 239 | Remove a Session from a non-owned Session Group | X | X | 240 +-------------------------------------------------+--------+--------+ 241 | Remove a Session from a Session Group where the | X | X | 242 | Diameter node created the assignment | | | 243 +-------------------------------------------------+--------+--------+ 244 | Remove a Session from a Session Group where the | | | 245 | Diameter node did not create the assignment | | | 246 +-------------------------------------------------+--------+--------+ 247 | Overrule a different Diameter node's | | | 248 | group assignment *) | | | 249 +-------------------------------------------------+--------+--------+ 250 | Delete a Session Group which is owned by the | X | X | 251 | Diameter node | | | 252 +-------------------------------------------------+--------+--------+ 253 | Delete a Session Group which is not owned by | | | 254 | the Diameter node | | | 255 +-------------------------------------------------+--------+--------+ 257 Default Permission as per this Specification 259 4. Protocol Description 261 4.1. Session Grouping Capability Discovery 263 Diameter nodes SHOULD NOT perform group operations with peer nodes 264 unless the node has advertised support for session grouping and group 265 operations. 267 4.1.1. Implicit Capability Discovery 269 Newly defined Diameter applications may natively support Diameter 270 session grouping and group operations. Such applications provide 271 intrinsic discovery for the support of session grouping capability 272 using the assigned Application Id advertised during the capability 273 exchange phase two Diameter peers establish a transport connection 274 (see Section 5.3 of [RFC6733]). 276 System- and deployment-specific means, as well as out-of-band 277 mechanisms for capability discovery can be used to announce nodes' 278 support for session grouping and session group operations. In such 279 case, the optional Session-Group-Capability-Vector AVP, as described 280 in Section 4.1.2 can be omitted in Diameter messages being exchanged 281 between nodes. 283 4.1.2. Explicit Capability Discovery 285 If no other mechanism for capability discovery is deployed to enable 286 Diameter nodes to learn about nodes' capability to support session 287 grouping and group commands for a given application, a Diameter node 288 SHOULD append the Session-Group-Capability-Vector AVP to any Diameter 289 application messages exchanged with the other Diameter nodes to 290 announce its capability to support session grouping and session group 291 operations for the advertised application. Implementations following 292 the specification as per this document MUST set the 293 BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability- 294 Vector AVP. 296 When a Diameter node receives at least one Session-Group-Capability- 297 Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag 298 set, the receiving Diameter node discovers the supported session 299 grouping capability of the sending Diameter node for the advertised 300 application and MUST cache this information for the lifetime of the 301 routing table entry associated with the peer identity/Application Id 302 pair (see Section 2.7 of [RFC6733]). 304 4.2. Session Grouping 306 This specification does not limit the number of session groups to 307 which a single session is assigned. It is left to the implementation 308 of an application to determine such limitations. If an application 309 facilitates a session to belong to multiple session groups, the 310 application MUST maintain consistency of associated application 311 session states for these multiple session groups. 313 Either Diameter node (client or server) can initiate the assignment 314 of a session to a single or multiple session groups. Modification of 315 a group by removing or adding a single or multiple user sessions can 316 be initiated and performed mid-session by either Diameter node 317 responsible for the session assignment to this group. Diameter AAA 318 applications typically assign client and server roles to the Diameter 319 nodes, which are referred to as relevant Diameter nodes to utilize 320 session grouping and issue group commands. Section 5 describes 321 particularities about session grouping and performing group commands 322 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 is locally maintained on each node, 327 each group pointing to individual sessions being assigned to the 328 group. A Diameter node MUST also keep a record about sessions, which 329 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. For all assignments of a session to an active 345 session group made by the client or the server, the 346 SESSION_GROUP_STATUS_IND flag in the Session-Group-Info AVP, which 347 identifies the session group, MUST be set. A set 348 SESSION_GROUP_STATUS_IND flag indicates that the identified session 349 group has just been created or is still active. 351 The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the 352 Session-Group-Control-Vector AVP in each appended Session-Group-Info 353 AVP to indicate that the session contained in the request should be 354 assigned to the identified session group. 356 The client may also indicate in the request that the server is 357 responsible for the assignment of the session in one or multiple 358 sessions owned by the server. In such a case, the client MUST 359 include the Session-Group-Info AVP in the request including the 360 Session-Group-Control-Vector AVP with the 361 SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP. 363 If the Diameter server receives a command request from a Diameter 364 client and the command includes at least one Session-Group-Info AVP 365 having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group- 366 Control-Vector AVP set, the server can accept or reject the request 367 for group assignment. Reasons for rejection may be e.g., lack of 368 resources for managing additional groups. When rejected, the session 369 MUST NOT be assigned to any session group. 371 If the Diameter server accepts the client's request for a group 372 assignment, the server MUST assign the new session to each of the one 373 or multiple identified session groups when present in the Session- 374 Group-Info AVP. If one or multiple identified session groups are not 375 already stored by the server, the server MUST store the newly 376 identified group(s) to its local list of known session groups. When 377 sending the response to the client, e.g., a service-specific auth 378 response as per NASREQ AA-Answer [RFC7155], the server MUST include 379 all Session-Group-Info AVPs as received in the client's request. 381 In addition to the one or multiple session groups identified in the 382 client's request, the server may decide to assign the new session to 383 one or multiple additional groups. In such a case, the server MUST 384 add to the response the additional Session-Group-Info AVPs, each 385 identifying a session group to which the new session is assigned by 386 the server. Each of the Session-Group-Info AVP added by the server 387 MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the 388 Session-Group-Control-Vector AVP set. 390 If the Diameter server rejects the client's request for a group 391 assignment, the server sends the response to the client, e.g., a 392 service-specific auth response as per NASREQ AA-Answer [RFC7155], and 393 MUST include all Session-Group-Info AVPs as received in the client's 394 request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION 395 flag of the Session-Group-Control-Vector AVP. The server MAY accept 396 the client's request for the identified session but refuse the 397 session's assignment to any session group. The server sends the 398 response to the client indicating success in the result code. In 399 such case the session is treated as single session without assignment 400 to any session group by the Diameter nodes. 402 If the assignment of the session to one or some of the multiple 403 identified session groups fails, the session group assignment is 404 treated as failure. In such case the session is treated as single 405 session without assignment to any session group by the Diameter 406 nodes. The server sends the response to the client and MAY include 407 those Session-Group-Info AVPs for which the group assignment failed. 408 The SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group- 409 Info AVPs MUST be cleared. 411 If the Diameter server receives a command request from a Diameter 412 client and the command includes a Session-Group-Info AVP which does 413 not include a Session-Group-Id AVP, the server MAY decide to assign 414 the session to one or multiple session groups. For each session 415 group, to which the server assigns the new session, the server 416 includes a Session-Group-Info AVP with the Session-Group-Id AVP 417 identifying a session group in the response sent to the client. Each 418 of the Session-Group-Info AVPs included by the server MUST have the 419 SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- 420 Vector AVP set. 422 If the Diameter server receives a command request from a Diameter 423 client and the command does not contain any Session-Group-Info AVP, 424 the server MUST NOT assign the new session to any session group but 425 treat the request as for a single session. The server MUST NOT 426 return any Session-Group-Info AVP in the command response. 428 If the Diameter client receives a response to its previously issued 429 request from the server and the response includes at least one 430 Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION 431 flag of the associated Session-Group-Control-Vector AVP set, the 432 client MUST add the new session to all session groups as identified 433 in the one or multiple Session-Group-Info AVPs. If the Diameter 434 client fails to add the session to one or more session groups as 435 identified in the one or multiple Session-Group-info AVPs, the client 436 MUST terminate the session. The client MAY send a subsequent request 437 for session initiation to the server without requesting the 438 assignment of the session to a session group 440 If the Diameter client receives a response to its previously issued 441 request from the server and the one or more Session-Group-Info AVPs 442 have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated 443 Session-Group-Control-Vector AVP cleared, the client MUST terminate 444 the assignment of the session to the one or multiple groups. If the 445 response from the server indicates success in the result code but 446 solely the assignment of the session to a session group has been 447 rejected by the server, the client treats the session as single 448 session without group assignment. 450 A Diameter client, which sent a request for session initiation to a 451 Diameter server and appended a single or multiple Session-Group-Id 452 AVPs but cannot find any Session-Group-Info AVP in the associated 453 response from the Diameter server proceeds as if the request was 454 processed for a single session. The Diameter client MUST NOT retry 455 to request group assignment for this session, but MAY try to request 456 group assignment for other new sessions. 458 4.2.2. Removing a session from a session group 460 When a Diameter client decides to remove a session from a particular 461 session group, the client sends a service-specific re-authorization 462 request to the server and adds one Session-Group-Info AVP to the 463 request for each session group, from which the client wants to remove 464 the session. The session, which is to be removed from a group, is 465 identified in the Session-Id AVP of the command request. The 466 SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- 467 Vector AVP in each Session-Group-Info AVP MUST be cleared to indicate 468 removal of the session from the session group identified in the 469 associated Session-Group-id AVP. 471 When a Diameter client decides to remove a session from all session 472 groups, to which the session has been previously assigned, the client 473 sends a service-specific re-authorization request to the server and 474 adds a single Session-Group-Info AVP to the request which has the 475 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 476 AVP omitted. The session, which is to be removed from all groups, to 477 which the session has been previously assigned, is identified in the 478 Session-Id AVP of the command request. 480 If the Diameter server receives a request from the client which has 481 at least one Session-Group-Info AVP appended with the 482 SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove 483 the session from the session group identified in the associated 484 Session-Group-Id AVP. If the request includes at least one Session- 485 Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared 486 and no Session-Id AVP present, the server MUST remove the session 487 from all session groups to which the session has been previously 488 assigned. The server MUST include in its response to the requesting 489 client all Session-Group-Id AVPs as received in the request. 491 When the Diameter server decides to remove a session from one or 492 multiple particular session groups or from all session groups to 493 which the session has been assigned beforehand, the server sends a 494 Re-Authorization Request (RAR) or a service-specific server-initiated 495 request to the client, indicating the session in the Session-Id AVP 496 of the request. The client sends a Re-Authorization Answer (RAA) or 497 a service-specific answer to respond to the server's request. The 498 client subsequently sends service-specific re-authorization request 499 containing one or multiple Session-Group-Info AVPs, each indicating a 500 session group, to which the session had been previously assigned. To 501 indicate removal of the indicated session from one or multiple 502 session groups, the server sends a service-specific auth response to 503 the client, containing a list of Session-Group-Info AVPs with the 504 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 505 AVP identifying the session group, from which the session should be 506 removed. The server MAY include to the service-specific auth 507 response a list of Session-Group-Info AVPs with the 508 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 509 identifying session groups to which the session remains subscribed. 510 If the server decides to remove the identified session from all 511 session groups, to which the session has been previously assigned, 512 the server includes in the service-specific auth response at least 513 one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION 514 flag cleared and Session-Group-Id AVP absent. 516 4.2.3. Mid-session group assignment modifications 518 Either Diameter node (client or server) can modify the group 519 membership of an active Diameter session according to the specified 520 permission considerations. 522 To update an assigned group mid-session, a Diameter client sends a 523 service-specific re-authorization request to the server, containing 524 one or multiple Session-Group-Info AVPs with the 525 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 526 present, identifying the session group to which the session should be 527 assigned. With the same message, the client may send one or multiple 528 Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag 529 cleared and the Session-Group-Id AVP identifying the session group 530 from which the identified session is to be removed. To remove the 531 session from all previously assigned session groups, the client 532 includes at least one Session-Group-Info AVP with the 533 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 534 AVP present. When the server received the service-specific re- 535 authorization request, it MUST update its locally maintained view of 536 the session groups for the identified session according to the 537 appended Session-Group-Info AVPs. The server sends a service- 538 specific auth response to the client containing one or multiple 539 Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag 540 set and the Session-Group-Id AVP identifying the new session group to 541 which the identified session has been assigned. 543 When a Diameter server enforces an update to the assigned groups mid- 544 session, it sends a Re-Authorization Request (RAR) message or a 545 service-specific request to the client identifying the session, for 546 which the session group lists are to be updated. The client responds 547 with a Re-Authorization Answer (RAA) message or a service-specific 548 answer. The client subsequently sends a service-specific re- 549 authorization request containing one or multiple Session-Group-Info 550 AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the 551 Session-Group-Id AVP identifying the session group to which the 552 session had been previously assigned. The server responds with a 553 service-specific auth response and includes one or multiple Session- 554 Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and 555 the Session-Group-Id AVP identifying the session group, to which the 556 identified session is to be assigned. With the same response 557 message, the server may send one or multiple Session-Group-Info AVPs 558 with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the 559 Session-Group-Id AVP identifying the session groups from which the 560 identified session is to be removed. When server wants to remove the 561 session from all previously assigned session groups, it sends at 562 least one Session-Group-Info AVP with the response having the 563 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 564 AVP present. 566 4.3. Deleting a Session Group 568 To delete a session group and release the associated Session-Group-Id 569 value, the owner of a session group appends a single Session-Group- 570 Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the 571 Session-Group-Id AVP identifying the session group, which is to be 572 deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated 573 Session-Group-Control-Vector AVP MUST be cleared. 575 4.4. Performing Group Operations 577 4.4.1. Sending Group Commands 579 Either Diameter node (client or server) can request the recipient of 580 a request to process an associated command for all sessions assigned 581 to one or multiple groups by identifying these groups in the request. 582 The sender of the request appends for each group, to which the 583 command applies, a Session-Group-Info AVP including the Session- 584 Group-Id AVP to identify the associated session group. Both, the 585 SESSION_GROUP_ALLOCATION_ACTION flag as well as the 586 SESSION_GROUP_STATUS_IND flag MUST be set. 588 If the Command Code Format (CCF) of the request mandates a Session-Id 589 AVP, the Session-Id AVP MUST identify one of the single sessions 590 which is assigned to at least one of the groups being identified in 591 the appended Session-Group-Id AVPs. 593 The sender of the request MUST indicate to the receiver how multiple 594 resulting transactions associated with a group command are to be 595 treated by appending a single instance of a Group-Response-Action 596 AVP. For example, when a server sends a Re-Authorization Request 597 (RAR) or a service-specific server-initiated request to the client, 598 it indicates to the client to follow the request according to one of 599 three possible procedures. When the server sets the Group-Response- 600 Action AVP to ALL_GROUPS (1), the client sends a single RAR message 601 for all identified groups. When the server sets the Group-Response- 602 Action AVP to PER_GROUP (2), the client sends a single RAR message 603 for each identified group individually. When the server sets the 604 Group-Response-Action AVP to PER_SESSION (3), the client follows-up 605 with a single RAR message per impacted session. If a session is 606 included in more than one of the identified session groups, the 607 client sends only one RAR message for that session. 609 If the sender sends a request including the Group-Response-Action AVP 610 set to ALL_GROUPS (1) or PER_GROUP (2), it has to expect some delay 611 before receiving the corresponding answer(s) as the answer(s) will 612 only be sent back when the request is processed for all the sessions 613 or all the session of a session group. If the process of the request 614 is delay-sensitive, the sender SHOULD NOT set the Group-Response- 615 Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be 616 sent before the complete process of the request for all the sessions 617 or if the request timeout timer is high enough, the sender MAY set 618 the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). 620 If the sender wants the receiver of the request to process the 621 associated command solely for a single session, the sender does not 622 append any group identifier, but identifies the relevant session in 623 the Session-Id AVP. 625 4.4.2. Receiving Group Commands 627 A Diameter node receiving a request to process a command for a group 628 of sessions, identifies the relevant groups according to the appended 629 Session-Group-Id AVP in the Session-Group-Info AVP and processes the 630 group command according to the appended Group-Response-Action AVP . 631 If the received request identifies multiple groups in multiple 632 appended Session-Group-Id AVPs, the receiver SHOULD process the 633 associated command for each of these groups. If a session has been 634 assigned to more than one of the identified groups, the receiver MUST 635 process the associated command only once per session. 637 4.4.3. Error Handling for Group Commands 639 When a Diameter node receives a request to process a command for one 640 or more session groups and the result of processing the command is an 641 error that applies to all sessions in the identified groups, an 642 associated protocol error MUST be returned to the source of the 643 request. In such case, the sender of the request MUST fall back to 644 single-session processing and the session groups, which have been 645 identified in the group command, MUST be deleted according to the 646 procedure described in Section 4.3. 648 When a Diameter node receives a request to process a command for one 649 or more session groups and the result of processing the command 650 succeeds for some sessions identified in one or multiple session 651 groups, but fails for one or more sessions, the Result-Code AVP in 652 the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per 653 Section 7.1.2 of [RFC6733]. 655 In the case of limited success, the sessions, for which the 656 processing of the group command failed, MUST be identified using a 657 Failed-AVP AVP as per Section 7.5 of [RFC6733]. The sender of the 658 request MUST fall back to single-session operation for each of the 659 identified sessions, for which the group command failed. In 660 addition, each of these sessions MUST be removed from all session 661 groups to which the group command applied. To remove sessions from a 662 session group, the Diameter client performs the procedure described 663 in Section 4.2.2. 665 4.4.4. Single-Session Fallback 667 Either Diameter node can fall back to single session operation by 668 ignoring and omitting the optional group session-specific AVPs. 669 Fallback to single-session operation is performed by processing the 670 Diameter command solely for the session identified in the mandatory 671 Session-Id AVP. In such case, the response to the group command MUST 672 NOT identify any group but identify solely the single session for 673 which the command has been processed. 675 5. Operation with Proxy Agents 677 In the case of a present stateful Proxy Agent between a Diameter 678 client and a Diameter server, the Proxy Agent MUST perform the same 679 mechanisms per this specification to advertise session grouping and 680 group operations capability towards the client and the server 681 respectively. The Proxy MUST update and maintain consistency of its 682 local session states as per the result of the group commands which 683 are operated between a Diameter client and a server. In such case, 684 the Proxy Agent MUST act as a Diameter server in front of the 685 Diameter client and MUST act as a Diameter client in front of the 686 Diameter server. Therefore, the client and server behavior described 687 in Section 4 applies respectively to the stateful Proxy Agent. 689 If a stateful Proxy Agent manipulates session groups, it MUST 690 maintain consistency of session groups between a client and a server. 691 This applies to a deployment where the Proxy Agent utilizes session 692 grouping and performs group operations with, for example, a Diameter 693 server, whereas the Diameter client is not aware of session groups. 694 In such case the Proxy Agent must reflect the states associated with 695 the session groups as individual session operations towards the 696 client and ensure the client has a consistent view of each session. 697 The same applies to a deployment where all nodes, the Diameter client 698 and server, as well as the Proxy Agent are group-aware but the Proxy 699 Agent manipulates groups, e.g., to adopt different administrative 700 policies that apply to the client's domain and the server's domain. 702 Stateless Proxy Agents do not maintain any session state (only 703 transaction state are maintained). Consequently, the notion of 704 session group is transparent for any stateless Proxy Agent present 705 between a Diameter client and a Diameter server handling session 706 groups. Session group related AVPs being defined as optional AVP are 707 ignored by stateless Proxy Agents and should not be removed from the 708 Diameter commands. If they are removed by the Proxy Agent for any 709 reason, the Diameter client and Diameter server will discover the 710 absence the related session group AVPs and will fall back to single- 711 session processing, as described in Section 4. 713 6. Commands Formatting 715 This document does not specify new Diameter commands to enable group 716 operations, but relies on command extensibility capability provided 717 by the Diameter Base protocol. This section provides the guidelines 718 to extend the CCF of existing Diameter commands with optional AVPs to 719 enable the recipient of the command applying the command to all 720 sessions associated with the identified group(s). 722 6.1. Formatting Example: Group Re-Auth-Request 724 A request for re-authentication of one or more groups of users is 725 issued by appending one or multiple Session-Group-Id AVP(s), as well 726 as a single instance of a Group-Response-Action AVP to the Re-Auth- 727 Request (RAR). The one or multiple Session-Group-Id AVP(s) identify 728 the associated group(s) for which the group re-authentication has 729 been requested. The Group-Response-Action AVP identifies the 730 expected means to perform and respond to the group command. The 731 recipient of the group command initiates re-authentication for all 732 users associated with the identified group(s). Furthermore, the 733 sender of the group re-authentication request appends a Group- 734 Response-Action AVP to provide more information to the receiver of 735 the command about how to accomplish the group operation. 737 The value of the mandatory Session-Id AVP MUST identify a session 738 associated with a single user, which is assigned to at least one of 739 the groups being identified in the appended Session-Group-Id AVPs. 741 ::= < Diameter Header: 258, REQ, PXY > 742 < Session-Id > 743 { Origin-Host } 744 { Origin-Realm } 745 { Destination-Realm } 746 { Destination-Host } 747 { Auth-Application-Id } 748 { Re-Auth-Request-Type } 749 [ User-Name ] 750 [ Origin-State-Id ] 751 * [ Proxy-Info ] 752 * [ Route-Record ] 753 [ Session-Group-Capability-Vector ] 754 * [ Session-Group-Info ] 755 [ Group-Response-Action ] 756 * [ AVP ] 758 7. Attribute-Value-Pairs (AVP) 760 +--------------------+ 761 | AVP Flag rules | 762 +----+---+------+----+ 763 AVP | | |SHOULD|MUST| 764 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 765 +-------------------------------------------------+----+---+------+----+ 766 |Session-Group-Info TBD1 Grouped | | P | | V | 767 |Session-Group-Control-Vector TBD2 Unsigned32 | | P | | V | 768 |Session-Group-Id TBD3 OctetString | | P | | V | 769 |Group-Response-Action TBD4 Unsigned32 | | P | | V | 770 |Session-Group-Capability-Vector TBD5 Unsigned32 | | P | | V | 771 +-------------------------------------------------+----+---+------+----+ 773 AVPs for the Diameter Group Signaling 775 7.1. Session-Group-Info AVP 777 The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It 778 contains the identifier of the session group as well as an indication 779 of the node responsible for session group identifier assignment. 781 Session-Group-Info ::= < AVP Header: TBD1 > 782 < Session-Group-Control-Vector > 783 [ Session-Group-Id ] 784 * [ AVP ] 786 7.2. Session-Group-Control-Vector AVP 788 The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type 789 Unsigned32 and contains a 32-bit flags field to control the group 790 assignment at session-group aware nodes. 792 The following control flags are defined in this document: 794 SESSION_GROUP_ALLOCATION_ACTION (0x00000001) 796 This flag indicates the action to be performed for the identified 797 session. When this flag is set, it indicates that the identified 798 Diameter session is to be assigned to the session group as 799 identified by the Session-Group-Id AVP or the session's assignment 800 to the session group identified in the Session-Group-Id AVP is 801 still valid. When the flag is cleared, the identified Diameter 802 session is to be removed from at least one session group. When 803 the flag is cleared and the Session-Group-Info AVP identifies a 804 particular session group in the associated Session-Group-Id AVP, 805 the session is to be removed solely from the identified session 806 group. When the flag is cleared and the Session-Group-Info AVP 807 does not identify a particular session group (Session-Group-Id AVP 808 is absent), the identified Diameter session is to be removed from 809 all session groups, to which it has been previously assigned. 811 SESSION_GROUP_STATUS_IND (0x00000010) 813 This flag indicates the status of the session group identified in 814 the associated Session-Group-Id AVP. The flag is set when the 815 identified session group has just been created or is still active. 816 If the flag is cleared, the identified session group is deleted 817 and the associated Session-Group-Id is released. If the Session- 818 Group-Info AVP does not include a Session-Group-Id AVP, this flag 819 is meaningless and MUST be ignored by the receiver. 821 7.3. Session-Group-Id AVP 823 The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and 824 identifies a group of Diameter sessions. 826 The Session-Group-Id MUST be globally unique. The default format of 827 the Session-Group-id MUST comply to the format recommended for a 828 Session-Id, as defined in the section 8.8 of the [RFC6733]. The 829 portion of the Session-Group-Id MUST identify the 830 Diameter node, which owns the session group. 832 7.4. Group-Response-Action AVP 834 The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 835 and contains a 32-bit address space representing values indicating 836 how the node SHOULD issue follow up exchanges in response to a 837 command which impacts multiple sessions. The following values are 838 defined by this document: 840 ALL_GROUPS (1) 841 Follow up message exchanges associated with a group command should 842 be performed with a single message exchange for all impacted 843 groups. 845 PER_GROUP (2) 846 Follow up message exchanges associated with a group command should 847 be performed with a separate message exchange for each impacted 848 group. 850 PER_SESSION (3) 851 Follow up message exchanges associated with a group command should 852 be performed with a separate message exchange for each impacted 853 session. 855 7.5. Session-Group-Capability-Vector AVP 857 The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type 858 Unsigned32 and contains a 32-bit flags field to indicate capabilities 859 in the context of session-group assignment and group operations. 861 The following capabilities are defined in this document: 863 BASE_SESSION_GROUP_CAPABILITY (0x00000001) 865 This flag indicates the capability to support session grouping and 866 session group operations according to this specification. 868 8. Result-Code AVP Values 870 This document does not define new Result-Code [RFC6733] values for 871 existing applications, which are extended to support group commands. 872 Specification documents of new applications, which will have 873 intrinsic support for group commands, may specify new Result-Codes. 875 9. IANA Considerations 877 This section contains the namespaces that have either been created in 878 this specification or had their values assigned to existing 879 namespaces managed by IANA. 881 9.1. AVP Codes 883 This specification requires IANA to register the following new AVPs 884 from the AVP Code namespace defined in [RFC6733]. 886 o Session-Group-Info 888 o Session-Group-Control-Vector 890 o Session-Group-Id 892 o Group-Response-Action 894 o Session-Group-Capability-Vector 896 The AVPs are defined in Section 7. 898 9.2. New Registries 900 This specification requires IANA to create two registries: 902 o Session-Group-Control-Vector AVP registry for control bits with 903 two initial assignments, which are described in Section 7.2. The 904 future registration assignment policy is proposed to be 905 Specification Required. 907 o Session-Group-Capability-Vector AVP with one initial assignment, 908 which is described in Section 7.5. The future registration 909 assignment policy is proposed to be Standards Action. 911 The AVP names can be used as registry names. 913 10. Security Considerations 915 The security considerations of the Diameter protocol itself are 916 discussed in [RFC6733]. Use of the AVPs defined in this document 917 MUST take into consideration the security issues and requirements of 918 the Diameter base protocol. In particular, the Session-Group-Info 919 AVP (including the Session-group-Control-Vector and the Session- 920 Group-Id AVPs) should be considered as a security-sensitive AVPs in 921 the same manner than the Session-Id AVP in the Diameter base protocol 922 [RFC6733]. 924 The management of session groups relies upon the existing trust 925 relationship between the Diameter client and the Diameter server 926 managing the groups of sessions. This document defines a mechanism 927 that allows a client or a server to act on multiple sessions at the 928 same time using only one command. if the Diameter client or server is 929 compromised, an attacker could launch DoS attacks by terminating a 930 large number of sessions with a limited set of commands using the 931 session group management concept. 933 According to the Diameter base protocol [RFC6733], transport 934 connections between Diameter peers are protected by TLS/TCP, DTLS/ 935 SCTP or alternative security mechanisms that are independent of 936 Diameter, such as IPsec. However, the lack of end-to-end security 937 features makes it difficult to establish trust in the session group 938 related information received from non-adjacent nodes. Any Diameter 939 agent in the message path can potentially modify the content of the 940 message and therefore the information sent by the Diameter client or 941 the server. There is ongoing work on the specification of end-to-end 942 security features for Diameter. Such features would enable the 943 establishment of trust relationship between non-adjacent nodes and 944 the security required for session group management would normally 945 rely on this end-to-end security. However, there is no assumption in 946 this document that such end-to-end security mechanism will be 947 available. It is only assumed that the solution defined on this 948 document relies on the security framework provided by the Diameter 949 based protocol. 951 In some cases, a Diameter Proxy agent can act on behalf of a client 952 or server. In such a case, the security requirements that normally 953 apply to a client (or a server) apply equally to the Proxy agent. 955 11. Acknowledgments 957 The authors of this document want to thank Ben Campbell and Eric 958 McMurry for their valuable comments to early versions of this draft. 959 Furthermore, authors thank Steve Donovan and Mark Bales for the 960 thorough review and comments on advanced versions of the WG document, 961 which helped a lot to improve this specification. 963 12. Normative References 965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 966 Requirement Levels", BCP 14, RFC 2119, 967 DOI 10.17487/RFC2119, March 1997, 968 . 970 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 971 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 972 May 2017, . 974 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 975 Ed., "Diameter Base Protocol", RFC 6733, 976 DOI 10.17487/RFC6733, October 2012, 977 . 979 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 980 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 981 . 983 Appendix A. Session Management -- Exemplary Session State Machine 985 A.1. Use of groups for the Authorization Session State Machine 987 Section 8.1 in [RFC6733] defines a set of finite state machines, 988 representing the life cycle of Diameter sessions, and which must be 989 observed by all Diameter implementations that make use of the 990 authentication and/or authorization portion of a Diameter 991 application. This section defines, as example, additional state 992 transitions related to the processing of the group commands which may 993 impact multiple sessions. 995 The group membership is session state and therefore only those state 996 machines from [RFC6733] in which the server is maintaining session 997 state are relevant in this document. As in [RFC6733], the term 998 Service-Specific below refers to a message defined in a Diameter 999 application (e.g., Mobile IPv4, NASREQ). 1001 The following state machine is observed by a client when state is 1002 maintained on the server. State transitions which are unmodified 1003 from [RFC6733] are not repeated here. 1005 The Diameter group command in the following tables is differentiated 1006 from a single-session related command by a preceding 'G' (Group). A 1007 Group Re-Auth Request, which applies to one or multiple session 1008 groups, has been exemplarily described in Section 6.1. Such Group 1009 RAR command is denoted as 'GRAR' in the following table. The same 1010 notation applies to other commands as per [RFC6733]. 1012 CLIENT, STATEFUL 1013 State Event Action New State 1014 --------------------------------------------------------------- 1015 Idle Client or Device Requests Send Pending 1016 access service 1017 specific 1018 auth req 1019 optionally 1020 including 1021 groups 1023 Open GASR received with Send GASA Discon 1024 Group-Response-Action with 1025 = ALL_GROUPS, Result-Code 1026 session is assigned to = SUCCESS, 1027 received group(s) and Send GSTR. 1028 client will comply with 1029 request to end the session 1031 Open GASR received with Send GASA Discon 1032 Group-Response-Action with 1033 = PER_GROUPS, Result-Code 1034 session is assigned to = SUCCESS, 1035 received group(s) and Send GSTR 1036 client will comply with per group 1037 request to end the session 1038 Open GASR received with Send GASA Discon 1039 Group-Response-Action with 1040 = PER_SESSION, Result-Code 1041 session is assigned to = SUCCESS, 1042 received group(s) and Send STR 1043 client will comply with per session 1044 request to end the session 1046 Open GASR received, Send GASA Open 1047 client will not comply with with 1048 request to end all session Result-Code 1049 in received group(s) != SUCCESS 1051 Discon GSTA Received Discon. Idle 1052 user/device 1054 Open GRAR received with Send GRAA, Pending 1055 Group-Response-Action Send 1056 = ALL_GROUPS, service 1057 session is assigned to specific 1058 received group(s) and group 1059 client will perform re-auth req 1060 subsequent re-auth 1062 Open GRAR received with Send GRAA, Pending 1063 Group-Response-Action Send 1064 = PER_GROUP, service 1065 session is assigned to specific 1066 received group(s) and group 1067 client will perform re-auth req 1068 subsequent re-auth per group 1070 Open GRAR received with Send GRAA, Pending 1071 Group-Response-Action Send 1072 = PER_SESSION, service 1073 session is assigned to specific 1074 received group(s) and re-auth req 1075 client will perform per session 1076 subsequent re-auth 1078 Open GRAR received and client will Send GRAA Idle 1079 not perform subsequent with 1080 re-auth Result-Code 1081 != SUCCESS, 1082 Discon. 1083 user/device 1085 Pending Successful service-specific Provide Open 1086 group re-authorization answer service 1087 received. 1089 Pending Failed service-specific Discon. Idle 1090 group re-authorization answer user/device 1091 received. 1093 The following state machine is observed by a server when it is 1094 maintaining state for the session. State transitions which are 1095 unmodified from [RFC6733] are not repeated here. 1097 SERVER, STATEFUL 1098 State Event Action New State 1099 --------------------------------------------------------------- 1101 Idle Service-specific authorization Send Open 1102 request received, and user successful 1103 is authorized service 1104 specific 1105 answer 1106 optionally 1107 including 1108 groups 1110 Open Server wants to terminate Send GASR Discon 1111 group(s) 1113 Discon GASA received Cleanup Idle 1115 Any GSTR received Send GSTA, Idle 1116 Cleanup 1118 Open Server wants to reauth Send GRAR Pending 1119 group(s) 1121 Pending GRAA received with Result-Code Update Open 1122 = SUCCESS session(s) 1124 Pending GRAA received with Result-Code Cleanup Idle 1125 != SUCCESS session(s) 1127 Open Service-specific group Send Open 1128 re-authoization request successful 1129 received and user is service 1130 authorized specific 1131 group 1132 re-auth 1133 answer 1135 Open Service-specific group Send Idle 1136 re-authorization request failed 1137 received and user is service 1138 not authorized specific 1139 group 1140 re-auth 1141 answer, 1142 cleanup 1144 Authors' Addresses 1146 Mark Jones 1148 Email: mark@azu.ca 1150 Marco Liebsch 1152 Email: marco.liebsch@neclab.eu 1154 Lionel Morand 1156 Email: lionel.morand@orange.com