< draft-ietf-dime-app-design-guide-14.txt   draft-ietf-dime-app-design-guide-15.txt >
Diameter Maintenance and Extensions L. Morand, Ed. Diameter Maintenance and Extensions L. Morand, Ed.
(DIME) Orange Labs (DIME) Orange Labs
Internet-Draft V. Fajardo Internet-Draft V. Fajardo
Intended status: Informational Intended status: Informational
Expires: October 3, 2012 H. Tschofenig Expires: January 31, 2013 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
April 1, 2012 July 30, 2012
Diameter Applications Design Guidelines Diameter Applications Design Guidelines
draft-ietf-dime-app-design-guide-14 draft-ietf-dime-app-design-guide-15
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 the Diameter Base protocol. It is meant as a guidelines to extend the Diameter Base protocol. It is meant as a guidelines
document and therefore it does not add, remove or change existing document and therefore it does not add, remove or change existing
rules. rules.
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 October 3, 2012. This Internet-Draft will expire on January 31, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Reusing existing Diameter applications . . . . . . . . . . . . 8 4. Reusing existing Diameter applications . . . . . . . . . . . . 8
4.1. Adding a new command . . . . . . . . . . . . . . . . . . . 8 4.1. Adding a new command . . . . . . . . . . . . . . . . . . . 8
4.2. Deleting a command . . . . . . . . . . . . . . . . . . . . 9 4.2. Deleting a command . . . . . . . . . . . . . . . . . . . . 9
4.3. Reusing existing commands . . . . . . . . . . . . . . . . 9 4.3. Reusing existing commands . . . . . . . . . . . . . . . . 9
4.3.1. Adding AVPs to a command . . . . . . . . . . . . . . . 10 4.3.1. Adding AVPs to a ommand . . . . . . . . . . . . . . . 9
4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . . 11 4.3.2. Deleting AVPs from a command . . . . . . . . . . . . . 11
4.4. Reusing existing AVPs . . . . . . . . . . . . . . . . . . 12 4.4. Reusing existing AVPs . . . . . . . . . . . . . . . . . . 12
4.4.1. Setting of the AVP flags . . . . . . . . . . . . . . . 12 4.4.1. Setting of the AVP flags . . . . . . . . . . . . . . . 12
4.4.2. Reuse of AVP of type Enumerated . . . . . . . . . . . 12 4.4.2. Reuse of AVP of type Enumerated . . . . . . . . . . . 12
5. Rules for new Applications . . . . . . . . . . . . . . . . . . 13 5. Defining new Diameter applications . . . . . . . . . . . . . . 13
5.1. Use of Application-Id in a Message . . . . . . . . . . . . 13 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Application Specific Session State Machine . . . . . . . . 14 5.2. Defining new commands . . . . . . . . . . . . . . . . . . 13
6. End-to-End Applications Capabilities Exchange . . . . . . . . 15 5.3. Use of Application-Id in a message . . . . . . . . . . . . 14
7. Diameter Accounting Support . . . . . . . . . . . . . . . . . 16 5.4. Application specific Session State Machine . . . . . . . . 14
8. Generic Diameter Extensions . . . . . . . . . . . . . . . . . 18 5.5. Session-Id AVP and session management . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5.6. AVPs defined as Boolean flag . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5.7. Application-specific message routing . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.8. About Translation Agent . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 5.9. End-to-End applications capabilities exchange . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.10. Diameter accounting support . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 5.11. Diameter security mechanisms . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . . 24 6. Defining Generic Diameter Extensions . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The Diameter Base protocol provides facilities to extend the Diameter The Diameter Base protocol provides facilities to extend the Diameter
Base protocol (see Section 1.3 of [I-D.ietf-dime-rfc3588bis]) for Base protocol (see Section 1.3 of [I-D.ietf-dime-rfc3588bis]) for
supporting new functionalities. In the context of this document, supporting new functionalities. In the context of this document,
extending Diameter means one of the following: extending Diameter means one of the following:
1. Addition of a new functionality to an existing Diameter 1. Addition of a new functionality to an existing Diameter
application without defining a new application. application without defining a new application.
2. Addition of a new functionality to an existing Diameter 2. Addition of a new functionality to an existing Diameter
application that requires the definition of a new application. application that requires the definition of a new application.
3. The definition of a new Diameter application to provide a set of 3. The definition of a new Diameter application to provide a set of
functionalities not supporting by existing applications. functionalities not supported by existing applications.
4. The definition of a new generic functionality that can be reused 4. The definition of a new generic functionality that can be reused
across different applications. across different applications.
All of these choices are design decisions that can done by any All of these choices are design decisions that can be done by any
combination of reusing existing or defining new commands, AVPs or AVP combination of reusing existing or defining new commands, AVPs or AVP
values. Protocol designers do, however, not have total freedom when values. However, application designers do not have total freedom
making their design. A number of rules defined in when making their design. A number of rules have been defined in
[I-D.ietf-dime-rfc3588bis] place constraints on when an extension [I-D.ietf-dime-rfc3588bis] and place constraints on when an extension
demands a new Diameter application to be defined or a new command requires the allocation of a new Diameter application identifier or a
code to be registered. The objective of this document is the new command code value. The objective of this document is the
following: following:
o Clarify updated Diameter extensibility rules in the Diameter Base o Clarify updated Diameter extensibility rules in the Diameter Base
Protocol. Protocol.
o Clarify usage of certain Diameter functionalities that are not o Clarify usage of certain Diameter functionalities that are not
explicitly described in the Diameter Base specification. explicitly described in the Diameter Base specification.
o Discuss design choices and provide guidelines when defining o Discuss design choices and provide guidelines when defining new
applications. applications.
o Present tradeoffs of design choices. o Present tradeoffs of design choices.
2. Terminology 2. Terminology
This document reuses the terminology used in This document reuses the terminology used in
[I-D.ietf-dime-rfc3588bis]. [I-D.ietf-dime-rfc3588bis].
3. Overview 3. Overview
As designed, the Diameter Base protocol can be seen as a two-layer As designed, the Diameter Base protocol [I-D.ietf-dime-rfc3588bis]
protocol. The lower layer is mainly responsible for managing can be seen as a two-layer protocol. The lower layer is mainly
connections between neighboring peers and for message routing. The responsible for managing connections between neighboring peers and
upper layer is where the Diameter applications reside. This model is for message routing. The upper layer is where the Diameter
in line with a Diameter node having an application layer and a peer- applications reside. This model is in line with a Diameter node
to-peer delivery layer. The Diameter Base protocol document having an application layer and a peer-to-peer delivery layer. The
completely defines the architecture and behavior of the message Diameter Base protocol document defines the architecture and behavior
delivery layer and then provides the framework for designing Diameter of the message delivery layer and then provides the framework for
applications on the application layer. This framework includes designing Diameter applications on the application layer. This
definitions of application sessions and accounting support (see framework includes definitions of application sessions and accounting
Section 8 and 9 of [I-D.ietf-dime-rfc3588bis]). The remainder of support (see Section 8 and 9 of [I-D.ietf-dime-rfc3588bis]).
this document also treats a Diameter node as a single instance of a Accordingly, a Diameter node is seen in this document as a single
Diameter message delivery layer and one or more Diameter applications instance of a Diameter message delivery layer and one or more
using it. Diameter applications using it.
The Diameter protocol is designed to be extensible and the principles The Diameter Base protocol is designed to be extensible and the
are descibed in the section 1.3 of [I-D.ietf-dime-rfc3588bis]. principles are described in the section 1.3 of
Extending Diameter can mean the definition of a new Diameter [I-D.ietf-dime-rfc3588bis]. Extending Diameter can mean either the
application and/or the reuse of commands, AVPs and AVP values in any definition of a completly new Diameter application or the reuse of
combination for the purpose of inheriting the features of an existing commands, AVPs and AVP values in any combination for the purpose of
Diameter application. The reuse recommendation is meaningful as most inheriting the features of an existing Diameter application. The
of the requirements defined for a new application are likely already recommendation for re-using as much as possible existing
fulfilled by an existing application. implementations is meaningful as most of the requirements defined for
a new application are likely already fulfilled by existing
applications.
However, when reusing existing applications, there is a greater However, when reusing existing applications, there is a greater
likelihood of ambiguity on how much of the existing application can likelihood of ambiguity on how much of the existing application can
be enhanced without being distorted too much and therefore requiring be enhanced without being distorted too much and therefore requiring
the definition of a new application. the definition of a new application.
The impacts of extending existing applications can be categorized as The impacts of extending existing applications can be categorized as
follow: follow:
Minor Extension: Enhancing the functional scope of an existing Minor Extension: Enhancing the functional scope of an existing
application by the addition of optional features to support. Such application by the addition of optional features to support. Such
enhancement has no backward compatibility issue with the existing enhancement has no backward compatibility issue with the existing
application. A typical example would be the definition of a new application. A typical example would be the definition of a new
optional AVP to use in an existing command. In general, this optional AVP to use in an existing command. Diameter
includes everything that is not covered by the next category. The implementations supporting the existing application but not the
standardization effort will be fairly small. new AVP will simply ignore it, without major consequences on the
Diameter message handling. In general, this includes everything
that is not covered by the next category. The standardization
effort will be fairly small.
Major Extension: Enhancing the functional scope of an existing Major Extension: Enhancing the functional scope of an existing
application in such a way that this implies backward compatible application in such a way that this implies backward compatible
change to the existing application and then requires the change to the existing application and then requires the
definition of a new Diameter application. A typical example would definition of a new Diameter application. Typical examples would
be the creation of a new command for providing functionality not be the creation of a new command for providing functionality not
supported by existing applications. For such extension, a supported by existing applications or the definition of a new AVP
significant specification effort is required and a carefull with M-bit set to carry in an existing command. For such
approach is recommended. extension, a significant specification effort is required and a
careful approach is recommended.
The rules outlined in the section 1.3 of [I-D.ietf-dime-rfc3588bis] The rules outlined in the section 1.3 of [I-D.ietf-dime-rfc3588bis]
indicate when an extension requires a new command code to be indicate when an extension requires a new command code to be
registered and when new Diameter applications have to be defined. registered and when new Diameter applications have to be defined.
The subsequent sections further explain and clarify the rules to The subsequent sections further explain and clarify the rules to
extend the Diameter Base protocol. It is meant as a guidelines extend the Diameter Base protocol. It is meant as a guidelines
document and therefore it does not add, remove or change existing document and therefore it does not add, remove or change existing
rules. rules.
4. Reusing existing Diameter applications 4. Reusing existing Diameter applications
skipping to change at page 9, line 7 skipping to change at page 9, line 7
applied. Before adding or importing a command, application designers applied. Before adding or importing a command, application designers
should consider the following: should consider the following:
o Can the new functionality be fulfilled by creating a new command o Can the new functionality be fulfilled by creating a new command
independent from any existing command? In this case, the independent from any existing command? In this case, the
resulting new application and the existing application can work resulting new application and the existing application can work
independent of, but cooperating with each other. independent of, but cooperating with each other.
o Can the existing command be reused without major extensions and o Can the existing command be reused without major extensions and
therefore without the need for the definition of a new therefore without the need for the definition of a new
application, e.g. new funtionality introduced by the creation of application, e.g. new functionality introduced by the creation of
new optional AVPs. new optional AVPs.
o Care should be taken to avoid a liberal method of importing o Care should be taken to avoid a liberal method of importing
existing command's CCF syntax specification. This would result in existing command's CCF syntax specification. This would result in
a monolithic and hard to manage applications supporting too many a monolithic and hard to manage applications supporting too many
different functionalities and can cause interoperability issues different functionalities and can cause interoperability issues
between the different applications. . between the different applications. .
4.2. Deleting a command 4.2. Deleting a command
skipping to change at page 9, line 46 skipping to change at page 9, line 46
It is worth to note that the strong recommendation to re-use existing It is worth to note that the strong recommendation to re-use existing
commands in the [RFC3588] was to prevent rapid scarcity of code commands in the [RFC3588] was to prevent rapid scarcity of code
values available for vendor-specific commands. values available for vendor-specific commands.
[I-D.ietf-dime-rfc3588bis] relaxes the policy with respect to the [I-D.ietf-dime-rfc3588bis] relaxes the policy with respect to the
allocation of command codes for vendor-specific uses and enlarges the allocation of command codes for vendor-specific uses and enlarges the
range of available code values for vendor-specific applications. range of available code values for vendor-specific applications.
Therefore, if it is still recommended to re-use as much as possible Therefore, if it is still recommended to re-use as much as possible
existing commands, protocol designers can consider more easily the existing commands, protocol designers can consider more easily the
definition of a new command when it is a solution more suitable than definition of a new command when it is a solution more suitable than
twisting existings command use and applications. twisting existing command use and applications.
4.3.1. Adding AVPs to a command 4.3.1. Adding AVPs to a ommand
Based on the rules in [I-D.ietf-dime-rfc3588bis], AVPs that are added Based on the rules in [I-D.ietf-dime-rfc3588bis], AVPs that are added
to an existing command can be categorized into: to an existing command can be categorized into:
o Mandatory (to understand) AVPs. As defined in o Mandatory (to understand) AVPs. As defined in
[I-D.ietf-dime-rfc3588bis], these are AVPs with the M-bit flag [I-D.ietf-dime-rfc3588bis], these are AVPs with the M-bit flag
set, which means that a Diameter node receiving are required to set, which means that a Diameter node receiving are required to
understand not only their values but their semantics. Failure to understand not only their values but their semantics. Failure to
do so will cause an message handling error. This is regardless of do so will cause an message handling error. This is regardless of
whether these AVPs are required or optional as specified by the whether these AVPs are required or optional as specified by the
skipping to change at page 11, line 32 skipping to change at page 11, line 22
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 present in the command. This essentially circumventing the
ABNF and is equivalent to adding a mandatory AVPs to the command. ABNF and is equivalent to adding a mandatory AVPs to the command.
These practices generally result in interoperability issues and These practices generally result in interoperability issues and
should be avoided as much as possible. should be avoided as much as possible.
4.3.2. Deleting AVPs from a Command 4.3.2. Deleting AVPs from a command
When deleting an AVP from a command, the following cases need to be When deleting an AVP from a command, the following cases need to be
differentiated: differentiated:
o Deleting an AVP that is indicated as { AVP } in the command's CCF o Deleting an AVP that is indicated as { AVP } in the command's CCF
syntax specification, whatever the setting of the M-bit set. This syntax specification, whatever the setting of the M-bit set. This
means the definition of a new command. In this case, a new means the definition of a new command. In this case, a new
command code and subsequently a new Diameter application have to command code and subsequently a new Diameter application have to
be specified. be specified.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
All other AVP flags shall remain unchanged All other AVP flags shall remain unchanged
4.4.2. Reuse of AVP of type Enumerated 4.4.2. Reuse of AVP of type Enumerated
When modifying the set of values supported by an AVP of type When modifying the set of values supported by an AVP of type
Enumerated, this means defining a new AVP. Modifying the set of Enumerated, this means defining a new AVP. Modifying the set of
Enumerated values includes adding a value or deprecating the use of a Enumerated values includes adding a value or deprecating the use of a
value defined initially for the AVP. Defining a new AVP will avoid value defined initially for the AVP. Defining a new AVP will avoid
interoperability issues. interoperability issues.
5. Rules for new Applications 5. Defining new Diameter applications
5.1. Introduction
The general recommendation for Diameter extensibility is to reuse The general recommendation for Diameter extensibility is to reuse
commands, AVPs and AVP values as much as possible. However, some of commands, AVPs and AVP values as much as possible. However, some of
the extensibility rules described in the previous section also apply the extensibility rules described in the previous sections also apply
to scenarios where a designer is trying to define a completely new to scenarios where a designer is trying to define a completely new
Diameter application. Diameter application.
This section discusses the case where new applications have This section discusses the case where new applications have
requirements that cannot be filled by existing applications and would requirements that cannot be filled by existing applications and would
require definition of completely new commands, AVPs and/or AVP require definition of completely new commands, AVPs and/or AVP
values. Typically, there is little ambiguity about the decision to values. Typically, there is little ambiguity about the decision to
create these types of applications. Some examples are the interfaces create these types of applications. Some examples are the interfaces
defined for the IP Multimedia Subsystem of 3GPP, i.e. Cx/Dx defined for the IP Multimedia Subsystem of 3GPP, i.e. Cx/Dx
([TS29.228] and [TS29.229]), Sh ([TS29.328] and [TS29.329]) etc. ([TS29.228] and [TS29.229]), Sh ([TS29.328] and [TS29.329]) etc.
Application designers should also follow the theme of Diameter Application designers should also follow the theme of Diameter
extensibility which in this case means to import existing AVPs and extensibility which in this case means to import existing AVPs and
AVP values for any newly defined commands. In certain cases where AVP values for any newly defined commands. In certain cases where
accounting will be used, the models described in Section 7 should accounting will be used, the models described in Section 5.10 should
also be considered. Though some decisions may be clear, designers also be considered. Though some decisions may be clear, designers
should also consider certain aspects of defining a new application. should also consider certain aspects of defining a new application.
Some of these aspects are described in following sections. Some of these aspects are described in following sections.
5.1. Use of Application-Id in a Message 5.2. Defining new commands
As a general recommendation, Reusing as much as possible of existing
material is encouraged when defining new commands. Protocol
designers can thus usefully benefit from the experience gained with
the implementation of existing commands. This includes good pratices
to reuse but also known mistakes not to repeat. Therefore it is
advisable to avoid the definition of a command from scratch and
rather take as an example an existing command that would be
functionally close to command under definition.
Moreover, the new command's CCF 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 if the context has slightly changed
and some AVPs become obsolete. 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 are only advised to 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.
In the same way, the CCF should be defined in a way 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, it is strongly recommended to add "* [AVP]" in the
command's CCF that will allow the addition of any arbitrary AVP as
described in [I-D.ietf-dime-rfc3588bis].
5.3. Use of Application-Id in a message
When designing new applications, designers should specify that the When designing new applications, designers should specify that the
application ID carried in all session level messages must be the application ID carried in all session level messages must be 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 base protocol, i.e., includes the session level messages defined in base protocol, i.e.,
RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled
accounting model, see Section 7. Existing specifications may not accounting model, see Section 5.10. Existing specifications may not
adhere to this rule for historical or other reasons. However, this adhere to this rule for historical or other reasons. However, this
scheme should be followed to avoid possible routing problems for scheme should be followed to avoid possible routing problems for
these messages. these messages.
In general, when a new application has been allocated with a new In general, when a new application has been allocated with a new
application id and it also reuses existing commands with or without application id and it also reuses existing commands with or without
modifications (Sec 4.1), it must use the newly allocated application modifications (Sec 4.1), it must use the newly allocated application
id in the header and in all relevant application id AVPs (Auth- id in the header and in all relevant application id AVPs (Auth-
Application-Id or Acct-Application-Id) present in the commands Application-Id or Acct-Application-Id) present in the commands
message body. message body.
Additionally, application designs using Additionally, application designs using
Vendor-Specific-Application-Id AVP should not use the Vendor-Id AVP Vendor-Specific-Application-Id AVP should not use the Vendor-Id AVP
to further dissect or differentiate the vendor-specification to further dissect or differentiate the vendor-specification
application id. Diameter routing is not based on the Vendor-Id. As 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 such, the Vendor-ID should not be used as an additional input for
routing or delivery of messages. In general, the Vendor-Id AVP is an routing or delivery of messages. In general, the Vendor-Id AVP is an
informational AVP only and kept for backward compatibility reasons. informational AVP only and kept for backward compatibility reasons.
5.2. Application Specific Session State Machine 5.4. Application specific Session State Machine
Section 8 of [I-D.ietf-dime-rfc3588bis] provides session state Section 8 of [I-D.ietf-dime-rfc3588bis] provides session state
machines for authentication, authorization and accounting (AAA) machines for authentication, authorization and accounting (AAA)
services. When a new application is being defined that cannot services. When a new application is being defined that cannot
clearly be categorized into any of these services it is recommended clearly be categorized into any of these services it is recommended
that the application itself define its own session state machine. that the application itself define its own session state machine.
The existing session state machines defined by The existing session state machines defined by
[I-D.ietf-dime-rfc3588bis] is not intended for general use beyond AAA [I-D.ietf-dime-rfc3588bis] is not intended for general use beyond AAA
services, therefore any behavior not covered by that category would services, therefore any behavior not covered by that category would
not fit well. Support for server initiated request is a clear not fit well. Support for server initiated request is a clear
example where an application specific session state machine would be example where an application specific session state machine would be
needed, for example, the Rw interface for ITU-T push model ( needed, for example, the Rw interface for ITU-T push model (
cf.[Q.3303.3]). cf.[Q.3303.3]).
6. End-to-End Applications Capabilities Exchange 5.5. Session-Id AVP and session management
It is also possible that applications can use optional AVPs to Diameter applications are usually designed with the aim of managing
exchange application specific capabilities and features. These AVPs user sessions, e.g. network access session (NASREQ application
are exchanged on an end-to-end basis. Examples of this can be found [RFC4005]) or specific service access session (Diameter SIP
in [I-D.ietf-dime-mip6-integrated] and application [RFC4740]). In the Diameter base protocol, the session
[I-D.ietf-dime-qos-attributes]. management is based on the Session-Id AVP that it used to identify a
given session and all the Diameter messages including 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 in the diameter path) are maintaining
session state information associated with the Session-Id contained in
the Diameter messages.
However, some applications may not need to rely on the Session-Id to
identify and manage user 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. There might even
be applications for which the notion of Diameter session management
would not be required at all. For such applications, the Auth-
Session-State AVP is usually set to NO_STATE_MAINTAINED in all the
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 the
concept of session management and whether the Session-Id defined in
the Diameter Base protocol would be really used for correlation of
messages related to the same session. If not, the protocol designers
could 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).
5.6. AVPs defined as Boolean flag
The type Enumerated was initially defined to provide 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 on the reception of the
request.
However, AVPs of type Enumerated are too often used as 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 has to be
considered as a sub-optimal design as this 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 that would cause in consequence backwards compatibility issues
with existing implementations.
Instead of defining Enumerated AVP when the AVP simply used as a
Boolean flag, protocol designers are encouraged to rely on AVP
defined in the form of a bit mask with the interpretation of the
setting of each bit described in the relevant Diameter application
specification. Such AVPs can be reused and extended to multiplex
several indications without major impact on the Diameter application.
The bit-mask should be therefore long enough to leave room for future
additions. Examples of AVP defined as bit mask are the Session-
Binding AVP defined in [I-D.ietf-dime-rfc3588bis] and the MIP6-
Feature-Vector AVP defined in [RFC5447]
5.7. Application-specific message routing
Diameter request message routing usually relies 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. 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
[I-D.ietf-dime-rfc3588bis] are not fully suitable and additional
application-level routing mechanisms have to 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.
Example of such specific routing function can be found the
applications defined for the IP Multimedia Subsystem of 3GPP, i.e.
Cx/Dx applications ([TS29.228] and [TS29.229]) in which the
Subscriber Location Function (SLF) is defined a proxy agent (or
enhanced Redirect agent) using 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 should follow the reverse path of
the request, as described in [I-D.ietf-dime-rfc3588bis], 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 Diameter agents in the request routing path (Relay or
Proxy agents) will be able to correctly release the transaction state
associated to the request upon receipt of the answer, avoiding thus
unnecessary failover triggering due to non reception of the answer
corresponding to the request. Application designers are strongly
recommended to not attempt to modify the answer routing principles
described in [I-D.ietf-dime-rfc3588bis] when defining a new
application.
5.8. About Translation Agent
As defined in [I-D.ietf-dime-rfc3588bis], a translation agent is a
device that provides interworking between Diameter and another
protocol (e.g. RADIUS, TACACS+).
In the specific case of RADIUS, it was initially foreseen that the
translation function would have been straightforward to define and
deploy by adopting few basic principles e.g. use of a shared range of
code values for RADIUS attributes and Diameter AVPs, some guidelines
on translation and management of key information (such as
authentication parameter, routing/accounting or states), etc. And
all this material was put in the RFC 4005 ([RFC4005]) to be used as
generic guideline for implementation of RADIUS-Diameter translation
agent.
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 will likely depend on the functionalities
provided by the Diameter application under specification and a case-
by-case analysis will be required.
Therefore, when interoperability with RADIUS infrastructure is
foreseen, protocol designers are advised that they cannot assume the
availability of "standard" Diameter-to-RADIUS gateways agent and the
required translation mechanism should be then specified along with
the Diameter application. And the recommendation in the case of
RADIUS-Diameter interworking applies of course for any other kind of
translation (e.g. Diameter/MAP).
5.9. End-to-End applications capabilities exchange
New 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 in [RFC5447] and [RFC5777].
The end-to-end capabilities AVPs can aid in the following cases: The end-to-end capabilities AVPs can aid in the following cases:
o Formalizing the way new functionality is added to existing o Formalizing the way new functionality is added to existing
applications by announcing support for it. applications by announcing support for it.
o Applications that do not understand these AVP can discard it upon o Applications that do not understand these AVP can discard it upon
receipt. In such case, senders of the AVP can also safely assume receipt. In such case, senders of the AVP can also safely assume
the receiving end-point does not support any functionality carried the receiving end-point does not support any functionality carried
by the AVP if it is not present in subsequent responses. by the AVP if it is not present in subsequent responses.
o Useful in cases where deployment choices are offered and the o Useful in cases where deployment choices are offered and the
generic design can be made available for a number of applications. generic design can be made available for a number of applications.
Note that this list is not meant to be comprehensive. Note that this list is not meant to be comprehensive.
When used in a new application, protocol designers should clearly When used in a new application, protocol designers should clearly
specify this end-to-end capabilities exchange and the corresponding specify this end-to-end capabilities exchange and the corresponding
behaviour of the Diameter nodes supporting the application. behaviour of the Diameter nodes supporting the application.
7. Diameter Accounting Support 5.10. Diameter accounting support
Accounting can be treated as an auxiliary application which is used Accounting can be treated as an auxiliary application which is used
in support of other applications. In most cases, accounting support in support of other applications. In most cases, accounting support
is required when defining new applications. This document provides is required when defining new applications. This document provides
two(2) possible models for using accounting: two(2) possible models for using accounting:
Split Accounting Model Split Accounting Model
In this model, the accounting messages will use the Diameter base In this model, the accounting messages will use the Diameter base
accounting application ID (value of 3). The design implication accounting application ID (value of 3). The design implication
skipping to change at page 18, line 5 skipping to change at page 20, line 20
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. Though it is not recommended, examples of other into account. Though it is not recommended, examples of other
methods might be defining a new set of commands to carry application methods might be defining a new set of commands to carry application
specific accounting records. specific accounting records.
8. Generic Diameter Extensions 5.11. Diameter security mechanisms
As specified in [I-D.ietf-dime-rfc3588bis], the Diameter message
exchange should be secured by using TLS/TCP or DTLS/SCTP. However,
IPsec Additional security mechanisms such as IPsec can also be
deployed to secure connections between Diameter peers. When IPsec is
used instead of TLS or DTLS, the following recommendations apply.
IPsec ESP 5.3 [RFC4301] in transport mode with non-null encryption
and authentication algorithms is used to provide per-packet
authentication, integrity protection and confidentiality, and support
the replay protection mechanisms of IPsec. IKE is used for peer
authentication, negotiation of security associations, and key
management, using the IPsec DOI [RFC2407]. Peer authentication can
be achieved by using a pre-shared key or certificate-based peer
authentication using digital signatures can be used as alternative.
Peer authentication using the public key encryption methods outlined
in IKE's Sections 5.2 and 5.3 [RFC2409] should not be used.
Diameter implementations using IPsec as security mechanisms must
support both IKE Main Mode and Aggressive Mode. When pre-shared keys
are used for authentication, IKE Aggressive Mode should be used
instead of IKE Main Mode. When digital signatures are used for
authentication, either IKE Main Mode or IKE Aggressive Mode can be
used.
When digital signatures are used to achieve authentication, an IKE
negotiator should use IKE Certificate Request Payload(s) to specify
the certificate authority (or authorities) that are trusted in
accordance with its local policy. IKE negotiators should use
pertinent certificate revocation checks before accepting a PKI
certificate for use in IKE's authentication procedures.
The Phase 2 Quick Mode exchanges used to negotiate protection for
Diameter connections must explicitly carry the Identity Payload
fields (IDci and IDcr). The DOI provides for several types of
identification data. However, when used in conformant
implementations, each ID Payload must carry a single IP address and a
single non-zero port number, and must not use the IP Subnet or IP
Address Range formats. This allows the Phase 2 security association
to correspond to specific TCP and SCTP connections.
Since IPsec acceleration hardware may only be able to handle a
limited number of active IKE Phase 2 SAs, Phase 2 delete messages may
be sent for idle SAs, as a means of keeping the number of active
Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete
message should not be interpreted as a reason for tearing down a
Diameter connection. Rather, it is preferable to leave the
connection up, and if additional traffic is sent on it, to bring up
another IKE Phase 2 SA to protect it. This avoids the potential for
continually bringing connections up and down.
6. Defining Generic Diameter Extensions
Generic Diameter extensions are AVPs, commands or applications that Generic Diameter extensions are AVPs, commands or applications that
are designed to support other Diameter applications. They are are designed to support other Diameter applications. They are
auxiliary applications meant to improve or enhance the Diameter auxiliary applications meant to improve or enhance the Diameter
protocol itself or Diameter applications/functionality. Some protocol itself or Diameter applications/functionality. Some
examples include the extensions to support auditing and redundancy examples include the extensions to support auditing and redundancy
(see [I-D.calhoun-diameter-res-mgmt]), improvements in duplicate (see [I-D.calhoun-diameter-res-mgmt]), improvements in duplicate
detection scheme (see [I-D.asveren-dime-dupcons]), and piggybacking detection scheme (see [I-D.asveren-dime-dupcons]), and piggybacking
of QoS attributes (see [I-D.ietf-dime-qos-attributes]). of QoS attributes (see [RFC5777]).
Since generic extensions can cover many aspects of Diameter and Since generic extensions can cover many aspects of Diameter and
Diameter applications, it is not possible to enumerate all the Diameter applications, it is not possible to enumerate all the
probable scenarios in this document. However, some of the most probable scenarios in this document. However, some of the most
common considerations are as follows: common considerations are as follows:
o Backward compatibility: Dealing with existing applications that do o Backward compatibility: Dealing with existing applications that do
not understand the new extension. Designers also have to make not understand the new extension. Designers also have to make
sure that new extensions do not break expected message delivery sure that new extensions do not break expected message delivery
layer behavior. layer behavior.
skipping to change at page 19, line 17 skipping to change at page 23, line 15
and the scenarios when the optional AVPs will be used. In the case and the scenarios when the optional AVPs will be used. In the case
where the optional AVPs can be carried by any application, it is where the optional AVPs can be carried by any application, it is
should be sufficient to specify such a use case and perhaps provide should be sufficient to specify such a use case and perhaps provide
specific examples of applications using them. specific examples of 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]).
9. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
10. Security Considerations 8. Security Considerations
This document does provides guidelines and considerations for This document does provides guidelines and considerations for
extending Diameter and Diameter applications. It does not define nor extending Diameter and Diameter applications. It does not define nor
address security related protocols or schemes. address security related protocols or schemes.
11. Contributors 9. 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 consisting of to revisit the Diameter extensibility rules. The team consisting of
the members listed below was formed in February 2008 and finished its the members listed below was formed in February 2008 and finished its
work in June 2008. work in June 2008.
o Avi Lior o Avi Lior
o Glen Zorn o Glen Zorn
skipping to change at page 23, line 5 skipping to change at page 27, line 5
o Glenn McGregor o Glenn McGregor
o Hannes Tschofenig o Hannes Tschofenig
o Dave Frascone o Dave Frascone
We would like to thank Tolga Asveren, Glenn McGregor, and John We would like to thank Tolga Asveren, Glenn McGregor, and John
Loughney for their contributions as co-authors to earlier versions of Loughney for their contributions as co-authors to earlier versions of
this document. this document.
12. Acknowledgments 10. Acknowledgments
We greatly appreciate the insight provided by Diameter implementers We greatly appreciate the insight provided by Diameter implementers
who have highlighted the issues and concerns being addressed by this who have highlighted the issues and concerns being addressed by this
document. document.
13. References 11. References
13.1. Normative References 11.1. Normative References
[I-D.ietf-dime-rfc3588bis] [I-D.ietf-dime-rfc3588bis]
Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", draft-ietf-dime-rfc3588bis-31 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34
(work in progress), March 2012. (work in progress), June 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
13.2. Informative References 11.2. Informative References
[I-D.asveren-dime-dupcons] [I-D.asveren-dime-dupcons]
Asveren, T., "Diameter Duplicate Detection Cons.", Asveren, T., "Diameter Duplicate Detection Cons.",
draft-asveren-dime-dupcons-00 (work in progress), draft-asveren-dime-dupcons-00 (work in progress),
August 2006. August 2006.
[I-D.calhoun-diameter-res-mgmt] [I-D.calhoun-diameter-res-mgmt]
Calhoun, P., "Diameter Resource Management Extensions", Calhoun, P., "Diameter Resource Management Extensions",
draft-calhoun-diameter-res-mgmt-08.txt (work in progress), draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
March 2001. March 2001.
[I-D.ietf-dime-mip6-integrated]
Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
and K. Chowdhury, "Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction",
draft-ietf-dime-mip6-integrated-12 (work in progress),
January 2009.
[I-D.ietf-dime-qos-attributes]
Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
and A. Lior, "Traffic Classification and Quality of
Service Attributes for Diameter",
draft-ietf-dime-qos-attributes-15 (work in progress),
December 2009.
[Q.3303.3] [Q.3303.3]
3rd Generation Partnership Project, "ITU-T Recommendation 3rd Generation Partnership Project, "ITU-T Recommendation
Q.3303.3, "Resource control protocol no. 3 (rcp3): Q.3303.3, "Resource control protocol no. 3 (rcp3):
Protocol at the Rw interface between the Policy Decision Protocol at the Rw interface between the Policy Decision
Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PD-PE) and the Policy Enforcement
Physical Entity (PE-PE): Diameter"", 2008. Physical Entity (PE-PE): Diameter"", 2008.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC2407] D. Piper, "The Internet IP Security Domain of
"Diameter Network Access Server Application", August 2005, Interpretation for ISAKMP", 1998.
[RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange
(IKE)", 1998.
[RFC4005] P. Calhoun et al., "Diameter Network Access Server
Application", August 2005,
<http://www.rfc-editor.org/rfc/rfc4005.txt>. <http://www.rfc-editor.org/rfc/rfc4005.txt>.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [RFC4072] P. Eronen et al., "Diameter Extensible Authentication
Authentication Protocol (EAP) Application", August 2005, Protocol (EAP) Application", August 2005,
<http://www.rfc-editor.org/rfc/rfc4072.txt>. <http://www.rfc-editor.org/rfc/rfc4072.txt>.
[RFC4301] S. Kent and K. Seo, "Security Architecture for the
Internet Protocol", 2005.
[RFC4740] M. Garcia-Martin et al., "Diameter Session Initiation
Protocol (SIP) Application", November 2006,
<http://www.rfc-editor.org/rfc/rfc4740.txt>.
[RFC5447] J. Korhonen et al., "Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction",
February 2009,
<http://www.rfc-editor.org/rfc/rfc5447.txt>.
[RFC5777] J. Korhonen et al., "Traffic Classification and Quality of
Service (QoS) Attributes for Diameter", 2010.
[TS29.228] [TS29.228]
3rd Generation Partnership Project, "3GPP TS 29.228; 3rd Generation Partnership Project, "3GPP TS 29.228;
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
IP Multimedia (IM) Subsystem Cx and Dx Interfaces; IP Multimedia (IM) Subsystem Cx and Dx Interfaces;
Signalling flows and message contents", Signalling flows and message contents",
<http://www.3gpp.org/ftp/Specs/html-info/29272.htm>. <http://www.3gpp.org/ftp/Specs/html-info/29272.htm>.
[TS29.229] [TS29.229]
3rd Generation Partnership Project, "3GPP TS 29.229; 3rd Generation Partnership Project, "3GPP TS 29.229;
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
skipping to change at page 26, line 10 skipping to change at page 30, line 10
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
Sh Interface based on the Diameter protocol; Protocol Sh Interface based on the Diameter protocol; Protocol
details", details",
<http://www.3gpp.org/ftp/Specs/html-info/29329.htm>. <http://www.3gpp.org/ftp/Specs/html-info/29329.htm>.
Authors' Addresses Authors' Addresses
Lionel Morand (editor) Lionel Morand (editor)
Orange Labs Orange Labs
Phone: +33 1 4529 6257
Email: lionel.morand@orange.com Email: lionel.morand@orange.com
Victor Fajardo Victor Fajardo
Email: vf0213@gmail.com Email: vf0213@gmail.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
 End of changes. 44 change blocks. 
105 lines changed or deleted 348 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/