- Diameter (protocol)
-
Internet protocol suite Application layer Transport layer Internet layer Link layer Diameter is an authentication, authorization and accounting protocol for computer networks, and an alternative to RADIUS.
Diameter Applications extend the base protocol by adding new commands and/or attributes, such as those for use of the Extensible Authentication Protocol (EAP).
Contents
Comparison with RADIUS
The name is a pun on 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 differences are as follows:
- Reliable transport protocols (TCP or SCTP, not UDP)
- The IETF is in the process of standardizing TCP Transport for RADIUS
- Network or transport layer security (IPsec or TLS)
- The IETF is in the process of standardizing Transport Layer Security for RADIUS
- 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
A Diameter Application is not a software application, but a protocol based on the Diameter base protocol (defined in 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:
- Diameter Mobile IPv4 Application (MobileIP, RFC 4004)
- Diameter Network Access Server Application (NASREQ, RFC 4005)
- Diameter Extensible Authentication Protocol Application (RFC 4072)
- Diameter Credit-Control Application (DCCA, RFC 4006)
- Diameter Session Initiation Protocol Application (RFC 4740)
- Various applications in the 3GPP IP Multimedia Subsystem
-
- Both the HSS and the SLF communicate using the Diameter protocol.
(Generic Bootstrapping Architecture): Bootstrapping Server Function
History
The Diameter protocol was initially developed by Pat R. Calhoun, Glen Zorn and Ping Pan in 1998 to provide an Authentication, Authorization, and Accounting (AAA) framework that could overcome the limitations of RADIUS. RADIUS had issues with reliability, scalability, security and flexibility. RADIUS cannot effectively deal well 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 in addition it is made more reliable by using TCP and SCTP instead of UDP. The Diameter protocol is further enhanced 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
The Diameter base protocol is defined by RFC 3588, and defines the minimum requirements for an AAA protocol. Diameter Applications can extend the base protocol, by adding new commands and/or attributes. Diameter security is provided by IPsec or TLS, both well-regarded protocols. The IANA has assigned TCP and SCTP port number 3868 to Diameter.
Packet format
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
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 Attribute-Value Pairs (AVP)
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
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.
-
Peer State Machine Part 1
-
Peer State Machine Part 2
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.
-
Diameter Authorization State Machines (Client)
-
Diameter Authorization State Machines (Server)
-
Diameter Accounting State Machines (Client)
-
Diameter Accounting State Machines (Server)
Message flows
The communication between two diameter peers starts 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). After that, TLS (Transport Layer Security) may optionally be negotiated.
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
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. Diameter 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 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. See also
- List of authentication protocols
- Host Identity Protocol (HIP)
References
- ^ Pat R. Calhoun, Glen Zorn and Ping Pan (2001-02). "DIAMETER Framework Document". IETF. http://tools.ietf.org/html/draft-calhoun-diameter-framework-09. Retrieved 2009-04-30.
- ^ Naman Mehta (2009-03-20). "Introduction to Diameter Protocol - What is Diameter Protocol?". Sun Microsystems. http://blogs.sun.com/naman/entry/introduction_to_diameter_protocol. Retrieved 2009-04-30.
External links
- Diameter Blog - Everything about the Diameter protocol
- Introduction to Diameter - Get the next generation AAA protocol
- Cisco page outlining differences between RADIUS and DIAMETER
- Diameter test tools from Developing Solutions
- Diameter: next generation’s AAA protocol Paper about Diameter by Håkan Ventura
- Diameter protocol discussion group Diameter protocol discussion group
- The Open IMS Core JavaDiameterPeer The Open IMS Core JavaDiameterPeer
- freeDiameter, open-source implementation of Diameter Base Protocol and Extensions
Categories:- Internet protocols
- Internet standards
- Computer access control protocols
- Reliable transport protocols (TCP or SCTP, not UDP)
Wikimedia Foundation. 2010.
