Diameter Applications Design GuidelinesOrange Labs38/40 rue du Général LeclercIssy-Les-Moulineaux Cedex 992794France+33145296257lionel.morand@orange.comIndependentvf0213@gmail.comNokia Siemens NetworksLinnoitustie 6Espoo02600Finland+358 (50) 4871445Hannes.Tschofenig@gmx.nethttp://www.tschofenig.priv.at
Operations and Management Area
Diameter Maintenance and Extensions (DIME)Internet-DraftThe Diameter base protocol provides facilities for protocol
extensibility enabling to define new Diameter applications or modify
existing applications. This document is a companion document to the
Diameter Base protocol that further explains and clarifies the rules to
extend Diameter. Futhermore, this document provides guidelines to
Diameter application designers reusing/defining Diameter applications or
creating generic Diameter extensions.The Diameter base protocol provides facilities to extend Diameter
(see Section 1.3 of ) to support new
functionality. In the context of this document, extending Diameter means
one of the following:Addition of new functionality to an existing Diameter application
without defining a new application.Addition of new functionality to an existing Diameter application
that requires the definition of a new application. The definition of an entirely new Diameter application to offer
functionality not supported by existing applications. The definition of a new generic functionality that can be reused
across different applications.All of these choices are design decisions that can be done 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 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:Clarify the Diameter extensibility rules as defined in the
Diameter base protocol. Discuss design choices and provide guidelines when defining new
applications. Present trade-off choices.This document reuses the terminology defined in . Additionally, the following terms and acronyms are
used in this application:Extension of the Diameter base protocol
via the addition of new commands or AVPs.
Each application is uniquely identified by an IANA-allocated
application identifier value.Diameter request or answer carrying AVPs
between Diameter endpoints. Each command is uniquely identified by a
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 .As designed, the Diameter base protocol 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 Section 8 and Section 9 of ). 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 the Section 1.3 of .
As a summary, Diameter can be extended by: Defining new AVP valuesCreating new AVPsCreating new commandsCreating new applicationsAs a main guiding principle, application designers SHOULD follow the
following recommendation: "try to re-use 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, re-use is not appropriate when the existing functionality
does not fit the new requirement and/or the re-use leads to
ambiguity.The impact on extending existing applications can be categorized into
two groups: Enhancing the functional scope of an
existing application by the addition of optional features to
support. 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
. The standardization effort will be fairly
small. Enhancing an application that
requires the definition of a new Diameter application. Such
enhancement causes 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 for definition of the "M-bit"). For such
extension, a significant specification effort is required and a
careful approach is recommended.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.Adding a new command to an existing application is considered as a
major extension and requires a new Diameter application to be defined,
as stated in the Section 1.3.4 of . 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 where the command came from. 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.
Therefore, a case by case study of each application requirement SHOULD
be applied.An example considers the Diameter EAP application and the Diameter Network Access Server application
. 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: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.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.Note: Importing commands too liberally could result in a monolithic
and hard to manage application supporting too many different
features.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. This
normally indicates of a flawed design. 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.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 to note that there was
a strong recommendation to re-use existing commands in the to prevent rapid depletion of code values available
for vendor-specific commands. However, 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 MAY consider
defining a new command when it provides a solution more suitable than
the twisting of an existing command's use and applications.Based on the rules in , AVPs that are
added to an existing command can be categorized into:Mandatory (to understand) AVPs. As defined in , these are AVPs with the M-bit flag set in
this command, which means that a Diameter node receiving them is
required to understand not only their values but also their
semantics. Failure to do so will cause an message handling
error.Optional (to understand) AVPs. As defined in , 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
definition given above are independent of whether these AVPs are
required or optional in the command as specified by the command's
Command Code Format (CCF) syntax .As stated in , 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
. 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:Would it be required for the receiving side to be able to
process and understand the AVP and its content?Would the new AVPs change the state machine of the
application?Would the presence of the new AVP lead to a different number
of round-trips, effectively changing the state machine of the
application?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?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. This list of questions is
non-exhaustive and other criteria MAY be taken into account in the
decision process.If application designers are instead contemplating the use of
optional AVPs, i.e., with the M-bit cleared, then the following are
some of the pitfalls that SHOULD be avoided: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. An 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.Adding one or more optional AVPs and indicating (usually
within descriptive text for the command) that at least one of
them has to be present in the command. This essentially
circumventing the ABNF and is equivalent to adding a mandatory
AVP to the command.These practices generally result in interoperability issues and
SHOULD be avoided.Application designers may want to reuse an existing command but
some of the AVP 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: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.Deleting an AVP, which has the M-bit set, and is indicated as
optional AVP (noted as [AVP]) in the command CCF) in the
command's CCF syntax specification. No
new command code has to be specified but the definition of a new
Diameter application is REQUIRED.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.Application designers SHOULD attempt the reuse the command's CCF
syntax specification without modification and simply ignore (but not
delete) any optional AVP that will not be used. This is to maintain
compatibility with existing applications that will not know about
the new functionality as well as maintain the integrity of existing
dictionaries.This section discusses rules in reusing existing AVP when reusing
an existing command or defining a new command in a new
application.When reusing AVPs in a new application, the M-bit flag setting
MUST be re-evaluated for a new Diameter application and, if
necessary, even for every command within the application. 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.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. When the full range
of values defined for this Enumerated AVP is not suitable for the
new application, it is RECOMMENDED to define a new AVP to avoid
backwards compatibility issues with existing implementations.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 ( and ), Sh ( and ) 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 SHOULD also be considered.Additional considerations are described in the following
sections.As a general recommendation, commands SHOULD not be defined from
scratch. It is instead RECOMMENDED to re-use an existing command
offering similar functionality and use it as a starting point. Code
re-use lead to a smaller implementation effort as well as reduce 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 changed
environment. Defining a command with most of the AVPs indicated as
optional MUST NOT be seen as a sub-optimal design introducing too much
flexibility in the protocol. The protocol designers SHOULD only
clearly state the condition of presence of these AVPs and properly
define the corresponding behaviour of the Diameter nodes when these
AVPs are absent from the command.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 .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 Diameter base protocol,
i.e., RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled
accounting model, see . 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
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.Section 8 of provides session state
machines for authentication, authorization and accounting (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 defines its own session state machine. Support for
server-initiated request is a clear example where an
application-specific session state machine would be needed, for
example, the Rw interface for ITU-T push model (cf.).Diameter applications are usually designed with the aim of managing
user sessions (e.g., Diameter network access session (NASREQ)
application ) or specific service access
session (e.g., Diameter SIP application ). 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 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 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
Session-Termination-Request/Answer (STR/STA) or
Abort-Session-Request/Answer (ASR/ASA) defined in the Diameter base
protocol . In such a case, the Session-Id is
not significant.Based on these considerations, protocol designers SHOULD carefully
appraise whether the application currently defined relies on its own
session management concept or whether the Session-Id defined in the
Diameter base protocol would be used for correlation of messages
related to the same session. If not, the protocol designers MAY decide
to define application commands without the Session-Id AVP. If any
session management concept is supported by the application, the
application documentation MUST clearly specify how the session is
handled between client and server (as possibly Diameter agents in the
path).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 the section 4.4.2 above, defining an AVP of type
Enumerated presents some limitations in term of extensibility and
reusability. Indeed, the finite set of valid values defined at 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 a near future. If such extension is foreseen
or cannot be avoided, it is RECOMMENED to rather 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.For illustration, an AVP describing possible access networks would
be defined as follow: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
issue, especially when intermediate nodes may be present between
Diameter endpoints.In the same line, AVPs of type Enumerated are too often used as a
simple Boolean flag, indicating for instance a specific permission or
capability, and therefore only two values are defined, e.g.,
TRUE/FALSE, AUTORIZED/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 AVP in which the data field would be
defined as 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 and the MIP6-Feature-Vector AVP defined in .As described in , 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 AVP 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 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 ( and ) 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 , with the answer
being sent to the source of the received request, using transaction
states and hop-by-hop identifier matching. In particular, 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. Application
designers SHOULD NOT modify the answer-routing principles described in
when defining a new application.As defined in , 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 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 NASREQ
Application ().However, it was acknowledged that such 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 NASREQ application specification [RFC4005bis], (see ) which deprecates the RFC4005 ().Therefore, protocol designers SHOULD NOT assume the availability of
a "standard" Diameter-to-RADIUS gateways 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.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 and the QoS-Capability AVP in .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 .
When supported, receivers of these AVPs can discover the additional
functionality supported by the Diameter end-point originating the
request and behave accordingly when processing the request. Senders of
these AVPs can safely assume the receiving end-point does not support
any functionality carried by the AVP if it is not present in
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 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 behaviour 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 .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: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 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, the use of this model is NOT
RECOMMENDED when all received accounting messages cannot be
clearly identified and sorted. For most cases, the use of Coupled
Accounting Model is RECOMMENDED. 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 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 into
account. An application MAY define a new set of commands to carry
application-specific accounting records but it is NOT RECOMMENDED to
do so.As specified in , the Diameter message
exchange SHOULD be secured between neighboring Diameter peers using
TLS/TCP or DTLS/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 ESP in transport mode with non-null
encryption and authentication algorithms MUST be used to provide
per-packet authentication, integrity protection and confidentiality,
and support the replay protection mechanisms of IPsec. IKEv2 SHOULD be used for performing mutual authentication
and for establishing and maintaining security associations (SAs).IKEv1 was used with RFC 3588 and for easier migration from IKEv1 based
implementations both RSA digital signatures and pre-shared keys SHOULD
be supported in IKEv2. However, if IKEv1 is used, implementers SHOULD
follow the guidelines given in Section 13.1 of RFC 3588 .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
), convey a specific set of priority parameters
influencing the distribution of resources (see ), and the support for QoS AVPs (see ).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: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 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.Protocol designers MUST ensure that their design
will not introduce undue restrictions for future
applications.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.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 IMS Cx/Dx
interfaces ( and ).As summarized in the Section 3 of this document and further described
in the Section 1.3 of , 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.The
specifications defining AVPs and AVP values MUST provide guidance
for defining new values and the corresponding policy for adding
these values. For example, the RFC 5777
defines the Treatment-Action AVP which contains a list of valid
values corresponding to pre-defined actions (drop, shape, mark,
permit). This set of values can be extended following the
Specification Required policy defined in .
As a second example, the Diameter base specification defines the Result-Code AVP that contains a
32-bit address space used to identity possible errors. According to
the Section 11.3.2 of , new values can be
assigned by IANA via an IETF Review process .Two
different types of AVP Codes namespaces can be used to create a new
AVPs: 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 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 Standard Action if the creation of
new AVP Flags is desired.Unlike the AVP Code 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;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.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-Serve basis.The IANA AAA parameters page can be found at
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml 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 .When the same
functionality/extension is used by more than one vendor, it is
RECOMMENDED to define a standard extension. Moreover, a
vendor-specific extension SHOULD be registered to avoid
interoperability issues in the same network. With this aim, the
registration policy of vendor-specific extension has been simplified
with the publication of and the namespace
reserved for vendor-specific extensions is large enough to avoid
exhaustion.This document does not require actions by IANA.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 guidance on enhancing Diameter with respect to security.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. Except the authors,
the design team members were:Avi LiorGlen ZornJari ArkkoJouni KorhonenMark JonesTolga AsverenGlenn McGregorDave FrasconeWe would like to thank Tolga Asveren, Glenn McGregor, and John
Loughney for their contributions as co-authors to earlier versions of
this document.We greatly appreciate the insight provided by Diameter implementers
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.3GPP TS 29.228; Technical Specification Group Core Network
and Terminals; IP Multimedia (IM) Subsystem Cx and Dx Interfaces;
Signalling flows and message contents3rd Generation Partnership
Project3GPP TS 29.229; Technical Specification Group Core Network
and Terminals; Cx and Dx interfaces based on the Diameter protocol;
Protocol details3rd Generation Partnership
Project3GPP TS 29.328; Technical Specification Group Core Network
and Terminals; IP Multimedia (IM) Subsystem Sh interface; signalling
flows and message content3rd Generation Partnership
Project3GPP TS 29.329; Technical Specification Group Core Network
and Terminals; Sh Interface based on the Diameter protocol; Protocol
details3rd Generation Partnership
ProjectITU-T Recommendation Q.3303.3, "Resource control protocol no.
3 (rcp3): Protocol at the Rw interface between the Policy Decision
Physical Entity (PD-PE) and the Policy Enforcement Physical Entity
(PE-PE): Diameter"3rd Generation Partnership
Project