The Web of Diameter Specifications

In the previous chapter we were complaining that, while RADIUS base specification defines support for many authentication mechanisms, it leaves the specification of accounting methods to another RFC. As shown in Figure 7.1, the relationships and dependencies between Diameter specification documents are much more complex, or less mildly put, peculiar to the eyes of uninitiated.

The Diameter base protocol was standardized (draft standard) as recently as September 2003. However, many of the important usages of the Diameter (applications) are defined in separate documents that often are still work in progress. In this section we intend to provide an overview of how the various specifications are tied to each other.

7.1.1.1 Diameter Base Specification

This specification [DIMETER3588] defines most of the Diameter basic building elements, such as a basic set of messages, attributes and the attribute structure. The base specification

also goes to great lengths (compared to RADIUS) in defining inter-realm operations. For instance, it clearly defines the role of various types of Diameter agents in processing and routing of Diameter messages. Diameter base specification also spends a great deal of its bandwidth on explaining message transport concepts.

One thing that is new with Diameter is that the Diameter base specification defines the concept of applications. Diameter applications are services, protocols, and procedures that use the facilities provided by the Diameter servers, proxies and the Diameter protocol itself. A good example of a protocol using Diameter is Mobile IP. All Diameter applications must support the functionality specified in Diameter base specification (this explains why Diameter base protocol is at the bottom of the pyramid in Figure 7.1).

Possibly the most jaw-dropping surprise to a person coming from the RADIUS-planet is that dealing with NAS for authentication and authorization purposes is considered an application for Diameter. Despite all the volume and feel of completeness offered by Diameter base specification, no details on simple authentication and authorization procedures or even on interaction with NASes are provided in that specification. The interaction of Diameter with NAS for providing authentications is defined in a separate specification (NAS application). Also when it comes to authorization, the Diameter base protocol assumes that authorization request messages (including those for access authorization) are application specific and need to be defined by other application-specification documents. The Diameter base specification goes only as far as saying that the Diameter client is the entity issuing an authentication and/or authorization request on behalf of the user to the server, but does not offer any detail on the messaging procedure or the messages themselves. Oddly enough, Diameter base specification does define messages for terminating user sessions.

In contrast to RADIUS, Diameter base specification defines accounting methods and messages. The reason may be that it is required of all Diameter applications to support accounting procedures.

7.1.1.2 Security Specifications

The Diameter base specification also specifies end-to-end as well as hop-by-hop security mechanisms. Unfortunately transport layer security protocols, such as TLS or network layer

CMS/IPsec/TLS Diameter Base Protocol

NAS

Mobile IP Other Apps

Transport Profile

security protocols, such as IPsec (see Chapter 4) would provide security for the entire Diameter message between the two nodes. However, as we explained in the previous chapter (see attribute hiding discussion in Chapter 6), often it is important to protect only specific data objects from some dubious intermediaries, while the message itself may have to be examined or processed by these intermediaries. Roaming scenarios, where Diameter signaling has to go through foreign-owned Diameter proxies, are perfect examples of this. To provide end-to-end data object security an additional security mechanism, called Cryptographic Message Syntax security (CMS) [CMS3370] module was suggested. Unfortunately, even though the specification describing the use of CMS with Diameter [DICMSDR] was pursued by the IETF AAA working group for a while and survived 4 revisions, it is no longer an active working group item. At the time of writing it is doubtful that this specification will be pursued by the group any longer.

7.1.1.3 Diameter Transport Profile

In the previous chapter, we discussed the issues with lack of reliability for RADIUS messaging due to its use of UDP. Diameter designers took reliability much more seriously and went as far as stating that Diameter specification consists of the base specification [DIMETER3588] and the AAA transport profile RFC 3539 document [AAATR3539]. This describes two of bottom blocks in the Diameter specification pyramid, shown in Figure 7.1. Oddly, the standards track RFC 3539 looks more like a recommendation document than a standards specification document. This document discusses issues of the interaction between AAA protocols and the transport layer and provides recommendations on how to deal with those issues. The only firm specification provided covers fail-over mechanisms. Still, there are several subtle inter- dependencies between Diameter base specification RFC and the AAA transport profile RFC that justify inclusion of the latter as a required Diameter specification:

● The Diameter base protocol specification defines the transport connection between Diameter nodes as a TCP or SCTP connection and puts great care on defining the transport layer concepts for Diameter. On the other hand, the transport profile document requires that Diameter agents and server must support both TCP and SCTP, while the client MUST support either TCP or SCTP.

● The transport profile document recommends that the AAA implementations make use of standards track and experimental techniques to deal with the transport issues described in that document.

The bottom line is that Diameter requires the use of reliable transport protocol. We will go through the Diameter transport concepts and requirements in more detail later on in this chapter. So far, we have covered all the bottom blocks in the pyramid in Figure 7.1. All Diameter applications must be implemented together with the Diameter base protocol, Diameter transport profile and the proper security mechanisms defined for Diameter.

7.1.1.4 Diameter NAS Application

As mentioned earlier, the dealings of Diameter servers with NASes are considered as applications of the Diameter protocol and therefore are defined in a separate application specification document. However, due to the central nature of AAA servers, and the enforcing

nature of the NASes as edge devices, almost all applications and services that deal with AAA servers need to do so through an NAS. That would mean the implementation of these applications must also support the Diameter NAS application specification. Thus Diameter NAS application procedures are fundamental for functionality of other Diameter applications. This should explain the awkward hump in the Diameter specification pyramid shown in Figure 7.1. Unfortunately all these intricate relations make understanding the lengthy and complicated Diameter specifications even more difficult.