idnits 2.17.00 (12 Aug 2021) /tmp/idnits40577/draft-ietf-dime-app-design-guide-17.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 29, 2013) is 3278 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) L. Morand, Ed. 3 Internet-Draft Orange Labs 4 Intended status: Informational V. Fajardo 5 Expires: November 30, 2013 H. Tschofenig 6 Nokia Siemens Networks 7 May 29, 2013 9 Diameter Applications Design Guidelines 10 draft-ietf-dime-app-design-guide-17 12 Abstract 14 The Diameter Base protocol provides facilities for protocol 15 extensibility enabling to define new Diameter applications or modify 16 existing applications. This document is a companion document to the 17 Diameter base protocol that further explains and clarifies the rules 18 to extend the Diameter base protocol. It is meant as a guidelines 19 document and therefore it does not add, remove or change existing 20 rules. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 30, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Reusing Existing Diameter Applications . . . . . . . . . . . 5 66 4.1. Adding a New Command . . . . . . . . . . . . . . . . . . 5 67 4.2. Deleting an Existing Command . . . . . . . . . . . . . . 6 68 4.3. Reusing Existing Commands . . . . . . . . . . . . . . . . 6 69 4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 7 70 4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . 8 71 4.4. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 9 72 4.4.1. Setting of the AVP Flags . . . . . . . . . . . . . . 9 73 4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 9 74 5. Defining New Diameter Applications . . . . . . . . . . . . . 9 75 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Defining New Commands . . . . . . . . . . . . . . . . . . 10 77 5.3. Use of Application-Id in a Message . . . . . . . . . . . 11 78 5.4. Application-Specific Session State Machines . . . . . . . 11 79 5.5. Session-Id AVP and Session Management . . . . . . . . . . 11 80 5.6. AVPs Defined as Boolean Flag . . . . . . . . . . . . . . 12 81 5.7. Application-Specific Message Routing . . . . . . . . . . 13 82 5.8. About Translation Agent . . . . . . . . . . . . . . . . . 13 83 5.9. End-to-End Application Capabilities Exchange . . . . . . 14 84 5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 15 85 5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 16 86 6. Defining Generic Diameter Extensions . . . . . . . . . . . . 17 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 93 11.2. Informative References . . . . . . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 97 The Diameter base protocol provides facilities to extend the Diameter 98 base protocol (see Section 1.3 of [RFC6733]) for supporting new 99 functionalities. In the context of this document, extending Diameter 100 means one of the following: 102 1. Addition of a new functionality to an existing Diameter 103 application without defining a new application. 105 2. Addition of a new functionality to an existing Diameter 106 application that requires the definition of a new application. 108 3. The definition of a new Diameter application to provide a set of 109 functionalities not supported by existing applications. 111 4. The definition of a new generic functionality that can be reused 112 across different applications. 114 All of these choices are design decisions that can be done by any 115 combination of reusing existing or defining new commands, AVPs or AVP 116 values. However, application designers do not have total freedom 117 when making their design. A number of rules have been defined in 118 [RFC6733] and place constraints on when an extension requires the 119 allocation of a new Diameter application identifier or a new command 120 code value. The objective of this document is the following: 122 o Clarify updated Diameter extensibility rules in the Diameter base 123 protocol. 125 o Clarify usage of certain Diameter functionalities that are not 126 explicitly described in the Diameter Base specification. 128 o Discuss design choices and provide guidelines when defining new 129 applications. 131 o Present trade-off of design choices. 133 2. Terminology 135 This document reuses the terminology used in [RFC6733]. 137 3. Overview 139 As designed, the Diameter base protocol [RFC6733] can be seen as a 140 two-layer protocol. The lower layer is mainly responsible for 141 managing connections between neighboring peers and for message 142 routing. The upper layer is where the Diameter applications reside. 144 This model is in line with a Diameter node having an application 145 layer and a peer-to-peer delivery layer. The Diameter base protocol 146 document defines the architecture and behavior of the message 147 delivery layer and then provides the framework for designing Diameter 148 applications on the application layer. This framework includes 149 definitions of application sessions and accounting support (see 150 Section 8 and 9 of [RFC6733]). Accordingly, a Diameter node is seen 151 in this document as a single instance of a Diameter message delivery 152 layer and one or more Diameter applications using it. 154 The Diameter base protocol is designed to be extensible and the 155 principles are described in the section 1.3 of [RFC6733]. Extending 156 Diameter can mean either the definition of a completely new Diameter 157 application or the reuse of commands, AVPs and AVP values in any 158 combination for the purpose of inheriting the features of an existing 159 Diameter application. The recommendation for re-using as much as 160 possible existing implementations is meaningful as most of the 161 requirements defined for a new application are likely already 162 fulfilled by existing applications. 164 However, when reusing existing applications, there is a greater 165 likelihood of ambiguity on how much of the existing application can 166 be enhanced without being distorted too much and therefore requiring 167 the definition of a new application. 169 The impacts of extending existing applications can be categorized as 170 follow: 172 Minor Extension: Enhancing the functional scope of an existing 173 application by the addition of optional features to support. Such 174 enhancement has no backward compatibility issue with the existing 175 application. A typical example would be the definition of a new 176 optional AVP to use in an existing command. Diameter 177 implementations supporting the existing application but not the 178 new AVP will simply ignore it, without major consequences on the 179 Diameter message handling. In general, this includes everything 180 that is not covered by the next category. The standardization 181 effort will be fairly small. 183 Major Extension: Enhancing the functional scope of an existing 184 application in such a way that this implies backward compatible 185 change to the existing application and then requires the 186 definition of a new Diameter application. Typical examples would 187 be the creation of a new command for providing functionality not 188 supported by existing applications or the definition of a new AVP 189 with M-bit set to carry in an existing command. For such 190 extension, a significant specification effort is required and a 191 careful approach is recommended. 193 The rules outlined in the section 1.3 of [RFC6733] indicate when an 194 extension requires a new command code to be registered and when new 195 Diameter applications have to be defined. The subsequent sections 196 further explain and clarify the rules to extend the Diameter base 197 protocol. It is meant as a guidelines document and therefore it does 198 not add, remove or change existing rules. 200 4. Reusing Existing Diameter Applications 202 When selecting the Diameter base protocol to support new 203 functionalities, protocol designers are advised to reuse as much as 204 possible existing Diameter applications in order to simplify 205 standardization, implementation and avoid potential interoperability 206 issues. However, existing application needs to be adapted to support 207 new requirements and these modifications can be at the command level 208 and/or at the AVP level. The following sections describe the 209 possible modifications that can be performed on existing applications 210 and their related impacts. 212 4.1. Adding a New Command 214 Adding a new command is considered as a major extension and requires 215 a new Diameter application to be defined. Adding a new command to an 216 application means either defining a completely new command or 217 importing the command's CCF syntax specification from another 218 application whereby the new application inherits some or all of the 219 functionality of the application where the command came from. In the 220 former case, the decision to create a new application is 221 straightforward since this is typically a result of adding a new 222 functionality that does not exist yet. For the latter, the decision 223 to create a new application will depend on whether importing the 224 command in a new application is more suitable than simply using the 225 existing application as it is in conjunction with any other 226 application. Therefore, a case by case study of each application 227 requirement should be applied. 229 An illustrative example is the command pair defined in Diameter EAP 230 application [RFC4072] that can be re-used conjointly with any other 231 application (e.g. the Diameter NASREQ application [RFC4005]) as soon 232 as standard EAP-based authentication procedures need to be supported 233 by the implementation. It may therefore not be required to import 234 the command pair in the new defined application. 236 However, in general, it is difficult to come to a hard guideline, and 237 so a case-by-case study of each application requirement should be 238 applied. Before adding or importing a command, application designers 239 should consider the following: 241 o Can the new functionality be fulfilled by creating a new command 242 independent from any existing command? In this case, the 243 resulting new application and the existing application can work 244 independent of, but cooperating with each other. 246 o Can the existing command be reused without major extensions and 247 therefore without the need for the definition of a new 248 application, e.g. new functionality introduced by the creation of 249 new optional AVPs. 251 o Care should be taken to avoid a liberal method of importing an 252 existing command's CCF syntax specification. This would result in 253 a monolithic and hard to manage application supporting too many 254 different functionalities and can cause interoperability issues 255 between the different applications. 257 4.2. Deleting an Existing Command 259 Although this process is not typical, removing a command from an 260 application requires a new Diameter application to be defined. This 261 is due to the fact that the reception of the deleted command would 262 systematically result in a protocol error 263 (DIAMETER_COMMAND_UNSUPPORTED). 265 It is unusual to delete an existing command from an application for 266 the sake of deleting it or the functionality it represents. This 267 normally indicates of a flawed design. An exception might be if the 268 intent of the deletion is to create a newer version of the same 269 application that is somehow simpler than the previous version. 271 4.3. Reusing Existing Commands 273 This section discusses rules in adding and/or deleting AVPs from an 274 existing command of an existing application. The cases described in 275 this section may not necessarily result in the creation of new 276 applications. 278 It is worth to note that the strong recommendation to re-use existing 279 commands in the [RFC3588] was to prevent rapid scarcity of code 280 values available for vendor-specific commands. [RFC6733] relaxes the 281 policy with respect to the allocation of command codes for vendor- 282 specific uses and enlarges the range of available code values for 283 vendor-specific applications. Although reuse of existing commands is 284 still recommended, protocol designers can consider defining a new 285 command when it provides a solution more suitable than the twisting 286 of an existing command's use and applications. 288 4.3.1. Adding AVPs to a Command 290 Based on the rules in [RFC6733], AVPs that are added to an existing 291 command can be categorized into: 293 o Mandatory (to understand) AVPs. As defined in [RFC6733], these 294 are AVPs with the M-bit flag set, which means that a Diameter node 295 receiving them is required to understand not only their values but 296 their semantics. Failure to do so will cause an message handling 297 error. This is regardless of whether these AVPs are required or 298 optional as specified by the command's CCF syntax specification. 300 o Optional (to understand) AVPs. As defined in [RFC6733], these are 301 AVPs with the M-bit flag cleared, which mean that a Diameter node 302 receiving these AVPs can simply ignore them if not supported in 303 the process of the received command. 305 The rules are strict in the case where the AVPs to be added are 306 mandatory to understand i.e. with the M-bit set. A mandatory AVP 307 cannot be added to an existing command without defining a new 308 Diameter application, as stated in [RFC6733]. This falls into the 309 "Major Extensions" category. Despite the clarity of the rule, 310 ambiguity still arises when evaluating whether a new AVP being added 311 should be mandatory to begin with. Application designers should 312 consider the following questions when deciding to set the M-bit for a 313 new AVP: 315 o Would it be required for the receiving side to be able to process 316 and understand the AVP and its content? 318 o Would the new AVPs change the state machine of the application? 320 o Would the presence of the new AVP lead to a different number of 321 round-trips, effectively changing the state machine of the 322 application? 324 o Would the new AVP be used to differentiate between old and new 325 versions of the same application whereby the two versions are not 326 backward compatible? 328 o Would the new AVP have duality in meaning i.e. be used to carry 329 application-related information as well as be used to indicate 330 that the message is for a new application? 332 When one of the above questions can be answered in the affirmative 333 then the M-bit has to be set for the new AVP. This list of questions 334 is non-exhaustive and other criteria can be taken into account in the 335 decision process. 337 If application designers are instead contemplating the use of 338 optional AVPs i.e. with the M-bit cleared, then the following are 339 some of the pitfalls that should be avoided: 341 o Use of optional AVPs with intersecting meaning. One AVP has 342 partially the same usage and meaning as another AVP. The presence 343 of both can lead to confusion. 345 o An optional AVPs with dual purpose, i.e. to carry application 346 data as well as to indicate support for one or more features. 347 This has a tendency to introduce interpretation issues. 349 o Adding one or more optional AVPs and indicating (usually within 350 descriptive text for the command) that at least one of them has to 351 be present in the command. This essentially circumventing the 352 ABNF and is equivalent to adding a mandatory AVP to the command. 354 These practices generally result in interoperability issues and 355 should be avoided as much as possible. 357 4.3.2. Deleting AVPs from a Command 359 The impacts of deleting an AVP from a command depend on its command 360 code format specification and M-bit setting: 362 o Deleting an AVP that is indicated as { AVP } in the command's CCF 363 syntax specification, whatever the setting of the M-bit set. This 364 means the definition of a new command. In this case, a new 365 command code and subsequently a new Diameter application have to 366 be specified. 368 o Deleting an AVP with M-bit set that is indicated as [ AVP ] in the 369 command's CCF syntax specification. No new command code has to be 370 specified but the definition of a new Diameter application is 371 required. 373 o Deleting an AVP with the M-bit cleared that is indicated as [ AVP 374 ] in the command's CCF syntax specification. In this case, the 375 AVP can be deleted without consequences. 377 If possible application designers should attempt the reuse the 378 command's CCF syntax specification without modification and simply 379 ignore (but not delete) any optional AVP that will not be used. This 380 is to maintain compatibility with existing applications that will not 381 know about the new functionality as well as maintain the integrity of 382 existing dictionaries. 384 4.4. Reusing Existing AVPs 386 This section discusses rules in reusing existing AVP when reusing an 387 existing command or defining a new command in a new application. 389 4.4.1. Setting of the AVP Flags 391 When reusing AVPs in a new application, the AVP flag setting, such as 392 the mandatory flag ('M'-bit), has to be re-evaluated for a new 393 Diameter application and, if necessary, even for every command within 394 the application. In general, for AVPs defined outside of the 395 Diameter base protocol, its mandatory characteristics are tied to its 396 role within an application and command. 398 All other AVP flags shall remain unchanged. 400 4.4.2. Reuse of AVP of Type Enumerated 402 When modifying the set of values supported by an AVP of type 403 Enumerated, this means defining a new AVP. Modifying the set of 404 Enumerated values includes adding a value or deprecating the use of a 405 value defined initially for the AVP. Defining a new AVP will avoid 406 interoperability issues. 408 5. Defining New Diameter Applications 410 5.1. Introduction 412 The general recommendation for Diameter extensibility is to reuse 413 commands, AVPs and AVP values as much as possible. However, some of 414 the extensibility rules described in the previous sections also apply 415 to scenarios where a designer is trying to define a completely new 416 Diameter application. 418 This section discusses the case where new applications have 419 requirements that cannot be filled by existing applications and would 420 require definition of completely new commands, AVPs and/or AVP 421 values. Typically, there is little ambiguity about the decision to 422 create these types of applications. Some examples are the interfaces 423 defined for the IP Multimedia Subsystem of 3GPP, i.e. Cx/Dx 424 ([TS29.228] and [TS29.229]), Sh ([TS29.328] and [TS29.329]) etc. 426 Application designers should also follow the theme of Diameter 427 extensibility, which in this case means to import existing AVPs and 428 AVP values for any newly defined commands. In certain cases where 429 accounting will be used, the models described in Section 5.10 should 430 also be considered. Though some decisions may be clear, designers 431 should also consider certain aspects of defining a new application. 432 Some of these aspects are described in following sections. 434 5.2. Defining New Commands 436 As a general recommendation, reusing as much as possible of existing 437 material is encouraged when defining new commands. Protocol 438 designers can thus usefully benefit from the experience gained with 439 the implementation of existing commands. This includes good 440 practices to reuse but also known mistakes not to repeat. Therefore 441 it is advisable to avoid the definition of a command from scratch and 442 rather take as an example an existing command that would be 443 functionally close to command under definition. 445 Moreover, the new command's CCF should be carefully defined when 446 considering applicability and extensibility of the application. If 447 most of the AVPs contained in the command are indicated as fixed or 448 required, it might be difficult to reuse the same command and 449 therefore the same application if the context has slightly changed 450 and some AVPs become obsolete. Defining a command with most of the 451 AVPs indicated as optional must not be seen as a sub-optimal design 452 introducing too much flexibility in the protocol. The protocol 453 designers are only advised to clearly state the condition of presence 454 of these AVPs and properly define the corresponding behaviour of the 455 Diameter nodes when these AVPs are absent from the command. 457 In the same way, the CCF should be defined in a way that it will be 458 possible to add any arbitrary optional AVPs with the M-bit cleared 459 (including vendor-specific AVPs) without modifying the application. 460 For this purpose, it is strongly recommended to add "* [AVP]" in the 461 command's CCF that will allow the addition of any arbitrary AVP as 462 described in [RFC6733]. 464 5.3. Use of Application-Id in a Message 466 When designing new applications, designers should specify that the 467 application ID carried in all session-level messages must be the 468 application ID of the application using those messages. This 469 includes the session-level messages defined in Diameter base 470 protocol, i.e., RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the 471 coupled accounting model, see Section 5.10. Existing specifications 472 may not adhere to this rule for historical or other reasons. 473 However, this scheme should be followed to avoid possible routing 474 problems for these messages. 476 In general, when a new application has been allocated with a new 477 application id and it also reuses existing commands with or without 478 modifications (Sec 4.1), it must use the newly allocated application 479 id in the header and in all relevant application id AVPs (Auth- 480 Application-Id or Acct-Application-Id) present in the commands 481 message body. 483 Additionally, application designs using Vendor-Specific-Application- 484 Id AVP should not use the Vendor-Id AVP to further dissect or 485 differentiate the vendor-specification application id. Diameter 486 routing is not based on the Vendor-Id. As such, the Vendor-ID should 487 not be used as an additional input for routing or delivery of 488 messages. In general, the Vendor-Id AVP is an informational AVP only 489 and kept for backward compatibility reasons. 491 5.4. Application-Specific Session State Machines 493 Section 8 of [RFC6733] provides session state machines for 494 authentication, authorization and accounting (AAA) services and these 495 session state machines are not intended to cover behavior outside of 496 AAA. If a new application cannot clearly be categorized into any of 497 these AAA services, it is recommended that the application define its 498 own session state machine. Support for server-initiated request is a 499 clear example where an application-specific session state machine 500 would be needed, for example, the Rw interface for ITU-T push model 501 (cf.[Q.3303.3]). 503 5.5. Session-Id AVP and Session Management 505 Diameter applications are usually designed with the aim of managing 506 user sessions, e.g. network access session (NASREQ application 507 [RFC4005]) or specific service access session (Diameter SIP 508 application [RFC4740]). In the Diameter base protocol, the session 509 management is based on the Session-Id AVP that it used to identify a 510 given session and all the Diameter messages including the same 511 Session-Id will be bound to the same session. Diameter-based session 512 management also implies that both Diameter client and server (and 513 potentially proxy agents in the diameter path) are maintaining 514 session state information associated with the Session-Id contained in 515 the Diameter messages. 517 However, some applications may not need to rely on the Session-Id to 518 identify and manage user sessions because other information can be 519 used instead to correlate Diameter messages. Indeed, the User-Name 520 AVP or any other specific AVP can be present in every Diameter 521 message and used therefore for message correlation. There might even 522 be applications for which the notion of Diameter session management 523 would not be required at all. For such applications, the Auth- 524 Session-State AVP is usually set to NO_STATE_MAINTAINED in all the 525 Diameter messages and these applications are therefore designed as a 526 set of stand-alone transactions. Even if an explicit access session 527 termination is required, application-specific commands are defined 528 and used instead of the Session-Termination-Request/Answer (STR/STA) 529 or Abort-Session-Request/Answer (ASR/ASA) defined in the Diameter 530 base protocol. In such a case, the Session-Id is not significant. 532 Based on these considerations, protocol designers should carefully 533 appraise whether the application currently defined relies on the 534 concept of session management and whether the Session-Id defined in 535 the Diameter base protocol would be used for correlation of messages 536 related to the same session. If not, the protocol designers could 537 decide to define application commands without the Session-Id AVP. If 538 any session management concept is supported by the application, the 539 application documentation must clearly specify how the session is 540 handled between client and server (as possibly Diameter agents in the 541 path). 543 5.6. AVPs Defined as Boolean Flag 545 The type Enumerated was initially defined to provide a list of valid 546 values for an AVP with their respective interpretation described in 547 the specification. For instance, AVPs of type Enumerated can be used 548 to provide further information on the reason for the termination of a 549 session or a specific action to perform upon the reception of the 550 request. 552 However, AVPs of type Enumerated are too often used as a simple 553 Boolean flag, indicating for instance a specific permission or 554 capability, and therefore only two values are defined e.g. TRUE/ 555 FALSE, AUTORIZED/UNAUTHORIZED or SUPPORTED/UNSUPPORTED. This is a 556 sub-optimal design since it limits the extensibility of the 557 application: any new capability/permission would have to be supported 558 by a new AVP or new Enumerated value of the already defined AVP, 559 causing backwards compatibility issues with existing implementations. 561 Instead of using an Enumerated AVP for a Boolean flag, protocol 562 designers are encouraged to use Unsigned32 or Unsigned64 AVP type as 563 bit mask whose bit settings are described in the relevant Diameter 564 application specification. Such AVPs can be reused and extended 565 without major impact on the Diameter application. The bit mask 566 should leave room for future additions. Examples of bit mask AVP are 567 the Session-Binding AVP defined in [RFC6733] and the MIP6-Feature- 568 Vector AVP defined in [RFC5447] 570 5.7. Application-Specific Message Routing 572 Diameter request message routing usually relies on the Destination- 573 Realm AVP and the Application Id present in the request message 574 header. However, some applications may need to rely on the User-Name 575 AVP or any other application-specific AVP present in the request to 576 determine the final destination of a request e.g. find the target 577 AAA server hosting the authorization information for a given user 578 when multiple AAA servers are addressable in the realm. 580 In such a context, basic routing mechanisms described in [RFC6733] 581 are not fully suitable, and additional application-level routing 582 mechanisms have to be described in the application documentation to 583 provide such specific AVP-based routing. Such functionality will be 584 basically hosted by an application-specific Proxy agent that will be 585 responsible for routing decisions based on the received specific 586 AVPs. 588 Example of such application-specific routing functions can be found 589 in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP IP 590 Multimedia Subsystem, in which the proxy agent (Subscriber Location 591 Function aka SLF) uses specific application-level identities found in 592 the request to determine the final destination of the message. 594 Whatever the criteria used to establish the routing path of the 595 request, the routing of the answer should follow the reverse path of 596 the request, as described in [RFC6733], with the answer being sent to 597 the source of the received request, using transaction states and hop- 598 by-hop identifier matching. In particular, this ensures that the 599 Diameter Relay or Proxy agents in the request routing path will be 600 able to release the transaction state upon receipt of the 601 corresponding answer, avoiding unnecessary failover. Application 602 designers are strongly dissuaded from modifying the answer-routing 603 principles described in [RFC6733] when defining a new application. 605 5.8. About Translation Agent 606 As defined in [RFC6733], a translation agent is a device that 607 provides interworking between Diameter and another protocol (e.g. 608 RADIUS, TACACS+). 610 In the case of RADIUS, it was initially thought that defining the 611 translation function would be straightforward by adopting few basic 612 principles e.g. use of a shared range of code values for RADIUS 613 attributes and Diameter AVPs. Guidelines for implementing a RADIUS- 614 Diameter translation agent were put into RFC 4005 ([RFC4005]). 616 However, it was acknowledged that such translation mechanism was not 617 so obvious and deeper protocol analysis was required to ensure 618 efficient interworking between RADIUS and Diameter. Moreover, the 619 interworking requirements depend on the functionalities provided by 620 the Diameter application under specification, and a case-by-case 621 analysis will be required. 623 Therefore, protocol designers cannot assume the availability of a 624 "standard" Diameter-to-RADIUS gateways agent when planning to 625 interoperate with the RADIUS infrastructure. They should specify the 626 required translation mechanism along with the Diameter application. 627 This recommendation applies for any kind of translation (e.g. 628 Diameter/MAP). 630 5.9. End-to-End Application Capabilities Exchange 632 New Diameter applications can rely on optional AVPs to exchange 633 application-specific capabilities and features. These AVPs can be 634 exchanged on an end-to-end basis at the application layer. Examples 635 of this can be found in [RFC5447] and [RFC5777]. 637 The end-to-end capabilities AVPs formalize the addition of new 638 optional functionality to existing applications by announcing support 639 for it. Applications that do not understand these AVPs can discard 640 them upon receipt. Recevers of these AVPs can discover the addional 641 functionalities supported the end-point orignating the request and 642 behave accordingly when processing the request. Senders of these 643 AVPs can safely assume the receiving end-point does not support any 644 functionality carried by the AVP if it is not present in 645 corresponding response. This is useful in cases where deployment 646 choices are offered, and the generic design can be made available for 647 a number of applications. 649 When used in a new application, protocol designers should clearly 650 specify this end-to-end capabilities exchange and the corresponding 651 behaviour of the Diameter nodes supporting the application. 653 It is also important to note that this end-to-end capabilities 654 exchange relying on the use of optional AVPs is not meant as a 655 generic mechanism to support extensibility of Diameter applications 656 with arbitrary functionalities. When the added features drastically 657 change the Diameter application or when Diameter agents have to be 658 upgraded to support the new features, a new application should be 659 defined. 661 5.10. Diameter Accounting Support 663 Accounting can be treated as an auxiliary application that is used in 664 support of other applications. In most cases, accounting support is 665 required when defining new applications. This document provides 666 two(2) possible models for using accounting: 668 Split Accounting Model 669 In this model, the accounting messages will use the Diameter base 670 accounting application ID (value of 3). The design implication 671 for this is that the accounting is treated as an independent 672 application, especially during Diameter routing. This means that 673 accounting commands emanating from an application may be routed 674 separately from the rest of the other application messages. This 675 may also imply that the messages end up in a central accounting 676 server. A split accounting model is a good design choice when: 678 * The application itself will not define its own unique 679 accounting commands. 681 * The overall system architecture permits the use of centralized 682 accounting for one or more Diameter applications. 683 Centralizing accounting may have advantages but there are also 684 drawbacks. The model assumes that the accounting server can 685 differentiate received accounting messages. Since the received 686 accounting messages can be for any application and/or service, the 687 accounting server has to have a method to match accounting 688 messages with applications and/or services being accounted for. 689 This may mean defining new AVPs, checking the presence, absence or 690 contents of existing AVPs, or checking the contents of the 691 accounting record itself. But in general, there is no clean and 692 generic scheme for sorting these messages. Therefore, the use of 693 this model is recommended only when all received accounting 694 messages can be clearly identified and sorted. For most cases, 695 the use of Coupled Accounting Model is recommended. 697 Coupled Accounting Model 698 In this model, the accounting messages will use the application ID 699 of the application using the accounting service. The design 700 implication for this is that the accounting messages are tightly 701 coupled with the application itself; meaning that accounting 702 messages will be routed like any other application messages. It 703 would then be the responsibility of the application server 704 (application entity receiving the ACR message) to send the 705 accounting records carried by the accounting messages to the 706 proper accounting server. The application server is also 707 responsible for formulating a proper response (ACA). A coupled 708 accounting model is a good design choice when: 710 * The system architecture or deployment will not provide an 711 accounting server that supports Diameter. 713 * The system architecture or deployment requires that the 714 accounting service for the specific application should be 715 handled by the application itself. 717 * The application server is provisioned to use a different 718 protocol to access the accounting server; e.g., via LDAP, SOAP 719 etc. This includes attempting to support older accounting 720 systems that are not Diameter aware. 722 In all cases above, there will generally be no direct Diameter 723 access to the accounting server. 725 These models provide a basis for using accounting messages. 726 Application designers may obviously deviate from these models 727 provided that the factors being addressed here have also been taken 728 into account. Though it is not recommended, examples of other 729 methods might be defining a new set of commands to carry application- 730 specific accounting records. 732 5.11. Diameter Security Mechanisms 734 As specified in [RFC6733], the Diameter message exchange should be 735 secured by using TLS/TCP or DTLS/SCTP. However, IPsec can also be 736 deployed to secure connections between Diameter peers. When IPsec is 737 used instead of TLS or DTLS, the following recommendations apply. 739 IPsec ESP 5.3 [RFC4301] in transport mode with non-null encryption 740 and authentication algorithms is used to provide per-packet 741 authentication, integrity protection and confidentiality, and support 742 the replay protection mechanisms of IPsec. The version 2 of IKE 743 (IKEv2) [RFC5996] is recommended for performing mutual authentication 744 and establishing and maintaining security associations (SAs). 746 IKEv1 [RFC2409] was used in [RFC3588] and for easier migration from 747 IKEv1 based implementations both RSA Digital Signatures and pre- 748 shared keys should be used in IKEv2. However, if IKEv1 is used, 749 implementers should follow the guidelines given in section 13.1 in 750 RFC3588 [RFC3588]. 752 6. Defining Generic Diameter Extensions 754 Generic Diameter extensions are AVPs, commands or applications that 755 are designed to support other Diameter applications. They are 756 auxiliary applications meant to improve or enhance the Diameter 757 protocol itself or Diameter applications/functionality. Some 758 examples include the extensions to support auditing and redundancy 759 (see [I-D.calhoun-diameter-res-mgmt]), improvements in duplicate 760 detection scheme (see [I-D.asveren-dime-dupcons]), and piggybacking 761 of QoS attributes (see [RFC5777]). 763 Since generic extensions can cover many aspects of Diameter and 764 Diameter applications, it is not possible to enumerate all the 765 probable scenarios in this document. However, some of the most 766 common considerations are as follows: 768 o Backward compatibility: Dealing with existing applications that do 769 not understand the new extension. Designers also have to make 770 sure that new extensions do not break expected message delivery 771 layer behavior. 773 o Forward compatibility: Making sure that the design will not 774 introduce undue restrictions for future applications. Future 775 applications attempting to support this feature should not have to 776 go through great lengths to implement any new extensions. 778 o Trade-off in signaling: Designers may have to choose between the 779 use of optional AVPs piggybacked onto existing commands versus 780 defining new commands and applications. Optional AVPs are simpler 781 to implement and may not need changes to existing applications. 782 However, this ties the sending of extension data to the 783 application's transmission of a message. This has consequences if 784 the application and the extensions have different timing 785 requirements. The use of commands and applications solves this 786 issue, but the trade-off is the additional complexity of defining 787 and deploying a new application. It is left up to the designer to 788 find a good balance among these trade-offs based on the 789 requirements of the extension. 791 In practice, generic extensions often use optional AVPs because they 792 are simple and non-intrusive to the application that would carry 793 them. Peers that do not support the generic extensions need not 794 understand nor recognize these optional AVPs. However, it is 795 recommended that the authors of the extension specify the context or 796 usage of the optional AVPs. As an example, in the case that the AVP 797 can be used only by a specific set of applications then the 798 specification must enumerate these applications and the scenarios 799 when the optional AVPs will be used. In the case where the optional 800 AVPs can be carried by any application, it is should be sufficient to 801 specify such a use case and perhaps provide specific examples of 802 applications using them. 804 In most cases, these optional AVPs piggybacked by applications would 805 be defined as a Grouped AVP and it would encapsulate all the 806 functionality of the generic extension. In practice, it is not 807 uncommon that the Grouped AVP will encapsulate an existing AVP that 808 has previously been defined as mandatory ('M'-bit set) e.g., 3GPP IMS 809 Cx/Dx interfaces ([TS29.228] and [TS29.229]). 811 7. IANA Considerations 813 This document does not require actions by IANA. 815 8. Security Considerations 817 This document provides guidelines and considerations for extending 818 Diameter and Diameter applications. It does not define nor address 819 security-related protocols or schemes. 821 9. Contributors 823 The content of this document was influenced by a design team created 824 to revisit the Diameter extensibility rules. The team consisting of 825 the members listed below was formed in February 2008 and finished its 826 work in June 2008. 828 o Avi Lior 830 o Glen Zorn 832 o Jari Arkko 834 o Lionel Morand 836 o Mark Jones 838 o Victor Fajardo 840 o Tolga Asveren 841 o Jouni Korhonen 843 o Glenn McGregor 845 o Hannes Tschofenig 847 o Dave Frascone 849 We would like to thank Tolga Asveren, Glenn McGregor, and John 850 Loughney for their contributions as co-authors to earlier versions of 851 this document. 853 10. Acknowledgments 855 We greatly appreciate the insight provided by Diameter implementers 856 who have highlighted the issues and concerns being addressed by this 857 document. The authors would also like to thank A. Jean Mahoney and 858 Ben Campbell for their invaluable detailed review and comments on 859 this document. 861 11. References 863 11.1. Normative References 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, March 1997. 868 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 869 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 871 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 872 "Diameter Base Protocol", RFC 6733, October 2012. 874 11.2. Informative References 876 [I-D.asveren-dime-dupcons] 877 Asveren, T., "Diameter Duplicate Detection Cons.", draft- 878 asveren-dime-dupcons-00 (work in progress), August 2006. 880 [I-D.calhoun-diameter-res-mgmt] 881 Calhoun, P., "Diameter Resource Management Extensions", 882 draft-calhoun-diameter-res-mgmt-08.txt (work in progress), 883 March 2001. 885 [Q.3303.3] 886 3rd Generation Partnership Project, "ITU-T Recommendation 887 Q.3303.3, "Resource control protocol no. 3 (rcp3): 888 Protocol at the Rw interface between the Policy Decision 889 Physical Entity (PD-PE) and the Policy Enforcement 890 Physical Entity (PE-PE): Diameter"", 2008. 892 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 893 (IKE)", RFC 2409, November 1998. 895 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 896 "Diameter Network Access Server Application", RFC 4005, 897 August 2005. 899 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 900 Authentication Protocol (EAP) Application", RFC 4072, 901 August 2005. 903 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 904 Internet Protocol", RFC 4301, December 2005. 906 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 907 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 908 Initiation Protocol (SIP) Application", RFC 4740, November 909 2006. 911 [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 912 and K. Chowdhury, "Diameter Mobile IPv6: Support for 913 Network Access Server to Diameter Server Interaction", RFC 914 5447, February 2009. 916 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 917 and A. Lior, "Traffic Classification and Quality of 918 Service (QoS) Attributes for Diameter", RFC 5777, February 919 2010. 921 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 922 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 923 5996, September 2010. 925 [TS29.228] 926 3rd Generation Partnership Project, "3GPP TS 29.228; 927 Technical Specification Group Core Network and Terminals; 928 IP Multimedia (IM) Subsystem Cx and Dx Interfaces; 929 Signalling flows and message contents", , 930 . 932 [TS29.229] 933 3rd Generation Partnership Project, "3GPP TS 29.229; 934 Technical Specification Group Core Network and Terminals; 935 Cx and Dx interfaces based on the Diameter protocol; 936 Protocol details", , 937 . 939 [TS29.328] 940 3rd Generation Partnership Project, "3GPP TS 29.328; 941 Technical Specification Group Core Network and Terminals; 942 IP Multimedia (IM) Subsystem Sh interface; signalling 943 flows and message content", , 944 . 946 [TS29.329] 947 3rd Generation Partnership Project, "3GPP TS 29.329; 948 Technical Specification Group Core Network and Terminals; 949 Sh Interface based on the Diameter protocol; Protocol 950 details", , 951 . 953 Authors' Addresses 955 Lionel Morand (editor) 956 Orange Labs 958 Email: lionel.morand@orange.com 960 Victor Fajardo 962 Email: vf0213@gmail.com 964 Hannes Tschofenig 965 Nokia Siemens Networks 966 Linnoitustie 6 967 Espoo 02600 968 Finland 970 Phone: +358 (50) 4871445 971 Email: Hannes.Tschofenig@gmx.net 972 URI: http://www.tschofenig.priv.at