From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7423.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc7423.txt (limited to 'doc/rfc/rfc7423.txt') diff --git a/doc/rfc/rfc7423.txt b/doc/rfc/rfc7423.txt new file mode 100644 index 0000000..d020529 --- /dev/null +++ b/doc/rfc/rfc7423.txt @@ -0,0 +1,1627 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Morand, Ed. +Request for Comments: 7423 Orange Labs +BCP: 193 V. Fajardo +Category: Best Current Practice Fluke Networks +ISSN: 2070-1721 H. Tschofenig + November 2014 + + + Diameter Applications Design Guidelines + +Abstract + + The Diameter base protocol provides facilities for protocol + extensibility enabling the definition of new Diameter applications or + modification of existing applications. This document is a companion + document to the Diameter base protocol that further explains and + clarifies the rules to extend Diameter. Furthermore, this document + provides guidelines to Diameter application designers reusing/ + defining Diameter applications or creating generic Diameter + extensions. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7423. + + + + + + + + + + + + + + + + + +Morand, et al. Best Current Practice [Page 1] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Morand, et al. Best Current Practice [Page 2] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Reusing Existing Diameter Applications . . . . . . . . . . . 6 + 4.1. Adding a New Command . . . . . . . . . . . . . . . . . . 7 + 4.2. Deleting an Existing Command . . . . . . . . . . . . . . 8 + 4.3. Reusing Existing Commands . . . . . . . . . . . . . . . . 8 + 4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 8 + 4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . 10 + 4.3.3. Changing the Flag Settings of AVP in Existing + Commands . . . . . . . . . . . . . . . . . . . . . . 11 + 4.4. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 11 + 4.4.1. Setting of the AVP Flags . . . . . . . . . . . . . . 11 + 4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 12 + 5. Defining New Diameter Applications . . . . . . . . . . . . . 12 + 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 12 + 5.2. Defining New Commands . . . . . . . . . . . . . . . . . . 12 + 5.3. Use of Application Id in a Message . . . . . . . . . . . 13 + 5.4. Application-Specific Session State Machines . . . . . . . 14 + 5.5. Session-Id AVP and Session Management . . . . . . . . . . 14 + 5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 15 + 5.7. Application-Specific Message Routing . . . . . . . . . . 17 + 5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 18 + 5.9. End-to-End Application Capabilities Exchange . . . . . . 18 + 5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 19 + 5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 21 + 6. Defining Generic Diameter Extensions . . . . . . . . . . . . 21 + 7. Guidelines for Registrations of Diameter Values . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 + 9.2. Informative References . . . . . . . . . . . . . . . . . 25 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + + + + + + + + + + + + + + +Morand, et al. Best Current Practice [Page 3] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + +1. Introduction + + The Diameter base protocol [RFC6733] is intended to provide an + Authentication, Authorization, and Accounting (AAA) framework for + applications such as network access or IP mobility in both local and + roaming situations. This protocol provides the ability for Diameter + peers to exchange messages carrying data in the form of Attribute- + Value Pairs (AVPs). + + The Diameter base protocol provides facilities to extend Diameter + (see Section 1.3 of [RFC6733]) to support new functionality. In the + context of this document, extending Diameter means one of the + following: + + 1. The addition of new functionality to an existing Diameter + application without defining a new application. + + 2. The addition of new functionality to an existing Diameter + application that requires the definition of a new application. + + 3. The definition of an entirely new Diameter application to offer + functionality not supported by existing applications. + + 4. The definition of a new generic functionality that can be reused + across different applications. + + All of these extensions are design decisions that can be carried out + by any combination of reusing existing or defining new commands, + AVPs, or AVP values. However, application designers do not have + complete freedom when making their design. A number of rules have + been defined in [RFC6733] that place constraints on when an extension + requires the allocation of a new Diameter application identifier or a + new command code value. The objective of this document is the + following: + + o Clarify the Diameter extensibility rules as defined in the + Diameter base protocol. + + o Discuss design choices and provide guidelines when defining new + applications. + + o Present trade-off choices. + + + + + + + + + +Morand, et al. Best Current Practice [Page 4] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + +2. Terminology + + This document reuses the terminology defined in [RFC6733]. + Additionally, the following terms and acronyms are used in this + application: + + Application: Extension of the Diameter base protocol [RFC6733] via + the addition of new commands or AVPs. Each application is + uniquely identified by an IANA-allocated application identifier + value. + + Command: Diameter request or answer carrying AVPs between Diameter + endpoints. Each command is uniquely identified by an IANA- + allocated Command Code value and is described by a Command Code + Format (CCF) for an application. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Overview + + As designed, the Diameter base protocol [RFC6733] can be seen as a + two-layer protocol. The lower layer is mainly responsible for + managing connections between neighboring peers and for message + routing. The upper layer is where the Diameter applications reside. + This model is in line with a Diameter node having an application + layer and a peer-to-peer delivery layer. The Diameter base protocol + document defines the architecture and behavior of the message + delivery layer and then provides the framework for designing Diameter + applications on the application layer. This framework includes + definitions of application sessions and accounting support (see + Sections 8 and 9 of [RFC6733]). Accordingly, a Diameter node is seen + in this document as a single instance of a Diameter message delivery + layer and one or more Diameter applications using it. + + The Diameter base protocol is designed to be extensible and the + principles are described in Section 1.3 of [RFC6733]. In summary, + Diameter can be extended by the following: + + 1. Defining new AVP values + + 2. Creating new AVPs + + 3. Creating new commands + + 4. Creating new applications + + + + +Morand, et al. Best Current Practice [Page 5] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + As a main guiding principle, application designers SHOULD comply with + the following recommendation: "try to reuse as much as possible!". + It will reduce the time to finalize specification writing, and it + will lead to a smaller implementation effort as well as reduce the + need for testing. In general, it is clever to avoid duplicate effort + when possible. + + However, reuse is not appropriate when the existing functionality + does not fit the new requirement and/or the reuse leads to ambiguity. + + The impact on extending existing applications can be categorized into + two groups: + + Minor Extension: Enhancing the functional scope of an existing + application by the addition of optional features to support it. + Such enhancement has no backward-compatibility issue with the + existing application. + + A typical example would be the definition of a new optional AVP + for use in an existing command. Diameter implementations + supporting the existing application but not the new AVP will + simply ignore it, without consequences for the Diameter message + handling, as described in [RFC6733]. The standardization effort + will be fairly small. + + Major Extension: Enhancing an application that requires the + definition of a new Diameter application. Such enhancement causes + a backward-compatibility issue with existing implementations + supporting the application. + + Typical examples would be the creation of a new command for + providing functionality not supported by existing applications or + the definition of a new AVP to be carried in an existing command + with the M-bit set in the AVP flags (see Section 4.1 of [RFC6733] + for definition of "M-bit"). For such an extension, a significant + specification effort is required, and a careful approach is + recommended. + +4. Reusing Existing Diameter Applications + + An existing application may need to be enhanced to fulfill new + requirements, and these modifications can be at the command level + and/or at the AVP level. The following sections describe the + possible modifications that can be performed on existing applications + and their related impact. + + + + + + +Morand, et al. Best Current Practice [Page 6] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + +4.1. Adding a New Command + + Adding a new command to an existing application is considered to be a + major extension and requires a new Diameter application to be + defined, as stated in Section 1.3.4 of [RFC6733]. The need for a new + application is because a Diameter node that is not upgraded to + support the new command(s) within the (existing) application would + reject any unknown command with the protocol error + DIAMETER_COMMAND_UNSUPPORTED and cause the failure of the + transaction. The new application ensures that Diameter nodes only + receive commands within the context of applications they support. + + Adding a new command means either defining a completely new command + or importing the command's Command Code Format (CCF) syntax from + another application whereby the new application inherits some or all + of the functionality of the application from which the command came. + In the former case, the decision to create a new application is + straightforward, since this is typically a result of adding a new + functionality that does not exist yet. For the latter, the decision + to create a new application will depend on whether importing the + command in a new application is more suitable than simply using the + existing application as it is in conjunction with any other + application. + + An example considers the Diameter Extensible Authentication Protocol + (EAP) application [RFC4072] and the Diameter Network Access Server + application [RFC7155]. When network access authentication using EAP + is required, the Diameter EAP commands (Diameter-EAP-Request/ + Diameter-EAP-Answer) are used; otherwise, the Diameter Network Access + Server application will be used. When the Diameter EAP application + is used, the accounting exchanges defined in the Diameter Network + Access Server may be used. + + However, in general, it is difficult to come to a hard guideline, and + so a case-by-case study of each application requirement should be + applied. Before adding or importing a command, application designers + should consider the following: + + o Can the new functionality be fulfilled by creating a new command + independent from any existing command? In this case, the + resulting new application and the existing application can work + independent of, but cooperating with, each other. + + o Can the existing command be reused without major extensions and, + therefore, without the need for the definition of a new + application, e.g., new functionality introduced by the creation of + new optional AVPs. + + + + +Morand, et al. Best Current Practice [Page 7] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + It is important to note that importing commands too liberally could + result in a monolithic and hard-to-manage application supporting too + many different features. + +4.2. Deleting an Existing Command + + Although this process is not typical, removing a command from an + application requires a new Diameter application to be defined, and + then it is considered as a major extension. This is due to the fact + that the reception of the deleted command would systematically result + in a protocol error (i.e., DIAMETER_COMMAND_UNSUPPORTED). + + It is unusual to delete an existing command from an application for + the sake of deleting it or the functionality it represents. An + exception might be if the intent of the deletion is to create a newer + variance of the same application that is somehow simpler than the + application initially specified. + +4.3. Reusing Existing Commands + + This section discusses rules in adding and/or deleting AVPs from an + existing command of an existing application. The cases described in + this section may not necessarily result in the creation of new + applications. + + From a historical point of view, it is worth noting that there was a + strong recommendation to reuse existing commands in [RFC3588] to + prevent rapid depletion of code values available for vendor-specific + commands. However, [RFC6733] has relaxed the allocation policy and + enlarged the range of available code values for vendor-specific + applications. Although reuse of existing commands is still + RECOMMENDED, protocol designers can consider defining a new command + when it provides a solution more suitable than the twisting of an + existing command's use and applications. + +4.3.1. Adding AVPs to a Command + + Based on the rules in [RFC6733], AVPs that are added to an existing + command can be categorized as either: + + o Mandatory (to understand) AVPs. As defined in [RFC6733], these + are AVPs with the M-bit flag set in this command, which means that + the Diameter node receiving them is required to understand not + only their values but also their semantics. Failure to do so will + cause a message handling error: either an error message with the + result-code set to DIAMETER_AVP_UNSUPPORTED if the AVP is not + understood in a request or an application-specific error handling + if the given AVP is in an answer. + + + +Morand, et al. Best Current Practice [Page 8] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + o Optional (to understand) AVPs. As defined in [RFC6733], these are + AVPs with the M-bit flag cleared in this command. A Diameter node + receiving these AVPs can simply ignore them if it does not support + them. + + It is important to note that the definitions given above are + independent of whether these AVPs are required or optional in the + command as specified by the command's CCF syntax [RFC6733]. + + NOTE: As stated in [RFC6733], the M-bit setting for a given AVP is + relevant to an application and each command within that + application that includes the AVP. + + The rules are strict in the case where the AVPs to be added in an + exiting command are mandatory to understand, i.e., they have the + M-bit set. A mandatory AVP MUST NOT be added to an existing command + without defining a new Diameter application, as stated in [RFC6733]. + This falls into the "Major Extensions" category. Despite the clarity + of the rule, ambiguity still arises when evaluating whether a new AVP + being added should be mandatory to begin with. Application designers + should consider the following questions when deciding about the M-bit + for a new AVP: + + o Would it be required for the receiving side to be able to process + and understand the AVP and its content? + + o Would the new AVPs change the state machine of the application? + + o Would the presence of the new AVP lead to a different number of + round trips, effectively changing the state machine of the + application? + + o Would the new AVP be used to differentiate between old and new + variances of the same application whereby the two variances are + not backward compatible? + + o Would the new AVP have duality in meaning, i.e., be used to carry + application-related information as well as to indicate that the + message is for a new application? + + If the answer to at least one of the questions is "yes", then the + M-bit MUST be set for the new AVP, and a new Diameter application + MUST be defined. This list of questions is non-exhaustive, and other + criteria MAY be taken into account in the decision process. + + + + + + + +Morand, et al. Best Current Practice [Page 9] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + If application designers are instead contemplating the use of + optional AVPs, i.e., with the M-bit cleared, there are still pitfalls + that will cause interoperability problems; therefore, they must be + avoided. Some examples of these pitfalls are as follows: + + o Use of optional AVPs with intersecting meaning. One AVP has + partially the same usage and meaning as another AVP. The presence + of both can lead to confusion. + + o Optional AVPs with dual purpose, i.e., to carry application data + as well as to indicate support for one or more features. This has + a tendency to introduce interpretation issues. + + o Adding one or more optional AVPs and indicating (usually within + descriptive text for the command) that at least one of them has to + be understood by the receiver of the command. This would be + equivalent to adding a mandatory AVP, i.e., an AVP with the M-bit + set, to the command. + +4.3.2. Deleting AVPs from a Command + + Application designers may want to reuse an existing command, but some + of the AVPs present in the command's CCF syntax specification may be + irrelevant for the functionality foreseen to be supported by this + command. It may be then tempting to delete those AVPs from the + command. + + The impacts of deleting an AVP from a command depends on its Command + Code format specification and M-bit setting: + + o Case 1: Deleting an AVP that is indicated as a required AVP (noted + as {AVP}) in the command's CCF syntax specification (regardless of + the M-bit setting). + + In this case, a new Command Code, and subsequently a new Diameter + application, MUST be specified. + + o Case 2: Deleting an AVP, which has the M-bit set, and is indicated + as an optional AVP (noted as [AVP] in the command CCF) in the + command's CCF syntax specification. + + In this case, no new Command Code has to be specified, but the + definition of a new Diameter application is REQUIRED. + + o Case 3: Deleting an AVP, which has the M-bit cleared, and is + indicated as [AVP] in the command's CCF syntax specification. + + In this case, the AVP can be deleted without consequences. + + + +Morand, et al. Best Current Practice [Page 10] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + Application designers SHOULD attempt to reuse the command's CCF + syntax specification without modification and simply ignore (but not + delete) any optional AVPs that will not be used. This is to maintain + compatibility with existing applications that will not know about the + new functionality as well as to maintain the integrity of existing + dictionaries. + +4.3.3. Changing the Flag Settings of AVP in Existing Commands + + Although unusual, implementors may want to change the setting of the + AVP flags a given AVP used in a command. + + Into an existing command, an AVP that was initially defined as a + mandatory AVP to understand, i.e., an AVP with the M-bit flag set in + the command MAY be safely turned to an optional AVP, i.e., with the + M-bit cleared. Any node supporting the existing application will + still understand the AVP, whatever the setting of the M-bit. On the + contrary, an AVP initially defined as an optional AVP to understand, + i.e., an AVP with the M-bit flag cleared in the command MUST NOT be + changed into a mandatory AVP with the M-bit flag set without defining + a new Diameter application. Setting the M-bit for an AVP that was + defined as an optional AVP is equivalent to adding a new mandatory + AVP to an existing command, and the rules given in Section 4.3.1 + apply. + + All other AVP flags (V-bit, P-bit, reserved bits) MUST remain + unchanged. + +4.4. Reusing Existing AVPs + + This section discusses rules in reusing existing AVPs when reusing an + existing command or defining a new command in a new application. + +4.4.1. Setting of the AVP Flags + + When reusing existing AVPs in a new application, application + designers MUST specify the setting of the M-bit flag for a new + Diameter application and, if necessary, for every command of the + application that can carry these AVPs. In general, for AVPs defined + outside of the Diameter base protocol, the characteristics of an AVP + are tied to its role within a given application and the commands used + in this application. + + All other AVP flags (V-bit, P-bit, reserved bits) MUST remain + unchanged. + + + + + + +Morand, et al. Best Current Practice [Page 11] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + +4.4.2. Reuse of AVP of Type Enumerated + + When reusing an AVP of type Enumerated in a command for a new + application, it is RECOMMENDED to avoid modifying the set of valid + values defined for this AVP. Modifying the set of Enumerated values + includes adding a value or deprecating the use of a value defined + initially for the AVP. Modifying the set of values will impact the + application defining this AVP and all the applications using this + AVP, causing potential interoperability issues: a value used by a + peer that will not be recognized by all the nodes between the client + and the server will cause an error response with the Result-Code AVP + set to DIAMETER_INVALID_AVP_VALUE. When the full range of values + defined for this Enumerated AVP is not suitable for the new + application, it is RECOMMENDED that a new AVP be defined to avoid + backward-compatibility issues with existing implementations. + +5. Defining New Diameter Applications + +5.1. Introduction + + This section discusses the case where new applications have + requirements that cannot be fulfilled by existing applications and + would require definition of completely new commands, AVPs, and/or AVP + values. Typically, there is little ambiguity about the decision to + create these types of applications. Some examples are the interfaces + defined for the IP Multimedia Subsystem of 3GPP, e.g., Cx/Dx + ([TS29.228] and [TS29.229]), Sh ([TS29.328] and [TS29.329]), etc. + + Application designers SHOULD try to import existing AVPs and AVP + values for any newly defined commands. In certain cases where + accounting will be used, the models described in Section 5.10 SHOULD + also be considered. + + Additional considerations are described in the following sections. + +5.2. Defining New Commands + + As a general recommendation, commands SHOULD NOT be defined from + scratch. It is instead RECOMMENDED to reuse an existing command + offering similar functionality and use it as a starting point. Code + reuse leads to a smaller implementation effort as well as reduces the + need for testing. + + Moreover, the new command's CCF syntax specification SHOULD be + carefully defined when considering applicability and extensibility of + the application. If most of the AVPs contained in the command are + indicated as fixed or required, it might be difficult to reuse the + same command and, therefore, the same application in a slightly + + + +Morand, et al. Best Current Practice [Page 12] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + changed environment. Defining a command with most of the AVPs + indicated as optional is considered as a good design choice in many + cases, despite the flexibility it introduces in the protocol. + Protocol designers MUST clearly state the reasons why these optional + AVPs might or might not be present and properly define the + corresponding behavior of the Diameter nodes when these AVPs are + absent from the command. + + NOTE: As a hint for protocol designers, it is not sufficient to + just look at the command's CCF syntax specification. It is also + necessary to carefully read through the accompanying text in the + specification. + + In the same way, the CCF syntax specification SHOULD be defined such + that it will be possible to add any arbitrary optional AVPs with the + M-bit cleared (including vendor-specific AVPs) without modifying the + application. For this purpose, "* [AVP]" SHOULD be added in the + command's CCF, which allows the addition of any arbitrary number of + optional AVPs as described in [RFC6733]. + +5.3. Use of Application Id in a Message + + When designing new applications, application designers SHOULD specify + that the Application Id carried in all session-level messages is the + Application Id of the application using those messages. This + includes the session-level messages defined in the Diameter base + protocol, i.e., Re-Auth-Request (RAR) / Re-Auth-Answer (RAA), + Session-Termination-Request (STR) / Session-Termination-Answer (STA), + Abort-Session-Request (ASR) / Abort-Session-Answer (ASA), and + possibly Accounting-Request (ACR) / Accounting Answer (ACA) in the + coupled accounting model; see Section 5.10. Some existing + specifications do not adhere to this rule for historical reasons. + However, this guidance SHOULD be followed by new applications to + avoid routing problems. + + When a new application has been allocated with a new Application Id + and it also reuses existing commands with or without modifications, + the commands SHOULD use the newly allocated Application Id in the + header and in all relevant Application-Id AVPs (Auth-Application-Id + or Acct-Application-Id) present in the commands message body. + + Additionally, application designers using a vendor-specific + Application-Id AVP SHOULD NOT use the Vendor-Id AVP to further + dissect or differentiate the vendor-specification Application Id. + Diameter routing is not based on the Vendor Id. As such, the Vendor + Id SHOULD NOT be used as an additional input for routing or delivery + of messages. The Vendor-Id AVP is an informational AVP only and kept + for backward compatibility reasons. + + + +Morand, et al. Best Current Practice [Page 13] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + +5.4. Application-Specific Session State Machines + + Section 8 of [RFC6733] provides session state machines for AAA + services, and these session state machines are not intended to cover + behavior outside of AAA. If a new application cannot clearly be + categorized into any of these AAA services, it is RECOMMENDED that + the application define its own session state machine. Support for a + server-initiated request is a clear example where an application- + specific session state machine would be needed, for example, the Rw + interface for the ITU-T push model (cf. [Q.3303.3]). + +5.5. Session-Id AVP and Session Management + + Diameter applications are usually designed with the aim of managing + user sessions (e.g., Diameter Network Access Server (NAS) application + [RFC4005]) or a specific service access session (e.g., Diameter SIP + application [RFC4740]). In the Diameter base protocol, session state + is referenced using the Session-Id AVP. All Diameter messages that + use the same Session-Id will be bound to the same session. Diameter- + based session management also implies that both the Diameter client + and server (and potentially proxy agents along the path) maintain + session state information. + + However, some applications may not need to rely on the Session-Id to + identify and manage sessions because other information can be used + instead to correlate Diameter messages. Indeed, the User-Name AVP or + any other specific AVP can be present in every Diameter message and + used, therefore, for message correlation. Some applications might + not require the notion of the Diameter-session concept at all. For + such applications, the Auth-Session-State AVP is usually set to + NO_STATE_MAINTAINED in all Diameter messages, and these applications + are, therefore, designed as a set of stand-alone transactions. Even + if an explicit access session termination is required, application- + specific commands are defined and used instead of the STR/STA or ASR/ + ASA defined in the Diameter base protocol [RFC6733]. In such a case, + the Session-Id is not significant. + + Based on these considerations, protocol designers should carefully + appraise whether the Diameter application being defined relies on the + session management specified in the Diameter base protocol: + + o If it is, the Diameter command defined for the new application + MUST include the Session-Id AVP defined in the Diameter base + protocol [RFC6733], and the Session-Id AVP MUST be used for + correlation of messages related to the same session. Guidance on + the use of the Auth-Session-State AVP is given in the Diameter + base protocol [RFC6733]. + + + + +Morand, et al. Best Current Practice [Page 14] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + o Otherwise, because session management is not required or the + application relies on its own session management mechanism, + Diameter commands for the application need not include the + Session-Id AVP. If any specific session management concept is + supported by the application, the application documentation MUST + clearly specify how the session is handled between the client and + server (and possibly Diameter agents in the path). Moreover, + because the application is not maintaining session state at the + Diameter base protocol level, the Auth-Session-State AVP MUST be + included in all Diameter commands for the application and MUST be + set to NO_STATE_MAINTAINED. + +5.6. Use of Enumerated Type AVPs + + The type Enumerated was initially defined to provide a list of valid + values for an AVP with their respective interpretation described in + the specification. For instance, AVPs of type Enumerated can be used + to provide further information on the reason for the termination of a + session or a specific action to perform upon the reception of the + request. + + As described in Section 4.4.2 above, defining an AVP of type + Enumerated presents some limitations in terms of extensibility and + reusability. Indeed, the finite set of valid values defined in the + definition of the AVP of type Enumerated cannot be modified in + practice without causing backward-compatibility issues with existing + implementations. As a consequence, AVPs of type Enumerated MUST NOT + be extended by adding new values to support new capabilities. + Diameter protocol designers SHOULD carefully consider before defining + an Enumerated AVP whether the set of values will remain unchanged or + new values may be required in the near future. If such an extension + is foreseen or cannot be avoided, it is RECOMMENDED to define AVPs of + type Unsigned32 or Unsigned64 in which the data field would contain + an address space representing "values" that would have the same use + of Enumerated values. Whereas only the initial values defined at the + definition of the AVP of type Enumerated are valid as described in + Section 4.4.2, any value from the address space from 0 to 2^32 - 1 + for AVPs of type Unsigned32 or from 0 to 2^64 - 1 for AVPs of type + Unsigned64 is valid at the Diameter base protocol level and will not + cause interoperability issues for intermediary nodes between clients + and servers. Only clients and servers will be able to process the + values at the application layer. + + + + + + + + + +Morand, et al. Best Current Practice [Page 15] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + For illustration, an AVP describing possible access networks would be + defined as follows: + + Access-Network-Type AVP (XXX) is of type Unsigned32 and + contains a 32-bit address space representing types of access + networks. This application defines the following classes of access + networks, all identified by the thousands digit in the decimal + notation: + + o 1xxx (Mobile Access Networks) + + o 2xxx (Fixed Access Networks) + + o 3xxx (Wireless Access Networks) + + Values that fall within the Mobile Access Networks category are used + to inform a peer that a request has been sent for a user attached to + a mobile access network. The following values are defined in this + application: + + 1001: 3GPP-GERAN + + The user is attached to a Global System for Mobile Communications + (GSM) Enhanced Data rates for GSM Evolution (EDGE) Radio Access + Network. + + 1002: 3GPP-UTRAN-FDD + + The user is attached to a Universal Mobile Telecommunications + System (UMTS) access network that uses frequency-division + duplexing for duplexing. + + Unlike Enumerated AVP, any new value can be added in the address + space defined by this Unsigned32 AVP without modifying the definition + of the AVP. There is, therefore, no risk of backward-compatibility + issues, especially when intermediate nodes may be present between + Diameter endpoints. + + Along the same line, AVPs of type Enumerated are too often used as a + simple Boolean flag, indicating, for instance, a specific permission + or capability; therefore, only three values are defined, e.g., TRUE/ + FALSE, AUTHORIZED/UNAUTHORIZED, or SUPPORTED/UNSUPPORTED. This is a + sub-optimal design since it limits the extensibility of the + application: any new capability/permission would have to be supported + by a new AVP or new Enumerated value of the already-defined AVP, with + the backward-compatibility issues described above. Instead of using + an Enumerated AVP for a Boolean flag, protocol designers SHOULD use + AVPs of type Unsigned32 or Unsigned64 in which the data field would + + + +Morand, et al. Best Current Practice [Page 16] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + be defined as a bit mask whose bit settings are described in the + relevant Diameter application specification. Such AVPs can be reused + and extended without major impact on the Diameter application. The + bit mask SHOULD leave room for future additions. Examples of AVPs + that use bit masks are the Session-Binding AVP defined in [RFC6733] + and the MIP6-Feature-Vector AVP defined in [RFC5447]. + +5.7. Application-Specific Message Routing + + As described in [RFC6733], a Diameter request that needs to be sent + to a home server serving a specific realm, but not to a specific + server (such as the first request of a series of round trips), will + contain a Destination-Realm AVP and no Destination-Host AVP. + + For such a request, the message routing usually relies only on the + Destination-Realm AVP and the Application Id present in the request + message header. However, some applications may need to rely on the + User-Name AVP or any other application-specific AVPs present in the + request to determine the final destination of a request, e.g., to + find the target AAA server hosting the authorization information for + a given user when multiple AAA servers are addressable in the realm. + + In such a context, basic routing mechanisms described in [RFC6733] + are not fully suitable, and additional application-level routing + mechanisms MUST be described in the application documentation to + provide such specific AVP-based routing. Such functionality will be + basically hosted by an application-specific proxy agent that will be + responsible for routing decisions based on the received specific + AVPs. + + Examples of such application-specific routing functions can be found + in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP IP + Multimedia Subsystem, in which the proxy agent (Subscriber Location + Function, aka SLF) uses specific application-level identities found + in the request to determine the final destination of the message. + + Whatever the criteria used to establish the routing path of the + request, the routing of the answer MUST follow the reverse path of + the request, as described in [RFC6733], with the answer being sent to + the source of the received request, using transaction states and + hop-by-hop identifier matching. This ensures that the Diameter relay + or proxy agents in the request routing path will be able to release + the transaction state upon receipt of the corresponding answer, + avoiding unnecessary failover. Moreover, especially in roaming + cases, proxy agents in the path must be able to apply local policies + when receiving the answer from the server during authentication/ + authorization and/or accounting procedures and maintain up-to-date + session state information by keeping track of all authorized active + + + +Morand, et al. Best Current Practice [Page 17] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + sessions. Therefore, application designers MUST NOT modify the + answer-routing principles described in [RFC6733] when defining a new + application. + +5.8. Translation Agents + + As defined in [RFC6733], a translation agent is a device that + provides interworking between Diameter and another AAA protocol, such + as RADIUS. + + In the case of RADIUS, it was initially thought that defining the + translation function would be straightforward by adopting a few basic + principles, e.g., by the use of a shared range of code values for + RADIUS attributes and Diameter AVPs. Guidelines for implementing a + RADIUS-Diameter translation agent were put into the Diameter NAS + Application [RFC4005]. + + However, it was acknowledged that such a translation mechanism was + not so obvious and deeper protocol analysis was required to ensure + efficient interworking between RADIUS and Diameter. Moreover, the + interworking requirements depend on the functionalities provided by + the Diameter application under specification, and a case-by-case + analysis is required. As a consequence, all the material related to + RADIUS-to-Diameter translation is removed from the new version of the + Diameter NAS Application specification [RFC7155], which deprecates + RFC 4005 [RFC4005]. + + Therefore, protocol designers SHOULD NOT assume the availability of a + "standard" Diameter-to-RADIUS gateway agent when planning to + interoperate with the RADIUS infrastructure. They SHOULD specify the + required translation mechanism along with the Diameter application, + if needed. This recommendation applies for any kind of translation. + +5.9. End-to-End Application Capabilities Exchange + + Diameter applications can rely on optional AVPs to exchange + application-specific capabilities and features. These AVPs can be + exchanged on an end-to-end basis at the application layer. Examples + of this can be found with the MIP6-Feature-Vector AVP in [RFC5447] + and the QoS-Capability AVP in [RFC5777]. + + End-to-end capabilities AVPs can be added as optional AVPs with the + M-bit cleared to existing applications to announce support of new + functionality. Receivers that do not understand these AVPs or the + AVP values can simply ignore them, as stated in [RFC6733]. When + supported, receivers of these AVPs can discover the additional + functionality supported by the Diameter endpoint originating the + request and behave accordingly when processing the request. Senders + + + +Morand, et al. Best Current Practice [Page 18] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + of these AVPs can safely assume the receiving endpoint does not + support any functionality carried by the AVP if it is not present in + the corresponding response. This is useful in cases where deployment + choices are offered, and the generic design can be made available for + a number of applications. + + When used in a new application, these end-to-end capabilities AVPs + SHOULD be added as an optional AVP into the CCF of the commands used + by the new application. Protocol designers SHOULD clearly specify + this end-to-end capabilities exchange and the corresponding behavior + of the Diameter nodes supporting the application. + + It is also important to note that this end-to-end capabilities + exchange relying on the use of optional AVPs is not meant as a + generic mechanism to support extensibility of Diameter applications + with arbitrary functionality. When the added features drastically + change the Diameter application or when Diameter agents must be + upgraded to support the new features, a new application SHOULD be + defined, as recommended in [RFC6733]. + +5.10. Diameter Accounting Support + + Accounting can be treated as an auxiliary application that is used in + support of other applications. In most cases, accounting support is + required when defining new applications. This document provides two + possible models for using accounting: + + Split Accounting Model: + + In this model, the accounting messages will use the Diameter base + accounting Application Id (value of 3). The design implication + for this is that the accounting is treated as an independent + application, especially for Diameter routing. This means that + accounting commands emanating from an application may be routed + separately from the rest of the other application messages. This + may also imply that the messages end up in a central accounting + server. A split accounting model is a good design choice when: + + * The application itself does not define its own accounting + commands. + + * The overall system architecture permits the use of centralized + accounting for one or more Diameter applications. + + Centralizing accounting may have advantages, but there are also + drawbacks. The model assumes that the accounting server can + differentiate received accounting messages. Since the received + accounting messages can be for any application and/or service, the + + + +Morand, et al. Best Current Practice [Page 19] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + accounting server MUST have a method to match accounting messages + with applications and/or services being accounted for. This may + mean defining new AVPs; checking the presence, absence, or + contents of existing AVPs; or checking the contents of the + accounting record itself. One of these means could be to insert + into the request sent to the accounting server an + Auth-Application-Id AVP containing the identifier of the + application for which the accounting request is sent. But in + general, there is no clean and generic scheme for sorting these + messages. Therefore, this model SHOULD NOT be used when all + received accounting messages cannot be clearly identified and + sorted. For most cases, the use of the Coupled Accounting Model + is RECOMMENDED. + + Coupled Accounting Model: + + In this model, the accounting messages will use the Application Id + of the application using the accounting service. The design + implication for this is that the accounting messages are tightly + coupled with the application itself, meaning that accounting + messages will be routed like the other application messages. It + would then be the responsibility of the application server + (application entity receiving the ACR message) to send the + accounting records carried by the accounting messages to the + proper accounting server. The application server is also + responsible for formulating a proper response (ACA). A coupled + accounting model is a good design choice when: + + * The system architecture or deployment does not provide an + accounting server that supports Diameter. Consequently, the + application server MUST be provisioned to use a different + protocol to access the accounting server, e.g., via the + Lightweight Directory Access Protocol (LDAP), SOAP, etc. This + case includes the support of older accounting systems that are + not Diameter aware. + + * The system architecture or deployment requires that the + accounting service for the specific application should be + handled by the application itself. + + In all cases above, there will generally be no direct Diameter + access to the accounting server. + + These models provide a basis for using accounting messages. + Application designers may obviously deviate from these models + provided that the factors being addressed here have also been taken + + + + + +Morand, et al. Best Current Practice [Page 20] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + into account. As a general recommendation, application designers + SHOULD NOT define a new set of commands to carry application-specific + accounting records. + +5.11. Diameter Security Mechanisms + + As specified in [RFC6733], the Diameter message exchange SHOULD be + secured between neighboring Diameter peers using Transport Layer + Security (TLS) / TCP or Datagram Transport Layer Security (DTLS) / + Stream Control Transmission Protocol (SCTP). However, IPsec MAY also + be deployed to secure communication between Diameter peers. When + IPsec is used instead of TLS or DTLS, the following recommendations + apply. + + IPsec Encapsulating Security Payload (ESP) [RFC4301] in transport + mode with non-null encryption and authentication algorithms MUST be + used to provide per-packet authentication, integrity protection, and + confidentiality and to support the replay protection mechanisms of + IPsec. Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] + SHOULD be used for performing mutual authentication and for + establishing and maintaining security associations (SAs). + + Version 1 of IKE (IKEv1), defined in [RFC2409], was initially used + for peer authentication, negotiation of security associations, and + key management in RFC 3588 [RFC3588]. For easier migration from the + obsoleted implementations based on IKEv1 to IKEv2, both RSA digital + signatures and pre-shared keys SHOULD be supported in IKEv2. + However, if IKEv1 is used, implementors SHOULD follow the guidelines + given in Section 13.1 of RFC 3588 [RFC3588]. + +6. Defining Generic Diameter Extensions + + Generic Diameter extensions are AVPs, commands, or applications that + are designed to support other Diameter applications. They are + auxiliary applications meant to improve or enhance the Diameter + protocol itself or Diameter applications/functionality. Some + examples include the extensions to support realm-based redirection of + Diameter requests (see [RFC7075]), conveying a specific set of + priority parameters influencing the distribution of resources (see + [RFC6735]), and the support for QoS AVPs (see [RFC5777]). + + + + + + + + + + + +Morand, et al. Best Current Practice [Page 21] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + Since generic extensions may cover many aspects of Diameter and + Diameter applications, it is not possible to enumerate all scenarios. + However, some of the most common considerations are as follows: + + Backward Compatibility: + + When defining generic extensions designed to be supported by + existing Diameter applications, protocol designers MUST consider + the potential impacts of the introduction of the new extension on + the behavior of the node that would not be yet upgraded to + support/understand this new extension. Designers MUST also ensure + that new extensions do not break expected message delivery layer + behavior. + + Forward Compatibility: + + Protocol designers MUST ensure that their design will not + introduce undue restrictions for future applications. + + Trade-off in Signaling: + + Designers may have to choose between the use of optional AVPs + piggybacked onto existing commands versus defining new commands + and applications. Optional AVPs are simpler to implement and may + not need changes to existing applications. However, this ties the + sending of extension data to the application's transmission of a + message. This has consequences if the application and the + extensions have different timing requirements. The use of + commands and applications solves this issue, but the trade-off is + the additional complexity of defining and deploying a new + application. It is left up to the designer to find a good balance + among these trade-offs based on the requirements of the extension. + + In practice, generic extensions often use optional AVPs because they + are simple and non-intrusive to the application that would carry + them. Peers that do not support the generic extensions need not + understand nor recognize these optional AVPs. However, it is + RECOMMENDED that the authors of the extension specify the context or + usage of the optional AVPs. As an example, in the case that the AVP + can be used only by a specific set of applications, then the + specification MUST enumerate these applications and the scenarios + when the optional AVPs will be used. In the case where the optional + AVPs can be carried by any application, it should be sufficient to + specify such a use case and perhaps provide specific examples of + applications using them. + + + + + + +Morand, et al. Best Current Practice [Page 22] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + In most cases, these optional AVPs piggybacked by applications would + be defined as a Grouped AVP, and it would encapsulate all the + functionality of the generic extension. In practice, it is not + uncommon that the Grouped AVP will encapsulate an existing AVP that + has previously been defined as mandatory ('M'-bit set), e.g., 3GPP IP + Multimedia Subsystems (IMS) Cx/Dx interfaces ([TS29.228] and + [TS29.229]). + +7. Guidelines for Registrations of Diameter Values + + As summarized in Section 3 of this document and further described in + Section 1.3 of [RFC6733], there are four main ways to extend + Diameter. The process for defining new functionality slightly varies + based on the different extensions. This section provides protocol + designers with some guidance regarding the definition of values for + possible Diameter extensions and the necessary interaction with IANA + to register the new functionality. + + a. Defining New AVP Values + + The specifications defining AVPs and AVP values MUST provide + guidance for defining new values and the corresponding policy for + adding these values. For example, RFC 5777 [RFC5777] defines the + Treatment-Action AVP, which contains a list of valid values + corresponding to predefined actions (drop, shape, mark, permit). + This set of values can be extended following the Specification + Required policy defined in [RFC5226]. As a second example, the + Diameter base specification [RFC6733] defines the Result-Code AVP + that contains a 32-bit address space used to identity possible + errors. According to Section 11.3.2 of [RFC6733], new values can + be assigned by IANA via an IETF Review process [RFC5226]. + + b. Creating New AVPs + + Two different types of AVP Codes namespaces can be used to create + a new AVP: + + * IETF AVP Codes namespace. + + * Vendor-specific AVP Codes namespace. + + In the latter case, a vendor needs to be first assigned by IANA + with a private enterprise number, which can be used within the + Vendor-Id field of the vendor-specific AVP. This enterprise + number delimits a private namespace in which the vendor is + responsible for vendor-specific AVP code value assignment. The + absence of a Vendor Id or a Vendor-Id value of zero (0) in the AVP + header identifies standard AVPs from the IETF AVP Codes namespace + + + +Morand, et al. Best Current Practice [Page 23] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + managed by IANA. The allocation of code values from the IANA- + managed namespace is conditioned by an Expert Review of the + specification defining the AVPs or an IETF Review if a block of + AVPs needs to be assigned. Moreover, the remaining bits of the + AVP Flags field of the AVP header are also assigned via Standards + Action if the creation of new AVP flags is desired. + + c. Creating New Commands + + Unlike the AVP Codes namespace, the Command Code namespace is + flat, but the range of values is subdivided into three chunks with + distinct IANA registration policies: + + * A range of standard Command Code values that are allocated via + IETF Review; + + * A range of vendor-specific Command Code values that are + allocated on a first-come, first-served basis; and + + * A range of values reserved only for experimental and testing + purposes. + + As for AVP flags, the remaining bits of the Command Flags field of + the Diameter header are also assigned via a Standards Action to + create new Command flags if required. + + d. Creating New Applications + + Similarly, to the Command Code namespace, the Application-Id + namespace is flat but divided into two distinct ranges: + + * A range of values reserved for standard Application Ids, + allocated after Expert Review of the specification defining the + standard application. + + * A range for values for vendor-specific applications, allocated + by IANA on a first-come, first-served basis. + + The IANA AAA parameters page can be found at + , and the enterprise + number IANA page is available at . More details on the policies followed by IANA + for namespace management (e.g., first-come, first-served; Expert + Review; IETF Review; etc.) can be found in [RFC5226]. + + + + + + + +Morand, et al. Best Current Practice [Page 24] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + NOTE: When the same functionality/extension is used by more than + one vendor, it is RECOMMENDED that a standard extension be + defined. Moreover, a vendor-specific extension SHOULD be + registered to avoid interoperability issues in the same network. + With this aim, the registration policy of a vendor-specific + extension has been simplified with the publication of [RFC6733], + and the namespace reserved for vendor-specific extensions is large + enough to avoid exhaustion. + +8. Security Considerations + + This document provides guidelines and considerations for extending + Diameter and Diameter applications. Although such an extension may + be related to a security functionality, the document does not + explicitly give additional guidance on enhancing Diameter with + respect to security. However, as a general guideline, it is + recommended that any Diameter extension SHOULD NOT break the security + concept given in [RFC6733]. In particular, it is reiterated here + that any command defined or reused in a new Diameter application + SHOULD be secured by using TLS [RFC5246] or DTLS/SCTP [RFC6083] and + MUST NOT be used without one of the following: TLS, DTLS, or IPsec + [RFC4301]. When defining a new Diameter extension, any possible + impact of the existing security principles described in [RFC6733] + MUST be carefully appraised and documented in the Diameter + application specification. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, + "Diameter Base Protocol", RFC 6733, October 2012, + . + +9.2. Informative References + + [Q.3303.3] International Telecommunications Union, "Resource control + protocol No. 3: Protocols at the Rw interface between the + policy decision physical entity (PD-PE) and a policy + enforcement physical entity (PE-PE): Diameter profile + version 3", ITU-T Recommendation Q.3303.3, August 2008. + + + + + + +Morand, et al. Best Current Practice [Page 25] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998, + . + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. + Arkko, "Diameter Base Protocol", RFC 3588, September 2003, + . + + [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, + "Diameter Network Access Server Application", RFC 4005, + August 2005, . + + [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible + Authentication Protocol (EAP) Application", RFC 4072, + August 2005, . + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005, + . + + [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., + Canales-Valenzuela, C., and K. Tammi, "Diameter Session + Initiation Protocol (SIP) Application", RFC 4740, November + 2006, . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008, + . + + [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., + and K. Chowdhury, "Diameter Mobile IPv6: Support for + Network Access Server to Diameter Server Interaction", RFC + 5447, February 2009, + . + + [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., + and A. Lior, "Traffic Classification and Quality of + Service (QoS) Attributes for Diameter", RFC 5777, February + 2010, . + + [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram + Transport Layer Security (DTLS) for Stream Control + Transmission Protocol (SCTP)", RFC 6083, January 2011, + . + + + +Morand, et al. Best Current Practice [Page 26] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + + [RFC6735] Carlberg, K. and T. Taylor, "Diameter Priority Attribute- + Value Pairs", RFC 6735, October 2012, + . + + [RFC7075] Tsou, T., Hao, R., and T. Taylor, "Realm-Based Redirection + In Diameter", RFC 7075, November 2013, + . + + [RFC7155] Zorn, G., "Diameter Network Access Server Application", + RFC 7155, April 2014, + . + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, October 2014, + . + + [TS29.228] 3rd Generation Partnership Project, "Technical + Specification Group Core Network and Terminals; IP + Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling + flows and message contents", 3GPP TS 29.228, September + 2014, . + + [TS29.229] 3rd Generation Partnership Project, "Technical + Specification Group Core Network and Terminals; Cx and Dx + interfaces based on the Diameter protocol; Protocol + details", 3GPP TS 29.229, September 2014, + . + + [TS29.328] 3rd Generation Partnership Project, "Technical + Specification Group Core Network and Terminals; IP + Multimedia (IM) Subsystem Sh interface; Signalling flows + and message contents", 3GPP TS 29.328, September 2014, + . + + [TS29.329] 3rd Generation Partnership Project, "Technical + Specification Group Core Network and Terminals; Sh + Interface based on the Diameter protocol; Protocol + details", 3GPP TS 29.329, September 2014, + . + + + + + + + + + + + +Morand, et al. Best Current Practice [Page 27] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + +Contributors + + The content of this document was influenced by a design team created + to revisit the Diameter extensibility rules. The team was formed in + February 2008 and finished its work in June 2008. In addition to + those individuals listed in the Authors' Addresses section, the + design team members were: + + o Avi Lior + + o Glen Zorn + + o Jari Arkko + + o Jouni Korhonen + + o Mark Jones + + o Tolga Asveren + + o Glenn McGregor + + o Dave Frascone + + We would like to thank Tolga Asveren, Glenn McGregor, and John + Loughney for their contributions as coauthors to earlier versions of + this document. + +Acknowledgments + + We greatly appreciate the insight provided by Diameter implementors + who have highlighted the issues and concerns being addressed by this + document. The authors would also like to thank Jean Mahoney, Ben + Campbell, Sebastien Decugis, and Benoit Claise for their invaluable, + detailed reviews and comments on this document. + + + + + + + + + + + + + + + + +Morand, et al. Best Current Practice [Page 28] + +RFC 7423 Diameter Applications Design Guidelines November 2014 + + +Authors' Addresses + + Lionel Morand (editor) + Orange Labs + 38/40 rue du General Leclerc + Issy-Les-Moulineaux Cedex 9 92794 + France + + Phone: +33145296257 + EMail: lionel.morand@orange.com + + + Victor Fajardo + Fluke Networks + + EMail: vf0213@gmail.com + + + Hannes Tschofenig + Hall in Tirol 6060 + Austria + + EMail: Hannes.Tschofenig@gmx.net + URI: http://www.tschofenig.priv.at + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morand, et al. Best Current Practice [Page 29] + -- cgit v1.2.3