The Internet NG Project

ING Home

ING WU5 Home

D5.1 Contents

Summary

1. Introduction

2. Terminology

• IETF
• ISO/IEC
• ITU-T
• ETSI
• Dictionary
• ING

3. Technology

• RADIUS
• DIAMETER
• TACACS
• XTACACS
• TACACS+
• RTFM
• NetFlow
• ATM

4. Questions

5. Glossary

DIAMETER

Description - Packet Format - Sequence Diagram - Protocol Characteristics - Current Developments - References - Products

Description

The diameter protocol is a proposed protocol which can be used for policy, AAA (Authentication, Authorization and Accounting) and resource control. The protocol has been setup to coexist with RADIUS, a protocol which has already been widely implemented. The draft 'draft-calhoun-diameter-10.txt' [CR99] contains a description of the message format and transport to be used by all DIAMETER extensions or implementations. A DIAMETER extension is an extension on the described protocol for a specific service or task using DIAMETER as a transport mechanism.

The draft 'draft-calhoun-diameter-accounting-01.txt' [AC99] contains the accounting extension on the protocol. It describes how accounting data can be transferred using the DIAMETER protocol. According to the document the accounting data can be formatted using the ADIF (Accounting Data Interchange Format), described in the draft 'draft-ietf-roamops-actng-06.txt' [AL99]. There is no description of accounting keywords, just their format.

Packet Format

The data between client and server are exchanged in DIAMETER packets. Exactly one packet is encapsulated in an UDP data field. Every packet contains the following information:

Figure 1: Diameter Packet Format.

• Radius PCC (1 octet), for backward compatibility with RADIUS, must be set to 254 which equals 'diameter packet'
• Flags (3 bits), use to identify any options
• A (1 bit), package is only an acknowledgement, and does not contain a command code
• W (1 bit), Set when the fields NS and NR are present (used when using UDP as transport protocol)
• Version (3 bits), Indicates version number , should be set to 1
• Packet length (2 octets), Length of the complete packet
• Identifier (4 octets), Sequence number used to match outstand requests with replies.
• NS (2 octets), Next send
• NR (2 octets), Next received
  • AVP code (4 octets), Diameter command (256)
  • AVP length (2 octets), length of this AVP
  • Cmd flags (6 bits), can be used for a specific command, otherwise 0
  • Reserved (6 bits)
  • Flag T (1 bit), Tag bit, used to group AVP's
  • Flag V (1 bit), Vendor-specific bit, indicates whether the optional vendor-id field is present.
  • Flag H (1 bit), Hop bit, indicates that the AVP is encrypted using Hop-by-hop encryption.
  • Flag M (1 bit), Mandatory bit, Indicates whether support of the AVP is required.
  • Vendor id (4 octets, optional),
  • Tag (4 octets, optional),
  • Command code, contains the diameter command id.
    • diameter attributes (AVP's)

Diameter Commands:

• Message-Reject-Ind (server->client)
• Device-Reboot-Ind (server->client)
• Device-Watchdog-Ind (server->client)
• AA-Request (client->server), request authentication and/or authorization for a user.
  The server can reply on an 'AA-Request' with one of the following messages:
  • AA-Answer (server->client), request is accepted or rejected by the server
  • AA-Challenge-Ind (server->client), response on an aa-request, where the server expects a response from the client encapsulated in an aa-request.

Sequence Diagram

Below is a drawing of a sequence diagram when a user accesses the network through the Network Access Server and disconects itself.
The messages displayed in the sequence diagram are send using UDP as a transport protocol. A windowing protocol is used on top of this unreliable UDP transport protocol to guarantee a correct transmision and retrieval of those messages. This protocol introduces a ZLB message (Zero Length Body, a diameter message without a diameter command), which is used to send an acknowledge of a received message, when there is no other message to piggy-back the the acknowledgement. These messages have not been included in the sequence diagram.

Figure 2: DIAMETER's Message Flow.

1. Network Access Server (NAS) get username/password pair from remote user, and sends this with an 'AA-Request' to the DIAMETER Server (Authentication phase).
2. If the user and password combination is valid then the DIAMETER Server sends an 'AA-Response' with authorization information (For example: IP-address, network mask, allowed session time, etc.) to the Network Access Server (Authorization phase).
3. The NAS send an accounting message in ADIF format (the Accounting Data Interchange Format [AL99]) to the AAA server.
4. The AAA server replies with an accounting answer to acknowledge the accounting request.
5. When the user logs out, the NAS send an accounting message in ADIF format (the Accounting Data Interchange Format [AL99]) to the AAA server. It is possible to end interrim accounting requests.
6. The AAA server replies with an accounting answer to acknowledge the accounting request.

Protocol Characteristics

Transport protocol used	UDP or TCP depending on the protocol extension
Message traffic	request/response from client to server. unsolicited messages from server to client.
hop-by-hop security	Encryption of complete data with shared secret (HMAC-MD5-96 [RFC2104]). No encryption using IP encryption instead.
end-to-end security (for use through proxies)	Described in the 'draft-calhoun-diameter-proxy-02.txt' [CB99]
Message size	Header size (12 bytes) + NrOfAVP's(0 .. N) * AVP (12..65400 bytes) (AVP = Attribute Value Pair)
Total number of different AVP's	65535 (0.255) are compatible with RADIUS

Differences between RADIUS and DIAMETER

The DIAMETER protocol is designed as a next generation RADIUS protocol, which has to solve the known RADIUS problems today. (derrived from 'Diameter Framework Document' [CZ99]. Below is a list of problems known to RADIUS and how the're being solved in DIAMETER

1. 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).
2. 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)
3. 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)
4. 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.
   a Diameter client expects a success of failed response or just an acknowledgement of the received request by the server.
5. 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
6. No fail-over server support
   Radius server has no way of indicating that it's going down or is currently running
   Diameter supports Keep-allive messages and messages that indicate that a server is going down for a time period .
7. 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 encription and authentication.
8. 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 orrigin.
   Diameter supports als end-to-end security which guarantees that the information can not be modified without notice.
9. 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
10. 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 allignment requirement, which can be handled more efficient by most processors.

Current Developments

The DIAMETER protocol is currently under development. There is no specific working group assigned to this protocol, but there is a homepage which contains the latest information on DIAMETER at www.diameter.org.

References

Products

Yet Empty