Diameter (protocol)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Diameter is an authentication, authorization, and accounting protocol for computer networks. It evolved from and replaces the much less capable RADIUS protocol that preceded it.

Diameter Applications extend the base protocol by adding new commands and/or attributes, such as those for use of the Extensible Authentication Protocol (EAP).

Comparison with RADIUS[edit]

The name is a play on words, derived from the RADIUS protocol, which is the predecessor (a diameter is twice the radius). Diameter is not directly backwards compatible but provides an upgrade path for RADIUS. The main features provided by Diameter but lacking in RADIUS are:

  • Reliable transport protocols (TCP or SCTP, not UDP)
  • Network or transport layer security (IPsec or TLS)
  • Transition support for RADIUS, although Diameter is not fully compatible with RADIUS
  • Larger address space for attribute-value pairs (AVPs) and identifiers (32 bits instead of 8 bits)
  • Client–server protocol, with exception of supporting some server-initiated messages as well
  • Both stateful and stateless models can be used
  • Dynamic discovery of peers (using DNS SRV and NAPTR)
  • Capability negotiation
  • Supports application layer acknowledgements, defines failover methods and state machines (RFC 3539)
  • Error notification
  • Better roaming support
  • More easily extended; new commands and attributes can be defined
  • Aligned on 32-bit boundaries
  • Basic support for user-sessions and accounting

Applications[edit]

A Diameter Application is not a software application but is a protocol based on the Diameter base protocol defined in RFC 6733 (Obsoletes: RFC 3588). Each application is defined by an application identifier and can add new command codes and/or new mandatory AVPs. Adding a new optional AVP does not require a new application.

Examples of Diameter applications:

Both the HSS and the SLF communicate using the Diameter protocol.

(Generic Bootstrapping Architecture): Bootstrapping Server Function

History[edit]

The Diameter protocol was initially developed by Pat R. Calhoun, Glen Zorn, and Ping Pan in 1998 to provide a framework for authentication, authorization and accounting (AAA) that could overcome the limitations of RADIUS. RADIUS had issues with reliability, scalability, security and flexibility. RADIUS cannot deal effectively with remote access, IP mobility and policy control. The Diameter protocol defines a policy protocol used by clients to perform policy, AAA, and resource control. This allows a single server to handle policies for many services.[1]

Like RADIUS, Diameter provides AAA functionality, but it is using TCP and SCTP instead of UDP, therefore logic for detection of communication problems is not included in the Diameter protocol itself. The Diameter protocol is enhanced further by the development of the 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS). The Cx, Dh, Dx, Rf, Ro, and Sh interfaces are supported by Diameter applications.[2] Through the use of extensions, the protocol was designed to be extensible to support proxies, brokers, strong security, mobile IP, network-access servers (NASREQ), accounting and resource management.

Protocol description[edit]

The Diameter base protocol is defined by RFC 6733 (Obsoletes: RFC 3588) and defines the minimum requirements for an AAA protocol. Diameter Applications can extend the base protocol by adding new commands, attributes, or both. Diameter security is provided by IPsec or TLS. The IANA has assigned TCP and SCTP port number 3868 to Diameter.

Packet format[edit]

The packet consists of a Diameter header and a variable number of Attribute-Value Pairs, or AVPs, for encapsulating information relevant to the Diameter message.

Diameter Header
Bit offset  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 version message length
32 R P E T         command code
64 application ID
96 hop-by-hop ID
128 end-to-end ID
160
...
AVPs
...

The "R" (Request) bit – If set, the message is a request. If cleared, the message is an answer.

The "P" (Proxiable) bit – If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed.

The "E" (Error) bit – 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.

The "T" (Potentially re-transmitted message) bit – 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.

Commands[edit]

Each command is assigned a command code, which is used for both Requests and Answers.

The values 0-255 are reserved for RADIUS backward compatibility. The values 256-16777213 are for permanent, standard commands allocated by IANA. The values 16777214 and 16777215 (hex 0xFFFFFE and 0xFFFFFF) are reserved for experimental and testing purposes.

Some common Diameter commands are:

Command-Name Abbr. Code
AA-Request AAR 265
AA-Answer AAA 265
Diameter-EAP-Request DER 268
Diameter-EAP-Answer DEA 268
Abort-Session-Request ASR 274
Abort-Session-Answer ASA 274
Accounting-Request ACR 271
Accounting-Answer ACA 271
Credit-Control-Request CCR 272
Credit-Control-Answer CCA 272
Capabilities-Exchange-Request CER 257
Capabilities-Exchange-Answer CEA 257
Device-Watchdog-Request DWR 280
Device-Watchdog-Answer DWA 280
Disconnect-Peer-Request DPR 282
Disconnect-Peer-Answer DPA 282
Re-Auth-Request RAR 258
Re-Auth-Answer RAA 258
Session-Termination-Request STR 275
Session-Termination-Answer STA 275
User-Authorization-Request UAR 300
User-Authorization-Answer UAA 300
Server-Assignment-Request SAR 301
Server-Assignment-Answer SAA 301
Location-Info-Request LIR 302
Location-Info-Answer LIA 302
Multimedia-Auth-Request MAR 303
Multimedia-Auth-Answer MAA 303
Registration-Termination-Request RTR 304
Registration-Termination-Answer RTA 304
Push-Profile-Request PPR 305
Push-Profile-Answer PPA 305
User-Data-Request UDR 306
User-Data-Answer UDA 306
Profile-Update-Request PUR 307
Profile-Update-Answer PUA 307
Subscribe-Notifications-Request SNR 308
Subscribe-Notifications-Answer SNA 308
Push-Notification-Request PNR 309
Push-Notification-Answer PNA 309
Bootstrapping-Info-Request BIR 310
Bootstrapping-Info-Answer BIA 310
Message-Process-Request MPR 311
Message-Process-Answer MPA 311
Update-Location-Request ULR 316
Update-Location-Answer ULA 316
Authentication-Information-Request AIR 318
Authentication-Information-Answer AIA 318
Notify-Request NR 323
Notify-Answer NA 323

Attribute-Value Pairs (AVP)[edit]

AVP Header
Bit offset  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 AVP code
32 V M P           AVP length
64 vendor ID (optional)
96
...
data
...

For simplicity, "V" bit Means Vendor Specific; "M" bit means Mandatory; "P" bit means Protected.

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.

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 "P" bit indicates the need for encryption for end-to-end security.

Attribute-Name Code Data Type
Acct-Interim-Interval 85 Unsigned32
Accounting-Realtime-Required 483 Enumerated
Acct-Multi-Session-Id 50 UTF8String
Accounting-Record-Number 485 Unsigned32
Accounting-Record-Type 480 Enumerated
Accounting-Session-Id 44 OctetString
Accounting-Sub-Session-Id 287 Unsigned64
Acct-Application-Id 259 Unsigned32
Auth-Application-Id 258 Unsigned32
Auth-Request-Type 274 Enumerated
Authorization-Lifetime 291 Unsigned32
Auth-Grace-Period 276 Unsigned32
Auth-Session-State 277 Enumerated
Re-Auth-Request-Type 285 Enumerated
Class 25 OctetString
Destination-Host 293 DiamIdent
Destination-Realm 283 DiamIdent
Disconnect-Cause 273 Enumerated
E2E-Sequence 300 Grouped
Error-Message 281 UTF8String
Error-Reporting-Host 294 DiamIdent
Event-Timestamp 55 Time
Experimental-Result 297 Grouped
Experimental-Result-Code 298 Unsigned32
Failed-AVP 279 Grouped
Firmware-Revision 267 Unsigned32
Host-IP-Address 257 Address
Inband-Security-Id 299 Unsigned32
Multi-Round-Time-Out 272 Unsigned32
Origin-Host 264 DiamIdent
Origin-Realm 296 DiamIdent
Origin-State-Id 278 Unsigned32
Product-Name 269 UTF8String
Proxy-Host 280 DiamIdent
Proxy-Info 284 Grouped
Proxy-State 33 OctetString
Redirect-Host 292 DiamURI
Redirect-Host-Usage 261 Enumerated
Redirect-Max-Cache-Time 262 Unsigned32
Result-Code 268 Unsigned32
Route-Record 282 DiamIdent
Session-Id 263 UTF8String
Session-Timeout 27 Unsigned32
Session-Binding 270 Unsigned32
Session-Server-Failover 271 Enumerated
Supported-Vendor-Id 265 Unsigned32
Termination-Cause 295 Enumerated
User-Name 1 UTF8String
Vendor-Id 266 Unsigned32
Vendor-Specific-Application-Id 260 Grouped

State machines[edit]

The RFC 3588 defines a core state machine for maintaining connections between peers and processing messages. This is part of the basic protocol functionality and all stacks should support it and as such abstract from the connectivity related operations.

Additionally, application specific state machines can be introduced either later or at a higher abstraction layer. The RFC 3588 defines an authorization and an accounting state machine.

Message flows[edit]

Diameter message flow.png

The communication between two diameter peers starts with the establishment of a transport connection (TCP or SCTP). The initiator then sends a Capabilities-Exchange-Request (CER) to the other peer, which responds with a Capabilities-Exchange-Answer (CEA). For RFC3588 compliant peers TLS (Transport Layer Security) may optionally be negotiated. For RFC6733 compliant peers TLS negotiation may optionally happen before the CER/CEA.

The connection is then ready for exchanging application messages.

If no messages have been exchanged for some time either side may send a Device-Watchdog-Request (DWR) and the other peer must respond with Device-Watchdog-Answer.

Either side may terminate the communication by sending a Disconnect-Peer-Request (DPR) which the other peer must respond to with Disconnect-Peer-Answer. After that the transport connection can be disconnected.

RFCs[edit]

The Diameter protocol is currently defined in the following IETF RFCs: Obsolete RFCs are indicated with strikethrough text.

# Title Date published Related article Obsoleted by Notes
RFC 3588 Diameter Base Protocol. September 2003 RFC 6733
RFC 3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5. September 2003
RFC 4004 Diameter Mobile IPv4 Application. August 2005
RFC 4005 Diameter Network Access Server Application. August 2005 RFC 7155
RFC 4006 Diameter Credit-Control Application. August 2005 Diameter Credit-Control Application
RFC 4072 Diameter Extensible Authentication Protocol (EAP) Application. August 2005
RFC 4740 Diameter Session Initiation Protocol (SIP) Application. M. November 2006
RFC 5224 Diameter Policy Processing Application. March 2008
RFC 5431 Diameter ITU-T Rw Policy Enforcement Interface Application. March 2009
RFC 5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction. February 2009
RFC 5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). April 2009 -
RFC 5624 Quality of Service Parameters for Usage with Diameter. August 2009
RFC 6733 Diameter Base Protocol. October 2012
RFC 6737 The Diameter Capabilities Update Application. October 2012
RFC 7155 Diameter Network Access Server Application. April 2014

See also[edit]

References[edit]

  1. ^ Pat R. Calhoun, Glen Zorn and Ping Pan (February 2001). "DIAMETER Framework Document". IETF. Retrieved 2009-04-30. 
  2. ^ Naman Mehta (2009-03-20). "Introduction to Diameter Protocol - What is Diameter Protocol?". Sun Microsystems. Retrieved 2009-04-30. 

External links[edit]