2. Protocol Overview
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).
2.1.1. SCTP Guidelines
The following are guidelines for Diameter implementations that
support SCTP:
1. For interoperability: All Diameter nodes MUST be prepared to
receive Diameter messages on any SCTP stream in the association.
2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP
streams available to the association to prevent head-of-the-line
blocking.
2.2. Securing Diameter Messages
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:
1. LOCAL - Diameter messages that resolve to a route entry with
the Local Action set to Local can be satisfied locally, and do
not need to be routed to another server.
2. RELAY - All Diameter messages that fall within this category
MUST be routed to a next hop server, without modifying any
non-routing AVPs. See Section 6.1.8 for relaying guidelines
3. PROXY - All Diameter messages that fall within this category
MUST be routed to a next hop server. The local server MAY
apply its local policies to the message by including new AVPs
to the message prior to routing. See Section 6.1.8 for
proxying guidelines.
4. REDIRECT - Diameter messages that fall within this category
MUST have the identity of the home Diameter server(s) appended,
and returned to the sender of the message. See Section 6.1.7
for redirect guidelines.
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.
2.8.3. Redirect Agents
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.
2.8.4. Translation Agents
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.
