This book is based on the authors' personal experiences in the technical field and public standards documents created by the 3rd Generation Partnership Project (3GPP), the Internet Engineering Task Force (IETF), and other standards development organizations. The opinions and views of the authors are solely those of the authors and do not necessarily represent the views of organizations where the authors work. Throughout this book the authors have attempted to make it clear when something is an opinion or a view of the authors. Some of the examples, feature lists, and identified ambiguities may not apply universally to all deployments and products.

The publisher and the authors make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the authors shall be liable for damages arising herefrom. The fact that an organization or website is referred to in this work as a citation and/or a potential source of further information does not mean that the authors or the publisher endorses the information that the organization or website may provide or recommendations it may make. Further, readers should be aware that Internet websites listed in this work may have changed or disappeared between when this work was written and when it is read.

This book is a collaborative effort of the following four persons (in alphabetical order):

• Sébastien Decugis is the original author and maintainer of the freeDiameter implementation. He was involved in IETF activities related to Diameter from 2008 to 2010, and he met Hannes and Jouni working on Diameter at IETF. His work was supported by the National Institute of Information and Communications Technology (NICT) and the WIDE Project, a cross‐company and cross‐university research project in Japan. Sébastien is not working for those structures anymore, but maintaining and developing the freeDiameter implementation on his free time, while NICT and WIDE are kindly maintaining the server resources required by the project.
• Jouni Korhonen, PhD, is a Principal R&D Engineer with Nordic Semiconductor. Previously he was with Broadcom and was active in Ethernet‐based base station architectures, Ethernet‐based fronthaul networks, and time‐sensitive networking. Prior to Broadcom Dr. Korhonen was with Nokia Siemens Networks and TeliaSonera where he was heavily involved in IPv6, DNS, mobility, and Diameter‐based core network signaling matters in 3GPP and IETF. He has also held multiple leadership positions within IETF and IEEE during his career, including chairing both the Diameter Maintenance and Extensions (DIME) and RADEXT WGs. Dr. Korhonen is still an active contributor with 38 published Requests for Comments (RFCs) to date. His current focus is on cellular Internet of Things and 3GPP system architecture evolution.
• Jean Mahoney had wanted to work on an oceanographic research vessel ever since she was a child. Having achieved her life goal right out of college, she discovered that she did not like being in the middle of the ocean. Thus she started on her career in computer networking and technical communication, explaining complex software systems to other developers, system administrators, and users. Jean has more than a decade's worth of experience with IETF specifications and the servers and clients built on top of them. Jean is currently the co‐chair of the IETF SIPCORE working group and Gen‐ART Secretary.
• Hannes Tschofenig co‐chaired the IETF DIME working group from March 2006 till March 2010, when he was elected to the Internet Architecture Board (IAB) of the IETF. He is co‐author of over 80 RFCs, including several Diameter specifications. His work on Diameter in the IETF was sponsored by Siemens (from 2001 to 2007) and later by Nokia Siemens Networks (from 2007 to 2013), i.e., telecommunication equipment manufacturers selling Diameter‐based products. Hannes is now employed by Arm Ltd., where his focus is on improving the security of Internet of Things devices.

The Diameter effort started 20 years ago. Its roots were in the limitations of other technologies for user authentication in access networks.

The need for backend authentication servers to assist access networks had grown in the preceding era of modem pools and dial‐in access servers. Tools for the simple authentication task existed, but mobile networks in particular needed tools that were capable of growing beyond this task.

The Diameter protocol was born in the IETF. It was designed to be a general‐purpose Authentication, Authorization, and Accounting (AAA) protocol for many uses.

Like many other pieces of Internet technology, AAA is not really visible to the end user, but it is crucial for the functioning of the Internet, in particular for the various access networks that provide connectivity for users. When your phone connects to a mobile network, the mobile network's control functions that are needed in the background are built on Diameter.

Mobile networks are the prime area where Diameter is used; simpler other tools also continue their existence and are today equally broadly used, in wireless local area network authentication for instance. And the technology continues to evolve, with most recent designs starting to employ web‐based protocols.

The authors, Jean, Jouni, Sébastien, and Hannes, have all worked tirelessly for many years – or even decades – on Diameter, AAA, and other critical Internet technologies. They have written and reviewed specifications, worked on improvements, chaired working groups, built open source implementations, and helped the industry use this technology.

I am happy to see this book on Diameter come out. It focuses on the protocol itself, of course, but also covers open source systems. This is important, as we need both specifications and code to achieve something. It is code that ultimately provides a function, while specifications are needed to ensure that different systems interoperate. The authors approach this book as they have approached their work at the IETF and open source communities, by meticulous attention to detail while keeping the big picture and practical use also up front. Thank you!

Why Did We Write This Book?

“To make money,” you will say. That was, however, not our motivation.

We all have been working on Diameter for several years in different roles and therefore we are regularly involved in discussions about Diameter specification questions, or questions about system design and implementation. Often, we go through the same discussions again and again – just with different people.

There was, however, no book to recommend to our co‐workers and friends. While we were attending the IETF #86 meeting in Orlando, we sat together outside the conference venue and talked about how to address the common questions we receive. The idea to write a book was born. We reached out to Sébastien, who maintains the freeDiameter implementation, and asked him if he would be willing to help us by creating freeDiameter examples since we prefer hands‐on examples in our technical books.

Since two of us had worked with Wiley before on other book projects, we reached out to Wiley again to socialize our idea. To keep it short, you are now holding a Diameter book in your hands.

We hope you enjoy our approach in making you a Diameter expert. We have set up a dedicated website with additional material for this book. If you have questions or feedback, please send us an email at (diameter.book@gmail.com) or visit our webpage at https://diameter‐book.info.

What Does This Book Provide?

This book provides the necessary material to understand Diameter, Diameter applications, and the interactions many applications have with the backend infrastructure.

This book provides a coherent picture of Diameter without regurgitating the specifications. It provides information necessary to understand Diameter. To provide you with a hands‐on experience and to make your reading experience more interesting, we make use of an open source implementation of the Diameter protocol, called freeDiameter, to

• help you to understand how a Diameter implementation works, and
• illustrate a number of examples using freeDiameter.

It is not our goal to cover everything found in the Diameter specifications. We will, however, provide you with the necessary pointers for further reading.

Who is the Intended Audience?

This book assumes only basic familiarity with how Internet protocols work, such as the concept of IP addresses, the layered protocol stack, and the functions of the layers (particularly the “network layer”, the “transport layer”, and the “application layer”).

We use freeDiameter for examples and to illustrate test setups. A basic understanding of Unix is required in order to set up the freeDiameter environment and to execute the protocol runs. An understanding of TCP/IP will make the examples easier to follow. Readers may skip the examples, but we do recommend engineers use the hands‐on experience to gain a deeper understanding of the protocol.

While a technical background or interest in technical matters is a plus, familiarity with the standardization work in the IETF or 3GPP is not required to understand this book.

We believe the following groups will benefit:

• System architects and system designers who have to understand a range of technologies to solve specific use cases. The challenge for those people is to understand the big picture and enough details to glue different protocols together.
• Programmers who need to understand the bigger picture of the Diameter protocol.
• Standardization experts who are new to Diameter or need to define new Diameter extensions.
• Students and researchers who are interested in technology that is deployed by many network operators. Typically, Diameter is not widely known since it is not an end‐user‐facing technology.
• Technical marketing people who want to gain a better understanding of the technology they are dealing with.

Book Structure

Chapter 1 discusses the motivation for using Diameter, briefly talks about the predecessor to Diameter, RADIUS, and introduces the open source Diameter implementation, freeDiameter.

Chapter 2 describes Diameter via its building blocks. These building blocks are then used to illustrate the basic peer‐to‐peer communication between neighboring Diameter nodes in Chapter 3.

Chapter 4 extends Diameter communication from two nodes to an arbitrary number of nodes.

Following the chapters covering communication between Diameter nodes, Chapter 5 introduces security functionality. Diameter security is today mainly implemented and deployed at the level of peer‐to‐peer communication.

Chapter 6 describes selected Diameter applications in more detail. We have chosen applications that are deployed today and illustrate the flexibility and capabilities of Diameter well.

Chapter 7 is an advanced chapter that teaches you how to develop your own Diameter extensions, for example by defining new attribute–value pairs (AVPs), new commands, or even completely new Diameter applications.

We have added freeDiameter examples throughout the book as far as applicable. Not every standardized functionality is already available in freeDiameter.

This book effort took much longer than we had expected. A big thanks to Wiley for their continued support and patience. We (Jean, Sébastien, Jouni, and Hannes) had specific ideas in mind of what type of book we wanted to write. We are happy that we managed to implement our ideas in this book without taking shortcuts and came this far in our journey.

Needless to say, this book project would not have been possible without the efforts put forth by those working in the IETF DIME working group. We would also like to thank our peers working in other organizations on Diameter extensions, specifically in 3GPP. A tremendous amount of work has gone into Diameter's standardization and widespread deployment. It does not just happen by accident or luck.

Writing more than 200 pages was not easy, and we would like to thank our families for their patience. Without their support it would not have been possible to complete this project. Thank you, Verena, Elena, Robert, and Hanna. Jouni also sends special thanks to Dana Street Roasting Company for its excellent caffeine‐rich products that helped him to stay focused as the writing of this book took place during hours when normal people sleep.

Finally, we would also like to thank our employers. They have enabled us to participate in various standards developing organizations for many years. Not only have we been able to work on exciting technical topics, and to travel around the world to participate in many face‐to‐face standardization meetings and interoperability events, but we also met many great people.

1.1 What is AAA?

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.

1.2 Open Standards and the IETF

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.

1.3 What is Diameter?

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

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:

• Scalability: The AAA protocol has to be able to support millions of end users and tens of thousands of devices, AAA servers, Network Access Servers, and brokers.
• Failover: Failover support aims to provide uninterrupted AAA service in the case of a failure. Failover requires the detection of a failed node and the re‐routing of outstanding messages to an alternative node. Failover support may lead to the retransmission of messages, and those duplicate messages should be handled appropriately by the protocol.
• Security: AAA protocols carry sensitive data, including long‐term authentication credentials (such as passwords), session keys, service usage information as part of accounting records, and possibly the end user's location. From a data protection point of view, this personal data requires special care. Network operators also want to avoid malicious parties injecting false information into the system. For this purpose, providing a common, widely used security mechanism is desirable.
• Reliable transport: When accounting records were transmitted over an unreliable transport protocol, as done in earlier protocols (such as RADIUS), packet loss translated to loss of money. Consequently, implementations added their own reliability mechanisms, leading to differences among vendors. Diameter incorporates the reliable transports the Transmission Control Protocol (TCP) and the Stream Control Transmission Protocol (SCTP) to ensure uniform behavior among implementations by different vendors.
• Agent support: Earlier AAA protocols did not offer nodes that could route and redirect AAA messages, which can future‐proof a AAA network deployment.
• Server‐initiated messaging: In earlier AAA protocols, only the AAA client could initiate the message exchange. The AAA server's ability to initiate messages was added later as an optional feature, and therefore support for it could not be assumed. Server‐initiated messaging is used, for example, when authorization characteristics change and re‐authorization by the user or the end device is required. With long‐running sessions, this initiation has to be triggered by the AAA server towards the AAA client.
• Transition support: Since Diameter would be introduced into existing AAA deployments, it needed to provide a transition story to lower the deployment effort for network operators.
• Ability to carry service‐specific attributes: The AAA protocol needs to be extensible and provide the ability to define new attributes required by new services.

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.

1.4 What is 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.