Diameter
The Diameter protocol was derived from the RADIUS protocol with a lot of improvements in different aspects, and is generally believed to be the next generation Authentication, Authorization, and Accounting (AAA) protocol. The Diameter protocol was widely used in the IMS architecture for IMS entities to exchange AAA-related information. Because the IMS system might be the next big thing in the telecom industry, we believe a clear understanding of the Diameter protocol is necessary for understanding the essence of the IMS architecture. This article offers an overview of Diameter and how it works. For developers interested in how AAA in IMS works, or who want to implement Diameter applications, this article is a good starting page.
With the emergence of new technologies and applications such as wireless networks and mobile IPs, the requirements for authentication and authorization have greatly increased, and access control mechanisms are more complex than ever. The existing RADIUS (Remote Authentication Dial-In User Service) protocol can be insufficient to cope with these new requirements; what's needed is a new protocol that is capable of fulfilling new access control features while keeping the flexibility for further extension. This is where the Diameter protocol comes into play.
Please note that this article provides an overview of Diameter and does not cover all the protocol details. If you want to go further and implement the Diameter base protocol, refer to RFC3588 in Resources for more details. So, because this article mainly addresses the base protocol, Diameter will refer to the Diameter Base Protocol.
Before immersing ourselves in protocol details, let's see what drives the requirement for AAA protocol. In the old days, people tried to dial into their Internet Service providers (ISPs) by providing their ID and password to an access server, which then authenticated the user before granting Internet access. In most cases, a user's credential information is not stored directly in the access server, but in a more secure location such as a Lightweight Directory Access Protocol (LDAP) server behind a boundary firewall. Therefore, a standardized protocol is required between the access server and the user information repository in order to exchange authentication-, authorization-, and accounting-related information. The RADIUS protocol was designed to provide a simple, but efficient, way to deliver such AAA capability.
As with the evolution of network applications and protocols, new requirements and mechanisms are required to authenticate users. These requirements are summarized in RFC2989 (see Resources), which includes such topics as failover, security, and audit ability. Although there are some subsidiary protocols intended to extend the capability of the RADIUS protocol, a more extensible and general protocol was expected. The Diameter protocol was then derived from that of RADIUS, and designed to be a general framework for future AAA applications.
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. Figure 1 illustrates the relationship between the Diameter base protocol and various Diameter applications.
Figure 1. The relationship of the Diameter base protocol and Diameter applications
| |
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. Typically, there are three kinds of Diameter agents:
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.
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 2 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.
Figure 2. The Diameter Proxy 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 3 illustrates how a Redirect Agent works. The scenario in Figure 3 below is basically identical to the one in Figure 2, 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.
Figure 3. The Diameter Redirect Agent
| |
In addition to these agents, there is a special agent called 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 4 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.
Figure 4. The Diameter Translation Agent
| |
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-Answer 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.
Figure 5 illustrates the relationship between Diameter messages and their AVPs. For more details on each part of Figure 5, see Chapters 3 and Chapter 4 of the Diameter base protocol.
Figure 5. The Diameter Packet Format
Table 1 lists all messages defined in the Diameter base protocol:
Table 1. Messages defined in the Diameter base protocol
| Abort-Session-Request | ASR | 274 |
| Abort-Session-Answer | ASA | 274 |
| Accounting-Request | ACR | 271 |
| Accounting-Answer | ACA | 271 |
| Capabilities-Exchanging-Request | CER | 257 |
| Capabilities-Exchanging-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 |
No comments:
Post a Comment