Introduction to Diameter Protocol[1]

1 http://thediameter.blogspot.com 1st Aug 2009

An Introduction to Diameter Protocol

Saro Velrajan1st Aug 2009

http://aaacorner.blogspot.com/�


Pre-requisites

Familiarity with the basics of - TCP/IP networking & - RADIUS protocol



Agenda

Protocol Basics

Functional Nodes

Key Features

Messages

Summary / References



Protocol Basics



Why Diameter?

Networks have evolved in the last 10 years. Need a protocol that is flexible enough

Need for more reliability & security

Need a protocol that addresses limitations of RADIUS protocol



What is Diameter?

Provides an Authentication, Authorization & Accounting framework

Flexible architecture that supports developing a variety of authentication applications such as Mobile-IP, NASREQ & ROAMOPS

Addresses limitations of RADIUS protocols

Presenter

Presentation Notes

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. The Diameter NASREQ application provides AAA services for dial-in PPP users and is the next generation replacement for the RADIUS protocol. The Diameter Mobile IPv4 application, in conjunction with extensions to the Mobile IP protocol, supports some of the recent work in the Mobile IP Working Group involving - Better scaling of security associations, Mobility across administrative domain boundaries, and Dynamic home agent assignment, in either the home or visited network. The Mobile IPv4 application defines Diameter functions that allow the AAA server to act as a Key Distribution Center (KDC), whereby dynamic session keys (or key material) are created and distributed to the mobility entities for the purposes of securing a particular session's Mobile IP Registration messages. The mobile node and its home AAA server share a security association (a secret), which the AAA server uses to manufacture these derivative security associations (keys). The purpose of this group is to develop or adopt procedures, mechanisms and protocols to support user roaming among groups of Internet service providers (ISPs). This is different from, but related to, the work of the IP Routing for Wireless/Mobile Hosts Working Group (mobileip) in that the roamops group is not concerned with the movement of hosts or subnets, but of users. Thus far, the group has produced an architectural document describing the basic mechanisms required to support user roaming, a description of several existing roaming implementations and defined a standard username syntax to support roaming.



NASREQ

Diameter Protocol Architecture

Diameter Base Protocol CMSSecurity

Mobile IP SIP

Presenter

Presentation Notes

The Diameter protocol is not a brand-new one for AAA, but rather, as its name implies, is an enhanced version of the RADIUS protocol. It includes numerous enhancements in all aspects, such as error handling and message delivery reliability. It extracts the essence of the AAA protocol from RADIUS and defines a set of messages that are general enough to be the core of the Diameter Base protocol. The various applications that require AAA functions can define their own extensions on top of the Diameter base protocol, and can benefit from the general capabilities provided by the Diameter base protocol.



Differences between RADIUS & Diameter

Feature RADIUS DiameterTransport Protocol

Connectionless (UDP) Connection-Oriented (TCP & SCTP)

Ports 1812 & 1813 3868 (Base Protocol)

Security Hop-to-Hop Hop-to-Hop

End-to-End Capabilities Negotiation

Not Supported Negotiate supported applications and security level

Peer Discovery

Static configuration Static configuration and dynamic lookup

Presenter

Presentation Notes

Transportation Protocol Whereas TCP transports a byte-stream, SCTP can transport multiple message-streams. All bytes sent in a TCP connection must be delivered in that order, which requires that a byte transmitted first must safely arrive at the destination before a second byte can be processed even if the second byte manages to arrive first. If an arbitrary number of bytes are sent in one step and later some more bytes are sent, these bytes will be received in order, but the receiver can not distinguish which bytes were sent in which step. SCTP in contrast, conserves message boundaries by operating on whole messages instead of single bytes. That means if one message of several related bytes of information is sent in one step, exactly that message is received in one step.The term "multi-streaming" refers to the capability of SCTP to transmit several independent streams of messages in parallel. For example, transmitting two images in a HTTP application in parallel over the same SCTP association. You might think of multi-streaming as bundling several TCP-connections in one SCTP-association operating with messages instead of bytes. Security The RADIUS protocol offers only hop-by-hop security and has no facility for securing A-V pairs between theNAS and the home server. This offers proxy servers the opportunity to collect confidential information ormodify messages (e.g. accounting information) without detection by the endpoints.The Diameter protocol offers end-to-end security in addition to hop-by-hop security. Digital signatures canensure the integrity of selected A-V pairs, and the confidentiality of selected A-V pairs can be ensured by encryption. Capabilities Negotiation The first Diameter messages exchanged between two Diameter peers, after establishing the transport connection, are Capabilities Exchange messages. A Capabilities Exchange message carries a peer's identity and its capabilities (protocol version number, supported Diameter applications, etc.). A Diameter node only transmits commands to peers that have advertised support for the Diameter application associated with the given command.



Differences between RADIUS & Diameter (Contd.)

Feature RADIUS Diameter

Server Initiated Message

Not Supported (Extensions available)

Supported. for example, re-authentication message, Session termination

Maximum Attribute Data Size

255 octets 16,777,215 octets

Vendor-specific Support

Vendor-specific attributes only

Vendor-specific attributes and messages

Presenter

Presentation Notes

Server initiated messages in RADIUS are supported through CoA extensions. Vendor Specific messages are dependant upon the application. MIP application may have its own message exchanges/command codes for Diameter authentication. NASREQ application can have a different set of message exchanges/command codes.



Functional Nodes



Diameter Nodes

Diameter ClientDiameter ServerDiameter Proxy/Relay AgentDiameter Redirect AgentDiameter Translation Agent

Presenter

Presentation Notes

Diameter is designed as a Peer-To-Peer architecture, and every host who implements the Diameter protocol can act as either a client or a server depending on network deployment. So the term Diameter node is used to refer to a Diameter client, a Diameter server, or a Diameter agent, which we will introduce later. The Diameter node that receives the user connection request will act as the Diameter client. In most cases, a Diameter client will be a Network Access Server. After collecting user credentials, such as username and password, it will send an access request message to one Diameter node serving the request. For simplicity, we assume it is the Diameter server. The Diameter server authenticates the user based on the information provided. If the authentication process succeeds, the user's access privileges are included in the response message and sent back to the corresponding Diameter client. Otherwise, an access reject message is sent. Although the architecture just described looks like a traditional client-server architecture, a node acting as the Diameter server for some requests might actually act as a Diameter client in some situations; the Diameter protocol is actually peer-to-peer-based architecture in a more generic sense. Besides, a special Diameter node called Diameter agent is clearly defined in Diameter – Proxy/Relay Agent, Redirect Agent, Translation Agent



Proxy/Relay Agent

Diameter Client

Diameter Proxy/Relay

Agent

Diameter Server

1. Request

4. Response

2. Request3. Response

• Proxy/Relay forward messages to appropriate Diameter Server

• Proxy can modify message content and apply rules

Presenter

Presentation Notes

Relay Agent A Relay Agent is used to forward a message to the appropriate destination, depending on the information contained in the message. The Relay Agent is advantageous because it can aggregate requests from different realms (or regions) to a specific realm, which eliminates the burdensome configurations of network access servers for every Diameter server change. Proxy Agent A Proxy Agent can also be used to forward messages, but unlike a Relay Agent, a Proxy Agent can modify the message content and, therefore, provide value-added services, enforce rules on different messages, or perform administrative tasks for a specific realm. Figure shows how a Proxy Agent is used to forward a message to another domain. If the Proxy Agent will not modify the content of an original request, a Relay Agent in this scenario would be sufficient.



Redirect Agent

• Redirection agent returns a response with redirection information

• Request routing information maintained in a central location

Diameter Client

Diameter ProxyAgent

Diameter Server

1. Request

6. Response

4. Request5. Response

Diameter Redirect

Agent

2. Request

3. Response

Presenter

Presentation Notes

Redirect Agent A Redirect Agent acts as a centralized configuration repository for other Diameter nodes. When it receives a message, it checks its routing table, and returns a response message along with redirection information to its original sender. This would be very useful for other Diameter nodes because they won't need to keep a list routing entries locally and can look up a Redirect Agent when needed. Figure illustrates how a Redirect Agent works. The scenario in this Figure is basically identical to the one in the previous slide’s Figure, but this time the Proxy Agent is not aware of the address of the contacting Diameter node within example.com. Therefore, it looks up the information in the Redirect Agent of its own realm to get the address.



Translation Agent

• Translation Agent converts RADIUS messages to Diameter format and vice versa

• Provides an upgrade path & seamless migration for RADIUS based network systems

RADIUSClient

Diameter Translation

Agent

1. RADIUS Request

4. RADIUS ResponseDiameter Redirect

Agent

2. Diameter Request

3. Diameter Response

Presenter

Presentation Notes

Translation Agent The responsibility of this agent, as you might have guessed, is to convert a message from one AAA protocol to another. The Translation Agent is helpful for a company or a service provider to integrate the user database of two application domains, while keeping their original AAA protocols. Another situation is that a company wants to migrate to Diameter protocol, but the migration consists of many phases. The Translation Agent could provide the backward capability for a smooth migration. Figure shows how one agent translates the RADIUS protocol into the Diameter protocol, but, of course, other kinds of protocol translation (for example, Diameter to RADIUS, Diameter to TACACS+) are also possible.



Key Features



Diameter Features

Peer Detection

Capabilities Exchange

Transport Failure Detection

Failover/Fallback Procedures

Accounting

Presenter

Presentation Notes

Diameter Peers Diameter peers, the set of Diameter nodes with which a given Diameter node will directly communicate, may be statically configured or may be dynamically discovered using SLPv2 or DNS SRV RRs. Capabilities Exchange The first Diameter messages exchanged between two Diameter peers, after establishing the transport connection, are Capabilities Exchange messages. A Capabilities Exchange message carries a peer's identity and its capabilities (protocol version number, supported Diameter applications, etc.). A Diameter node only transmits commands to peers that have advertised support for the Diameter application associated with the given command. Transport Failure Detection Application-level heartbeat messages called the Device-Watchdog-Request and Device-Watchdog-Response messages are used to proactively detect transport failures. These messages are sent periodically when a peer connection is idle and when a timely response has not been received for an outstanding request. Failover/Fallback Procedures If a transport failure is detected with a peer, a Diameter node attempts to failover to an alternate peer, which means that all pending request messages sent to the failed peer will be forwarded to the alternate peer. A Diameter node periodically attempts to re-establish the transport connection with a failed peer. Should a connection be re-established, a node can failback to this peer (i.e., messages can once again be forwarded to this peer). A failover to an alternate proxy agent may result in the reception of duplicate request messages by the home server. Accounting Accounting support and accounting messages are defined as part of the base protocol. The accounting protocol is based on a server directed model that supports real-time delivery of accounting information. The server directed model means that the Diameter client generating the accounting data receives direction from the (authorization or accounting) server regarding accounting record timeliness requirements. Batch accounting is not a requirement and is currently not supported by Diameter. CMS security may be applied to Diameter accounting messages, providing strong authentication and integrity protection for accounting data.



Messages



Attribute Value Pairs (AVPs)

End to End Identifier

Hop by Hop Identifier

Application Identifier

Command CodeFlags

Message LengthVersion

Diameter Message Format

Message Header

Message Body

Data

Vendor-ID (optional)

AVP LengthFlags

AVP Code

Presenter

Presentation Notes

A Diameter message is the base unit to send a command or deliver a notification to other Diameter nodes. For different purposes, Diameter protocol has defined several types of Diameter messages, which are identified by their command code. For example, an Accounting-Request message recognizes that the message carries accounting-related information, while a Capability-Exchange-Request message recognizes that the message carries capability information of the Diameter node sending the message. Because the message exchange style of Diameter is synchronous, each message has its corresponding counterpart, which shares the same command code. In both previous examples, the receiver of an Accounting-Request message prepares an Account-Response message and sends it to the original sender. The command code is used to identify the intention of a message, but the actual data is carried by a set of Attribute-Value-Pairs (AVPs). The Diameter protocol has predefined a set of common attributes and imposes each attribute with a corresponding semantic. These AVPs carry the detail of AAA as well as routing, security, and capability information between two Diameter nodes. In addition, each AVP is associated with an AVP Data Format, which is defined within the Diameter protocol (for example, OctetString, Integer32), so the value of each attribute must follow the data format.



Diameter Messages – Supported by BASE Protocol

Capabilities Exchange Request/Response

Accounting Request/Response

Re-Auth Request/Response

Session Termination Request/Response

Abort Session Request/Response

Disconnect Peer Request/Response

Device Watchdog Request/Response

Presenter

Presentation Notes

Capabilities-Exchange-Request/Response When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages. This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, security mechanisms, etc.) The receiver only issues commands to its peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer. Accounting-Request The Accounting-Request (ACR) command, is sent by a Diameter node, acting as a client, in order to exchange accounting information with a peer. Accounting-Response The Accounting-Response (ACA) command, is used to acknowledge an Accounting-Request command. The Accounting-Response command contains the same Session-Id and includes the usage AVPs only if CMS is in use when sending this command. Note that the inclusion of the usage AVPs when CMS is not being used leads to unnecessarily large Response messages, and can not be used as a server's proof of the receipt of these AVPs in an end-to-end fashion. If the Accounting- Request was protected by end-to-end security, then the corresponding ACA message MUST be protected by end-to-end security. Re-Auth-Request The Re-Auth-Request (RAR), may be sent by any server to the access device that is providing session service, to request that the user be re-authenticated and/or re-authorized. Re-Auth-Response The Re-Auth-Response (RAA), is sent in response to the RAR. The Result-Code AVP MUST be present, and indicates the disposition of the request. Session-Termination-Request The Session-Termination-Request (STR), is sent by the access device to inform the Diameter Server that an authenticated and/or authorized session is being terminated. Session-Termination-Response The Session-Termination-Response (STA), is sent by the Diameter Server to acknowledge the notification that the session has been terminated. The Result-Code AVP MUST be present, and MAY contain an indication that an error occurred while servicing the STR. Upon sending or receipt of the STA, the Diameter Server MUST release all resources for the session indicated by the Session-Id AVP. Any intermediate server in the Proxy-Chain MAY also release any resources, if necessary. Abort-Session-Request The Abort-Session-Request (ASR), may be sent by any server to the access device that is providing session service, to request that the session identified by the Session-Id be stopped. Disconnect-Peer-Request The Disconnect-Peer-Request (DPR), is sent to a peer to inform its intentions to shutdown the transport connection. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer. Disconnect-Peer-Response The Disconnect-Peer-Response (DPA), is sent as a response to the Disconnect-Peer-Request message. Upon receipt of this message, the transport connection is shutdown. Device-Watchdog-Request The Device-Watchdog-Request (DWR), is sent to a peer when no traffic has been exchanged between two peers. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.



Connection Setup & Tear Down

Diameter Client

Diameter Server

Capabilities Exchange Request

Capabilities Exchange Response

Disconnect Peer Request

Disconnect Peer Response

Other Diameter Message

Exchanges



Subscriber Session – With Accounting

Diameter Client

Diameter Server

AA-Request

AA-Response

Accounting-Request

Accounting-Response

Accounting-Request

Accounting-Response

Session LOGIN

Session LOGOUT

Presenter

Presentation Notes

When a service only makes use of the Accounting portion of the Diameter protocol, even in combination with an application, the Session-Id is still used to identify user sessions. However, the session termination messages are not used, since a session is signaled as being terminated by issuing an accounting stop message. (Reference: RFC3588)



Subscriber Session – Without Accounting (Stateful)

Diameter Client

Diameter Server

AA-Request

AA-Response

Session-Terminate-Request

Session-Terminate-Response

Session LOGIN

Session LOGOUT



Subscriber Session – Without Accounting (Stateless)

Diameter Client

Diameter Server

AA-Request(No Session State Maintained)

AA-Response

Session LOGIN



Subscriber Session Termination –Client Initiated

Diameter Client

Diameter Server

Session-Terminate-Request

Session-Terminate-Response



Subscriber Session Termination –Server Initiated

Diameter Client

Diameter Server

Abort Session Response

Abort Session Request



Diameter - Summary

Provides an Authentication, Authorization & Accounting framework

Flexible architecture that supports developing a variety of applications such as Mobile-IP, NASREQ & ROAMOPS

Addresses limitations of RADIUS protocol



References

Diameter RFC 3588http://www.faqs.org/rfcs/rfc3588.html

The Internet NG Project

http://ing.ctit.utwente.nl/WU5/D5.1/Technology/diameter/

Introduction to Diameter

http://docs.hp.com/en/T1428-90011/T1428-90011.pdfhttp://www-128.ibm.com/developerworks/library/wi-diameter/index.html


http://www.faqs.org/rfcs/rfc3588.html�

http://ing.ctit.utwente.nl/WU5/D5.1/Technology/diameter/�

http://docs.hp.com/en/T1428-90011/T1428-90011.pdf�

http://www-128.ibm.com/developerworks/library/wi-diameter/index.html�


Thank You!


Documents

Introduction to Diameter Protocol[1]