77,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Presents the principles, design, development and applications of the Diameter protocol suite
The Diameter protocol was born in the Internet Engineering Task Force (IETF) and designed to be a general-purpose Authentication, Authorization, and Accounting (AAA) protocol applicable to many network environments. This book is for everyone who wants to understand the Diameter protocol and its applications. This book explains the place Diameter holds in global telecommunication networks and teaches system architects and designers how to incorporate Diameter into their network environments.
Diameter: New Generation AAA Protocol - Design, Practice and Applications begins by describing the foundation of Diameter step-by-step, starting with building blocks of the protocol, and progressing from a simple two-party exchange to a multi-party exchange involving complex routing. It discusses the motivation for using Diameter, talks about its predecessor, RADIUS, and introduces the open source Diameter implementation, freeDiameter. The book expands beyond protocol basics to cover end-to-end communication, security functionality, and real-world applications, extending to the backend infrastructure of mobile telecommunications. In addition, an advanced chapter teaches readers how to develop Diameter extensions for their own AAA applications.
- Written by an experienced author team who are members of the group that standardized Diameter in the IETF and are at the forefront of this cutting-edge technology
- Presents the still-developing topic of Diameter from both introductory and advanced levels
- Makes available for download a virtual machine containing the open source implementation: https://diameter-book.info
- Provides hands-on experience via freeDiameter examples and exercises throughout the book
Diameter: New Generation AAA Protocol - Design, Practice and Applications will appeal to system architects and system designers, programmers, standardization experts new to Diameter, students and researchers interested in technology that is deployed by many network operators.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 378
Veröffentlichungsjahr: 2019
Ähnliche
Table of Contents
Cover
Disclaimer
About the Authors
Foreword
Preface
Why Did We Write This Book?
What Does This Book Provide?
Who is the Intended Audience?
Book Structure
Acknowledgements
List of Abbreviations
1 Introduction
1.1 What is AAA?
1.2 Open Standards and the IETF
1.3 What is Diameter?
1.4 What is
freeDiameter
?
References
2 Fundamental Diameter Concepts and Building Blocks
2.1 Introduction
2.2 Diameter Nodes
2.3 Diameter Protocol Structure
2.4 Diameter Applications
2.5 Connections
2.6 Diameter Message Overview
2.7 Diameter Sessions
2.8 Transaction Results
2.9 Diameter Agents
References
3 Communication between Neighboring Peers
3.1 Introduction
3.2 Peer Connections and Diameter Sessions
3.3 The DiameterIdentity
3.4 Peer Discovery
3.5 Connection Establishment
3.6 Capabilities Exchange
3.7 The Peer Table
3.8 Peer Connection Maintenance
3.9 Advanced Transport and Peer Topics
References
4 Diameter End‐to‐End Communication
4.1 Introduction
4.2 The Routing Table
4.3 Diameter Request Routing
4.4 Request Routing Error Handling
4.5 Answer Message Routing
4.6 Intra‐Realm versus Inter‐Realm Communication
4.7 Diameter Routing and Inter‐Connection Networks
4.8 Diameter Overload Control
References
5 Diameter Security
5.1 Introduction
5.2 Background
5.3 Security Threats
5.4 Security Services
5.5 PKI Example Configuration in
freeDiameter
5.6 Security Evolution
References
6 Diameter Applications
6.1 Introduction
6.2 Base Accounting
6.3 Credit Control
6.4 Quality of Service
6.5 Interworking RADIUS and Diameter
6.6 S6a Interface
References
7 Guidelines for Extending Diameter
7.1 Introduction
7.2 Registration Policies
7.3 Overview of Extension Strategies
7.4 Extending Attribute–Value Pairs
7.5 Extending Commands
7.6 Creating New Applications
7.7 Lessons Learned
7.8 Vendor‐specific Extensions
7.9 Prototyping with
freeDiameter
References
Appendix A: freeDiameter Tutorial
A.1 Introduction to Virtual Machines
A.2 Installing the Virtualization Software
A.3 Creating Your Own Environment
A.4 Downloading the VM Image
A.5 Installing and Starting the Master VM
freeDiameter
A.6 Creating a Connection Between Two Diameter Peers
Appendix B: freeDiameter from Sources
B.1 Introduction
B.2 Tools and Dependencies
B.3 Obtaining
freeDiameter
Source Code
B.4 Configuring the Build
B.5 Compiling
freeDiameter
B.6 Installing
freeDiameter
B.7
freeDiameter
Configuration File
B.8 Running and Debugging
freeDiameter
B.9 Extensions for Debug Support
B.10 Further Reading
Reference
Appendix C: The freeDiameter Framework
C.1 Introduction
C.2 Framework Modules
C.3
freeDiameter
API Overview
C.4
freeDiameter
Architectures
Reference
Glossary
Index
End User License Agreement
List of Tables
Chapter 2
Table 2.1 Applications offered by the Diameter base protocol.
Table 2.2 Commands defined by the Diameter base protocol.
Table 2.3 Meanings of Command Flag fields.
Table 2.4 Base AVPs.
Table 2.5 Base AVPs, continued.
Table 2.6 Basic AVP data formats.
Chapter 3
Table 3.1 State machine transition events.
Table 3.2 State machine transition actions.
Table 3.3 Peer state machine transition events.
Table 3.4 Peer state machine transition actions.
Chapter 4
Table 4.1 Overload control state for reacting nodes.
Table 4.2 Overload control state for reporting nodes.
Chapter 5
Table 5.1 Essential attributes in a certificate.
Table 5.2 Comparable key sizes (in bits).
Chapter 6
Table 6.1 Base accounting application.
Table 6.2 Credit‐Control application.
Table 6.3 Quality of service application.
Table 6.4 Extensible Authentication Protocol (EAP) application.
Table 6.5 S6a interface application.
Chapter 7
Table 7.1 Diameter Application‐Id registry fragment.
List of Illustrations
Chapter 2
Figure 2.1 The layered design of Diameter.
Figure 2.2 Diameter providing AAA support for a generic service protocol.
Figure 2.3 An example of the Command Code Format.
Figure 2.4 An example of a CCF for a Grouped AVP.
Figure 2.5 Diameter message format.
Figure 2.6 AVP header format.
Figure 2.7 An example of the Command Code Format for a Diameter answer command ...
Figure 2.8 Protocol error call flow.
Figure 2.9 Application error call flow.
Figure 2.10 Diameter redirection.
Figure 2.11 Diameter relay.
Chapter 3
Figure 3.1 Diameter and transport connection between two peers.
Figure 3.2 Diameter user sessions and peer connections.
Figure 3.3 An example of legacy NAPTR records.
Figure 3.4 Results of an SRV query.
Figure 3.5 S‐NAPTR records showing support for Diameter applications.
Figure 3.6 An RFC 6733 style S‐NAPTR record.
Figure 3.7 An example of DNS RRs for realm “example.com”.
Figure 3.8 CER message format.
Figure 3.9 CEA message format.
Figure 3.10 Diameter peer connection failover and failback state machine.
Figure 3.11 Diameter transport connection state machine.
Figure 3.12 Diameter peer state machine. The pseudo states ‘C’ and ‘R‐O’ are ‘...
Figure 3.13 VirtualBox interface to disable a virtual network link.
Figure 3.14 Relations between realm tables, peer tables, application, and peer...
Chapter 4
Figure 4.1 The roaming terminal decides that the Diameter messages must be rou...
Figure 4.2 The Grouped
Proxy‐Info
AVP and its sub‐AVPs.
Figure 4.3 Example inter‐connection Diameter network using the IPX‐roaming netw...
Figure 4.4 Dynamic peer discovery: delegating the publishing of DNS information...
Figure 4.5 Dynamic peer discovery: realm publishes DNS information.
Figure 4.6 Dynamic peer discovery: static route between the client's edge agent...
Figure 4.7 Simplified architecture choices for overload indication delivery for...
Figure 4.8 The Grouped
OC‐Supported‐Features
AVP and its sub‐AVPs.
Figure 4.9 The Grouped
OC‐OLR
AVP and its sub‐AVPs.
Chapter 5
Figure 5.1 Adversary model.
Chapter 6
Figure 6.1 Split accounting service. The user's protocol is abstracted, as is ...
Figure 6.2 Coupled accounting service. The user's protocol is abstracted, as i...
Figure 6.3 Accounting‐Request Command Code Format.
Figure 6.4 Accounting‐Answer Command Code Format.
Figure 6.5 Credit‐Control‐Request Command Code Format.
Figure 6.6 Credit‐Control‐Answer Command Code Format.
Figure 6.7 Authorization scheme for Push mode.
Figure 6.8 Three‐party authorization scheme for Pull mode.
Figure 6.9 Token‐based three‐party scheme for Pull mode.
Figure 6.10 QoS‐Authorization‐Request Command Code Format.
Figure 6.11 QoS‐Authorization‐Answer Command Code Format.
Figure 6.12 QoS‐Install‐Request Command Code Format.
Figure 6.13 QoS‐Install‐Answer Command Code Format
Figure 6.14 Evolved Packet Core. Connections to charging and policy functions ...
Figure 6.15 Authentication‐Information‐Request Command Code Format.
Figure 6.16 Authentication‐Information‐Answer Command Code Format.
Figure 6.17 Update‐Location‐Request Command Code Format.
Figure 6.18 Cancel‐Location‐Request Command Code Format.
Figure 6.19 Cancel‐Location‐Answer Command Code Format.
Figure 6.20 Update‐Location‐Answer Command Code Format.
Figure 6.21 Insert‐Subscriber‐Data‐Request Command Code Format.
Figure 6.22 Insert‐Subscriber‐Data‐Answer Command Code Format.
Figure 6.23 Delete‐Subscriber‐Data‐Request Command Code Format.
Figure 6.24 Delete‐Subscriber‐Data‐Answer Command Code Format.
Figure 6.25 Reset‐Request Command Code Format.
Figure 6.26 Reset‐Answer Command Code Format.
Figure 6.27 Notify‐Request Command Code Format.
Figure 6.28 Notify‐Answer Command Code Format.
Figure 6.29 Purge‐UE‐Request Command Code Format.
Figure 6.30 Purge‐UE‐Answer Command Code Format.
Chapter 7
Figure 7.1 Diameter extensions.
Figure 7.2 Traffic classification and QoS attributes for Diameter.
Figure 7.3
NAT‐Internal‐Address
AVP.
Guide
Cover
Table of Contents
Begin Reading
Pages
xiii
xv
xvii
xix
xx
20
xxiii
xxv
xxvi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
78
79
80
81
77
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
201
202
203
204
205
206
207
208
209
209
210
211
212
213
Diameter
New Generation AAA Protocol - Design, Practice, and Applications
Hannes TschofenigSébastien DecugisJeanMahoneyJouni Korhonen
Copyright
This edition first published 2019
© 2019 John Wiley & Sons Ltd
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.
The right of Hannes Tschofenig, Sébastien Decugis, Jean Mahoney and Jouni Korhonen to be identified as the authors of this work has been asserted in accordance with law.
Registered Offices
John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA
John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK
Editorial Office
The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK
For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.
Wiley also publishes its books in a variety of electronic formats and by print‐on‐demand. Some content that appears in standard print versions of this book may not be available in other formats.
Limit of Liability/Disclaimer of Warranty
While the publisher and authors have used their best efforts in preparing this work, they 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 any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
Library of Congress Cataloging‐in‐Publication Data
Names: Tschofenig, Hannes, author.
Title: Diameter : new generation AAA protocol – design, practice, and
applications / Hannes Tschofenig, Sébastien Decugis, Jean Mahoney, Jouni
Korhonen.
Description: Hoboken, NJ, USA : John Wiley & Sons, Ltd, [2019] | Includes
bibliographical references and index. |
Identifiers: LCCN 2019003182 (print) | LCCN 2019009248 (ebook) | ISBN
9781118875858 (Adobe PDF) | ISBN 9781118875834 (ePub) | ISBN 9781118875902
(hardcover)
Subjects: LCSH: Diameter (Computer network protocol)
Classification: LCC TK5105.5663 (ebook) | LCC TK5105.5663 .T75 2019 (print) |
DDC 004.6/2-dc23
LC record available at https://lccn.loc.gov/2019003182
Cover Design: Wiley
Cover Image : © catalby/Getty images
Dedication
This book is dedicated to the next AAA.
Hannes, Sébastien, Jean, Jouni
Disclaimer
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.
About the Authors
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.
Foreword
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!
Jari Arkko
Senior Expert, Ericsson Research
Preface
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 ([email protected]) 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.
Acknowledgements
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.
Hannes, Sébastien, Jean, Jouni
List of Abbreviations
ABNF
Augmented Backus–Naur Form
AE
authorizing entity
AESE
Architecture Enhancements for Service Capability Exposure
AoC
advice of charge
AppE
application endpoint
CA
certification authority
CCF
Command Code Format
CEA
Capability Exchange Answer
CER
Capability Exchange Request
CIoT
Cellular Internet of Things
COPS
Common Open Policy Service Protocol
CRL
certificate revocation list
DCN
dedicated core network
DDDS
Dynamic Delegation Discovery Service
DEA
diameter edge agent
DIME
Diameter Maintenance and Extensions
DNS
Domain Name System
DOIC
Diameter Overload Information Conveyance
DPA
Disconnect Peer Answer
DPR
Disconnect Peer Request
DRA
diameter routing agent
DRMP
Diameter Routing Message Priority
DSL
digital subscriber line
DTLS
Datagram Transport Layer Security
DWA
Device Watchdog Answer
DWR
Device Watchdog Request
E‐UTRAN
Evolved Universal Terrestrial Radio Access Network
EAP
Extensible Authentication Protocol
ECC
elliptic curve cryptography
EPC
Evolved Packet Core
EPS
Evolved Packet System
FQDN
fully qualified domain name
GSMA
GSM Association
HSS
Home Subscriber Server
HTTP
Hypertext Transfer Protocol
IANA
Internet Assigned Numbers Authority
IESG
Internet Engineering Steering Group
IKEv2
Internet Key Exchange version 2
IMEI‐SV
International Mobile Station Equipment Identity and Software Version number
LTE
Long‐Term Evolution
MME
Mobility Management Entity
MPTCP
Multipath TCP
NAI
Network Access Identifier
NAPTR
Naming Authority Pointer
NAS
network access server
NE
network element
NTP
Network Time Protocol
OCS
overload control state
OCSP
Online Certificate Status Protocol
OLR
overload report
OVF
Open Virtualization Format
PDN
packet data network
PDP
Packet Data Protocol
PKI
public key infrastructure
QoS
quality of service
RADIUS
Remote Authentication Dial In User Service
RAT
radio access technology
RR DNS
Resource Record
RRE
resource‐requesting entity
S‐NAPTR
Straightforward‐NAPTR
SCEF
Service Capability Exposure Function
SCM
source code management
SCTP
Stream Control Transmission Protocol
SDO
standards development organizations
SGSN
Serving GPRS Support Node
SGW
signaling gateway
SIP
Session Initiation Protocol
SLPv2
Service Location Protocol version 2
SNMP
Simple Network Management Protocol
SRV
Service Location
SS7
Signaling System 7
TCP
Transmission Control Protocol
TLS
Transport Layer Security
UDP
User Datagram Protocol
UE
user equipment
URI
Uniform Resource Identifier
V2X
vehicle‐to‐everything communication
VM
virtual machine
VoIP
voice‐over IP
VPN
virtual private network
WLAN
wireless local area network
1Introduction
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.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:
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.3.1 Diameter versus RADIUS
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:
No reliable message delivery. RADIUS used the User Datagram Protocol (UDP), an unreliable transport protocol, to communicate messages from a RADIUS client to a RADIUS server.
RADIUS had a monolithic design whereby RADIUS attributes used by different applications were put into one bucket for transport with RADIUS. Unlike Diameter, RADIUS did not separate the message delivery from the application's semantics. Interoperability issues and lack of extensibility were common problems in deployments.
The Datagram Transport Layer Security (DTLS) protocol did not exist at that time, therefore RADIUS had to rely on either IP
sec [10]
or no security protection at all.
Only client‐initiated messaging. RADIUS initially did not provide a mechanism for letting the server initiate messages.
RADIUS only supported a basic set of data types, which made it difficult for application designers to define their own RADIUS attributes.
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:
Reliable message delivery. RFC 6613
[13]
added support for the TCP to RADIUS.
Improved security. RFC 7360
[14]
added the ability to use DTLS with UDP‐based RADIUS messages. RFC 6614
[15]
added support for TLS for TCP‐based RADIUS messaging.
Server‐initiated messages. RFC 3576
[16]
added support for server‐initiated messages as part of the dynamic authorization extensions.
Extended attribute type space. The demand for attributes had been close to exhausting RADIUS's 8‐bit attribute type space. RFC 6929
[17]
extended the type space and added a mechanism for complex attributes.
Design guide. To combat interoperability problems caused by protocol design activities in various organizations, RADIUS design guidelines were published with RFC 6158
[18]
.
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.
1.3.2 Diameter Improvements
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:
Security
: RFC 6733 specifies Transport Layer Security (TLS) (when used with TCP) and DTLS (when used with SCTP) as the primary ways to secure Diameter messages. It also specifies the use of a well‐known port, which is similar to how TLS is used with other application‐layer protocols such as HTTPS. The end‐to‐end security framework described in RFC 3588 is deprecated since the actual technical solution has not yet been standardized. More discussion about Diameter security can be found in
Chapter 5
.
Diameter Node Discovery
: A Diameter node discovers to which node it needs to talk via either manual configuration or a dynamic discovery procedure. RFC 6733 simplifies the dynamic discovery procedure since it was observed that many vendors had implemented only the DNS‐based mechanism.
Extensibility
: The story for extending Diameter presented in RFC 3588 was unclear and led to incompatible extensions. RFC 6733 clarified Diameter extensibility, and
Chapter 7
is dedicated to the topic of Diameter extensibility to provide help to those who want to develop their own extensions.
Clarifications
: RFC 6733 is full of helpful clarifications for readers and implementers. The clarifications are the results of many discussions within the working group to reconstruct the original intentions and to match them with implementations in the field.
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.
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.
References
1 IETF. The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force, Nov. 2012.
http://ietf.org/tao.html
.
2 V. Fajardo, J. Arkko, J. Loughney, and G. Zorn. Diameter Base Protocol. RFC 6733, Internet Engineering Task Force, Oct. 2012.
3 D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Sastry. The COPS (Common Open Policy Service) Protocol. RFC 2748, Internet Engineering Task Force, Jan. 2000.
4 C. Rigney, S. Willens, A. Rubens, and W. Simpson. Remote Authentication Dial In User Service (RADIUS). RFC 2865, Internet Engineering Task Force, June 2000.
5 B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, and E. Jaques. Criteria for Evaluating AAA Protocols for Network Access. RFC 2989, Internet Engineering Task Force, Nov. 2000.
6 IETF. Authentication, Authorization and Accounting (AAA) (Concluded) Working Group, Mar. 2014.
http://datatracker.ietf.org/wg/aaa/charter/
.
7 D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, M. Stevens, and B. Wolff. Authentication, Authorization, and Accounting: Protocol Evaluation. RFC 3127, Internet Engineering Task Force, June 2001.
8 C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote Authentication Dial In User Service (RADIUS). RFC 2058, Internet Engineering Task Force, Jan. 1997.
9 C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote Authentication Dial In User Service (RADIUS). RFC 2138, Internet Engineering Task Force, Apr. 1997.
