AAA stands for Authentication, Authorization, and Accounting.
Authentication is the verification that a user who is requesting services is a valid user of the network services requested. The user must present an identity, like a user name or phone number, and credentials, like a password, a digital certificate, or one‐time passphrase, to the verifier in order to be authenticated.
Authorization is the determination of whether requested services can be granted to a user who has presented an identity and credentials based on their authentication, service request, and system state. Authorization state may change over the course of a user's session due to consumption limits or time of day.
Accounting is the tracking of the user's consumption of resources for billing, auditing, and/or system planning. Typical accounting data collected includes the identity of the user, the service delivered, and when the service started and stopped.
Consider a voice‐over IP (VoIP) service provider that offers telephony services to a large number of end users. End users can connect to the service with software for VoIP clients that runs on a smart phone, tablet or desktop PC, or they may use a purpose‐built hardware phone.
When the user's device contacts the VoIP network, the VoIP service provider will authenticate the user accessing their network. That is, the provider wants to determine that the user, or her device, is who they say they are. The authentication mechanisms and credentials vary by deployment. For example, some deployments may use human‐memorizable username and password combinations, while others may use a public key infrastructure with certificates stored on smart cards.
Once the VoIP service provider has successfully authenticated the user, the provider will then authorize them to use the services by verifying the conditions and privileges of the user's account and the status of the user's credits for the requested action, such as making a phone call.
If the user successfully passes the authorization procedure, the user's resource consumption will be accounted. Accounting resource consumption is useful for a number of reasons, including capacity planning, understanding user behavior to improve service experience, charging for service use, and measuring policy compliance. The kinds of data collected as part of the accounting process depend on the application context and the needs of the service provider, and the data may need to be collected from various places in the network. For example, one VoIP service provider may collect data about transmitted voice packets. Another provider may be satisfied with collecting data about the call setup procedures only.
Typically VoIP deployments use Session Initiation Protocol (SIP) for call setup. In small VoIP deployments that use SIP, the AAA operations happen within the SIP proxy, which is a network element that helps to route SIP requests to their final destinations. As a SIP network grows larger, the VoIP service provider may deploy a dedicated and centralized AAA server to manage subscribers' information and their authorization properties on behalf of multiple proxies. When a service request arrives at a SIP proxy, the proxy will send AAA‐related requests to the AAA server.
The SIP proxy in this distributed network is a kind of network access server. Network access server (NAS) is a generic term for the end user's entry point to a network. A NAS provides services on a per‐user basis, based on authentication, and ensures the service provided is accounted for. A NAS contacts a separate AAA server to verify the user's credentials and then sends accounting data to the AAA server. A NAS, then, is an AAA client.
When the AAA functionality is outsourced from a NAS to the AAA server, there needs to be a protocol defined between the AAA client within the NAS and AAA server. Since the developers who created the NAS are likely different than the developers who created the AAA server, it is helpful to not only define a communication protocol, but also to agree on an open standard rather than to use a proprietary interface. In fact, various AAA protocol standards have been defined, with standards work starting with the early Internet dial‐up services and progressing to cover connections to today's modern wireless networks.
The standards organization that works to improve the interoperability of the Internet is the Internet Engineering Task Force (IETF), an international community of network designers, operators, vendors, and researchers that develop open, voluntary Internet standards. Examples of such standards include Internet transport (TCP/IP, UDP), email (SMTP), network management (SNMP), web (HTTP), voice over IP (SIP), and also AAA (RADIUS, Diameter). The IETF does not have formal membership requirements and is open to anyone interested in improving the Internet. The newcomer's guide to the IETF is known as The Tao of the IETF [1] and can be found online.
Standards work in the IETF is done in working groups, which discuss protocol solutions on mailing lists and in person at IETF meetings, and capture these solutions in documents known as Internet drafts. Working groups are self‐organized by topic and are grouped into broad focus areas. Work on AAA protocols has taken place in multiple working groups.
The gauge of a protocol in the IETF is “rough consensus and running code”. When the working group has arrived at rough consensus, the Internet draft enters a review period known as a Last Call, in which the larger IETF community can provide input. Internet drafts are then reviewed by the Internet Engineering Steering Group (IESG). When the IESG approves an Internet draft, the draft moves on to become a Request for Comments (RFC), which, despite its categorization, is now at a level of stability that it can be implemented with confidence.
The details of IETF Internet protocols, such as port numbers, application identifiers, and header field names, are stored with the Internet Assigned Numbers Authority (IANA), which is responsible for the global coordination of Internet protocol resources.
Diameter is an open standard AAA protocol defined by the IETF. Diameter's features fulfill multiple requirements of network operators. The definition of the Diameter protocol is given in the Diameter base specification, RFC 6733 [2].
Various AAA protocols, such as the Common Open Policy Service Protocol (COPS) [3] and Remote Authentication Dial In User Service (RADIUS) [4], had been developed before work on the Diameter protocol started. Experience with these protocols provided the IETF community with requirements for a next‐generation AAA protocol. These requirements are documented in RFC 2989, Criteria for Evaluating AAA Protocols for Network Access [5]. The design of Diameter incorporated the lessons learned from these various AAA protocols.1
As work continued on Diameter, the AAA working group of the IETF [6] evaluated the available AAA protocols against the requirements given in RFC 2989. Those requirements are:
The AAA working group published their results in RFC 3127 [7], Authentication, Authorization, and Accounting: Protocol Evaluation, expressing a preference for Diameter since it met most of the requirements specified in RFC 2989 and needed only minor engineering to bring it into complete compliance. Since the Diameter specification was still under development, the working group could address the requirement gaps.
A book about Diameter cannot be silent about its predecessor, RADIUS. RADIUS was originally standardized in January 1997 by the IETF with RFC 2058 [8], which was replaced by RFC 2138 [9] a few months later, and was made obsolete in June 2000 by RFC 2865 [4].
Diameter was able to address deficiencies found in the RADIUS protocol, namely:
This was, however, not the end of the story since, paralleling the Diameter work within the IETF AAA working group and later continued in the RADIUS [11] and RADEXT [12] working groups, the RADIUS protocol experienced a number of improvements, many of which were inspired by work on the Diameter protocol:
At the time of this writing, development of the RADIUS protocol is still ongoing in the IETF radext working group. However, not only does the IETF develop extensions for RADIUS, but other organizations do also. Hence, the best way to gain an overview of the available extensions is to look at the IANA registry for RADIUS [19].
Today, many of the features of Diameter are also available within RADIUS. It is therefore fair to ask which communities are driving the development of each protocol. It turns out that many small‐ and medium‐size enterprises use RADIUS, including many WLAN hotspot deployments, universities, and digital subscriber line (DSL) and cable operators. On the other hand, large Internet service providers, and particularly mobile operators, use Diameter in their network architectures. The market is therefore is nicely divided, and does not lead to rivalry in the standardization environment.
It is important to note that the Diameter base specification (RFC 6733 [2]) is a revision of the original Diameter protocol, specified in RFC 3588 [20], and is the output of the IETF DIME working group [21], which incorporated feedback of protocol implementers from interoperability testing events and discussions on working group mailing lists. RFC 6733 obsoletes RFC 3588.
The main differences between RFC 3588 and RFC 6733 are the following:
More details about these differences can be found in Section 1.1.3 of RFC 6733.
Given these changes, we recommend that you look at RFC 6733 even though older implementations focus on RFC 3588. It is important to understand that many implementations will need time to meet the additional requirements outlined in RFC 6733. In particular, the security changes will lead to changes in implementation code. It is hoped that, by the time you read this book, many, if not most, vendors will have conducted interoperability tests and therefore have taken the various clarifications into account.
freeDiameter
?freeDiameter
is an open source implementation of the Diameter protocol. Development on freeDiameter
was started in 2008 as an academic project with the goals of evaluating and promoting the Diameter protocol as specified by RFC 3588. freeDiameter
has evolved to follow the revisions of the Diameter protocol in RFC 6733, part of which were introduced as a result of the evaluation started with freeDiameter
.
freeDiameter
has been used in commercial Diameter deployments, and it can be used as a reference implementation that anyone developing a commercial Diameter stack can use for interoperability testing. It is also a platform made freely available to researchers and students for prototyping, and for evaluating their ideas for new services built upon Diameter. For these reasons, freeDiameter
was written in the C language and has been engineered to be as flexible and extensible as possible, with a small system footprint and good performance.
We will use freeDiameter
throughout this book to illustrate various concepts of the Diameter protocol. By following the hands‐on examples in this book, freeDiameter
will give you a better understanding of Diameter as you configure it to exchange Diameter messages between different nodes. Instructions on setting up freeDiameter
can be found in Appendix A.