doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

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
+   <http://www.iana.org/assignments/aaa-parameters>, and the enterprise
+   number IANA page is available at <http://www.iana.org/assignments/
+   enterprise-numbers>.  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,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
+              "Diameter Base Protocol", RFC 6733, October 2012,
+              <http://www.rfc-editor.org/info/rfc6733>.
+
+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,
+              <http://xml.resource.org/public/rfc/info/rfc2409>.
+
+   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
+              Arkko, "Diameter Base Protocol", RFC 3588, September 2003,
+              <http://www.rfc-editor.org/info/rfc3588>.
+
+   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
+              "Diameter Network Access Server Application", RFC 4005,
+              August 2005, <http://www.rfc-editor.org/info/rfc4005>.
+
+   [RFC4072]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
+              Authentication Protocol (EAP) Application", RFC 4072,
+              August 2005, <http://www.rfc-editor.org/info/rfc4072>.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005,
+              <http://www.rfc-editor.org/info/rfc4301>.
+
+   [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, <http://www.rfc-editor.org/info/rfc4740>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008, <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc5447>.
+
+   [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, <http://www.rfc-editor.org/info/rfc5777>.
+
+   [RFC6083]  Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
+              Transport Layer Security (DTLS) for Stream Control
+              Transmission Protocol (SCTP)", RFC 6083, January 2011,
+              <http://www.rfc-editor.org/info/rfc6083>.
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc6735>.
+
+   [RFC7075]  Tsou, T., Hao, R., and T. Taylor, "Realm-Based Redirection
+              In Diameter", RFC 7075, November 2013,
+              <http://www.rfc-editor.org/info/rfc7075>.
+
+   [RFC7155]  Zorn, G., "Diameter Network Access Server Application",
+              RFC 7155, April 2014,
+              <http://www.rfc-editor.org/info/rfc7155>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7296>.
+
+   [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, <http://www.3gpp.org/ftp/Specs/html-info/29228.htm>.
+
+   [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,
+              <http://www.3gpp.org/ftp/Specs/html-info/29229.htm>.
+
+   [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,
+              <http://www.3gpp.org/ftp/Specs/html-info/29328.htm>.
+
+   [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,
+              <http://www.3gpp.org/ftp/Specs/html-info/29329.htm>.
+
+
+
+
+
+
+
+
+
+
+
+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]
+