Introduction To 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. 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.
Ø Successor and Improved version of radius protocol.
Ø Computer network protocol for AAA(authenication, authorisation,accounting).
Ø Maximize compatibility and ease migration from radius server to diameter server.
Ø Able to access new technologies.
Ø Access to Ip networks.
Advantages Of Diameter:
Ø Better transport:
o It runs over a reliable transport (TCP or SCTP).
o lost packets are retransmitted at each hop.
Ø Better proxying:
o automatically does retransmission of pending request message.
o transport failure detection allows failover to occur at appropriate places.
Ø Better session control:
o The server may initiate a message to request session termination.
o The server may initiate a message to request re-authentication and/or reauthorization of a user.
Ø Better security:
o Hop-by-hop security is provided using IPsec or TLS.
o Authentication replay attack prevention through encryption.
Ø Extremely reliable, highly available.
o AAA client/server send/receive acknowledgement mechanism for receipt of requests.
o server supports “keepalives” notifying if failure or pending failure.
o peer-to-peer bidirectional.
o handles many more pending AAA request.
Ø The base protocol defines the basic Diameter message format. Data is carried within a Diameter message as a collection of Attribute Value Pairs (AVPs).
Ø An AVP is like a RADIUS attribute. An AVP consists of multiple fields: an AVP Code, a Length, some Flags, and Data. Some AVPs are used by the Diameter base protocol; other AVPs are intended for the Diameter application (e.g. NASREQ)
ATTRIBUTE VALUE PAIR(AVP):
Computing system and applications.
Ø An open ended data structure that allows for future extension without modifying existing code or data.
Ø Encapsulating info relevant to diameter msg.
Eg. One Avp – home-agent address(attribute)
IP address(value).
There is separate private key code, userid, password for the user.
DIAMETER MESSAGES:
Ø 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.
Ø 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.
DIAMETER PACKET FORMAT:
Ø One Diameter value pair involves "home-agent-address" as the attribute and uses an IP address as the value.
Ø A mobile user calling from a cell phone might use this to pass through to the Diameter server of his or her home agent ISP in order to authenticate the user ID and password value pairs.
Ø But in order to allow for authentication through a third party - for instance, through a remote ISP to the user's home-agent ISP - Diameter also enhances the previously limited proxy capabilities of RADIUS.
Ø This way the remote ISP is allowed to create a proxy back to the user's home agent ISP, and on to the home-agent Diameter server. From there, the home-agent ISP and the user can carry on their authentication transaction. Once that is complete, the home agent ISP tells the remote ISP to give the user service.
Ø Diameter also lets the two ISPs exchange the necessary billing information, so the home agent ISP can bill the user and settle accounts with the remote ISP.
CONNECTION AND SESSION:
Ø A connection is a physical link between two Diameter nodes. It is mandatory for the Diameter protocol to run over either TCP or SCTP.
Ø A session is a logical connection between two Diameter nodes, and can cross multiple connections. A session is actually the concept of a sequence of activities within a timeframe, and refers to the interactions between a Diameter client and a Diameter server in a given period.
Ø Each session in Diameter is associated with a client-generated Session-Id that is globally and eternally unique. The Session-Id is then used to identify a particular session during further communication.
DIFFERENCES BETWEEN RADIUS AND DIAMETER:
Strict limitation of attribute data
Ø Radius has only one byte reserved for the length of a datafield (max. 255) in its attribute header.
Ø Diameter reserves two bytes for its length of a datafield (max. 16535).
Inefficient retransmission algorithm
Ø Radius has only one byte as identifier field to identify retransmissions. This limits the number of requests that can be pending (max. 255).
Ø Diameter has reserved four bytes for this purpose (max. 2^32
End-to-end message acknowledgement
Ø A Radius client expects a successful or failed response after a request, but does not know whether the request has been received by the server.
Ø Diameter client expects a success of failed response or just an acknowledgement of the received request by the server.
Silent discarding of packets
Ø A Radius server which receives packet which do not contain the expected infomation, or which have errors are silently discarded. This might cause the client to think that the server is down because it does not receive any response. It would then try to send it to a secondary server
Ø A Diameter server can send an error message back to the client indicating the problem
No fail-over server support
Ø Radius server has no way of indicating that it's going down or is currently running
Ø Diameter supports Keep-alive messages and messages that indicate that a server is going down for a time period .
Authentication replay attacks
Ø When using PPP CHAP any radius client can generate a challenge response sequence, which can be intercepted by any radius client or proxy server in the chain. This challenge response sequence can then be replayed by an other radius client at any time. (partly solved by the radius extension using the EAP protocol)
Ø In Diameter those challenge/response attributes can be secured using end-to-end encryption and authentication.
Inability to control flow to servers
Radius operates over UDP and has no standard scheme to regulate it's flow.Diameter has a scheme which regulates the flow of UDP packets (windowing scheme) By TCP or SCTP…
Hop-by-hop security
Ø Radius only support hop-by-hop security, which means that at every hop can easily modify information, which can not traced to it's origin
Ø Diameter supports also end-to-end security which guarantees that the information can not be modified without notice.
No support for user-specific commands
Radius does not support vendor specific commands, only vendor specific attributes.
Diameter has support of vendor specific command code's
Heavy processing costs
Ø The Radius protocol does not impose any alignment requirements, which adds an unnecessary burden on most processors.
Ø The Diameter protocol has a 32 bits alignment requirement, which can be handled more efficient by most processors.
RFC – 3588 Internet document by IETF work group
Ø This is based on diameter base protocol.
Ø Error notification.
Ø User session or accounting.
Ø Extensibility, delivery of AVP’s.
RFC – 4072 Extensible authentication protocol.
Ø Supports multiple authentication.
Ø End-End authentication.
Ø Switched circuits, wired or wireless.
RFC – 4005 Diameter NAS application.
Ø Existing Session id.
Ø Terminology are:
Ø PPP – primary IP datalink. Used for dial in NAS connection.
Ø CHAP – Challenge handshake authentication protocol.
Ø PAP – password authentication protocol.
Ø IPX - Internet Packet Exchange through netware networks.
VENDOR SUPPORTS FOR DIAMETER
Ø Sun microsystems.
Ø Nortel network.
Ø Merit network.
Ø Cisco systems.
Ø Blackstorm.
Ø Microsoft.
Ø Nokia research center.
Ø LM ericson.
the above mentioned is not yet reached standard.
At present Interlink network is testing the protocol.
DIAMETER APPLICATION
The three applications are:
Ø NASREQ.
Ø Mobile IPv4.
Ø ROAMOPS.
NASREQ:
Ø AAA services for dial in PPP users.
Ø reduces protocol conversion work.
Ø uses existing RADIUS attributes to carry data objects.
Mobile IPv4:
Ø AAA support for services rendered to a mobile node.
ROAMOPS(2477):
Ø supporting for roaming environment.
Ø Need of AAA protocol.
SUPPORTING OPERATING SYSTEMS
Ø All posix(linux,unix)
Ø Os independent.
Ø Written in C++, interpreted language.
Ø Its old version is Diameter(1.0.7i) in linux.
Ø Updated version is Diameter 1.0.8.
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:
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.
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.
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.
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.
After an appropriate peer has been discovered, the next step is to establish a connection with that peer. A connection is a physical link between two Diameter nodes. It is mandatory for the Diameter protocol to run over either TCP or SCTP. Compared with UDP, used in RADIUS, these two protocols provide more reliable transportation, which is critical for applications exchanging accounting-related information.
Given that Diameter is basically a peer-to-peer architecture; there could be more than one connection established for a particular node. Diameter protocol explicitly defines that a Diameter node must establish a connection with two peers per realm at a minimum, which act as primary and secondary contacts. Of course, additional connections could be established when necessary.
Compared with a connection, a session is a logical connection between two Diameter nodes, and can cross multiple connections. A session is actually the concept of a sequence of activities within a timeframe, and refers to the interactions between a Diameter client and a Diameter server in a given period. Each session in Diameter is associated with a client-generated Session-Id that is globally and eternally unique. The Session-Id is then used to identify a particular session during further communication.
Figure 6 shows the concept of a connection and session:
SESSION INITIATION
Like most client-server communication models, a Diameter session starts by issuing a request message from the client to the server. In Diameter context, a Diameter client will send an auth-request message containing a unique Session-Id to a Diameter server (or a Diameter proxy if message forwarding is required). Note that the AVPs to be used for authentication and authorization are application-specific, and that they are not defined in the base protocol.
After accepting the auth-request message, the Diameter server may include an Authorization-Lifetime AVP in the response messaging. This AVP is used to indicate the amount of time in seconds that the Diameter client needs to be re-authorized. After the timeout and acceptable Auth-Grace-Period have passed, the Diameter server will remove the session from its session list and release all resources allocated for the session.
THE SESSION
During the session, a Diameter server might initiate a re-authentication or re-authorization request. With prepaid service, this type of request is used to check whether the user is still engaging the service, and if not, the server removes the session to avoid further charging.
Also, the Origin-State-Id AVP is used for the inference of exceptional session closure. The sender of a request will include this AVP, and because it is required for the value of this AVP to be monotonically increased, the receiver of the request can easily infer that the previous session was closed, either because the access device was abnormally shutdown or because of some other exceptional situation. The request receiver can then remove the session from its list, free the resources, and possibly notify its upper stream Diameter servers if it acts as a proxy server.
SESSION TERMINATION
Session termination messages are only used in the context of authentication and authorization, and only when the session state was maintained. For accounting services, an accounting stop message is used instead.
A session termination message can be initiated by either the Diameter client or the Diameter server. When a session is deemed to be closed, the Diameter client sends a Session-Termination-Request message to the Diameter server. The Termination-Clause AVP is included in this request telling the Diameter server the reason why the session should be closed. Alternately, if the Diameter server detects that the session should be closed -- perhaps because the user runs out of credit or just for administrative purposes -- the Diameter server sends an Abort-Session-Request message to the Diameter client. However, depending upon different policy or usage scenarios, the Diameter client might decide not to close the session even when receiving a session termination message from the server, and let the user keep using its service.
