< draft-ietf-dime-app-design-guide-25.txt   draft-ietf-dime-app-design-guide-26.txt >
Diameter Maintenance and Extensions (DIME) L. Morand, Ed. Diameter Maintenance and Extensions (DIME) L. Morand, Ed.
Internet-Draft Orange Labs Internet-Draft Orange Labs
Intended status: Best Current Practice V. Fajardo Intended status: Best Current Practice V. Fajardo
Expires: January 20, 2015 Independent Expires: February 17, 2015 Fluke Networks
H. Tschofenig H. Tschofenig
Nokia Siemens Networks ARM Ltd.
July 19, 2014 August 16, 2014
Diameter Applications Design Guidelines Diameter Applications Design Guidelines
draft-ietf-dime-app-design-guide-25 draft-ietf-dime-app-design-guide-26
Abstract Abstract
The Diameter base protocol provides facilities for protocol The Diameter base protocol provides facilities for protocol
extensibility enabling to define new Diameter applications or modify extensibility enabling to define new Diameter applications or modify
existing applications. This document is a companion document to the existing applications. This document is a companion document to the
Diameter Base protocol that further explains and clarifies the rules Diameter Base protocol that further explains and clarifies the rules
to extend Diameter. Furthermore, this document provides guidelines to extend Diameter. Furthermore, this document provides guidelines
to Diameter application designers reusing/defining Diameter to Diameter application designers reusing/defining Diameter
applications or creating generic Diameter extensions. applications or creating generic Diameter extensions.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 20, 2015. This Internet-Draft will expire on February 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Reusing Existing Diameter Applications . . . . . . . . . . . 5 4. Reusing Existing Diameter Applications . . . . . . . . . . . 5
4.1. Adding a New Command . . . . . . . . . . . . . . . . . . 5 4.1. Adding a New Command . . . . . . . . . . . . . . . . . . 6
4.2. Deleting an Existing Command . . . . . . . . . . . . . . 7 4.2. Deleting an Existing Command . . . . . . . . . . . . . . 7
4.3. Reusing Existing Commands . . . . . . . . . . . . . . . . 7 4.3. Reusing Existing Commands . . . . . . . . . . . . . . . . 7
4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 7 4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 7
4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . 9 4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . 9
4.3.3. Changing the Flags Setting of AVP in existing
Commands . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 10 4.4. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 10
4.4.1. Setting of the AVP Flags . . . . . . . . . . . . . . 10 4.4.1. Setting of the AVP Flags . . . . . . . . . . . . . . 10
4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 10 4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 11
5. Defining New Diameter Applications . . . . . . . . . . . . . 10 5. Defining New Diameter Applications . . . . . . . . . . . . . 11
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Defining New Commands . . . . . . . . . . . . . . . . . . 11 5.2. Defining New Commands . . . . . . . . . . . . . . . . . . 11
5.3. Use of Application-Id in a Message . . . . . . . . . . . 11 5.3. Use of Application-Id in a Message . . . . . . . . . . . 12
5.4. Application-Specific Session State Machines . . . . . . . 12 5.4. Application-Specific Session State Machines . . . . . . . 13
5.5. Session-Id AVP and Session Management . . . . . . . . . . 12 5.5. Session-Id AVP and Session Management . . . . . . . . . . 13
5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 13 5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 14
5.7. Application-Specific Message Routing . . . . . . . . . . 15 5.7. Application-Specific Message Routing . . . . . . . . . . 16
5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 15 5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 17
5.9. End-to-End Application Capabilities Exchange . . . . . . 16 5.9. End-to-End Application Capabilities Exchange . . . . . . 17
5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 17 5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 18
5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 18 5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 20
6. Defining Generic Diameter Extensions . . . . . . . . . . . . 19 6. Defining Generic Diameter Extensions . . . . . . . . . . . . 20
7. Guidelines for Registrations of Diameter Values . . . . . . . 20 7. Guidelines for Registrations of Diameter Values . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 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.
The Diameter base protocol provides facilities to extend Diameter The Diameter base protocol provides facilities to extend Diameter
(see Section 1.3 of [RFC6733]) to support new functionality. In the (see Section 1.3 of [RFC6733]) to support new functionality. In the
context of this document, extending Diameter means one of the context of this document, extending Diameter means one of the
following: following:
1. Addition of new functionality to an existing Diameter application 1. Addition of new functionality to an existing Diameter application
without defining a new application. without defining a new application.
2. Addition of new functionality to an existing Diameter application 2. Addition of new functionality to an existing Diameter application
that requires the definition of a new application. that requires the definition of a new application.
skipping to change at page 5, line 50 skipping to change at page 6, line 12
requirements and these modifications can be at the command level and/ requirements and these modifications can be at the command level and/
or at the AVP level. The following sections describe the possible or at the AVP level. The following sections describe the possible
modifications that can be performed on existing applications and modifications that can be performed on existing applications and
their related impact. their related impact.
4.1. Adding a New Command 4.1. Adding a New Command
Adding a new command to an existing application is considered as a Adding a new command to an existing application is considered as a
major extension and requires a new Diameter application to be major extension and requires a new Diameter application to be
defined, as stated in the Section 1.3.4 of [RFC6733]. The need for a defined, as stated in the Section 1.3.4 of [RFC6733]. The need for a
new application is due to the fact that a Diameter node not upgraded new application is because a Diameter node that is not upgraded to
to support the new application and therefore the new command will support the new command(s) within the (existing) application would
reject any unknown command with the protocol error reject any unknown command with the protocol error
DIAMETER_COMMAND_UNSUPPORTED and the transaction will fail. 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 Adding a new command means either defining a completely new command
or importing the command's Command Code Format (CCF) syntax from or importing the command's Command Code Format (CCF) syntax from
another application whereby the new application inherits some or all another application whereby the new application inherits some or all
of the functionality of the application where the command came from. of the functionality of the application where the command came from.
In the former case, the decision to create a new application is In the former case, the decision to create a new application is
straightforward since this is typically a result of adding a new straightforward since this is typically a result of adding a new
functionality that does not exist yet. For the latter, the decision functionality that does not exist yet. For the latter, the decision
to create a new application will depend on whether importing the to create a new application will depend on whether importing the
command in a new application is more suitable than simply using the command in a new application is more suitable than simply using the
skipping to change at page 7, line 14 skipping to change at page 7, line 23
4.2. Deleting an Existing Command 4.2. Deleting an Existing Command
Although this process is not typical, removing a command from an Although this process is not typical, removing a command from an
application requires a new Diameter application to be defined and application requires a new Diameter application to be defined and
then it is considered as a major extension. This is due to the fact then it is considered as a major extension. This is due to the fact
that the reception of the deleted command would systematically result that the reception of the deleted command would systematically result
in a protocol error (i.e., DIAMETER_COMMAND_UNSUPPORTED). in a protocol error (i.e., DIAMETER_COMMAND_UNSUPPORTED).
It is unusual to delete an existing command from an application for It is unusual to delete an existing command from an application for
the sake of deleting it or the functionality it represents. This the sake of deleting it or the functionality it represents. An
normally indicates of a flawed design. An exception might be if the exception might be if the intent of the deletion is to create a newer
intent of the deletion is to create a newer variance of the same variance of the same application that is somehow simpler than the
application that is somehow simpler than the application initially application initially specified.
specified.
4.3. Reusing Existing Commands 4.3. Reusing Existing Commands
This section discusses rules in adding and/or deleting AVPs from an This section discusses rules in adding and/or deleting AVPs from an
existing command of an existing application. The cases described in existing command of an existing application. The cases described in
this section may not necessarily result in the creation of new this section may not necessarily result in the creation of new
applications. applications.
From a historical point of view, it is worth to note that there was a From a historical point of view, it is worth to note that there was a
strong recommendation to re-use existing commands in the [RFC3588] to strong recommendation to re-use existing commands in the [RFC3588] to
prevent rapid depletion of code values available for vendor-specific prevent rapid depletion of code values available for vendor-specific
commands. However, [RFC6733] has relaxed the allocation policy and commands. However, [RFC6733] has relaxed the allocation policy and
enlarged the range of available code values for vendor-specific enlarged the range of available code values for vendor-specific
applications. Although reuse of existing commands is still applications. Although reuse of existing commands is still
RECOMMENDED, protocol designers MAY consider defining a new command RECOMMENDED, protocol designers can consider defining a new command
when it provides a solution more suitable than the twisting of an when it provides a solution more suitable than the twisting of an
existing command's use and applications. existing command's use and applications.
4.3.1. Adding AVPs to a Command 4.3.1. Adding AVPs to a Command
Based on the rules in [RFC6733], AVPs that are added to an existing Based on the rules in [RFC6733], AVPs that are added to an existing
command can be categorized into: command can be categorized into:
o Mandatory (to understand) AVPs. As defined in [RFC6733], these o Mandatory (to understand) AVPs. As defined in [RFC6733], these
are AVPs with the M-bit flag set in this command, which means that are AVPs with the M-bit flag set in this command, which means that
skipping to change at page 8, line 22 skipping to change at page 8, line 30
relevant to an application and each command within that relevant to an application and each command within that
application that includes the AVP. application that includes the AVP.
The rules are strict in the case where the AVPs to be added in an 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 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 M-bit set. A mandatory AVP MUST NOT be added to an existing command
without defining a new Diameter application, as stated in [RFC6733]. without defining a new Diameter application, as stated in [RFC6733].
This falls into the "Major Extensions" category. Despite the clarity This falls into the "Major Extensions" category. Despite the clarity
of the rule, ambiguity still arises when evaluating whether a new AVP of the rule, ambiguity still arises when evaluating whether a new AVP
being added should be mandatory to begin with. Application designers being added should be mandatory to begin with. Application designers
SHOULD consider the following questions when deciding about the M-bit should consider the following questions when deciding about the M-bit
for a new AVP: for a new AVP:
o Would it be required for the receiving side to be able to process o Would it be required for the receiving side to be able to process
and understand the AVP and its content? and understand the AVP and its content?
o Would the new AVPs change the state machine of the application? 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 o Would the presence of the new AVP lead to a different number of
round-trips, effectively changing the state machine of the round-trips, effectively changing the state machine of the
application? application?
o Would the new AVP be used to differentiate between old and new o Would the new AVP be used to differentiate between old and new
variances of the same application whereby the two variances are variances of the same application whereby the two variances are
not backward compatible? not backward compatible?
o Would the new AVP have duality in meaning, i.e., be used to carry 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 application-related information as well as to indicate that the
message is for a new application? message is for a new application?
If the answer to at least one of the questions is "yes" then the 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- M-bit MUST be set for the new AVP and a new Diameter application MUST
exhaustive and other criteria MAY be taken into account in the be defined. This list of questions is non-exhaustive and other
decision process. criteria MAY be taken into account in the decision process.
If application designers are instead contemplating the use of If application designers are instead contemplating the use of
optional AVPs, i.e., with the M-bit cleared, then the following are optional AVPs, i.e., with the M-bit cleared, there are still pitfalls
some of the pitfalls that SHOULD be avoided: that will cause interoperability problems and therefore must be
avoided. Some examples of these pitfalls are :
o Use of optional AVPs with intersecting meaning. One AVP has o Use of optional AVPs with intersecting meaning. One AVP has
partially the same usage and meaning as another AVP. The presence partially the same usage and meaning as another AVP. The presence
of both can lead to confusion. of both can lead to confusion.
o An optional AVPs with dual purpose, i.e., to carry application o An optional AVPs with dual purpose, i.e., to carry application
data as well as to indicate support for one or more features. data as well as to indicate support for one or more features.
This has a tendency to introduce interpretation issues. This has a tendency to introduce interpretation issues.
o Adding one or more optional AVPs and indicating (usually within o Adding one or more optional AVPs and indicating (usually within
descriptive text for the command) that at least one of them has to descriptive text for the command) that at least one of them has to
be present in the command. This essentially circumventing the be understood by the receiver of the command. This would be
ABNF and is equivalent to adding a mandatory AVP to the command. equivalent to adding a mandatory AVP, i.e., an AVP with the M-bit
set, to the command.
These practices generally result in interoperability issues and
SHOULD be avoided.
4.3.2. Deleting AVPs from a Command 4.3.2. Deleting AVPs from a Command
Application designers may want to reuse an existing command but some Application designers may want to reuse an existing command but some
of the AVP present in the command's CCF syntax specification may be of the AVP present in the command's CCF syntax specification may be
irrelevant for the functionality foreseen to be supported by this irrelevant for the functionality foreseen to be supported by this
command. It may be then tempting to delete those AVPs from the command. It may be then tempting to delete those AVPs from the
command. command.
The impacts of deleting an AVP from a command depends on its command The impacts of deleting an AVP from a command depends on its command
skipping to change at page 10, line 9 skipping to change at page 10, line 17
In this case, the AVP can be deleted without consequences. In this case, the AVP can be deleted without consequences.
Application designers SHOULD attempt the reuse the command's CCF Application designers SHOULD attempt the reuse the command's CCF
syntax specification without modification and simply ignore (but not syntax specification without modification and simply ignore (but not
delete) any optional AVP that will not be used. This is to maintain delete) any optional AVP that will not be used. This is to maintain
compatibility with existing applications that will not know about the compatibility with existing applications that will not know about the
new functionality as well as maintain the integrity of existing new functionality as well as maintain the integrity of existing
dictionaries. dictionaries.
4.3.3. Changing the Flags Setting 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, a AVP that was initially defined as
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 the section 4.3.1
apply.
All other AVP flags (V-bit, P-bit, reserved bits) MUST remain
unchanged.
4.4. Reusing Existing AVPs 4.4. Reusing Existing AVPs
This section discusses rules in reusing existing AVP when reusing an This section discusses rules in reusing existing AVP when reusing an
existing command or defining a new command in a new application. existing command or defining a new command in a new application.
4.4.1. Setting of the AVP Flags 4.4.1. Setting of the AVP Flags
When reusing existing AVPs in a new application, application When reusing existing AVPs in a new application, application
designers MUST specify the setting of the M-bit flag for a new designers MUST specify the setting of the M-bit flag for a new
Diameter application and, if necessary, for every command of the Diameter application and, if necessary, for every command of the
skipping to change at page 10, line 35 skipping to change at page 11, line 16
unchanged. unchanged.
4.4.2. Reuse of AVP of Type Enumerated 4.4.2. Reuse of AVP of Type Enumerated
When reusing an AVP of type Enumerated in a command for a new When reusing an AVP of type Enumerated in a command for a new
application, it is RECOMMENDED to avoid modifying the set of valid application, it is RECOMMENDED to avoid modifying the set of valid
values defined for this AVP. Modifying the set of Enumerated values values defined for this AVP. Modifying the set of Enumerated values
includes adding a value or deprecating the use of a value defined includes adding a value or deprecating the use of a value defined
initially for the AVP. Modifying the set of values will impact the initially for the AVP. Modifying the set of values will impact the
application defining this AVP and all the applications using this application defining this AVP and all the applications using this
AVP, causing potential interoperability issues. When the full range AVP, causing potential interoperability issues: a value used by a
of values defined for this Enumerated AVP is not suitable for the new 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 to define a new AVP to avoid backwards application, it is RECOMMENDED to define a new AVP to avoid backwards
compatibility issues with existing implementations. compatibility issues with existing implementations.
5. Defining New Diameter Applications 5. Defining New Diameter Applications
5.1. Introduction 5.1. Introduction
This section discusses the case where new applications have This section discusses the case where new applications have
requirements that cannot be fulfilled by existing applications and requirements that cannot be fulfilled by existing applications and
would require definition of completely new commands, AVPs and/or AVP would require definition of completely new commands, AVPs and/or AVP
skipping to change at page 11, line 14 skipping to change at page 11, line 45
Application designers SHOULD try to import existing AVPs and AVP Application designers SHOULD try to import existing AVPs and AVP
values for any newly defined commands. In certain cases where values for any newly defined commands. In certain cases where
accounting will be used, the models described in Section 5.10 SHOULD accounting will be used, the models described in Section 5.10 SHOULD
also be considered. also be considered.
Additional considerations are described in the following sections. Additional considerations are described in the following sections.
5.2. Defining New Commands 5.2. Defining New Commands
As a general recommendation, commands SHOULD not be defined from As a general recommendation, commands SHOULD NOT be defined from
scratch. It is instead RECOMMENDED to re-use an existing command scratch. It is instead RECOMMENDED to re-use an existing command
offering similar functionality and use it as a starting point. Code offering similar functionality and use it as a starting point. Code
re-use lead to a smaller implementation effort as well as reduce the re-use lead to a smaller implementation effort as well as reduce the
need for testing. need for testing.
Moreover, the new command's CCF syntax specification SHOULD be Moreover, the new command's CCF syntax specification SHOULD be
carefully defined when considering applicability and extensibility of carefully defined when considering applicability and extensibility of
the application. If most of the AVPs contained in the command are the application. If most of the AVPs contained in the command are
indicated as fixed or required, it might be difficult to reuse the indicated as fixed or required, it might be difficult to reuse the
same command and therefore the same application in a slightly changed same command and therefore the same application in a slightly changed
environment. Defining a command with most of the AVPs indicated as environment. Defining a command with most of the AVPs indicated as
optional MUST NOT be seen as a sub-optimal design introducing too optional is considered as a good design choice in many cases, despite
much flexibility in the protocol. The protocol designers SHOULD only the flexibility it introduces in the protocol. Protocol designers
clearly state the condition of presence of these AVPs and properly MUST clearly state the reasons why these optional AVPs might or might
define the corresponding behaviour of the Diameter nodes when these not be present and properly define the corresponding behavior of the
AVPs are absent from the command. Diameter nodes when these AVPs are absent from the command.
NOTE: As a hint for protocol designers, it is not sufficient to just NOTE: As a hint for protocol designers, it is not sufficient to just
look at the command's CCF syntax specification. It is also look at the command's CCF syntax specification. It is also
necessary to carefully read through the accompanying text in the necessary to carefully read through the accompanying text in the
specification. specification.
In the same way, the CCF syntax specification SHOULD be defined such 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 that it will be possible to add any arbitrary optional AVPs with the
M-bit cleared (including vendor-specific AVPs) without modifying the M-bit cleared (including vendor-specific AVPs) without modifying the
application. For this purpose, "* [AVP]" SHOULD be added in the application. For this purpose, "* [AVP]" SHOULD be added in the
skipping to change at page 12, line 4 skipping to change at page 12, line 35
5.3. Use of Application-Id in a Message 5.3. Use of Application-Id in a Message
When designing new applications, application designers SHOULD specify When designing new applications, application designers SHOULD specify
that the Application Id carried in all session-level messages is the that the Application Id carried in all session-level messages is the
Application Id of the application using those messages. This Application Id of the application using those messages. This
includes the session-level messages defined in Diameter base includes the session-level messages defined in Diameter base
protocol, i.e., RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the protocol, i.e., RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the
coupled accounting model, see Section 5.10. Some existing coupled accounting model, see Section 5.10. Some existing
specifications do not adhere to this rule for historical reasons. specifications do not adhere to this rule for historical reasons.
However, this guidance SHOULD be followed by new applications to However, this guidance SHOULD be followed by new applications to
avoid routing problems. avoid routing problems.
When a new application has been allocated with a new Application Id When a new application has been allocated with a new Application Id
and it also reuses existing commands with or without modifications, and it also reuses existing commands with or without modifications,
the commands SHOULD use the newly allocated Application Id in the the commands SHOULD use the newly allocated Application Id in the
header and in all relevant Application Id AVPs (Auth-Application-Id header and in all relevant Application Id AVPs (Auth-Application-Id
or Acct-Application-Id) present in the commands message body. or Acct-Application-Id) present in the commands message body.
Additionally, application designers using Vendor-Specific- Additionally, application designers using Vendor-Specific-
Application-Id AVP SHOULD not use the Vendor-Id AVP to further Application-Id AVP SHOULD NOT use the Vendor-Id AVP to further
dissect or differentiate the vendor-specification Application Id. dissect or differentiate the vendor-specification Application Id.
Diameter routing is not based on the Vendor-Id. As such, the Vendor- 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 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 of messages. The Vendor-Id AVP is an informational AVP only and kept
for backward compatibility reasons. for backward compatibility reasons.
5.4. Application-Specific Session State Machines 5.4. Application-Specific Session State Machines
Section 8 of [RFC6733] provides session state machines for Section 8 of [RFC6733] provides session state machines for
authentication, authorization and accounting (AAA) services and these authentication, authorization and accounting (AAA) services and these
session state machines are not intended to cover behavior outside of session state machines are not intended to cover behavior outside of
AAA. If a new application cannot clearly be categorized into any of AAA. If a new application cannot clearly be categorized into any of
these AAA services, it is RECOMMENDED that the application defines these AAA services, it is RECOMMENDED that the application defines
skipping to change at page 13, line 23 skipping to change at page 14, line 7
appraise whether the application currently defined relies on its own appraise whether the application currently defined relies on its own
session management concept or whether the Session-Id defined in the session management concept or whether the Session-Id defined in the
Diameter base protocol would be used for correlation of messages Diameter base protocol would be used for correlation of messages
related to the same session. If not, the protocol designers MAY related to the same session. If not, the protocol designers MAY
decide to define application commands without the Session-Id AVP. If decide to define application commands without the Session-Id AVP. If
any session management concept is supported by the application, the any session management concept is supported by the application, the
application documentation MUST clearly specify how the session is application documentation MUST clearly specify how the session is
handled between client and server (as possibly Diameter agents in the handled between client and server (as possibly Diameter agents in the
path). path).
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].
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 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 5.6. Use of Enumerated Type AVPs
The type Enumerated was initially defined to provide a list of valid The type Enumerated was initially defined to provide a list of valid
values for an AVP with their respective interpretation described in values for an AVP with their respective interpretation described in
the specification. For instance, AVPs of type Enumerated can be used the specification. For instance, AVPs of type Enumerated can be used
to provide further information on the reason for the termination of a to provide further information on the reason for the termination of a
session or a specific action to perform upon the reception of the session or a specific action to perform upon the reception of the
request. request.
As described in the section 4.4.2 above, defining an AVP of type As described in the section 4.4.2 above, defining an AVP of type
skipping to change at page 13, line 45 skipping to change at page 15, line 4
definition of the AVP of type Enumerated cannot be modified in definition of the AVP of type Enumerated cannot be modified in
practice without causing backward compatibility issues with existing practice without causing backward compatibility issues with existing
implementations. As a consequence, AVPs of Type Enumerated MUST NOT implementations. As a consequence, AVPs of Type Enumerated MUST NOT
be extended by adding new values to support new capabilities. be extended by adding new values to support new capabilities.
Diameter protocol designers SHOULD carefully consider before defining Diameter protocol designers SHOULD carefully consider before defining
an Enumerated AVP whether the set of values will remain unchanged or 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 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 foreseen or cannot be avoided, it is RECOMMENED to rather define AVPs
of type Unsigned32 or Unsigned64 in which the data field would of type Unsigned32 or Unsigned64 in which the data field would
contain an address space representing "values" that would have the contain an address space representing "values" that would have the
same use of Enumerated values. 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 interoperability issues for intermediary nodes between
clients and servers. Only clients and servers will be able to
process the values at the application layer.
For illustration, an AVP describing possible access networks would be For illustration, an AVP describing possible access networks would be
defined as follow: defined as follow:
Access-Network-Type AVP (XXX) is of type Unsigned32 and contains a Access-Network-Type AVP (XXX) is of type Unsigned32 and contains a
32-bit address space representing types of access networks. This 32-bit address space representing types of access networks. This
application defines the following classes of access networks, all application defines the following classes of access networks, all
identified by the thousands digit in the decimal notation: identified by the thousands digit in the decimal notation:
o 1xxx (Mobile Access Networks) o 1xxx (Mobile Access Networks)
o 2xxx (Fixed Access Network) o 2xxx (Fixed Access Network)
o 3xxx (Wireless Access Networks) o 3xxx (Wireless Access Networks)
Values that fall within the Mobile Access Networks category are used 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 to inform a peer that a request has been sent for a user attached to
a mobile access networks. The following values are defined in this a mobile access network. The following values are defined in this
application: application:
1001: 3GPP-GERAN 1001: 3GPP-GERAN
TBD. The user is attached to a GSM EDGE Radio Access Network.
1002: 3GPP-UTRAN-FDD 1002: 3GPP-UTRAN-FDD
TBD. The user is attached to a UMTS access network that uses
frequency-division duplexing for duplexing.
Unlike Enumerated AVP, any new value can be added in the address Unlike Enumerated AVP, any new value can be added in the address
space defined by this Unsigned32 AVP without modifying the definition space defined by this Unsigned32 AVP without modifying the definition
of the AVP. There is therefore no risk of backward compatibility of the AVP. There is therefore no risk of backward compatibility
issue, especially when intermediate nodes may be present between issue, especially when intermediate nodes may be present between
Diameter endpoints. Diameter endpoints.
In the same line, AVPs of type Enumerated are too often used as a In the same line, AVPs of type Enumerated are too often used as a
simple Boolean flag, indicating for instance a specific permission or simple Boolean flag, indicating for instance a specific permission or
capability, and therefore only two values are defined, e.g., TRUE/ capability, and therefore only two values are defined, e.g., TRUE/
skipping to change at page 15, line 38 skipping to change at page 16, line 49
Examples of such application-specific routing functions can be found Examples of such application-specific routing functions can be found
in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP IP in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP IP
Multimedia Subsystem, in which the proxy agent (Subscriber Location Multimedia Subsystem, in which the proxy agent (Subscriber Location
Function aka SLF) uses specific application-level identities found in Function aka SLF) uses specific application-level identities found in
the request to determine the final destination of the message. the request to determine the final destination of the message.
Whatever the criteria used to establish the routing path of the Whatever the criteria used to establish the routing path of the
request, the routing of the answer MUST follow the reverse path of 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 request, as described in [RFC6733], with the answer being sent to
the source of the received request, using transaction states and hop- the source of the received request, using transaction states and hop-
by-hop identifier matching. In particular, this ensures that the by-hop identifier matching. This ensures that the Diameter Relay or
Diameter Relay or Proxy agents in the request routing path will be Proxy agents in the request routing path will be able to release the
able to release the transaction state upon receipt of the transaction state upon receipt of the corresponding answer, avoiding
corresponding answer, avoiding unnecessary failover. Application unnecessary failover. Moreover, especially in roaming cases, proxy
designers SHOULD NOT modify the answer-routing principles described agents in the path must be able to apply local policies when
in [RFC6733] when defining a new application. 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
sessions. Therefore, application designers MUST NOT modify the
answer-routing principles described in [RFC6733] when defining a new
application.
5.8. Translation Agents 5.8. Translation Agents
As defined in [RFC6733], a translation agent is a device that As defined in [RFC6733], a translation agent is a device that
provides interworking between Diameter and another AAA protocol, such provides interworking between Diameter and another AAA protocol, such
as RADIUS . as RADIUS .
In the case of RADIUS, it was initially thought that defining the In the case of RADIUS, it was initially thought that defining the
translation function would be straightforward by adopting few basic translation function would be straightforward by adopting few basic
principles, e.g., by the use of a shared range of code values for principles, e.g., by the use of a shared range of code values for
skipping to change at page 18, line 38 skipping to change at page 20, line 11
* The system architecture or deployment requires that the * The system architecture or deployment requires that the
accounting service for the specific application should be accounting service for the specific application should be
handled by the application itself. handled by the application itself.
In all cases above, there will generally be no direct Diameter In all cases above, there will generally be no direct Diameter
access to the accounting server. access to the accounting server.
These models provide a basis for using accounting messages. These models provide a basis for using accounting messages.
Application designers may obviously deviate from these models Application designers may obviously deviate from these models
provided that the factors being addressed here have also been taken provided that the factors being addressed here have also been taken
into account. An application MAY define a new set of commands to into account. Defining a new set of commands to carry application-
carry application-specific accounting records but it is NOT specific accounting records is NOT RECOMMENDED.
RECOMMENDED to do so.
5.11. Diameter Security Mechanisms 5.11. Diameter Security Mechanisms
As specified in [RFC6733], the Diameter message exchange SHOULD be As specified in [RFC6733], the Diameter message exchange SHOULD be
secured between neighboring Diameter peers using TLS/TCP or DTLS/ secured between neighboring Diameter peers using TLS/TCP or DTLS/
SCTP. However, IPsec MAY also be deployed to secure communication SCTP. However, IPsec MAY also be deployed to secure communication
between Diameter peers. When IPsec is used instead of TLS or DTLS, between Diameter peers. When IPsec is used instead of TLS or DTLS,
the following recommendations apply. the following recommendations apply.
IPsec ESP [RFC4301] in transport mode with non-null encryption and IPsec ESP [RFC4301] in transport mode with non-null encryption and
skipping to change at page 20, line 22 skipping to change at page 21, line 41
In practice, generic extensions often use optional AVPs because they In practice, generic extensions often use optional AVPs because they
are simple and non-intrusive to the application that would carry are simple and non-intrusive to the application that would carry
them. Peers that do not support the generic extensions need not them. Peers that do not support the generic extensions need not
understand nor recognize these optional AVPs. However, it is understand nor recognize these optional AVPs. However, it is
RECOMMENDED that the authors of the extension specify the context or 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 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 can be used only by a specific set of applications then the
specification MUST enumerate these applications and the scenarios specification MUST enumerate these applications and the scenarios
when the optional AVPs will be used. In the case where the optional 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 AVPs can be carried by any application, it should be sufficient to
specify such a use case and perhaps provide specific examples of specify such a use case and perhaps provide specific examples of
applications using them. applications using them.
In most cases, these optional AVPs piggybacked by applications would In most cases, these optional AVPs piggybacked by applications would
be defined as a Grouped AVP and it would encapsulate all the be defined as a Grouped AVP and it would encapsulate all the
functionality of the generic extension. In practice, it is not functionality of the generic extension. In practice, it is not
uncommon that the Grouped AVP will encapsulate an existing AVP that uncommon that the Grouped AVP will encapsulate an existing AVP that
has previously been defined as mandatory ('M'-bit set) e.g., 3GPP IMS has previously been defined as mandatory ('M'-bit set) e.g., 3GPP IMS
Cx/Dx interfaces ([TS29.228] and [TS29.229]). Cx/Dx interfaces ([TS29.228] and [TS29.229]).
skipping to change at page 22, line 4 skipping to change at page 23, line 22
allocated on a First-Come/First-Served basis; allocated on a First-Come/First-Served basis;
* A range of values reserved only for experimental and testing * A range of values reserved only for experimental and testing
purposes. purposes.
As for AVP Flags, the remaining bits of the Command Flags field of As for AVP Flags, the remaining bits of the Command Flags field of
the Diameter header are also assigned via a Standards Action to the Diameter header are also assigned via a Standards Action to
create new Command Flags if required. create new Command Flags if required.
d. Creating new applications d. Creating new applications
Similarly to the Command Code namespace, the Application-Id Similarly to the Command Code namespace, the Application-Id
namespace is flat but divided into two distinct ranges: namespace is flat but divided into two distinct ranges:
* A range of values reserved for standard Application-Ids * A range of values reserved for standard Application-Ids
allocated after Expert Review of the specification defining the allocated after Expert Review of the specification defining the
standard application; standard application;
* A range for values for vendor specific applications, allocated * A range for values for vendor specific applications, allocated
by IANA on a First-Come/First-Serve basis. by IANA on a First-Come/First-Serve basis.
The IANA AAA parameters page can be found at The IANA AAA parameters page can be found at
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml and http://www.iana.org/assignments/aaa-parameters and the enterprise
the enterprise number IANA page is available at number IANA page is available at http://www.iana.org/assignments/
http://www.iana.org/assignments/enterprise-numbers. More details on enterprise-numbers. More details on the policies followed by IANA
the policies followed by IANA for namespace management (e.g. First- for namespace management (e.g. First-Come/First-Served, Expert
Come/First-Served, Expert Review, IETF Review, etc.) can be found in Review, IETF Review, etc.) can be found in [RFC5226].
[RFC5226].
NOTE: NOTE:
When the same functionality/extension is used by more than one When the same functionality/extension is used by more than one
vendor, it is RECOMMENDED to define a standard extension. vendor, it is RECOMMENDED to define a standard extension.
Moreover, a vendor-specific extension SHOULD be registered to Moreover, a vendor-specific extension SHOULD be registered to
avoid interoperability issues in the same network. With this aim, avoid interoperability issues in the same network. With this aim,
the registration policy of vendor-specific extension has been the registration policy of vendor-specific extension has been
simplified with the publication of [RFC6733] and the namespace simplified with the publication of [RFC6733] and the namespace
reserved for vendor-specific extensions is large enough to avoid reserved for vendor-specific extensions is large enough to avoid
exhaustion. exhaustion.
8. IANA Considerations 8. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
9. Security Considerations 9. Security Considerations
This document provides guidelines and considerations for extending This document provides guidelines and considerations for extending
Diameter and Diameter applications. Although such an extension may Diameter and Diameter applications. Although such an extension may
be related to a security functionality, the document does not be related to a security functionality, the document does not
explicitly give guidance on enhancing Diameter with respect to explicitly give additional guidance on enhancing Diameter with
security. respect to security. However, as a general guideline, it is
recommended that any Diameter extension SHOULD NOT break the security
concept given in the [RFC6733]. In particular, it is reminded 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 TLS, DTLS, or IPsec [RFC4301]. When
defining a new Diameter extension, any possible impact of the
existing security principles described in the [RFC6733] MUST be
carefully appraised and documented in the Diameter application
specification.
10. Contributors 10. Contributors
The content of this document was influenced by a design team created The content of this document was influenced by a design team created
to revisit the Diameter extensibility rules. The team was formed in to revisit the Diameter extensibility rules. The team was formed in
February 2008 and finished its work in June 2008. Except the February 2008 and finished its work in June 2008. Except the
authors, the design team members were: authors, the design team members were:
o Avi Lior o Avi Lior
o Glen Zorn o Glen Zorn
o Jari Arkko o Jari Arkko
o Jouni Korhonen o Jouni Korhonen
o Mark Jones o Mark Jones
o Tolga Asveren o Tolga Asveren
skipping to change at page 24, line 28 skipping to change at page 26, line 9
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
Canales-Valenzuela, C., and K. Tammi, "Diameter Session Canales-Valenzuela, C., and K. Tammi, "Diameter Session
Initiation Protocol (SIP) Application", RFC 4740, November Initiation Protocol (SIP) Application", RFC 4740, November
2006. 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
and K. Chowdhury, "Diameter Mobile IPv6: Support for and K. Chowdhury, "Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction", RFC Network Access Server to Diameter Server Interaction", RFC
5447, February 2009. 5447, February 2009.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
and A. Lior, "Traffic Classification and Quality of and A. Lior, "Traffic Classification and Quality of
Service (QoS) Attributes for Diameter", RFC 5777, February Service (QoS) Attributes for Diameter", RFC 5777, February
2010. 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010. 5996, September 2010.
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC6735] Carlberg, K. and T. Taylor, "Diameter Priority Attribute- [RFC6735] Carlberg, K. and T. Taylor, "Diameter Priority Attribute-
Value Pairs", RFC 6735, October 2012. Value Pairs", RFC 6735, October 2012.
[RFC7075] Tsou, T., Hao, R., and T. Taylor, "Realm-Based Redirection [RFC7075] Tsou, T., Hao, R., and T. Taylor, "Realm-Based Redirection
In Diameter", RFC 7075, November 2013. In Diameter", RFC 7075, November 2013.
[RFC7155] Zorn, G., "Diameter Network Access Server Application", [RFC7155] Zorn, G., "Diameter Network Access Server Application",
RFC 7155, April 2014. RFC 7155, April 2014.
[TS29.228] [TS29.228]
skipping to change at page 25, line 45 skipping to change at page 27, line 31
Lionel Morand (editor) Lionel Morand (editor)
Orange Labs Orange Labs
38/40 rue du General Leclerc 38/40 rue du General Leclerc
Issy-Les-Moulineaux Cedex 9 92794 Issy-Les-Moulineaux Cedex 9 92794
France France
Phone: +33145296257 Phone: +33145296257
Email: lionel.morand@orange.com Email: lionel.morand@orange.com
Victor Fajardo Victor Fajardo
Independent Fluke Networks
Email: vf0213@gmail.com Email: vf0213@gmail.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks ARM Ltd.
Linnoitustie 6 Hall in Tirol 6060
Espoo 02600 Austria
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 43 change blocks. 
88 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/