[RFCs/IDs] [Plain Text] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 10 11
12 13 14 15 16 17 RFC 3588
AAA Working Group Pat R. Calhoun
Internet-Draft Black Storm Networks
Category: Standards Track John Loughney
<draft-ietf-aaa-diameter-17.txt> Nokia
Erik Guttman
Sun Microsystems, Inc.
Glen Zorn
Cisco Systems, Inc.
Jari Arkko
Ericsson
December 2002
Diameter Base Protocol
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2002. All Rights Reserved.
Calhoun et al. expires June 2003 [Page 1]
Internet-Draft December 2002
Abstract
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 draft 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.
Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[KEYWORD].
Table of Contents
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
Calhoun et al. expires June 2003 [Page 2]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 3]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 4]
Internet-Draft December 2002
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 Accounting-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
Calhoun et al. expires June 2003 [Page 5]
Internet-Draft December 2002
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
14.2 Non-Normative
15 Acknowledgements
16 Authors' Addresses
17 Full Copyright Statement
18 Expiration Date
Appendix A. Diameter Service Template
Appendix B. NAPTR Example
Appendix C. Duplicate Detection
Appendix D. Intellectual Property Considerations
Calhoun et al. expires June 2003 [Page 6]
Internet-Draft December 2002
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 [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,
Calhoun et al. expires June 2003 [Page 7]
Internet-Draft December 2002
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 s. 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).
Calhoun et al. expires June 2003 [Page 8]
Internet-Draft December 2002
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.
1.1 Diameter Protocol
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
Calhoun et al. expires June 2003 [Page 9]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 10]
Internet-Draft December 2002
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).
1.2.1 Defining New AVP Values
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.
Calhoun et al. expires June 2003 [Page 11]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 12]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 13]
Internet-Draft December 2002
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.
1.2.5 Application Authentication Procedures
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.4 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).
Calhoun et al. expires June 2003 [Page 14]
Internet-Draft December 2002
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.
Calhoun et al. expires June 2003 [Page 15]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 16]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 17]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 18]
Internet-Draft December 2002
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.
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
Calhoun et al. expires June 2003 [Page 19]
Internet-Draft December 2002
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.
2.1 Transport
Transport profile is defined in [AAATRANS].
The base Diameter protocol is run on port TBD of both TCP [TCP] and
SCTP [SCTP] transport protocols (for interoperability test purposes
port 1812 will be used until IANA assigns a port to the protocol).
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 TBD. 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.
Calhoun et al. expires June 2003 [Page 20]
Internet-Draft December 2002
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.
2.3 Diameter Application Compliance
Application Identifiers are advertised during the capabilities
Calhoun et al. expires June 2003 [Page 21]
Internet-Draft December 2002
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.
2.4 Application Identifiers
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.
2.5 Connections vs. Sessions
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
Calhoun et al. expires June 2003 [Page 22]
Internet-Draft December 2002
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.
2.6 Peer Table
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.3. This
field contains the contents of the Origin-Host (section 6.3) AVP
found in the CER or CEA message.
- Status. 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)
2.7 Realm-Based Routing Table
Calhoun et al. expires June 2003 [Page 23]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 24]
Internet-Draft December 2002
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.
2.8 Role of Diameter Agents
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
Calhoun et al. expires June 2003 [Page 25]
Internet-Draft December 2002
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.
2.8.1 Relay Agents
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,
Calhoun et al. expires June 2003 [Page 26]
Internet-Draft December 2002
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.
2.8.2 Proxy Agents
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
Calhoun et al. expires June 2003 [Page 27]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 28]
Internet-Draft December 2002
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
2.9 End-to-End Security Framework
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.
Calhoun et al. expires June 2003 [Page 29]
Internet-Draft December 2002
2.10 Diameter Path Authorization
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
Calhoun et al. expires June 2003 [Page 30]
Internet-Draft December 2002
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.
3 Diameter Header
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:
Calhoun et al. expires June 2003 [Page 31]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 32]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 33]
Internet-Draft December 2002
AVPs are a method of encapsulating information relevant to the
Diameter message. See section 4 for more information on AVPs.
3.1 Command Codes
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
3.2 Command Code ABNF specification
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 / "-")
Calhoun et al. expires June 2003 [Page 34]
Internet-Draft December 2002
diameter-message = header [ *fixed] [ *required] [ *optional]
[ *fixed]
header = "<" Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] ">"
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.
Calhoun et al. expires June 2003 [Page 35]
Internet-Draft December 2002
;
; 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 ]
3.3 Diameter Command Naming Conventions
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.
Calhoun et al. expires June 2003 [Page 36]
Internet-Draft December 2002
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.
4 Diameter AVPs
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.
4.1 AVP Header
The fields in the AVP header MUST be sent in network byte order. The
format of the header is:
Calhoun et al. expires June 2003 [Page 37]
Internet-Draft December 2002
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.
Calhoun et al. expires June 2003 [Page 38]
Internet-Draft December 2002
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.
4.1.1 Optional Header Elements
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.
Calhoun et al. expires June 2003 [Page 39]
Internet-Draft December 2002
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.
4.2 Basic AVP Data Formats
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
Calhoun et al. expires June 2003 [Page 40]
Internet-Draft December 2002
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.
4.3 Derived AVP Data Formats
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.
Calhoun et al. expires June 2003 [Page 41]
Internet-Draft December 2002
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
Calhoun et al. expires June 2003 [Page 42]
Internet-Draft December 2002
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 (TBD) 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
Calhoun et al. expires June 2003 [Page 43]
Internet-Draft December 2002
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]
Calhoun et al. expires June 2003 [Page 44]
Internet-Draft December 2002
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
specificatio