Diameter Protocol an Overview

Aug 8, 2011 at 4:49 am in LTE by Shri Diameter is an AAA (Authentication, Authorization and Accounting) protocol initially developed by IETF for the applications such as network access and IP mobility. It is a base foundation protocol to provide AAA services like Delivery of AVPs (attribute value pairs), Negotiation Capabilities, Routing Capabilities and Error Handling to new access technologies. Authentication, Authorization and Accounting (AAA) protocols such as TACACS and RADIUS were initially deployed to provide dial-up PPP and terminal server access. Over a 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. Diameter protocol came as a result of developments to overcome limitations of RADIUS and to fulfil new requirements on AAA protocols of new access technologies. Diameter is designed as an improved version of RADIUS. As name suggests Diameter is double of RADIUS, it has several advantages over RADIUS. Diameter based Protocol provides following facilities:

Reliable delivery of AVPs (attribute value pairs) User authentication, capabilities negotiation and Error Notification Connection and session management Extensibility, through addition of new commands and AVPs Agent support for proxy, redirect, and relay servers Basic services necessary for applications, such as handling of user sessions or accounting Basic accounting services

ADVANTAGES OF DIAMETER OVER RADIUS

There are several general shortcomings of the RADIUS protocol that were addressed in the design of the Diameter base protocol. In addition to the protocol shortcomings, there are further application-specific RADIUS deficiencies that limit its capability to support AAA services in specific areas of new access technologies. Following are the major limitations of RADIUS:

FAILOVER

RADIUS does not define failover mechanisms, and as a result, failover behaviour differs between implementations. In order to provide well defined failover behaviour, Diameter supports application-layer acknowledgements and defines failover algorithms and the associated state machine.

TRANSPORT-LEVEL SECURITY

RADIUS runs over UDP and does not define retransmission behaviour; as a result, reliability varies between implementations. This is a major issue in accounting, where packet loss may translate directly into revenue loss. In order to provide well defined transport behaviour, Diameter runs over reliable transport mechanisms such as TCP, SCTP.

AGENT SUPPORT

RADIUS does not provide explicit support for agents, including Proxies, Redirects and Relays. Since the expected behaviour is not defined, it varies between implementations. Diameter defines agent behaviour explicitly.

SERVER INITIATED MESSAGES

Server initiated message support in RADIUS is optional. This makes it difficult to implement features such as unsolicited disconnect or re-authentication/re-authorization on demand across a heterogeneous deployment. Support for server initiated messages is mandatory in Diameter.

AUDITABILITY

RADIUS does not define data-object security mechanisms; 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. Implementation of data object security is also not mandatory within Diameter but these capabilities are supported in Diameter.

LIMITED SIZE OF ATTRIBUTE DATA

A RADIUS attribute is carried in a RADIUS message as a variable-length {Attribute Type, Attribute Length, Attribute Value} 3-tuple. The Attribute Length field is one octet, hence its maximum value of 255 puts a ceiling on the number of octets of a given attributes data. A Diameter attribute is carried in a Diameter message as a variable-length {Attribute Type, Flags, Attribute Length, Vendor-ID, Attribute Value} 5-tuple. The Attribute Length field is three octets, hence its maximum value allows for over 16,000,000 octets of data for a given attribute.

ERROR HANDLING AND 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 others 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, capability negotiation, and mandatory/non-mandatory attribute-value pairs (AVPs).

SHARED SECRET

RADIUS protocol requires that a shared secret exist between two peers, even if IP Security is employed over a local communication. The Diameter protocol can secure communications between peers with either IP Security or Transport Layer Security (TLS).

ROAMING SUPPORT

Since RADIUS does not provide explicit support for proxies, lacks auditability and transportlevel 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 for roaming. By providing explicit support for inter-domain roaming and message routing, auditability, and transport-layer security features, Diameter addresses these limitations and provides for secure and scalable roaming. Above points can be summarised on following advantages of Diameter over RADIUS:

Better Transport Better Security Better Proxying Better Session Control Better Interoperability

DIAMETER MESSAGE FORMAT

A Diameter message consists of a fixed-length 20-octet header followed by a variable number of AVPs. The Diameter header format is shown below. 0 1 2 3 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command flags | Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs +-+-+-+-+-+-+-+-+-+-+-+-+-

Diameter Header Format

The above shown fields are transmitted in the network byte order.

Version: Indicates Diameter version and set to 1 for Diameter Version1. Message Length: 3 octacts field, indicates the length of the Diameter message including the header fields. Command Flags: 8 bits field, indicates type and nature of message Command-Code: 3 octacts field, used in order to communicate the command associated with the message. Application-ID: 4 octacts field, used to identify to which application the message is applicable for. Hop-by-Hop Identifier: An unsigned 4 octacs 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. End-to-End Identifier: An unsigned 4 octact integer field (in network byte order), used to detect duplicate messages. AVPs: AVPs are a method of encapsulating information relevant to the Diameter message. 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.

AVP MESSAGE FORMAT An AVP includes a header and is used to encapsulate protocol-specific data such as authentication, accounting, authorization, routing and security information as well as configuration details for the request and reply. The AVP header format is shown below. 0 1 2 3 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Flags | AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data +-+-+-+-+-+-+-+-+ AVP Header Format The above shown fields are transmitted in the network byte order.

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. AVP Flag: The AVP Flags field informs the receiver how each attribute must be handled. AVP Length: 3 octacts field, 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. Vendor-ID (Optional Field): 4 octacts optional field present if the respective bit-flag (V) is enabled. It contains the IANA assigned SMI Network Management Private Enterprise Codes[ASSIGNNO] value, encoded in network byte order. AVP DATA: o Basic AVP Data: The Basic 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. Following are the Diameter defined basic data types:OctetString, Integer32, Integer64, Unsigned32, Unsigned64, Float32, Float64, Grouped. o Derived AVP Data: 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. Following AVP Derived Data Formats are commonly used by applications: Address, Time, UTF8String, DiameterIdentity, DiameterURI, Enumerated, IPFilterRule, QoSFilterRule.

DIAMETER NODES
Diameter is a Server-Client based protocol. In addition to Servers and Clients the Diameter protocol defines several agents. A Diameter Agent is a Diameter node that provides relay, proxy, redirect or translation services.

Diameter Server: A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. Diameter Server must support Diameter applications in addition to the base protocol. Diameter Clients: A Diameter Client is a device at the edge of the network that performs access control. Network Access Server (NAS) and Foreign Agent (FA) are examples of Diameter client. Proxy Agent: Proxy agent or Proxy is used to forward requests and responses (Diameter messages). Proxies also make policy decisions relating to resource usage and provisioning. This is typically accomplished by tracking the state of NAS devices. Relay Agent: Relay Agent or Relay forwards requests and responses (Diameter messages) based on routing-related AVPs and realm routing table entries. Relays do not make policy decisions, they do not examine or alter non-routing AVPs and never originate messages.

Redirect Agent: Redirect agent 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. Translation Agent: A translation agent is a state full Diameter node that performs protocol translation between Diameter and another AAA protocol, such as RADIUS.

References: RFC-3588, RFC-2138, RFC-2139