Diameter Protocol

                 Diameter is a planned replacement of RADIUS. It is an AAA protocol for applications such as network access and IP mobility. Listed below are a few points that you need to know about Diameter:

• It is intended to work in both local and roaming AAA situations.
• It uses TCP or SCTP and not UDP.
• It uses transport level security (IPSEC or TLS).
• It has 32 bit identifier instead of 8 bit.
• It supports application layer acknowledgement, define failover.
• It offers better roaming support.
• It uses AVPs.
• Diameter allows to define new commands and attributes. It is easy to extend.

Authentication

• Refers to confirmation that a user who is requesting a service is a valid user.
• Accomplished via the presentation of an identity and credentials.
• Examples of credentials include passwords, one-time tokens, digital certificates, and phone numbers (calling/called).

Authorization

• Refers to the granting of specific types of service (including "no service") to the users based on their authentication.
• May be based on restrictions, for example, time-of-day restrictions, or physical location restrictions, or restrictions against multiple logins by the same user.
• Examples of services include, IP address filtering, address assignment, route assignment, encryption, QoS/differential services, bandwidth control/traffic management, etc.

Accounting

• Refers to the tracking of the consumption of network resources by users.
• Typical information that is gathered in accounting include the identity of the user, the nature of the service delivered, when the service began, and when it ended.
• May be used for management, planning, billing, etc.
• AAA server provides all the above services to its clients.

  
Diameter nodes and agents
        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.

         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.

Relay Agent
      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. Below 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.

Proxy Agent

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 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.

Redirect Agent

.
Translation 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.

Translation Agent

Diameter Message
      A Diameter message consists of a fixed-length 20-octet header followed by a variable number of AVPs (Attributed Value Pair). The format of a Diameter message is shown on the figure.

                                        0                                  7                                           31

Version	Message Length
Command Flag	Command code
Application ID
Hop-By-Hop Identifier
End-to-End Identifier
AVPs

                                                                 Diameter message format                                                                         

 The Version field indicates the Diameter protocol version and is set to 1 for now.
 The Command flags field specifies 4 flags for now:

• R flag (stands for Request) shows whether the message is a request or a response.
• P flag (stands for Proxiable) shows if the message can be proxied, relayed orredirected or it must be locally processed.
• E flag (stands for Error) to show if the message contains protocol or semantic errors. When a request message generates a protocol error an answer message is sent back with the ‘‘E’’ bit set in the Diameter header, indicating a protocol error.
• T flag to show that a message can potentially be a retransmitted message after a link fail-over or is used to aid removal of duplicate messages.
• r : these flag bits are reserved for future use, and must be set to zero, and ignored by the receiver.

                                   0            1            2               3              4               5              6           7 

R

P

E

T

r

r

r

r

                                                                         Command Flag

 The command code value indicates the command associated with the message, such as “credit-control-request ” or “accounting-request”, and so on. Every Diameter message must contain a command code so that the receiver can determine what action it needs to take for each message. The command code is the same of the request and its corresponding answer.

Application ID identifies the specific application the message is used for, such as S6a/S6d between MME and HSS, Gx between PCEF and PCR, etc.



Application-ID
 Application-ID is four octets and is used to identify to which application the message is applicable for.  The application can be an authentication application, an accounting application or a vendor specific application.

The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message.

Application	Application
Diameter Common Messages	0
NASREQ	1
Diameter Base Accounting, Rf , Gz	3
Diameter Credit Control, Ro, Gy	4
Relay	0xFFFFFFFF
Cx/Dx Interface Application	16777216
Rx Interface Application	16777236
Sh/Dh Interface Application	16777217
Re Interface Application	16777218
S6a/S6d Interface Application	16777251
S13/S13 ’ Interface Application	16777252
S9 Interface Application	16777267
Gx Interface Application	16777238
Sy Interface Application	16777302
SWx Interface Application	16777265

 Hop-by-hop identifier field carries an identifier that is used to match request and responses over that hop. The sender of the request must ensure that the identifier is unique over the connection on that hop at any given time. The sender of a response must ensure that the identifier value is the same as that in the corresponding request. . The Hop-by-Hop identifier is normally a monotonically increasing number, whose start value was randomly generated. An answer message that is received with an unknown Hop-by-Hop Identifier must be discarded. Hop-by-Hop identifier allows a Diameter response to follow the same route as the corresponding diameter request.

 End-to-end identifier is an identifier used to detect duplicate messages. The identifier in a response message must match the identifier in the corresponding request message. The identifier must remain locally unique for at least 4 minutes. This identifier and the Origin Host AVP are used together to detect message duplicates. Note duplicate request could cause duplicate responses but the duplications must not affect any states that were created by the original request. What follows the DIAMETER command header is a set of AVPs (Attribute Value Pair)


Command Codes
   Each command Request/Answer pair is assigned a command code, and the   sub-type (i.e., request or answer) is identified via the 'R' bit in    the Command Flags field of the Diameter header.
   Every Diameter message MUST contain a command code in its header's Command-Code field, which is used to determine the action that is to be taken for a particular message. The following Command Codes are defined in the Diameter base protocol:

Diameter Base protocol messages:

Command Name	Abbreviation Command	Code
I. Diameter Connection Management
Capabilities-Exchange-Request	CER	275
Capabilities-Exchange-Answer	CEA	275
Device-Watchdog-Request	DWR	280
Device-Watchdog-Answer	DWA	280
Disconnect-Peer-Request	DPR	282
Disconnect-Peer-Answer	DPA	282
II. Generic Session Operations
Abort-Session-Request	ASR	274
Abort-Session-Answer	ASA	274
Re-Auth-Request	RAR	258
Re-Auth-Answer	RAA	258
Session-Termination-Request	STR	275
Session-Termination-Answer	STA	275
III.Offline Charging
Accounting-Request	ACR	271
Accounting-Answer	ACA	271

 Diameter messages, like RADIUS messages, transport a collection of Attribute-Value Pairs (AVPs). These AVPs carry the detail of AAA as well as routing, security, and capability information between two Diameter nodes. An AVP is a container of data. Each AVP contains an AVP Code, Flags, anAVP Length, an optional Vendor-ID and Data.


    0                                       7                                    31

AVP Codes
Flag	AVP Length
Vendor-ID (optional)
Data

                                    AVP Header Format

AVP Code: The AVP code identifies the type of information (attribute) included in the attribute data field of the AVP. AVP code values are standardized by IETF for the AVPs of the base protocol. New applications should try using the existing AVPs to the extent possible. Diameter saves AVP codes 0-255 for backward compatibility with attributes defined by RADIUS. New applications can define additional AVPs if necessary.


 AVP Flags:
                                               
                              0                 1              2              3             4                5            6             7  

V

M

P

r

r

r

r

r

                                                                                   AVP Flag Format
 The “V” bit, known as the Vendor-Specific bit, indicates whether the optional VendorID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space. If set to 0, it means absence of a Vendor-ID field, which indicates a standard AVP specified by IETF.
  The “M” bit known as Mandatory bit, indicates if the AVP is mandatory (M bit set to 1) or optional (M bit set to 0). If the sender indicates that support for the AVP is mandatory and the receiver does not understand the AVP, the Diameter request is rejected; If the AVP is optional and not understood by the destination, it may be ignored.
 The “P” bit known as Protected bit. The P bit indicates the need for encryption for end-to-end security. Diameter base protocol specifies which AVPs must be protected by end-to-end security measures (encryption) if the message is to pass through a Diameter agent.

                          
                                                                                           

AVP Format

         

Error handling
      Errors in the Diameter fall into two categories: protocol errors and application errors. Protocol errors refer to something being wrong with the underlying protocol used to carry Diameter messages, perhaps incorrect routing information or temporary network failure.
        
   Applications errors, on the other hand, result from the failure of the Diameter protocol itself, and there are plenty of sources that will cause application errors. For example, when a mandatory AVP is missing in a particular Diameter command, a DIAMETER_MISSING_AVP error code is returned. Every response message in Diameter will carry a Result-Code AVP, and the receiver of a response message can check this AVP to see if the previous message was successfully processed.

  The Diameter protocol shares the same semantics of error code definition as the HTTP protocol. The return status of messages can be easily identified by checking the first digit of the return code:

1xxx: means the request can't be satisfied and additional information is required for the service to be granted.

 2xxx: means the request was processed successfully.

3xxx: means there was a protocol error when transmitting a Diameter message. Generally, a Diameter proxy should try to fix this problem by either routing the message to another Diameter server, or by keeping the message in a local cache and sending it again later.

4xxx: means the requested message cannot be satisfied at the moment, but it might work in the future. An example is a server that temporarily lacks physical storage space to handle any incoming requests.

5xxx: means there was an application error when the server was processing the request message. The sender should not try to send the same message again. Instead, the sender will have to determine the cause of the application error by checking the error code, and then fix the problem.

Location Update

Location Update(UL):

            When ever the MS tries to connect with the network location update happens. Here we gonna see the location update from MSC to the HLR.

             When your mobile station tries to latch with the network for the very first time, UL request will be sent respective operators MSC/VLR after that MSC will request HLR to provide the authentication   information to authenticate the mobile station(send authentication request). HLR will respond to the MSC/VLR with corresponding authentication vectors. Once MSC receives authentication vectors from HLR, it request the same to the MS(for detailed SAI please refer below) and MSC will compare both MS and HLR requests if both matches MSC will send the UL request to HLR else it will fail the UL.

                           Once the UL request reaches the HLR, HLR will send the Insert Subscriber Data request (ISD)to the MSC which carries what are all the services provided by the operators such as telephony services, SMS services, call waiting call forwarding, etc.
                       
                 Followed by the ISD request HLR will send the UL acknowledgment request to MSC to confirm that UL is done and the same will be notified to MS from MSC once it get done MS will be successfully latch with  that corresponding MSC/VLR.

First UL

UL

    The difference between first time UL and non-first UL is, when the HLR receives UL request from a new MSC/VLR, it will initiate cancel location to the previous MSC/VLR where the customer presently latched. So that customer datas will removed from existing MSC/VLR and the same will available on new MSC/VLR.

                         SAI: Send Authentication Information

Authentication Vectors:

                         There are two different types(majority) of authentication vectors used MSC/VLR to authenticate the MS. Those are Triplet or Quintet parameters together forms a authentication vector.

Quintet:

RAND - Random value

XRES – Expected Signed Response

CK - Ciphering Key

IK - Integrity Key

AUTN - Authentication Token

Triplet: 

RAND – Random Number

XRES- Signed Response

Kc - Ciphering Key

Send Authentication Information for GSM:

                         For GSM-SAI, triplet parameter together forms a authentication vector.

The new VLR sends a request to the HLR/AUC (Authentication Center) requesting the “authentication triplets” (RAND, SRES, and Kc) available for the specified IMSI.

The AUC, using the IMSI, extracts the subscriber's authentication key (Ki). The AUC then generates a random number (RAND), applies the Ki and RAND to both the authentication algorithm (A3) and the cipher key generation algorithm (A8) to produce an authentication Signed Response (SRES) and a Cipher Key (Kc). The AUC then returns to the new VLR an authentication triplet: RAND, SRES, and Kc.

The MSC/VLR keeps the two parameters Kc and SRES for later use and then sends a message to the MS. The MS reads its Authentication key (Ki) from the SIM, applies the received random number (RAND) and Ki to both its Authentication Algorithm (A3) and Cipher key generation Algorithm (A8) to produce an authentication Signed Response (SRES) and Cipher Key (Kc). The MS saves Kc for later, and will use Kc when it receives command to cipher the channel. 

The MS returns the generated SRES to the MSC/VLR. The VLR compares the SRES returned from the MS with the expected SRES received earlier from the AUC. If equal, the mobile passes authentication. If unequal, all signaling activities will be aborted.

Update Location for GSM