|
Network Working Group Request for Comments: 3588 Category: Standards Track |
P. Calhoun Airespace, Inc. J. Loughney Nokia E. Guttman Sun Microsystems, Inc. G. Zorn Cisco Systems, Inc. J. Arkko Ericsson September 2003 |
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © The Internet Society (2003). All Rights Reserved.
The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations.
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 BCP 14, RFC 2119 [KEYWORD].
1. Introduction
1.1. Diameter Protocol
1.1.1. Description of the Document Set
1.2. Approach to Extensibility
1.2.1. Defining New AVP Values
1.2.2. Creating New AVPs
1.2.3. Creating New Authentication Applications
1.2.4. Creating New Accounting Applications
1.2.5. Application Authentication Procedures
1.3. Terminology
2. Protocol Overview
2.1. Transport
2.1.1. SCTP Guidelines
2.2. Securing Diameter Messages
2.3. Diameter Application Compliance
2.4. Application Identifiers
2.5. Connections vs. Sessions
2.6. Peer Table
2.7. Realm-Based Routing Table
2.8. Role of Diameter Agents
2.8.1. Relay Agents
2.8.2. Proxy Agents
2.8.3. Redirect Agents
2.8.4. Translation Agents
2.9. End-to-End Security Framework
2.10. Diameter Path Authorization
3. Diameter Header
3.1. Command Codes
3.2. Command Code ABNF specification
3.3. Diameter Command Naming Conventions
4. Diameter AVPs
4.1. AVP Header
4.1.1. Optional Header Elements
4.2. Basic AVP Data Formats
4.3. Derived AVP Data Formats
4.4. Grouped AVP Values
4.4.1. Example AVP with a Grouped Data Type
4.5. Diameter Base Protocol AVPs
5. Diameter Peers
5.1. Peer Connections
5.2. Diameter Peer Discovery
5.3. Capabilities Exchange
5.3.1. Capabilities-Exchange-Request
5.3.2. Capabilities-Exchange-Answer
5.3.3. Vendor-Id AVP
5.3.4. Firmware-Revision AVP
5.3.5. Host-IP-Address AVP
5.3.6. Supported-Vendor-Id AVP
5.3.7. Product-Name AVP
5.4. Disconnecting Peer Connections
5.4.1. Disconnect-Peer-Request
5.4.2. Disconnect-Peer-Answer
5.4.3. Disconnect-Cause AVP
5.5. Transport Failure Detection
5.5.1. Device-Watchdog-Request
5.5.2. Device-Watchdog-Answer
5.5.3. Transport Failure Algorithm
5.5.4. Failover and Failback Procedures
5.6. Peer State Machine
5.6.1. Incoming connections
5.6.2. Events
5.6.3. Actions
5.6.4. The Election Process
6. Diameter Message Processing
6.1. Diameter Request Routing Overview
6.1.1. Originating a Request
6.1.2. Sending a Request
6.1.3. Receiving Requests
6.1.4. Processing Local Requests
6.1.5. Request Forwarding
6.1.6. Request Routing
6.1.7. Redirecting Requests
6.1.8. Relaying and Proxying Requests
6.2. Diameter Answer Processing
6.2.1. Processing Received Answers
6.2.2. Relaying and Proxying Answers
6.3. Origin-Host AVP
6.4. Origin-Realm AVP
6.5. Destination-Host AVP
6.6. Destination-Realm AVP
6.7. Routing AVPs
6.7.1. Route-Record AVP
6.7.2. Proxy-Info AVP
6.7.3. Proxy-Host AVP
6.7.4. Proxy-State AVP
6.8. Auth-Application-Id AVP
6.9. Acct-Application-Id AVP
6.10. Inband-Security-Id AVP
6.11. Vendor-Specific-Application-Id AVP
6.12. Redirect-Host AVP
6.13. Redirect-Host-Usage AVP
6.14. Redirect-Max-Cache-Time AVP
6.15. E2E-Sequence AVP
7. Error Handling
7.1. Result-Code AVP
7.1.1. Informational
7.1.2. Success
7.1.3. Protocol Errors
7.1.4. Transient Failures
7.1.5. Permanent Failures
7.2. Error Bit
7.3. Error-Message AVP
7.4. Error-Reporting-Host AVP
7.5. Failed-AVP AVP
7.6. Experimental-Result AVP
7.7. Experimental-Result-Code AVP
8. Diameter User Sessions
8.1. Authorization Session State Machine
8.2. Accounting Session State Machine
8.3. Server-Initiated Re-Auth
8.3.1. Re-Auth-Request
8.3.2. Re-Auth-Answer
8.4. Session Termination
8.4.1. Session-Termination-Request
8.4.2. Session-Termination-Answer
8.5. Aborting a Session
8.5.1. Abort-Session-Request
8.5.2. Abort-Session-Answer
8.6. Inferring Session Termination from Origin-State-Id
8.7. Auth-Request-Type AVP
8.8. Session-Id AVP
8.9. Authorization-Lifetime AVP
8.10. Auth-Grace-Period AVP
8.11. Auth-Session-State AVP
8.12. Re-Auth-Request-Type AVP
8.13. Session-Timeout AVP
8.14. User-Name AVP
8.15. Termination-Cause AVP
8.16. Origin-State-Id AVP
8.17. Session-Binding AVP
8.18. Session-Server-Failover AVP
8.19. Multi-Round-Time-Out AVP
8.20. Class AVP
8.21. Event-Timestamp AVP
9. Accounting
9.1. Server Directed Model
9.2. Protocol Messages
9.3. Application Document Requirements
9.4. Fault Resilience
9.5. Accounting Records
9.6. Correlation of Accounting Records
9.7. Accounting Command-Codes
9.7.1. Accounting-Request
9.7.2. Accounting-Answer
9.8. Accounting AVPs
9.8.1. Accounting-Record-Type AVP
9.8.2. Acct-Interim-Interval AVP
9.8.3. Accounting-Record-Number AVP
9.8.4. Acct-Session-Id AVP
9.8.5. Acct-Multi-Session-Id AVP
9.8.6. Accounting-Sub-Session-Id AVP
9.8.7. Accounting-Realtime-Required AVP
10. AVP Occurrence Table
10.1. Base Protocol Command AVP Table
10.2. Accounting AVP Table
11. IANA Considerations
11.1. AVP Header
11.1.1. AVP Code
11.1.2. AVP Flags
11.2. Diameter Header
11.2.1. Command Codes
11.2.2. Command Flags
11.3. Application Identifiers
11.4. AVP Values
11.4.1. Result-Code AVP Values
11.4.2. Accounting-Record-Type AVP Values
11.4.3. Termination-Cause AVP Values
11.4.4. Redirect-Host-Usage AVP Values
11.4.5. Session-Server-Failover AVP Values
11.4.6. Session-Binding AVP Values
11.4.7. Disconnect-Cause AVP Values
11.4.8. Auth-Request-Type AVP Values
11.4.9. Auth-Session-State AVP Values
11.4.10. Re-Auth-Request-Type AVP Values
11.4.11. Accounting-Realtime-Required AVP Values
11.5. Diameter TCP/SCTP Port Numbers
11.6. NAPTR Service Fields
12. Diameter Protocol Related Configurable Parameters
13. Security Considerations
13.1. IPsec Usage
13.2. TLS Usage
13.3. Peer-to-Peer Considerations
14. References
14.1. Normative References
14.2. Informative References
15. Acknowledgements
Appendix A. Diameter Service Template
Appendix B. NAPTR Example
Appendix C. Duplicate Detection
Appendix D. Intellectual Property Statement
Authors' Addresses
Full Copyright Statement
Authentication, Authorization and Accounting (AAA) protocols such as TACACS [TACACS] and RADIUS [RADIUS] were initially deployed to provide dial-up PPP [PPP] and terminal server access. Over time, with the growth of the Internet and the introduction of new access technologies, including wireless, DSL, Mobile IP and Ethernet, routers and network access servers (NAS) have increased in complexity and density, putting new demands on AAA protocols.
Network access requirements for AAA protocols are summarized in [AAAREQ]. These include:
Failover
[RADIUS] 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. This is described in
Section 5.5 and [AAATRANS].
Transmission-level security
[RADIUS] defines an application-layer authentication and integrity
scheme that is required only for use with Response packets. While
[RADEXT] defines an additional authentication and integrity
mechanism, use is only required during Extensible Authentication
Protocol (EAP) sessions. While attribute-hiding is supported,
[RADIUS] does not provide support for per-packet confidentiality.
In accounting, [RADACCT] 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. Since within [IKE] authentication occurs only within Phase 1 prior to the establishment of IPsec SAs in Phase 2, it is typically not possible to define separate trust or authorization schemes for each application. This limits the usefulness of IPsec in inter-domain AAA applications (such as roaming) where it may be desirable to define a distinct certificate hierarchy for use in a AAA deployment. In order to provide universal support for transmission-level security, and enable both intra- and inter-domain AAA deployments, IPsec support is mandatory in Diameter, and TLS support is optional. 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 [ACCMGMT], 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, SCTP) as defined in
[AAATRANS].
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 RADIUS server-initiated messages are defined in [DYNAUTH],
support is optional. This makes it difficult to implement
features such as unsolicited disconnect or
reauthentication/reauthorization on demand across a heterogeneous
deployment. Support for server-initiated messages is mandatory in
Diameter, and is described in Section 8.
Auditability
RADIUS does not define data-object security mechanisms, and as a
result, untrusted proxies may modify attributes or even packet
headers without being detected. Combined with lack of support for
capabilities negotiation, this makes it very difficult to
determine what occurred in the event of a dispute. While
implementation of data object security is not mandatory within
Diameter, these capabilities are supported, and are described in
[AAACMS].
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, described in
[NASREQ], 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 [RADIUS]. Through DNS, Diameter
enables dynamic discovery of peers. Derivation of dynamic session
keys is enabled via transmission-level security.
Roaming support
The ROAMOPS WG provided a survey of roaming implementations
[ROAMREV], detailed roaming requirements [ROAMCRIT], defined the
Network Access Identifier (NAI) [NAI], and documented existing
implementations (and imitations) of RADIUS-based roaming
[PROXYCHAIN]. In order to improve scalability, [PROXYCHAIN]
introduced the concept of proxy chaining via an intermediate
server, facilitating roaming between providers. However, since
RADIUS does not provide explicit support for proxies, and lacks
auditability and transmission-level security features, RADIUS-
based roaming is vulnerable to attack from external parties as
well as susceptible to fraud perpetrated by the roaming partners
themselves. As a result, it is not suitable for wide-scale
deployment on the Internet [PROXYCHAIN]. By providing explicit
support for inter-domain roaming and message routing (Sections 2.7
and 6), auditability [AAACMS], and transmission-layer security
(Section 13) features, Diameter addresses these limitations and
provides for secure and scalable roaming.
In the decade since AAA protocols were first introduced, 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
within embedded devices, given improvements in processor speeds and
the widespread availability of embedded IPsec and TLS
implementations.
The Diameter base protocol provides the following facilities:
- Delivery of AVPs (attribute value pairs)
- Capabilities negotiation
- Error notification
- Extensibility, through addition of new commands and AVPs (required
in [AAAREQ]).
- Basic services necessary for applications, such as handling of
user sessions or accounting
All data delivered by the protocol is in the form of an AVP. 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 added arbitrarily to Diameter messages, so long as the required AVPs are included and AVPs that are explicitly excluded are not included. AVPs are used by the base Diameter protocol to support the following required features:
- Transporting of user authentication information, for the purposes
of enabling the Diameter server to authenticate the user.
- Transporting of service specific authorization information,
between client and servers, allowing the peers to decide whether a
user's access request should be granted.
- Exchanging resource usage information, which MAY be used for
accounting purposes, capacity planning, etc.
- Relaying, proxying and redirecting of Diameter messages through a
server hierarchy.
The Diameter base protocol provides the minimum requirements needed for a AAA protocol, as required by [AAAREQ]. 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 [DIAMMIP], or network access [NASREQ]. It is also possible for the base protocol to be extended for use in new applications, via the addition of new commands or AVPs. At this time the focus of Diameter is 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 2.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 authenticate and/or authorize messages locally; 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.
Currently, the Diameter specification consists of a base
specification (this document), Transport Profile [AAATRANS] and
applications: Mobile IPv4 [DIAMMIP], and NASREQ [NASREQ].
The Transport Profile document [AAATRANS] 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.
The Mobile IPv4 [DIAMMIP] application defines a Diameter application that allows a Diameter server to perform AAA functions for Mobile IPv4 services to a mobile node.
The NASREQ [NASREQ] application defines a Diameter Application that allows a Diameter server to be used in a PPP/SLIP Dial-Up and Terminal Server Access environment. Consideration was given for servers that need to perform protocol conversion between Diameter and RADIUS.
In summary, this document defines the base protocol specification for AAA, which includes support for accounting. The Mobile IPv4 and the NASREQ documents describe applications that use this base specification for Authentication, Authorization and Accounting.
The Diameter protocol is designed to be extensible, using several mechanisms, including:
- Defining new AVP values
- Creating new AVPs
- Creating new authentication/authorization applications
- Creating new accounting applications
- Application authentication procedures
Reuse of existing AVP values, AVPs and Diameter applications are strongly recommended. Reuse simplifies standardization and implementation and avoids potential interoperability issues. It is expected that command codes are reused; new command codes can only be created by IETF Consensus (see Section 11.2.1).
New applications should attempt to reuse AVPs defined in existing applications when possible, as opposed to creating new AVPs. For AVPs of type Enumerated, an application may require a new value to communicate some service-specific information.
In order to allocate a new AVP value, a request MUST be sent to IANA [IANA], along with an explanation of the new AVP value. IANA considerations for Diameter are discussed in Section 11.
When no existing AVP can be used, a new AVP should be created. The new AVP being defined MUST use one of the data types listed in Section 4.2.
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).
In order to create a new AVP, a request MUST be sent to IANA, with a specification for the AVP. The request MUST include the commands that would make use of the AVP.
Every Diameter application specification MUST have an IANA assigned Application Identifier (see Section 2.4) or a vendor specific Application Identifier.
Should a new Diameter usage scenario find itself unable to fit within an existing application without requiring major changes to the specification, it may be desirable to create a new Diameter application. Major changes to an application include:
- Adding new AVPs to the command, which have the "M" bit set.
- Requiring a command that has a different number of round trips to
satisfy a request (e.g., application foo has a command that
requires one round trip, but new application bar has a command
that requires two round trips to complete).
- Adding support for an authentication method requiring definition
of new AVPs for use with the application. Since a new EAP
authentication method can be supported within Diameter without
requiring new AVPs, addition of EAP methods does not require the
creation of a new authentication application.
Creation of a new application should be viewed as a last resort. An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application. Please refer to Section 11.1.1 for details.
In order to justify allocation of a new application identifier, Diameter applications MUST define one Command Code, or add new mandatory AVPs to the ABNF.
The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see Section 3.2). If the Diameter application has accounting requirements, it MUST also specify the AVPs that are to be present in the Diameter Accounting messages (see Section 9.3). However, just because a new authentication application id is required, does not imply that a new accounting application id is required.
When possible, a new Diameter application SHOULD reuse existing Diameter AVPs, in order to avoid defining multiple AVPs that carry similar information.
There are services that only require Diameter accounting. Such services need to define the AVPs carried in the Accounting-Request (ACR)/ Accounting-Answer (ACA) messages, but do not need to define new command codes. An implementation MAY add arbitrary non-mandatory AVPs (AVPs with the "M" bit not set) to any command defined in an
application, including vendor-specific AVPs, without needing to define a new accounting application. Please refer to Section 11.1.1 for details.
Application Identifiers are still required for Diameter capability exchange. Every Diameter accounting application specification MUST have an IANA assigned Application Identifier (see Section 2.4) or a vendor specific Application Identifier.
Every Diameter implementation MUST support accounting. Basic accounting support is sufficient to handle any application that uses the ACR/ACA commands defined in this document, as long as no new mandatory AVPs are added. A mandatory AVP is defined as one which has the "M" bit set when sent within an accounting command, regardless of whether it is required or optional within the ABNF for the accounting application.
The creation of a new accounting application should be viewed as a last resort and MUST NOT be used unless a new command or additional mechanisms (e.g., application defined state machine) is defined within the application, or new mandatory AVPs are added to the ABNF.
Within an accounting command, setting the "M" bit implies that a backend server (e.g., billing server) or the accounting server itself MUST understand the AVP in order to compute a correct bill. If the AVP is not relevant to the billing process, when the AVP is included within an accounting command, it MUST NOT have the "M" bit set, even if the "M" bit is set when the same AVP is used within other Diameter commands (i.e., authentication/authorization commands).
A DIAMETER base accounting implementation MUST be configurable to advertise supported accounting applications in order to prevent the accounting server from accepting accounting requests for unbillable services. The combination of the home domain and the accounting application Id can be used in order to route the request to the appropriate accounting server.
When possible, a new Diameter accounting application SHOULD attempt to reuse existing AVPs, in order to avoid defining multiple AVPs that carry similar information.
If the base accounting is used without any mandatory AVPs, new commands or additional mechanisms (e.g., application defined state machine), then the base protocol defined standard accounting application Id (Section 2.4) MUST be used in ACR/ACA commands.
When possible, applications SHOULD be designed such that new authentication methods MAY be added without requiring changes to the application. This MAY require that new AVP values be assigned to represent the new authentication transform, or any other scheme that produces similar results. When possible, authentication frameworks, such as Extensible Authentication Protocol [EAP], SHOULD be used.
AAA
Authentication, Authorization and Accounting.
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).
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.
Broker
A broker is a business term commonly used in AAA infrastructures.
A broker is either a relay, proxy or redirect agent, and MAY be
operated by roaming consortiums. Depending on the business model,
a broker may either choose to deploy relay agents or proxy
agents.
Diameter Agent
A Diameter Agent is a Diameter node that provides either relay,
proxy, redirect or translation services.
Diameter Client
A Diameter Client is a device at the edge of the network that
performs access control. An example of a Diameter client is a
Network Access Server (NAS) or a Foreign Agent (FA).
Diameter Node
A Diameter node is a host process that implements the Diameter
protocol, and acts either as a Client, Agent or Server.
Diameter Peer
A Diameter Peer is a Diameter Node to which a given Diameter Node
has a direct transport connection.
Diameter Security Exchange
A Diameter Security Exchange is a process through which two
Diameter nodes establish end-to-end security.
Diameter Server
A Diameter Server is one that handles authentication,
authorization and accounting requests for a particular realm. By
its very nature, a Diameter Server MUST support Diameter
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 access device.
End-to-End Security
TLS and IPsec provide hop-by-hop security, or security across a
transport connection. When relays or proxy are involved, this
hop-by-hop security does not protect the entire Diameter user
session. End-to-end security is security between two Diameter
nodes, possibly communicating through Diameter Agents. This
security protects the entire Diameter communications path from the
originating Diameter node to the terminating Diameter node.
Home Realm
A Home Realm is the administrative domain with which the user
maintains an account relationship.
Home Server
See Diameter Server.
Interim accounting
An interim accounting message provides a snapshot of usage during
a user's session. It is typically implemented in order to provide
for partial accounting of a user's session in the case of a device
reboot or other network problem prevents the reception 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 [NAI], 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.
This is typically accomplished by tracking the state of NAS
devices. While proxies typically 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 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. Time constraints are
typically imposed in order to limit financial risk.
Relay Agent or Relay
Relays forward requests and responses based on routing-related
AVPs and realm 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 proxy
agents, redirect agents do not keep state with respect to sessions
or NAS resources.
Roaming Relationships
Roaming relationships include relationships between companies and
ISPs, relationships among peer ISPs within a roaming consortium,
and relationships between an ISP and a roaming consortium.
Security Association
A security association is an association between two endpoints in
a Diameter session which allows the endpoints to communicate with
integrity and confidentially, even in the presence of relays
and/or proxies.
Session
A session is a related progression of events devoted to a
particular activity. Each application SHOULD provide guidelines
as to when a session begins and ends. All Diameter packets with
the same Session-Identifier are considered to be part of the same
session.
Session state
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 by
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 is a stateful Diameter node that performs
protocol translation between Diameter and another AAA protocol,
such as RADIUS.
Transport Connection
A transport connection is a TCP or SCTP connection existing
directly between two Diameter peers, otherwise known as a Peer-
to-Peer Connection.
Upstream
Upstream is used to identify the direction of a particular
Diameter message from the access device towards the home server.
User
The entity requesting or using some resource, in support of which
a Diameter client has generated a request.
The base Diameter protocol may be used by itself for accounting applications, but for use in authentication and authorization it is always extended for a particular application. Two Diameter applications are defined by companion documents: NASREQ [NASREQ],
Mobile IPv4 [DIAMMIP]. These applications are introduced in this document but specified elsewhere. Additional Diameter applications MAY be defined in the future (see Section 11.3).
Diameter Clients MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement the client's service, e.g., NASREQ and/or Mobile IPv4. A Diameter Client that does not support both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X Client" where X is the application which it supports, and not a "Diameter Client".
Diameter Servers MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement the intended service, e.g., NASREQ and/or Mobile IPv4. A Diameter Server that does not support both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X Server" where X is the application which it supports, and not a "Diameter Server".
Diameter Relays and redirect agents are, by definition, protocol transparent, and MUST transparently support the Diameter base protocol, which includes accounting, and all Diameter applications.
Diameter proxies MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement proxied services, e.g., NASREQ and/or Mobile IPv4. A Diameter proxy which does not support also both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X Proxy" where X is the application which it supports, and not a "Diameter Proxy".
The base Diameter protocol concerns itself with capabilities negotiation, how messages are sent and how peers may eventually be abandoned. The base protocol also defines certain rules that apply to all exchanges of messages between Diameter nodes.
Communication between Diameter peers begins with one peer sending a message to another Diameter peer. The set of AVPs included in the message is determined by a particular Diameter application. One AVP that is included to reference a user's session is the Session-Id.
The initial request for authentication and/or authorization of a user would include the Session-Id. The Session-Id is then used in all subsequent messages to identify the user's session (see Section 8 for more information). The communicating party may accept the request, or reject it by returning an answer message with the Result-Code AVP
set to indicate an error occurred. The specific behavior of the Diameter server or client receiving a request depends on the Diameter application employed.
Session state (associated with a Session-Id) MUST be freed upon receipt of the Session-Termination-Request, Session-Termination- Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular Diameter application.
Transport profile is defined in [AAATRANS].
The base Diameter protocol is run on port 3868 of both TCP [TCP] and SCTP [SCTP] transport protocols.
Diameter clients MUST support either TCP or SCTP, while agents and servers MUST support both. Future versions of this specification MAY mandate that clients support SCTP.
A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and MUST be prepared to receive connections on port 3868. A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer in which case a separate connection per process is allowed.
When no transport connection exists with a peer, an attempt to connect SHOULD be periodically made. This behavior is handled via the Tc timer, whose recommended value is 30 seconds. There are certain exceptions to this rule, such as when a peer has terminated the transport connection stating that it does not wish to communicate.
When connecting to a peer and either zero or more transports are specified, SCTP SHOULD be tried first, followed by TCP. See Section 5.2 for more information on peer discovery.
Diameter implementations SHOULD be able to interpret ICMP protocol port unreachable messages as explicit indications that the server is not reachable, subject to security policy on trusting such messages. Diameter implementations SHOULD also be able to interpret a reset from the transport and timed-out connection attempts.
If Diameter receives data up from TCP that cannot be parsed or identified as a Diameter error made by the peer, the stream is compromised and cannot be recovered. The transport connection MUST be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT message (graceful closure is compromised).
The following are guidelines for Diameter implementations that support SCTP:
Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS]. Diameter servers MUST support TLS and IPsec. The Diameter protocol MUST NOT be used without any security mechanism (TLS or IPsec).
It is suggested that IPsec can be used primarily at the edges and in intra-domain traffic, such as using pre-shared keys between a NAS a local AAA proxy. This also eases the requirements on the NAS to support certificates. It is also suggested that inter-domain traffic would primarily use TLS. See Sections 13.1 and 13.2 for more details on IPsec and TLS usage.
Application Identifiers are advertised during the capabilities exchange phase (see Section 5.3). For a given application, advertising support of an application implies that the sender supports all command codes, and the AVPs specified in the associated ABNFs, described in the specification.
An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs. Please refer to Section 11.1.1 for details.
Each Diameter application MUST have an IANA assigned Application Identifier (see Section 11.3). The base protocol does not require an Application Identifier since its support is mandatory. During the capabilities exchange, Diameter nodes inform their peers of locally supported applications. Furthermore, all Diameter messages contain an Application Identifier, which is used in the message forwarding process.
The following Application Identifier values are defined:
Diameter Common Messages 0
NASREQ 1 [NASREQ]
Mobile-IP 2 [DIAMMIP]
Diameter Base Accounting 3
Relay 0xffffffff
Relay and redirect agents MUST advertise the Relay Application Identifier, while all other Diameter nodes MUST advertise locally supported applications. The receiver of a Capabilities Exchange message advertising Relay service MUST assume that the sender supports all current and future applications.
Diameter relay and proxy agents are responsible for finding an upstream server that supports the application of a particular message. If none can be found, an error message is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
This section attempts to provide the reader with an understanding of the difference between connection and session, which are terms used extensively throughout this document.
A connection is a transport level connection between two peers, used to send and receive Diameter messages. A session is a logical concept at the application layer, and is shared between an access device and a server, and is identified via the Session-Id AVP
+--------+ +-------+ +--------+
| Client | | Relay | | Server |
+--------+ +-------+ +--------+
<----------> <---------->
peer connection A peer connection B
<----------------------------->
User session x
Figure 1: Diameter connections and sessions
In the example provided in Figure 1, peer connection A is established between the Client and its local Relay. Peer connection B is established between the Relay and the Server. User session X spans from the Client via the Relay to the Server. Each "user" of a service causes an auth request to be sent, with a unique session identifier. Once accepted by the server, both the client and the server are aware of the session. It is important to note that there is no relationship between a connection and a session, and that Diameter messages for multiple sessions are all multiplexed through a single connection.
The Diameter Peer Table is used in message forwarding, and referenced by the Realm Routing Table. A Peer Table entry contains the following fields:
Host identity
Following the conventions described for the DiameterIdentity
derived AVP data format in Section 4.4. This field contains the
contents of the Origin-Host (Section 6.3) AVP found in the CER or
CEA message.
StatusT
This is the state of the peer entry, and MUST match one of the
values listed in Section 5.6.
Static or Dynamic
Specifies whether a peer entry was statically configured, or
dynamically discovered.
Expiration time
Specifies the time at which dynamically discovered peer table
entries are to be either refreshed, or expired.
TLS Enabled
Specifies whether TLS is to be used when communicating with the
peer.
Additional security information, when needed (e.g., keys, certificates)
All Realm-Based routing lookups are performed against what is commonly known as the Realm Routing Table (see Section 12). A Realm Routing Table Entry contains the following fields:
Realm Name
This is the field that is typically used as a primary key in the
routing table lookups. Note that some implementations perform
their lookups based on longest-match-from-the-right on the realm
rather than requiring an exact match.
Application Identifier
An application is identified by a vendor id and an application id.
For all IETF standards track Diameter applications, the vendor id
is zero. A route entry can have a different destination based on
the application identification AVP of the message. This field
MUST be used as a secondary key field in routing table lookups.
Local Action
The Local Action field is used to identify how a message should be
treated. The following actions are supported:
Server Identifier
One or more servers the message is to be routed to. These servers
MUST also be present in the Peer table. When the Local Action is
set to RELAY or PROXY, this field contains the identity of the
server(s) the message must be routed to. When the Local Action
field is set to REDIRECT, this field contains the identity of one
or more servers the message should be redirected to.
Static or Dynamic
Specifies whether a route entry was statically configured, or
dynamically discovered.
Expiration time
Specifies the time which a dynamically discovered route table
entry expires.
It is important to note that Diameter agents MUST support at least one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents do not need to support all modes of operation in order to conform with the protocol specification, but MUST follow the protocol compliance guidelines in Section 2. Relay agents MUST NOT reorder AVPs, and proxies MUST NOT reorder AVPs.
The routing table MAY include a default entry that MUST be used for any requests not matching any of the other entries. The routing table MAY consist of only such an entry.
When a request is routed, the target server MUST have advertised the
Application Identifier (see Section 2.4) for the given message, or
have advertised itself as a relay or proxy agent. Otherwise, an
error is returned with the Result-Code AVP set to
DIAMETER_UNABLE_TO_DELIVER.
In addition to client and servers, the Diameter protocol introduces relay, proxy, redirect, and translation agents, each of which is defined in Section 1.3. These Diameter agents are useful for several reasons:
- They can distribute administration of systems to a configurable
grouping, including the maintenance of security associations.
- They can be used for concentration of requests from an number of
co-located or distributed NAS equipment sets to a set of like user
groups.
- They can do value-added processing to the requests or responses.
- They can be used for load balancing.
- A complex network will have multiple authentication sources, they
can sort requests and forward towards the correct target.
The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, its 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.
The Proxy-Info AVP allows stateless agents to add local state to a Diameter request, with the guarantee that the same state will be present in the answer. However, the protocol's failover procedures require that agents maintain a copy of pending requests.
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 by expiration. Each authorized session has an expiration, which is communicated by Diameter servers via the Session-Timeout AVP.
Maintaining session state MAY be useful in certain applications, such as:
- Protocol translation (e.g., RADIUS <-> Diameter) - Limiting resources authorized to a particular user - Per user or transaction auditing
A Diameter agent MAY act in a stateful manner for some requests and be stateless for others. A Diameter implementation MAY act as one type of agent for some requests, and as another type of agent for others.
Relay Agents are Diameter agents that accept requests and route messages to other Diameter nodes based on information found in the messages (e.g., Destination-Realm). This routing decision is performed using a list of supported realms, and known peers. This is known as the Realm Routing Table, as is defined further in Section 2.7.
Relays MAY be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (POP). The use of Relays is advantageous since it eliminates the need for NASes to be configured with the necessary security information they would otherwise require to communicate with Diameter servers in other realms. Likewise, this reduces the configuration load on Diameter servers that would otherwise be necessary when NASes are added, changed or deleted.
Relays modify Diameter messages by inserting and removing routing information, but do not modify any other portion of a message. Relays SHOULD NOT maintain session state but MUST maintain transaction state.
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 2. Request | |
| NAS | | DRL | | HMS |
| | 4. Answer | | 3. Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 2: Relaying of Diameter messages
The example provided in Figure 2 depicts a request issued from NAS,
which is an access device, for the user bob@example.com. Prior to
issuing the request, NAS performs a Diameter route lookup, using
"example.com" as the key, and determines that the message is to be
relayed to DRL, which is a Diameter Relay. DRL performs the same
route lookup as NAS, and relays the message to HMS, which is
example.com's Home Diameter Server. HMS identifies that the request
can be locally supported (via the realm), processes the
authentication and/or authorization request, and replies with an
answer, which is routed back to NAS using saved transaction state.
Since Relays do not perform any application level processing, they provide relaying services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier.
Similarly to relays, proxy agents route Diameter messages using the Diameter Routing Table. However, they differ since they modify messages to implement policy enforcement. This requires that proxies maintain the state of their downstream peers (e.g., access devices) to enforce resource usage, provide admission control, and provisioning.
It is important to note that although proxies MAY provide a value-add function for NASes, they do not allow access devices to use end-to- end security, since modifying messages breaks authentication.
Proxies MAY be used in call control centers or access ISPs that provide outsourced connections, they can monitor the number and types of ports in use, and make allocation and admission decisions according to their configuration.
Proxies that wish to limit resources MUST maintain session state. All proxies MUST maintain transaction state.
Since enforcing policies requires an understanding of the service being provided, Proxies MUST only advertise the Diameter applications they support.
Redirect agents are useful in scenarios where the Diameter routing configuration needs to be centralized. An example is a redirect agent that provides services to all members of a consortium, but does not wish to be burdened with relaying all messages between realms. This scenario is advantageous since it does not require that the consortium provide routing updates to its members when changes are made to a member's infrastructure.
Since redirect agents do not relay messages, and only return an answer with the information necessary for Diameter agents to communicate directly, they do not modify messages. Since redirect agents do not receive answer messages, they cannot maintain session state. Further, since redirect agents never relay requests, they are not required to maintain transaction state.
The example provided in Figure 3 depicts a request issued from the access device, NAS, for the user bob@example.com. The message is forwarded by the NAS to its relay, DRL, which does not have a routing entry in its Diameter Routing Table for example.com. DRL has a default route configured to DRD, which is a redirect agent that returns a redirect notification to DRL, as well as HMS' contact information. Upon receipt of the redirect notification, DRL establishes a transport connection with HMS, if one doesn't already exist, and forwards the request to it.
+------+
| |
| DRD |
| |
+------+
^ |
2. Request | | 3. Redirection
| | Notification
| v
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 4. Request | |
| NAS | | DRL | | HMS |
| | 6. Answer | | 5. Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 3: Redirecting a Diameter Message
Since redirect agents do not perform any application level processing, they provide relaying services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier.
A translation agent is a device that provides translation between two protocols (e.g., RADIUS<->Diameter, TACACS+<->Diameter). Translation agents are likely to be used as aggregation servers to communicate with a Diameter infrastructure, while allowing for the embedded systems to be migrated at a slower pace.
Given that the Diameter protocol introduces the concept of long-lived authorized sessions, translation agents MUST be session stateful and MUST maintain transaction state.
Translation of messages can only occur if the agent recognizes the application of a particular request, and therefore translation agents MUST only advertise their locally supported applications.
+------+ ---------> +------+ ---------> +------+
| | RADIUS Request | | Diameter Request | |
| NAS | | TLA | | HMS |
| | RADIUS Answer | | Diameter Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 4: Translation of RADIUS to Diameter
End-to-end security services include confidentiality and message origin authentication. These services are provided by supporting AVP integrity and confidentiality between two peers, communicating through agents.
End-to-end security is provided via the End-to-End security
extension, described in [AAACMS]. The circumstances requiring the
use of end-to-end security are determined by policy on each of the
peers. Security policies, which are not the subject of
standardization, may be applied by next hop Diameter peer or by
destination realm. For example, where TLS or IPsec transmission-
level security is sufficient, there may be no need for end-to-end
security.
End-to-end security policies include:
- Never use end-to-end security.
- Use end-to-end security on messages containing sensitive AVPs.
Which AVPs are sensitive is determined by service provider policy.
AVPs containing keys and passwords should be considered sensitive.
Accounting AVPs may be considered sensitive. Any AVP for which
the P bit may be set or which may be encrypted may be considered
sensitive.
- Always use end-to-end security.
It is strongly RECOMMENDED that all Diameter implementations support end-to-end security.
As noted in Section 2.2, Diameter requires transmission level security to be used on each connection (TLS or IPsec). Therefore, each connection is authenticated, replay and integrity protected and confidential on a per-packet basis.
In addition to authenticating each connection, each connection as well as the entire session MUST also be authorized. Before initiating a connection, a Diameter Peer MUST check that its peers are authorized to act in their roles. For example, a Diameter peer may be authentic, but that does not mean that it is authorized to act as a Diameter Server advertising a set of Diameter applications.
Prior to bringing up a connection, authorization checks are performed at each connection along the path. Diameter capabilities negotiation (CER/CEA) also MUST be carried out, in order to determine what Diameter applications are supported by each peer. Diameter sessions MUST be routed only through authorized nodes that have advertised support for the Diameter application required by the session.
As noted in Section 6.1.8, a relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from.
The home Diameter server, prior to authorizing a session, MUST check the Route-Record AVPs to make sure that the route traversed by the request is acceptable. For example, administrators within the home realm may not wish to honor requests that have been routed through an untrusted realm. By authorizing a request, the home Diameter server is implicitly indicating its willingness to engage in the business transaction as specified by the contractual relationship between the server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error message (see Section 7.1.5) is sent if the route traversed by the request is unacceptable.
A home realm may also wish to check that each accounting request message corresponds to a Diameter response authorizing the session. Accounting requests without corresponding authorization responses SHOULD be subjected to further scrutiny, as should accounting requests indicating a difference between the requested and provided service.
Similarly, the local Diameter agent, on receiving a Diameter response authorizing a session, MUST check the Route-Record AVPs to make sure that the route traversed by the response is acceptable. At each step, forwarding of an authorization response is considered evidence of a willingness to take on financial risk relative to the session. A local realm may wish to limit this exposure, for example, by establishing credit limits for intermediate realms and refusing to accept responses which would violate those limits. By issuing an accounting request corresponding to the authorization response, the local realm implicitly indicates its agreement to provide the service indicated in the authorization response. If the service cannot be provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error message MUST be sent within the accounting request; a Diameter client receiving an authorization response for a service that it cannot perform MUST NOT substitute an alternate service, and then send accounting requests for the alternate service instead.
A summary of the Diameter header format is shown below. The fields are transmitted in network byte order.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command flags | Command-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop-by-Hop Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Version
This Version field MUST be set to 1 to indicate Diameter Version
1.
Message Length
The Message Length field is three octets and indicates the length
of the Diameter message including the header fields.
Command Flags
The Command Flags field is eight bits. The following bits are
assigned:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R P E T r r r r|
+-+-+-+-+-+-+-+-+
R(equest) - If set, the message is a request. If cleared, the
message is an answer.
P(roxiable) - If set, the message MAY be proxied, relayed or
redirected. If cleared, the message MUST be
locally processed.
E(rror) - If set, the message contains a protocol error,
and the message will not conform to the ABNF
described for this command. Messages with the 'E'
bit set are commonly referred to as error
messages. This bit MUST NOT be set in request
messages. See Section 7.2.
T(Potentially re-transmitted message)
- This flag is set after a link failover procedure,
to aid the removal of duplicate requests. It is
set when resending requests not yet acknowledged,
as an indication of a possible duplicate due to a
link failure. This bit MUST be cleared when
sending a request for the first time, otherwise
the sender MUST set this flag. Diameter agents
only need to be concerned about the number of
requests they send based on a single received
request; retransmissions by other entities need
not be tracked. Diameter agents that receive a
request with the T flag set, MUST keep the T flag
set in the forwarded request. This flag MUST NOT
be set if an error answer message (e.g., a
protocol error) has been received for the earlier
message. It can be set only in cases where no
answer has been received from the server for a
request and the request is sent again. This flag
MUST NOT be set in answer messages.
r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver.
Command-Code
The Command-Code field is three octets, and is used in order to
communicate the command associated with the message. The 24-bit
address space is managed by IANA (see Section 11.2.1).
Command-Code values 16,777,214 and 16,777,215 (hexadecimal values FFFFFE -FFFFFF) are reserved for experimental use (See Section 11.3).
Application-ID
Application-ID is four octets and is used to identify to which
application the message is applicable for. The application can be
an authentication application, an accounting application or a
vendor specific application. See Section 11.3 for the possible
values that the application-id may use.
The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message.
Hop-by-Hop Identifier
The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
network byte order) and aids in matching requests and replies.
The sender MUST ensure that the Hop-by-Hop identifier in a request
is unique on a given connection at any given time, and MAY attempt
to ensure that the number is unique across reboots. The sender of
an Answer message MUST ensure that the Hop-by-Hop Identifier field
contains the same value that was found in the corresponding
request. The Hop-by-Hop identifier is normally a monotonically
increasing number, whose start value was randomly generated. An
answer message that is received with an unknown Hop-by-Hop
Identifier MUST be discarded.
End-to-End Identifier
The End-to-End Identifier is an unsigned 32-bit integer field (in
network byte order) and is used to detect duplicate messages.
Upon reboot implementations MAY set the high order 12 bits to
contain the low order 12 bits of current time, and the low order
20 bits to a random value. Senders of request messages MUST
insert a unique identifier on each message. The identifier MUST
remain locally unique for a period of at least 4 minutes, even
across reboots. The originator of an Answer message MUST ensure
that the End-to-End Identifier field contains the same value that
was found in the corresponding request. The End-to-End Identifier
MUST NOT be modified by Diameter agents of any kind. The
combination of the Origin-Host (see Section 6.3) and this field is
used to detect duplicates. Duplicate requests SHOULD cause the
same answer to be transmitted (modulo the hop-by-hop Identifier
field and any routing AVPs that may be present), and MUST NOT
affect any state that was set when the original request was
processed. Duplicate answer messages that are to be locally
consumed (see Section 6.2) SHOULD be silently discarded.
AVPs
AVPs are a method of encapsulating information relevant to the
Diameter message. See Section 4 for more information on AVPs.
Each command Request/Answer pair is assigned a command code, and the sub-type (i.e., request or answer) is identified via the 'R' bit in the Command Flags field of the Diameter header.
Every Diameter message MUST contain a command code in its header's Command-Code field, which is used to determine the action that is to be taken for a particular message. The following Command Codes are defined in the Diameter base protocol:
Command-Name Abbrev. Code Reference
--------------------------------------------------------
Abort-Session-Request ASR 274 8.5.1
Abort-Session-Answer ASA 274 8.5.2
Accounting-Request ACR 271 9.7.1
Accounting-Answer ACA 271 9.7.2
Capabilities-Exchange- CER 257 5.3.1
Request
Capabilities-Exchange- CEA 257 5.3.2
Answer
Device-Watchdog-Request DWR 280 5.5.1
Device-Watchdog-Answer DWA 280 5.5.2
Disconnect-Peer-Request DPR 282 5.4.1
Disconnect-Peer-Answer DPA 282 5.4.2
Re-Auth-Request RAR 258 8.3.1
Re-Auth-Answer RAA 258 8.3.2
Session-Termination- STR 275 8.4.1
Request
Session-Termination- STA 275 8.4.2
Answer
Every Command Code defined MUST include a corresponding ABNF specification, which is used to define the AVPs that MUST or MAY be present. The following format is used in the definition:
command-def = command-name "::=" diameter-message
command-name = diameter-name
diameter-name = ALPHA *(ALPHA / DIGIT / "-")
diameter-message = header [ *fixed] [ *required] [ *optional]
[ *fixed]
header = "<" Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
application-id = 1*DIGIT
command-id = 1*DIGIT
; The Command Code assigned to the command
r-bit = ", REQ"
; If present, the 'R' bit in the Command
; Flags is set, indicating that the message
; is a request, as opposed to an answer.
p-bit = ", PXY"
; If present, the 'P' bit in the Command
; Flags is set, indicating that the message
; is proxiable.
e-bit = ", ERR"
; If present, the 'E' bit in the Command
; Flags is set, indicating that the answer
; message contains a Result-Code AVP in
; the "protocol error" class.
fixed = [qual] "<" avp-spec ">"
; Defines the fixed position of an AVP
required = [qual] "{" avp-spec "}"
; The AVP MUST be present and can appear
; anywhere in the message.
optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name which is included
; in a fixed or required rule. The AVP can
; appear anywhere in the message.
qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 Section 6.6.
; The absence of any qualifiers depends on whether
; it precedes a fixed, required, or optional
; rule. If a fixed or required rule has no
; qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be
; present.
;
; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above).
; These braces cannot be used to express
; optional fixed rules (such as an optional
; ICV at the end). To do this, the convention
; is '0*1fixed'.
min = 1*DIGIT
; The minimum number of times the element may
; be present. The default value is zero.
max = 1*DIGIT
; The maximum number of times the element may
; be present. The default value is infinity. A
; value of zero implies the AVP MUST NOT be
; present.
avp-spec = diameter-name
; The avp-spec has to be an AVP Name, defined
; in the base or extended Diameter
; specifications.
avp-name = avp-spec / "AVP"
; The string "AVP" stands for *any* arbitrary
; AVP Name, which does not conflict with the
; required or fixed position AVPs defined in
; the command code definition.
The following is a definition of a fictitious command code:
Example-Request ::= < "Diameter-Header: 9999999, REQ, PXY >
{ User-Name }
* { Origin-Host }
* [ AVP
Diameter command names typically includes one or more English words followed by the verb Request or Answer. Each English word is delimited by a hyphen. A three-letter acronym for both the request and answer is also normally provided.
An example is a message set used to terminate a session. The command name is Session-Terminate-Request and Session-Terminate-Answer, while the acronyms are STR and STA, respectively.
Both the request and the answer for a given command share the same command code. The request is identified by the R(equest) bit in the Diameter header set to one (1), to ask that a particular action be performed, such as authorizing a user or terminating a session. Once the receiver has completed the request it issues the corresponding answer, which includes a result code that communicates one of the following:
- The request was successful
- The request failed
- An additional request must be sent to provide information the peer
requires prior to returning a successful or failed answer.
- The receiver could not process the request, but provides
information about a Diameter peer that is able to satisfy the
request, known as redirect.
Additional information, encoded within AVPs, MAY also be included in answer messages.
Diameter AVPs carry specific authentication, accounting,
authorization, routing and security information as well as
configuration details for the request and reply.
Some AVPs MAY be listed more than once. The effect of such an AVP is specific, and is specified in each case by the AVP description.
Each AVP of type OctetString MUST be padded to align on a 32-bit boundary, while other AVP types align naturally. A number of zero- valued bytes are added to the end of the AVP Data field till a word boundary is reached. The length of the padding is not reflected in the AVP Length field.
The fields in the AVP header MUST be sent in network byte order. The format of the header is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
The AVP Code, combined with the Vendor-Id field, identifies the
attribute uniquely. AVP numbers 1 through 255 are reserved for
backward compatibility with RADIUS, without setting the Vendor-Id
field. AVP numbers 256 and above are used for Diameter, which are
allocated by IANA (see Section 11.1).
AVP Flags
The AVP Flags field informs the receiver how each attribute must
be handled. The 'r' (reserved) bits are unused and SHOULD be set
to 0. Note that subsequent Diameter applications MAY define
additional bits within the AVP Header, and an unrecognized bit
SHOULD be considered an error. The 'P' bit indicates the need for
encryption for end-to-end security.
The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs.
The 'M' bit MUST be set according to the rules defined for the AVP containing it. In order to preserve interoperability, a Diameter implementation MUST be able to exclude from a Diameter message any Mandatory AVP which is neither defined in the base Diameter protocol nor in any of the Diameter Application specifications governing the message in which it appears. It MAY do this in one of the following ways:
1) If a message is rejected because it contains a Mandatory AVP which is neither defined in the base Diameter standard nor in any of the Diameter Application specifications governing the message in which it appears, the implementation may resend the message without the AVP, possibly inserting additional standard AVPs instead.
2) A configuration option may be provided on a system wide, per peer, or per realm basis that would allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to avoid interoperability problems.
Diameter implementations are required to support all Mandatory AVPs which are allowed by the message's formal syntax and defined either in the base Diameter standard or in one of the Diameter Application specifications governing the message.
AVPs with the 'M' bit cleared are informational only and a receiver that receives a message with such an AVP that is not supported, or whose value is not supported, MAY simply ignore the AVP.
The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space.
Unless otherwise noted, AVPs will have the following default AVP Flags field settings:
The 'M' bit MUST be set. The 'V' bit MUST NOT be set.
AVP Length
The AVP Length field is three octets, and indicates the number of
octets in this AVP including the AVP Code, AVP Length, AVP Flags,
Vendor-ID field (if present) and the AVP data. If a message is
received with an invalid attribute length, the message SHOULD be
rejected.
The AVP Header contains one optional field. This field is only present if the respective bit-flag is enabled.
Vendor-ID
The Vendor-ID field is present if the 'V' bit is set in the AVP
Flags field. The optional four-octet Vendor-ID field contains the
IANA assigned "SMI Network Management Private Enterprise Codes"
[ASSIGNNO] value, encoded in network byte order. Any vendor
wishing to implement a vendor-specific Diameter AVP MUST use their
own Vendor-ID along with their privately managed AVP address
space, guaranteeing that they will not collide with any other
vendor's vendor-specific AVP(s), nor with future IETF
applications.
A vendor ID value of zero (0) corresponds to the IETF adopted AVP values, as managed by the IANA. Since the absence of the vendor ID field implies that the AVP in question is not vendor specific, implementations MUST NOT use the zero (0) vendor ID.
The Data field is zero or more octets and contains information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the following base data types or a data type derived from the base data types. In the event that a new Basic AVP Data Format is needed, a new version of this RFC must be created.
OctetString
The data contains arbitrary data of variable length. Unless
otherwise noted, the AVP Length field MUST be set to at least 8
(12 if the 'V' bit is enabled). AVP Values of this type that are
not a multiple of four-octets in length is followed by the
necessary padding so that the next AVP (if any) will start on a
32-bit boundary.
Integer32
32 bit signed value, in network byte order. The AVP Length field
MUST be set to 12 (16 if the 'V' bit is enabled).
Integer64
64 bit signed value, in network byte order. The AVP Length field
MUST be set to 16 (20 if the 'V' bit is enabled).
Unsigned32
32 bit unsigned value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the 'V' bit is enabled).
Unsigned64
64 bit unsigned value, in network byte order. The AVP Length
field MUST be set to 16 (20 if the 'V' bit is enabled).
Float32
This represents floating point values of single precision as
described by [FLOATPOINT]. The 32-bit value is transmitted in
network byte order. The AVP Length field MUST be set to 12 (16 if
the 'V' bit is enabled).
Float64
This represents floating point values of double precision as
described by [FLOATPOINT]. The 64-bit value is transmitted in
network byte order. The AVP Length field MUST be set to 16 (20 if
the 'V' bit is enabled).
Grouped
The Data field is specified as a sequence of AVPs. Each of these
AVPs follows - in the order in which they are specified -
including their headers and padding. The AVP Length field is set
to 8 (12 if the 'V' bit is enabled) plus the total length of all
included AVPs, including their headers and padding. Thus the AVP
length field of an AVP of type Grouped is always a multiple of 4.
In addition to using the Basic AVP Data Formats, applications may define data formats derived from the Basic AVP Data Formats. An application that defines new AVP Derived Data Formats MUST include them in a section entitled "AVP Derived Data Formats", using the same format as the definitions below. Each new definition must be either defined or listed with a reference to the RFC that defines the format.
The below AVP Derived Data Formats are commonly used by applications.
Address
The Address format is derived from the OctetString AVP Base
Format. It is a discriminated union, representing, for example a
32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most
significant octet first. The first two octets of the Address
AVP represents the AddressType, which contains an Address Family defined in [IANAADFAM]. The AddressType is used to discriminate the content and format of the remaining octets.
Time
The Time format is derived from the OctetString AVP Base Format.
The string MUST contain four octets, in the same format as the
first four bytes are in the NTP timestamp format. The NTP
Timestamp format is defined in chapter 3 of [SNTP].
This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. SNTP [SNTP] describes a procedure to extend the time to 2104. This procedure MUST be supported by all DIAMETER nodes.
UTF8String
The UTF8String format is derived from the OctetString AVP Base
Format. This is a human readable string represented using the
ISO/IEC IS 10646-1 character set, encoded as an OctetString using
the UTF-8 [UFT8] transformation format described in RFC 2279.
Since additional code points are added by amendments to the 10646 standard from time to time, implementations MUST be prepared to encounter any code point from 0x00000001 to 0x7fffffff. Byte sequences that do not correspond to the valid encoding of a code point into UTF-8 charset or are outside this range are prohibited.
The use of control codes SHOULD be avoided. When it is necessary to represent a new line, the control code sequence CR LF SHOULD be used.
The use of leading or trailing white space SHOULD be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, MAY be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 charset is identical to the US-ASCII charset.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of an UTF8String in octets may be different from the number of characters encoded.
Note that the AVP Length field of an UTF8String is measured in octets, not characters.
DiameterIdentity
The DiameterIdentity format is derived from the OctetString AVP
Base Format.
DiameterIdentity = FQDN
DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection and routing loop detection.
The contents of the string MUST be the FQDN of the Diameter node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN should be picked at startup, and used as the only DiameterIdentity for that node, whatever the connection it is sent on.
DiameterURI
The DiameterURI MUST follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below:
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used
FQDN = Fully Qualified Host Name
port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections.
; If absent,
; the default Diameter port (3868) is
; assumed.
transport = ";transport=" transport-protocol
; One of the transports used to listen
; for incoming connections. If absent,
; the default SCTP [SCTP] protocol is
; assumed. UDP MUST NOT be used when
; the aaa-protocol field is set to
; diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol
; If absent, the default AAA protocol
; is diameter.
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
The following are examples of valid Diameter host identities:
aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radius
Enumerated
Enumerated is derived from the Integer32 AVP Base Format. The
definition contains a list of valid values and their
interpretation and is described in the Diameter application
introducing the AVP.
IPFilterRule
The IPFilterRule format is derived from the OctetString AVP Base
Format. It uses the ASCII charset. Packets may be filtered based
on the following information that is associated with it:
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny.
IPFilterRule filters MUST follow the format:
action dir proto from src to dst [options]
action permit - Allow packets that match the rule.
deny - Drop packets that match the rule.
dir "in" is from the terminal, "out" is to the
terminal.
proto An IP protocol specified by number. The "ip"
keyword means any protocol will match.
src and dst <address/mask> [ports]
The <address/mask> may be specified as:
ipno An IPv4 or IPv6 number in dotted-
quad or canonical IPv6 form. Only
this exact IP number will match the
rule.
ipno/bits An IP number as above with a mask
width of the form 1.2.3.4/24. In
this case, all IP numbers from
1.2.3.0 to 1.2.3.255 will match.
The bit width MUST be valid for the
IP version and the IP number MUST
NOT have bits set beyond the mask.
For a match to occur, the same IP
version must be present in the
packet that was used in describing
the IP address. To test for a
particular IP version, the bits part
can be set to zero. The keyword
"any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned"
is the address or set of addresses
assigned to the terminal. For IPv4,
a typical first rule is often "deny
in ip! assigned"
The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers.
With the TCP, UDP and SCTP protocols, optional ports may be specified as:
{port/port-port}[,ports[,...]]
The '-' notation specifies a range of ports (including boundaries).
Fragmented packets that have a non-zero offset
(i.e., not the first fragment) will never match
a rule that has one or more port
specifications. See the frag option for
details on matching fragmented packets.
options:
frag Match if the packet is a fragment and this is not
the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or
TCP/UDP port specifications.
ipoptions spec
Match if the IP header contains the comma
separated list of options specified in spec. The
supported IP options are:
ssrr (strict source route), lsrr (loose source
route), rr (record packet route) and ts
(timestamp). The absence of a particular option
may be denoted with a '!'.
tcpoptions spec
Match if the TCP header contains the comma
separated list of options specified in spec. The
supported TCP options are:
mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'.
established
TCP packets only. Match packets that have the RST
or ACK bits set.
setup TCP packets only. Match packets that have the SYN
bit set but no ACK bit.
tcpflags spec
TCP packets only. Match if the TCP header
contains the comma separated list of flags
specified in spec. The supported TCP flags are:
fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets.
icmptypes types
ICMP packets only. Match if the ICMP type is in
the list types. The list may be specified as any
combination of ranges or individual types
separated by commas. Both the numeric values and
the symbolic values listed below can be used. The
supported ICMP types are:
echo reply (0), destination unreachable (3),
source quench (4), redirect (5), echo request
(8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13),
timestamp reply (14), information request (15),
information reply (16), address mask request (17)
and address mask reply (18).
There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls.
An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure.
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations.
QoSFilterRule
The QosFilterRule format is derived from the OctetString AVP Base
Format. It uses the ASCII charset. Packets may be marked or
metered based on the following information that is associated with
it:
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
DSCP values (no mask or range)
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is treated as best effort. An access device that is unable to interpret or apply a QoS rule SHOULD NOT terminate the session.
QoSFilterRule filters MUST follow the format:
action dir proto from src to dst [options]
tag - Mark packet with a specific DSCP
[DIFFSERV]. The DSCP option MUST be
included.
meter - Meter traffic. The metering options
MUST be included.
dir The format is as described under IPFilterRule.
proto The format is as described under
IPFilterRule.
src and dst The format is as described under IPFilterRule.
The Diameter protocol allows AVP values of type 'Grouped.' This implies that the Data field is actually a sequence of AVPs. It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them. AVPs within an AVP of type Grouped have the same padding requirements as non-Grouped AVPs, as defined in Section 4.
The AVP Code numbering space of all AVPs included in a Grouped AVP is the same as for non-grouped AVPs. Further, if any of the AVPs encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, the Grouped AVP itself MUST also include the 'M' bit set.
Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [ABNF] (with modifications), as defined below.
grouped-avp-def = name "::=" avp
name-fmt = ALPHA *(ALPHA / DIGIT / "-")
name = name-fmt
; The name has to be the name of an AVP,
; defined in the base or extended Diameter
; specifications.
avp = header [ *fixed] [ *required] [ *optional]
[ *fixed]
header = "<" "AVP-Header:" avpcode [vendor] ">"
avpcode = 1*DIGIT
; The AVP Code assigned to the Grouped AVP
vendor = 1*DIGIT
; The Vendor-ID assigned to the Grouped AVP.
; If absent, the default value of zero is
; used.
The Example-AVP (AVP Code 999999) is of type Grouped and is used to clarify how Grouped AVP values work. The Grouped Data field has the following ABNF grammar:
Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]
An Example-AVP with Grouped Data follows.
The Origin-Host AVP is required (Section 6.3). In this case:
Origin-Host = "example.com".
One or more Session-Ids must follow. Here there are two:
Session-Id =
"grump.example.com:33041;23432;893;0AF3B81"
Session-Id =
"grump.example.com:33054;23561;2358;0AF3B82"
optional AVPs included are
Recovery-Policy = <binary>
2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
Futuristic-Acct-Record = <binary>
fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
d3427475e49968f841
The data for the optional AVPs is represented in hex since the format of these AVPs is neither known at the time of definition of the Example-AVP group, nor (likely) at the time when the example instance of this AVP is interpreted - except by Diameter implementations which support the same set of AVPs. The encoding example illustrates how padding is used and how length fields are calculated. Also note that AVPs may be present in the Grouped AVP value which the receiver cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record AVPs).
This AVP would be encoded as follows:
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code = 999999), Length = 468 |
+-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
72 | Session-Id AVP Header (AVP Code = 263), Length = 51 |
+-------+-------+-------+-------+-------+-------+-------+-------+
80 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 |
+-------+-------+-------+-------+-------+-------+-------+-------+
120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137|
+-------+-------+-------+-------+-------+-------+-------+-------+
336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
464 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+
The following table describes the Diameter AVPs defined in the base
protocol, their AVP Code values, types, possible flag values and
whether the AVP MAY be encrypted. For the originator of a Diameter
message, "Encr" (Encryption) means that if a message containing that
AVP is to be sent via a Diameter agent (proxy, redirect or relay)
then the message MUST NOT be sent unless there is end-to-end security
between the originator and the recipient and integrity /
confidentiality protection is offered for this AVP OR the originator
has locally trusted configuration that indicates that end-to-end
security is not needed. Similarly, for the originator of a Diameter
message, a "P" in the "MAY" column means that if a message containing
that AVP is to be sent via a Diameter agent (proxy, redirect or
relay) then the message MUST NOT be sent unless there is end-to-end
security between the originator and the recipient or the originator
has locally trusted configuration that indicates that end-to-end
security is not needed.
Due to space constraints, the short form DiamIdent is used to represent DiameterIdentity.
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Acct- 85 9.8.2 Unsigned32 | M | P | | V | Y |
Interim-Interval | | | | | |
Accounting- 483 9.8.7 Enumerated | M | P | | V | Y |
Realtime-Required | | | | | |
Acct- 50 9.8.5 UTF8String | M | P | | V | Y |
Multi-Session-Id | | | | | |
Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y |
Record-Number | | | | | |
Accounting- 480 9.8.1 Enumerated | M | P | | V | Y |
Record-Type | | | | | |
Accounting- 44 9.8.4 OctetString| M | P | | V | Y |
Session-Id | | | | | |
Accounting- 287 9.8.6 Unsigned64 | M | P | | V | Y |
Sub-Session-Id | | | | | |
Acct- 259 6.9 Unsigned32 | M | P | | V | N |
Application-Id | | | | | |
Auth- 258 6.8 Unsigned32 | M | P | | V | N |
Application-Id | | | | | |
Auth-Request- 274 8.7 Enumerated | M | P | | V | N |
Type | | | | | |
Authorization- 291 8.9 Unsigned32 | M | P | | V | N |
Lifetime | | | | | |
Auth-Grace- 276 8.10 Unsigned32 | M | P | | V | N |
Period | | | | | |
Auth-Session- 277 8.11 Enumerated | M | P | | V | N |
State | | | | | |
Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N |