1. Introduction
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 [RFC3162prop] 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.
1.1.1. Description of the Document Set
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.
1.2. Approach to Extensibility
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.
1.2.2. Creating New AVPs
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.
1.2.3. Creating New Authentication Applications
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.
1.2.4. Creating New Accounting Applications
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.
1.3. Terminology
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.
