RFC 6733
Diameter Base Protocol
Pages: 152
Proposed Standard
→ Errata
Obsoletes: 3588 5719
Updated by: 7075 8553
Proposed Standard
→ Errata
Obsoletes: 3588 5719
Updated by: 7075 8553
Part 1 of 5 – Pages 1 to 20
Internet Engineering Task Force (IETF) V. Fajardo, Ed. Request for Comments: 6733 Telcordia Technologies Obsoletes: 3588, 5719 J. Arkko Category: Standards Track Ericsson Research ISSN: 2070-1721 J. Loughney Nokia Research Center G. Zorn, Ed. Network Zen October 2012 Diameter Base ProtocolAbstract
The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6733.
Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Table of Contents
1. Introduction ....................................................7 1.1. Diameter Protocol ..........................................9 1.1.1. Description of the Document Set ....................10 1.1.2. Conventions Used in This Document ..................11 1.1.3. Changes from RFC 3588 ..............................11 1.2. Terminology ...............................................12 1.3. Approach to Extensibility .................................17 1.3.1. Defining New AVP Values ............................18 1.3.2. Creating New AVPs ..................................18 1.3.3. Creating New Commands ..............................18 1.3.4. Creating New Diameter Applications .................19 2. Protocol Overview ..............................................20 2.1. Transport .................................................22 2.1.1. SCTP Guidelines ....................................23 2.2. Securing Diameter Messages ................................24 2.3. Diameter Application Compliance ...........................24 2.4. Application Identifiers ...................................24 2.5. Connections vs. Sessions ..................................25 2.6. Peer Table ................................................26
2.7. Routing Table .............................................27
2.8. Role of Diameter Agents ...................................28
2.8.1. Relay Agents .......................................30
2.8.2. Proxy Agents .......................................31
2.8.3. Redirect Agents ....................................31
2.8.4. Translation Agents .................................32
2.9. Diameter Path Authorization ...............................33
3. Diameter Header ................................................34
3.1. Command Codes .............................................37
3.2. Command Code Format Specification .........................38
3.3. Diameter Command Naming Conventions .......................40
4. Diameter AVPs ..................................................40
4.1. AVP Header ................................................41
4.1.1. Optional Header Elements ...........................42
4.2. Basic AVP Data Formats ....................................43
4.3. Derived AVP Data Formats ..................................44
4.3.1. Common Derived AVP Data Formats ....................44
4.4. Grouped AVP Values ........................................51
4.4.1. Example AVP with a Grouped Data Type ...............52
4.5. Diameter Base Protocol AVPs ...............................55
5. Diameter Peers .................................................58
5.1. Peer Connections ..........................................58
5.2. Diameter Peer Discovery ...................................59
5.3. Capabilities Exchange .....................................60
5.3.1. Capabilities-Exchange-Request ......................62
5.3.2. Capabilities-Exchange-Answer .......................63
5.3.3. Vendor-Id AVP ......................................63
5.3.4. Firmware-Revision AVP ..............................64
5.3.5. Host-IP-Address AVP ................................64
5.3.6. Supported-Vendor-Id AVP ............................64
5.3.7. Product-Name AVP ...................................64
5.4. Disconnecting Peer Connections ............................64
5.4.1. Disconnect-Peer-Request ............................65
5.4.2. Disconnect-Peer-Answer .............................65
5.4.3. Disconnect-Cause AVP ...............................66
5.5. Transport Failure Detection ...............................66
5.5.1. Device-Watchdog-Request ............................67
5.5.2. Device-Watchdog-Answer .............................67
5.5.3. Transport Failure Algorithm ........................67
5.5.4. Failover and Failback Procedures ...................67
5.6. Peer State Machine ........................................68
5.6.1. Incoming Connections ...............................71
5.6.2. Events .............................................71
5.6.3. Actions ............................................72
5.6.4. The Election Process ...............................74
6. Diameter Message Processing ....................................74 6.1. Diameter Request Routing Overview .........................74 6.1.1. Originating a Request ..............................75 6.1.2. Sending a Request ..................................76 6.1.3. Receiving Requests .................................76 6.1.4. Processing Local Requests ..........................76 6.1.5. Request Forwarding .................................77 6.1.6. Request Routing ....................................77 6.1.7. Predictive Loop Avoidance ..........................77 6.1.8. Redirecting Requests ...............................78 6.1.9. Relaying and Proxying Requests .....................79 6.2. Diameter Answer Processing ................................80 6.2.1. Processing Received Answers ........................81 6.2.2. Relaying and Proxying Answers ......................81 6.3. Origin-Host AVP ...........................................81 6.4. Origin-Realm AVP ..........................................82 6.5. Destination-Host AVP ......................................82 6.6. Destination-Realm AVP .....................................82 6.7. Routing AVPs ..............................................83 6.7.1. Route-Record AVP ...................................83 6.7.2. Proxy-Info AVP .....................................83 6.7.3. Proxy-Host AVP .....................................83 6.7.4. Proxy-State AVP ....................................83 6.8. Auth-Application-Id AVP ...................................83 6.9. Acct-Application-Id AVP ...................................84 6.10. Inband-Security-Id AVP ...................................84 6.11. Vendor-Specific-Application-Id AVP .......................84 6.12. Redirect-Host AVP ........................................85 6.13. Redirect-Host-Usage AVP ..................................85 6.14. Redirect-Max-Cache-Time AVP ..............................87 7. Error Handling .................................................87 7.1. Result-Code AVP ...........................................89 7.1.1. Informational ......................................90 7.1.2. Success ............................................90 7.1.3. Protocol Errors ....................................90 7.1.4. Transient Failures .................................92 7.1.5. Permanent Failures .................................92 7.2. Error Bit .................................................95 7.3. Error-Message AVP .........................................96 7.4. Error-Reporting-Host AVP ..................................96 7.5. Failed-AVP AVP ............................................96 7.6. Experimental-Result AVP ...................................97 7.7. Experimental-Result-Code AVP ..............................97 8. Diameter User Sessions .........................................98 8.1. Authorization Session State Machine .......................99 8.2. Accounting Session State Machine .........................104
8.3. Server-Initiated Re-Auth .................................110
8.3.1. Re-Auth-Request ...................................110
8.3.2. Re-Auth-Answer ....................................110
8.4. Session Termination ......................................111
8.4.1. Session-Termination-Request .......................112
8.4.2. Session-Termination-Answer ........................113
8.5. Aborting a Session .......................................113
8.5.1. Abort-Session-Request .............................114
8.5.2. Abort-Session-Answer ..............................114
8.6. Inferring Session Termination from Origin-State-Id .......115
8.7. Auth-Request-Type AVP ....................................116
8.8. Session-Id AVP ...........................................116
8.9. Authorization-Lifetime AVP ...............................117
8.10. Auth-Grace-Period AVP ...................................118
8.11. Auth-Session-State AVP ..................................118
8.12. Re-Auth-Request-Type AVP ................................118
8.13. Session-Timeout AVP .....................................119
8.14. User-Name AVP ...........................................119
8.15. Termination-Cause AVP ...................................120
8.16. Origin-State-Id AVP .....................................120
8.17. Session-Binding AVP .....................................120
8.18. Session-Server-Failover AVP .............................121
8.19. Multi-Round-Time-Out AVP ................................122
8.20. Class AVP ...............................................122
8.21. Event-Timestamp AVP .....................................122
9. Accounting ....................................................123
9.1. Server Directed Model ....................................123
9.2. Protocol Messages ........................................124
9.3. Accounting Application Extension and Requirements ........124
9.4. Fault Resilience .........................................125
9.5. Accounting Records .......................................125
9.6. Correlation of Accounting Records ........................126
9.7. Accounting Command Codes .................................127
9.7.1. Accounting-Request ................................127
9.7.2. Accounting-Answer .................................128
9.8. Accounting AVPs ..........................................129
9.8.1. Accounting-Record-Type AVP ........................129
9.8.2. Acct-Interim-Interval AVP .........................130
9.8.3. Accounting-Record-Number AVP ......................131
9.8.4. Acct-Session-Id AVP ...............................131
9.8.5. Acct-Multi-Session-Id AVP .........................131
9.8.6. Accounting-Sub-Session-Id AVP .....................131
9.8.7. Accounting-Realtime-Required AVP ..................132
10. AVP Occurrence Tables ........................................132
10.1. Base Protocol Command AVP Table .........................133
10.2. Accounting AVP Table ....................................134
11. IANA Considerations ..........................................135 11.1. AVP Header ..............................................135 11.1.1. AVP Codes ........................................136 11.1.2. AVP Flags ........................................136 11.2. Diameter Header .........................................136 11.2.1. Command Codes ....................................136 11.2.2. Command Flags ....................................137 11.3. AVP Values ..............................................137 11.3.1. Experimental-Result-Code AVP .....................137 11.3.2. Result-Code AVP Values ...........................137 11.3.3. Accounting-Record-Type AVP Values ................137 11.3.4. Termination-Cause AVP Values .....................137 11.3.5. Redirect-Host-Usage AVP Values ...................137 11.3.6. Session-Server-Failover AVP Values ...............137 11.3.7. Session-Binding AVP Values .......................137 11.3.8. Disconnect-Cause AVP Values ......................138 11.3.9. Auth-Request-Type AVP Values .....................138 11.3.10. Auth-Session-State AVP Values ...................138 11.3.11. Re-Auth-Request-Type AVP Values .................138 11.3.12. Accounting-Realtime-Required AVP Values .........138 11.3.13. Inband-Security-Id AVP (code 299) ...............138 11.4. _diameters Service Name and Port Number Registration ....138 11.5. SCTP Payload Protocol Identifiers .......................139 11.6. S-NAPTR Parameters ......................................139 12. Diameter Protocol-Related Configurable Parameters ............139 13. Security Considerations ......................................140 13.1. TLS/TCP and DTLS/SCTP Usage .............................140 13.2. Peer-to-Peer Considerations .............................141 13.3. AVP Considerations ......................................141 14. References ...................................................142 14.1. Normative References ....................................142 14.2. Informative References ..................................144 Appendix A. Acknowledgements .....................................147 A.1. This Document .............................................147 A.2. RFC 3588 ..................................................148 Appendix B. S-NAPTR Example ......................................148 Appendix C. Duplicate Detection ..................................149 Appendix D. Internationalized Domain Names .......................151
1. Introduction
Authentication, Authorization, and Accounting (AAA) protocols such as TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to provide dial-up PPP [RFC1661] and terminal server access. Over time, AAA support was needed on many new access technologies, the scale and complexity of AAA networks grew, and AAA was also used on new applications (such as voice over IP). This led to new demands on AAA protocols. Network access requirements for AAA protocols are summarized in Aboba, et al. [RFC2989]. These include: Failover [RFC2865] does not define failover mechanisms and, as a result, failover behavior differs between implementations. In order to provide well-defined failover behavior, Diameter supports application-layer acknowledgements and defines failover algorithms and the associated state machine. Transmission-level security RADIUS [RFC2865] defines an application-layer authentication and integrity scheme that is required only for use with response packets. While [RFC2869] defines an additional authentication and integrity mechanism, use is only required during Extensible Authentication Protocol (EAP) [RFC3748] sessions. While attribute hiding is supported, [RFC2865] does not provide support for per- packet confidentiality. In accounting, [RFC2866] assumes that replay protection is provided by the backend billing server rather than within the protocol itself. While [RFC3162] defines the use of IPsec with RADIUS, support for IPsec is not required. In order to provide universal support for transmission-level security, and enable both intra- and inter- domain AAA deployments, Diameter provides support for TLS/TCP and DTLS/SCTP. Security is discussed in Section 13. Reliable transport RADIUS runs over UDP, and does not define retransmission behavior; as a result, reliability varies between implementations. As described in [RFC2975], this is a major issue in accounting, where packet loss may translate directly into revenue loss. In order to
provide well-defined transport behavior, Diameter runs over
reliable transport mechanisms (TCP, Stream Control Transmission
Protocol (SCTP)) as defined in [RFC3539].
Agent support
RADIUS does not provide for explicit support for agents, including
proxies, redirects, and relays. Since the expected behavior is
not defined, it varies between implementations. Diameter defines
agent behavior explicitly; this is described in Section 2.8.
Server-initiated messages
While server-initiated messages are defined in RADIUS [RFC5176],
support is optional. This makes it difficult to implement
features such as unsolicited disconnect or re-authentication/
re-authorization on demand across a heterogeneous deployment. To
address this issue, support for server-initiated messages is
mandatory in Diameter.
Transition support
While Diameter does not share a common protocol data unit (PDU)
with RADIUS, considerable effort has been expended in enabling
backward compatibility with RADIUS so that the two protocols may
be deployed in the same network. Initially, it is expected that
Diameter will be deployed within new network devices, as well as
within gateways enabling communication between legacy RADIUS
devices and Diameter agents. This capability enables Diameter
support to be added to legacy networks, by addition of a gateway
or server speaking both RADIUS and Diameter.
In addition to addressing the above requirements, Diameter also
provides support for the following:
Capability negotiation
RADIUS does not support error messages, capability negotiation, or
a mandatory/non-mandatory flag for attributes. Since RADIUS
clients and servers are not aware of each other's capabilities,
they may not be able to successfully negotiate a mutually
acceptable service or, in some cases, even be aware of what
service has been implemented. Diameter includes support for error
handling (Section 7), capability negotiation (Section 5.3), and
mandatory/non-mandatory Attribute-Value Pairs (AVPs)
(Section 4.1).
Peer discovery and configuration
RADIUS implementations typically require that the name or address
of servers or clients be manually configured, along with the
corresponding shared secrets. This results in a large
administrative burden and creates the temptation to reuse the
RADIUS shared secret, which can result in major security
vulnerabilities if the Request Authenticator is not globally and
temporally unique as required in [RFC2865]. Through DNS, Diameter
enables dynamic discovery of peers (see Section 5.2). Derivation
of dynamic session keys is enabled via transmission-level
security.
Over time, the capabilities of Network Access Server (NAS) devices
have increased substantially. As a result, while Diameter is a
considerably more sophisticated protocol than RADIUS, it remains
feasible to implement it within embedded devices.
1.1. Diameter Protocol
The Diameter base protocol provides the following facilities:
o Ability to exchange messages and deliver AVPs
o Capabilities negotiation
o Error notification
o Extensibility, required in [RFC2989], through addition of new
applications, commands, and AVPs
o Basic services necessary for applications, such as the handling of
user sessions or accounting
All data delivered by the protocol is in the form of AVPs. Some of
these AVP values are used by the Diameter protocol itself, while
others deliver data associated with particular applications that
employ Diameter. AVPs may be arbitrarily added to Diameter messages,
the only restriction being that the Command Code Format (CCF)
specification (Section 3.2) be satisfied. AVPs are used by the base
Diameter protocol to support the following required features:
o Transporting of user authentication information, for the purposes
of enabling the Diameter server to authenticate the user
o Transporting of service-specific authorization information,
between client and servers, allowing the peers to decide whether a
user's access request should be granted
o Exchanging resource usage information, which may be used for
accounting purposes, capacity planning, etc.
o Routing, relaying, proxying, and redirecting of Diameter messages
through a server hierarchy
The Diameter base protocol satisfies the minimum requirements for a
AAA protocol, as specified by [RFC2989]. The base protocol may be
used by itself for accounting purposes only, or it may be used with a
Diameter application, such as Mobile IPv4 [RFC4004], or network
access [RFC4005]. It is also possible for the base protocol to be
extended for use in new applications, via the addition of new
commands or AVPs. The initial focus of Diameter was network access
and accounting applications. A truly generic AAA protocol used by
many applications might provide functionality not provided by
Diameter. Therefore, it is imperative that the designers of new
applications understand their requirements before using Diameter.
See Section 1.3.4 for more information on Diameter applications.
Any node can initiate a request. In that sense, Diameter is a peer-
to-peer protocol. In this document, a Diameter client is a device at
the edge of the network that performs access control, such as a
Network Access Server (NAS) or a Foreign Agent (FA). A Diameter
client generates Diameter messages to request authentication,
authorization, and accounting services for the user. A Diameter
agent is a node that does not provide local user authentication or
authorization services; agents include proxies, redirects, and relay
agents. A Diameter server performs authentication and/or
authorization of the user. A Diameter node may act as an agent for
certain requests while acting as a server for others.
The Diameter protocol also supports server-initiated messages, such
as a request to abort service to a particular user.
1.1.1. Description of the Document Set
The Diameter specification consists of an updated version of the base
protocol specification (this document) and the Transport Profile
[RFC3539]. This document obsoletes both RFC 3588 and RFC 5719. A
summary of the base protocol updates included in this document can be
found in Section 1.1.3.
This document defines the base protocol specification for AAA, which
includes support for accounting. There are also a myriad of
applications documents describing applications that use this base
specification for Authentication, Authorization, and Accounting.
These application documents specify how to use the Diameter protocol
within the context of their application.
The Transport Profile document [RFC3539] discusses transport layer issues that arise with AAA protocols and recommendations on how to overcome these issues. This document also defines the Diameter failover algorithm and state machine. "Clarifications on the Routing of Diameter Request Based on the Username and the Realm" [RFC5729] defines specific behavior on how to route requests based on the content of the User-Name AVP (Attribute Value Pair).1.1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].1.1.3. Changes from RFC 3588
This document obsoletes RFC 3588 but is fully backward compatible with that document. The changes introduced in this document focus on fixing issues that have surfaced during the implementation of Diameter (RFC 3588). An overview of some the major changes are given below. o Deprecated the use of the Inband-Security AVP for negotiating Transport Layer Security (TLS) [RFC5246]. It has been generally considered that bootstrapping of TLS via Inband-Security AVP creates certain security risks because it does not completely protect the information carried in the CER/CEA (Capabilities- Exchange-Request/Capabilities-Exchange-Answer). This version of Diameter adopts the common approach of defining a well-known secured port that peers should use when communicating via TLS/TCP and DTLS/SCTP. This new approach augments the existing in-band security negotiation, but it does not completely replace it. The old method is kept for backward compatibility reasons. o Deprecated the exchange of CER/CEA messages in the open state. This feature was implied in the peer state machine table of RFC 3588, but it was not clearly defined anywhere else in that document. As work on this document progressed, it became clear that the multiplicity of meaning and use of Application-Id AVPs in the CER/CEA messages (and the messages themselves) is seen as an abuse of the Diameter extensibility rules and thus required simplification. Capabilities exchange in the open state has been re-introduced in a separate specification [RFC6737], which clearly defines new commands for this feature.
o Simplified security requirements. The use of a secured transport
for exchanging Diameter messages remains mandatory. However, TLS/
TCP and DTLS/SCTP have become the primary methods of securing
Diameter with IPsec as a secondary alternative. See Section 13
for details. The support for the End-to-End security framework
(E2E-Sequence AVP and 'P'-bit in the AVP header) has also been
deprecated.
o Changed Diameter extensibility. This includes fixes to the
Diameter extensibility description (Section 1.3 and others) to
better aid Diameter application designers; in addition, the new
specification relaxes the policy with respect to the allocation of
Command Codes for vendor-specific uses.
o Clarified Application Id usage. Clarify the proper use of
Application Id information, which can be found in multiple places
within a Diameter message. This includes correlating Application
Ids found in the message headers and AVPs. These changes also
clearly specify the proper Application Id value to use for
specific base protocol messages (ASR/ASA, STR/STA) as well as
clarify the content and use of Vendor-Specific-Application-Id.
o Clarified routing fixes. This document more clearly specifies
what information (AVPs and Application Ids) can be used for making
general routing decisions. A rule for the prioritization of
redirect routing criteria when multiple route entries are found
via redirects has also been added (see Section 6.13).
o Simplified Diameter peer discovery. The Diameter discovery
process now supports only widely used discovery schemes; the rest
have been deprecated (see Section 5.2 for details).
There are many other miscellaneous fixes that have been introduced in
this document that may not be considered significant, but they have
value nonetheless. Examples are removal of obsolete types, fixes to
the state machine, clarification of the election process, message
validation, fixes to Failed-AVP and Result-Code AVP values, etc. All
of the errata filed against RFC 3588 prior to the publication of this
document have been addressed. A comprehensive list of changes is not
shown here for practical reasons.
1.2. Terminology
AAA
Authentication, Authorization, and Accounting.
ABNF
Augmented Backus-Naur Form [RFC5234]. A metalanguage with its own
formal syntax and rules. It is based on the Backus-Naur Form and
is used to define message exchanges in a bi-directional
communications protocol.
Accounting
The act of collecting information on resource usage for the
purpose of capacity planning, auditing, billing, or cost
allocation.
Accounting Record
An accounting record represents a summary of the resource
consumption of a user over the entire session. Accounting servers
creating the accounting record may do so by processing interim
accounting events or accounting events from several devices
serving the same user.
Authentication
The act of verifying the identity of an entity (subject).
Authorization
The act of determining whether a requesting entity (subject) will
be allowed access to a resource (object).
Attribute-Value Pair (AVP)
The Diameter protocol consists of a header followed by one or more
Attribute-Value-Pairs (AVPs). An AVP includes a header and is
used to encapsulate protocol-specific data (e.g., routing
information) as well as authentication, authorization, or
accounting information.
Command Code Format (CCF)
A modified form of ABNF used to define Diameter commands (see
Section 3.2).
Diameter Agent
A Diameter Agent is a Diameter node that provides relay, proxy,
redirect, or translation services.
Diameter Client
A Diameter client is a Diameter node that supports Diameter client
applications as well as the base protocol. Diameter clients are
often implemented in devices situated at the edge of a network and
provide access control services for that network. Typical
examples of Diameter clients include the Network Access Server
(NAS) and the Mobile IP Foreign Agent (FA).
Diameter Node
A Diameter node is a host process that implements the Diameter
protocol and acts as either a client, an agent, or a server.
Diameter Peer
Two Diameter nodes sharing a direct TCP or SCTP transport
connection are called Diameter peers.
Diameter Server
A Diameter server is a Diameter node that handles authentication,
authorization, and accounting requests for a particular realm. By
its very nature, a Diameter server must support Diameter server
applications in addition to the base protocol.
Downstream
Downstream is used to identify the direction of a particular
Diameter message from the home server towards the Diameter client.
Home Realm
A Home Realm is the administrative domain with which the user
maintains an account relationship.
Home Server
A Diameter server that serves the Home Realm.
Interim Accounting
An interim accounting message provides a snapshot of usage during
a user's session. Typically, it is implemented in order to
provide for partial accounting of a user's session in case a
device reboot or other network problem prevents the delivery of a
session summary message or session record.
Local Realm
A local realm is the administrative domain providing services to a
user. An administrative domain may act as a local realm for
certain users while being a home realm for others.
Multi-session
A multi-session represents a logical linking of several sessions.
Multi-sessions are tracked by using the Acct-Multi-Session-Id. An
example of a multi-session would be a Multi-link PPP bundle. Each
leg of the bundle would be a session while the entire bundle would
be a multi-session.
Network Access Identifier
The Network Access Identifier, or NAI [RFC4282], is used in the
Diameter protocol to extract a user's identity and realm. The
identity is used to identify the user during authentication and/or
authorization while the realm is used for message routing
purposes.
Proxy Agent or Proxy
In addition to forwarding requests and responses, proxies make
policy decisions relating to resource usage and provisioning.
Typically, this is accomplished by tracking the state of NAS
devices. While proxies usually do not respond to client requests
prior to receiving a response from the server, they may originate
Reject messages in cases where policies are violated. As a
result, proxies need to understand the semantics of the messages
passing through them, and they may not support all Diameter
applications.
Realm
The string in the NAI that immediately follows the '@' character.
NAI realm names are required to be unique and are piggybacked on
the administration of the DNS namespace. Diameter makes use of
the realm, also loosely referred to as domain, to determine
whether messages can be satisfied locally or whether they must be
routed or redirected. In RADIUS, realm names are not necessarily
piggybacked on the DNS namespace but may be independent of it.
Real-Time Accounting
Real-time accounting involves the processing of information on
resource usage within a defined time window. Typically, time
constraints are imposed in order to limit financial risk. The
Diameter Credit-Control Application [RFC4006] is an example of an
application that defines real-time accounting functionality.
Relay Agent or Relay
Relays forward requests and responses based on routing-related
AVPs and routing table entries. Since relays do not make policy
decisions, they do not examine or alter non-routing AVPs. As a
result, relays never originate messages, do not need to understand
the semantics of messages or non-routing AVPs, and are capable of
handling any Diameter application or message type. Since relays
make decisions based on information in routing AVPs and realm
forwarding tables, they do not keep state on NAS resource usage or
sessions in progress.
Redirect Agent
Rather than forwarding requests and responses between clients and
servers, redirect agents refer clients to servers and allow them
to communicate directly. Since redirect agents do not sit in the
forwarding path, they do not alter any AVPs transiting between
client and server. Redirect agents do not originate messages and
are capable of handling any message type, although they may be
configured only to redirect messages of certain types, while
acting as relay or proxy agents for other types. As with relay
agents, redirect agents do not keep state with respect to sessions
or NAS resources.
Session
A session is a related progression of events devoted to a
particular activity. Diameter application documents provide
guidelines as to when a session begins and ends. All Diameter
packets with the same Session-Id are considered to be part of the
same session.
Stateful Agent
A stateful agent is one that maintains session state information,
by keeping track of all authorized active sessions. Each
authorized session is bound to a particular service, and its state
is considered active either until it is notified otherwise or
until expiration.
Sub-session
A sub-session represents a distinct service (e.g., QoS or data
characteristics) provided to a given session. These services may
happen concurrently (e.g., simultaneous voice and data transfer
during the same session) or serially. These changes in sessions
are tracked with the Accounting-Sub-Session-Id.
Transaction State
The Diameter protocol requires that agents maintain transaction
state, which is used for failover purposes. Transaction state
implies that upon forwarding a request, the Hop-by-Hop Identifier
is saved; the field is replaced with a locally unique identifier,
which is restored to its original value when the corresponding
answer is received. The request's state is released upon receipt
of the answer. A stateless agent is one that only maintains
transaction state.
Translation Agent
A translation agent (TLA in Figure 4) is a stateful Diameter node
that performs protocol translation between Diameter and another
AAA protocol, such as RADIUS.
Upstream
Upstream is used to identify the direction of a particular
Diameter message from the Diameter client towards the home server.
User
The entity or device requesting or using some resource, in support
of which a Diameter client has generated a request.
1.3. Approach to Extensibility
The Diameter protocol is designed to be extensible, using several
mechanisms, including:
o Defining new AVP values
o Creating new AVPs
o Creating new commands
o Creating new applications
From the point of view of extensibility, Diameter authentication, authorization, and accounting applications are treated in the same way. Note: Protocol designers should try to reuse existing functionality, namely AVP values, AVPs, commands, and Diameter applications. Reuse simplifies standardization and implementation. To avoid potential interoperability issues, it is important to ensure that the semantics of the reused features are well understood. Given that Diameter can also carry RADIUS attributes as Diameter AVPs, such reuse considerations also apply to existing RADIUS attributes that may be useful in a Diameter application.1.3.1. Defining New AVP Values
In order to allocate a new AVP value for AVPs defined in the Diameter base protocol, the IETF needs to approve a new RFC that describes the AVP value. IANA considerations for these AVP values are discussed in Section 11.3. The allocation of AVP values for other AVPs is guided by the IANA considerations of the document that defines those AVPs. Typically, allocation of new values for an AVP defined in an RFC would require IETF Review [RFC5226], whereas values for vendor-specific AVPs can be allocated by the vendor.1.3.2. Creating New AVPs
A new AVP being defined MUST use one of the data types listed in Sections 4.2 or 4.3. If an appropriate derived data type is already defined, it SHOULD be used instead of a base data type to encourage reusability and good design practice. In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, it is recommended that a Grouped AVP be used (see Section 4.4). The creation of new AVPs can happen in various ways. The recommended approach is to define a new general-purpose AVP in a Standards Track RFC approved by the IETF. However, as described in Section 11.1.1, there are other mechanisms.1.3.3. Creating New Commands
A new Command Code MUST be allocated when required AVPs (those indicated as {AVP} in the CCF definition) are added to, deleted from, or redefined in (for example, by changing a required AVP into an optional one) an existing command.
Furthermore, if the transport characteristics of a command are changed (for example, with respect to the number of round trips required), a new Command Code MUST be registered. A change to the CCF of a command, such as described above, MUST result in the definition of a new Command Code. This subsequently leads to the need to define a new Diameter application for any application that will use that new command. The IANA considerations for Command Codes are discussed in Section 3.1.1.3.4. Creating New Diameter Applications
Every Diameter application specification MUST have an IANA-assigned Application Id (see Section 2.4). The managed Application ID space is flat, and there is no relationship between different Diameter applications with respect to their Application Ids. As such, there is no versioning support provided by these Application Ids themselves; every Diameter application is a standalone application. If the application has a relationship with other Diameter applications, such a relationship is not known to Diameter. Before describing the rules for creating new Diameter applications, it is important to discuss the semantics of the AVP occurrences as stated in the CCF and the M-bit flag (Section 4.1) for an AVP. There is no relationship imposed between the two; they are set independently. o The CCF indicates what AVPs are placed into a Diameter command by the sender of that command. Often, since there are multiple modes of protocol interactions, many of the AVPs are indicated as optional. o The M-bit allows the sender to indicate to the receiver whether or not understanding the semantics of an AVP and its content is mandatory. If the M-bit is set by the sender and the receiver does not understand the AVP or the values carried within that AVP, then a failure is generated (see Section 7). It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met:
M-bit Setting
An AVP with the M-bit in the MUST column of the AVP flag table is
added to an existing Command/Application. An AVP with the M-bit
in the MAY column of the AVP flag table is added to an existing
Command/Application.
Note: The M-bit setting for a given AVP is relevant to an
Application and each command within that application that includes
the AVP. That is, if an AVP appears in two commands for
application Foo and the M-bit settings are different in each
command, then there should be two AVP flag tables describing when
to set the M-bit.
Commands
A new command is used within the existing application because
either an additional command is added, an existing command has
been modified so that a new Command Code had to be registered, or
a command has been deleted.
AVP Flag bits
If an existing application changes the meaning/semantics of its
AVP Flags or adds new flag bits, then a new Diameter application
MUST be created.
If the CCF definition of a command allows it, an implementation may
add arbitrary optional AVPs with the M-bit cleared (including vendor-
specific AVPs) to that command without needing to define a new
application. Please refer to Section 11.1.1 for details.
(page 20 continued on part 2)