Diameter Security

Ensuring the Transport and Application

Layer Integrity of Diameter across
Network Interconnections

Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Diameter Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Transport Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Transport Security How does it work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Application Security Topology Hiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Topology Hiding How does it work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Application Security Admission Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Admission Control How does it work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
The Sonus Diameter Signaling Controller (DSC) Advantage. . . . . . . . . . . 7
About Sonus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Differences between RFC 6733 and RFC 3588 . . . . . . . . . .

Introduction
The Diameter protocol is closely linked with the evolution of IP Multimedia Subsystem (IMS) and mobile broadband network
architectures. Diameter was first introduced for communication over the interfaces between the IMS core and application servers,
charging systems and HSS databases. It was also specified by GSMA for Long Term Evolution (LTE) and Evolved Packet Core (EPC)
network interworking.
Diameter is the base protocol for authentication, authorization and accounting (AAA), enabling network access and IP mobility in
both home and roaming mobile LTE networks.
To simplify the roaming interface between peer networks, a functional entitythe Diameter Edge Agent (DEA)has been defined in
the LTE Roaming Guidelines (GSMA PRD IR.88). The DEA provides an entry point to provide efficient connection methodologies and
network security. The DEA hides the topology of the network behind it and advertises itself to roaming partners as a Diameter relay,
serving all Diameter applications in the network.
The DEA should be considered as a signaling firewall that protects the internal network from malformed messages, unauthorized
senders, and exposure of internal information to external networks. Figure 1 below shows this architecture.
As the use of Diameter is increasing exponentially and as mobile operators implement Diameter Edge Agent (DEA) functionality, it is
also important to consider how the DEA will scale while providing this important level of security.

Figure 1. IR.88 Diameter Roaming Implementation Architecture

This paper is focused on the security aspects of Diameter, why they exist and how they work.

Diameter Security
Any discussion of Diameter security needs to address three aspects:

Transport securityGuarantee the integrity of transmitted and received Diameter messages;

Application securityTopology hiding to prevent the exportation of network configuration information;
Application securityAdmission control to ensure message validity.
For reference, IETF originally defined Diameter in RFC 3588 and then updated it in RFC 6733, released in October 2012.
See Appendix A for a list of key security-related changes between these two documents.

Transport Security
To address the transport security needs, RFC 6733 clearly states, all Diameter base protocol implementations MUST support the
use of TLS/TCP and DTLS/SCTP, and the Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec.

More specifically, these security protocols are Transport

Layer Security [RFC 5246] when using Transmission Control
Protocol (TCP) and Datagram Transport Layer Security [RFC
6083] when using Stream Control Transmission Protocol
(SCTP). Diameter clients MUST support either TCP or SCTP,
while Diameter Agents and Servers SHOULD support both.
Optionally, IP Security [RFC 2401] can also be used. Figure 2
below shows the relationship between protocol layers.

Transport Layer Security (TLS)

TLS is used to provide private, reliable and secure
communications over TCP. It ensures that sensitive data is safe
from malicious attacks. The TLS protocol provides capabilities
to perform client authentication, server authentication, data
encryption and data integrity. RFC 5246 is the current TLS
specification, defining TLS version 1.2.

Figure 2. Protocol Relationships

Datagram Transport Layer Security (DTLS)

Some may wonder why they should not use TLS as a security protocol for SCTP, especially when TCP and SCTP are both connectionoriented protocols and TLS is used for TCP. The reason is that there are serious limitations of TLS related to SCTP, including:

TLS does not support unordered delivery of SCTP user messages;

TLS would only support the same number of data streams in both directions;
TLS would have a connection for every bidirectional stream which would cause a large resource impact when a large quantity
of SCTP is used.
DTLS over SCTP was specified by IETF because it overcomes these issues by:

Preserving SCTP message boundaries;

Supporting a large quantity of either unidirectional or bidirectional streams;
Allowing ordered and unordered delivery of SCTP messages

IP Security (IPSec)
The original Diameter Base Protocol specification (RFC 3588) stated, In order to provide universal support for transmission-level
security, and enable both intra and inter domain AAA deployments, IPsec support is mandatory in Diameter, and TLS support is
optional. However, one of the key updates in RFC 6733 modified this position. RFC 6733 states, The use of a secured transport
for exchanging Diameter messages remains mandatory. TLS/TCP and DTLS/SCTP have become the primary methods of securing
Diameter, with IPsec as a secondary alternative.

Transport Security How does it work

RFC 6733 states that in order to protect a Diameter connection via TLS/TCP and DTLS/SCTP (or IPSec), the TLS/TCP and DTLS/
SCTP (or IPSec/IKE) SHOULD begin prior to any Diameter message exchange. All security parameters for TLS/TCP and DTLS/SCTP
(or IPSec) are to be configured independent of the Diameter protocol. This is the recommended handshake in RFC 6733.
If RFC 6733 cannot be followed because one of the negotiating devices only supports RFC 3588, then the TLS/TCP and DTLS/SCTP
handshake will begin when both ends successfully reach the open state, after completion of the Capabilities-Exchange-Request
(CER) / Capabilities-Exchange-Answer (CEA) exchange. If the TLS/TCP and DTLS/SCTP handshake is successful, all further messages
will be sent via TLS/TCP and DTLS/SCTP. If the handshake fails, both ends MUST move to the closed state.
Diameter nodes using TLS/TCP and DTLS/SCTP for security MUST mutually authenticate as part of the TLS/TCP and DTLS/SCTP
session establishment. Based on which specification a Diameter peer supports, the section below identifies the respective port
numbers that should be used:

Port Numbers
As per RFC 6733, the base Diameter protocol is run on port 3868 for both TCP [RFC 0793] and SCTP [RFC 4960]. For TLS and DTLS,
a Diameter node that initiates a connection prior to any message exchanges MUST run on port 5658. It is assumed that TLS is run
on top of TCP when it is used, and DTLS is run on top of SCTP when it is used.
If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP connections on port 5658 (i.e., the peer complies only
with RFC 3588), then the initiator MAY revert to using TCP or SCTP on port 3868. Note that this scheme is kept only for the
purpose of backward compatibility, and that there are inherent security vulnerabilities when the initial CER/CEA messages are sent
unprotected.
A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections
on, and it MUST always be prepared to receive connections on port 3868 for TCP or SCTP and port 5658 for TLS/TCP and DTLS/
SCTP connections.

Peer Discovery
During the session establishment process, there are two possible mechanisms to discover the next hop, each of which has
advantages and disadvantages:

Manually configured static entries in the Peer and Routing Tables;

Dynamic Discovery using DNS (S) NAPTR.
IR.88 states the use of static entries in the Peer and Routing Tables is recommended to enhance security, so if these are available
they should take precedence and be used. However, this configuration method requires mobile operators to define provisioning
procedures and ensure resources are allocated for this as changes occur.
The use of dynamic discovery using DNS is allowed as it makes for simpler deployments; however, the use of dynamic discovery
raises several security issues related to DNS vulnerabilities/attacks when a GRX/IPX DNS is used.
At least two critical attacks to DNS infrastructure can be cited:

An amplification and/or reflection attack can overload (DoS) a victim DEA with a huge number of unsolicited DNS answers;
DNS Poisoning attack corrupts the association name/IP (i.e., Kaminsky attack). Once corrupted, the entry persists for a long
time (TTL value), resulting in the DEAs routing table becoming improperly altered.
If dynamic discovery is used, the DEA performs a Straightforward-Naming Authority Pointer (S-NAPTR) query for a server in a
particular realm. Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage [RFC 6408] defines an extended format
for the S-NAPTR application service tag that allows for discovery of the supported applications without doing Diameter capability
exchange beforehand.
If no S-NAPTR records are found, the requester may directly query for an SRV record. Note, when DNS-based peer discovery is used,
the port numbers received from SRV records take precedence over the default ports (3868 and 5658).

Application Security Topology Hiding

Some Diameter Attribute-Value Pairs (AVPs) may contain security-sensitive data, such as user passwords, location data, network
addresses and cryptographic keys. IETF RFC 6733 provides a list of AVPs that are considered to be security sensitive; however,
there are other 3GPP applications that use AVPs that are not part of the base Diameter protocol and many of those will also carry
sensitive information. It is fair to say that in a 3GPP environment, Diameter peers must be considered trustworthy before any
Diameter messages are exchanged.
In the earlier releases of IR.88 (version 9 and earlier), DEA recommendations to provide topology hiding did not describe how
topology hiding was to be implemented. This has now been corrected and topology hiding recommendations have been provided
in GSMA PRD IR.88, Version 10.0. Adherence to these rules and recommendations helps to secure and maintain LTE/EPC Diameter
signaling networks at the application level.

Topology hiding is used to ensure that internal information of a Public Mobile Network (PMN), which is not required outside the
PMN, is NOT disclosed by changing or removing it from all egress messages.

Topology Hiding How does it work

IR.88, Version 10.0, specifically states the rules expected to be applied. In general, all egress messages should hide:

All Diameter Host Names;

The number of Diameter Nodes in the network by hiding routing and identity details.
More specifically, the DEA should determine messages to apply topology hiding based on:

Their connection type and origin;

Application Routing Rules-like criteria: Application-ID, Origin-Realm, Origin-Host, Destination-Realm, Destination-Host.
In addition, topology hiding should also prevent other networks from determining the routing used within a network by hiding the
path that Diameter messages use when being routed through the network. This is accomplished by:

Hiding Diameter names in Route-Record AVP and using generic names in their place;
Re-inserting the correct names if the request reenters the home network;
Hiding Diameter host names in other base Diameter AVPs, such as Session-ID and Proxy-Info.
To prevent other networks from discovering the number of HSS in the network and their identity, topology hiding should hide:

Diameter name in Origin-Host AVP in requests from HSS to foreign MME;

Diameter name in Origin-Host AVP for answers from HSS to foreign MME.
Likewise, to prevent other networks from discovering the number of MMEs in the network and their identity, topology hiding should:

Hide Diameter name in Origin-Host AVP in requests from MME to foreign HSS;
Re-insert Host ID (Diameter name) in Destination-Host AVP in requests from foreign HSS to MME;
Hide Diameter name in Origin-Host in answer message from MME to foreign HSS

Application Security Admission Control

In addition to providing topology hiding recommendations, GSMA IR.88 V10.0 also lists the following recommendations for
admission control to ensure that only allowable messages are processed. The DEA is expected to filter Diameter messages to accept
only supported Application IDs, Command Codes and AVPs. Custom AVPs are not allowed by default. Note that IR.88 does not define
what is a custom AVP, so in fact this could be a vendor-specific AVP or an SVP that is only allowed in a message due to an [AVP]
block in the ABNF. If custom AVPs are needed, they need to be bilaterally agreed to.

Admission Control How does it work?

IR.88, Version 10.0, specifically states:

Compare all AVPs that identify the origin and the destination (that is Origin/Destination Realm/Host and Visited PMN ID) to
determine consistency between them;

Verify CER/CEA Diameter Messages against Diameter Servers and capabilities declared in IR.21 RAEX DB;
Check if Origin Realm/Host and/or Visited PMN ID is from a PMN which has a roaming agreement with ones own PMN.
Information related to this PMN is taken from IR.21 RAEX DB during provisioning of the ACLs in the DEA;

Check if the Route Record AVPs (if they exist) are sound in that the documented route is possible for the source and destination
given in the message;

Egress Diameter messages are received by the DEA from an internal network element. They are only sent to their destination if
all the AVPs which determine the origin are addressing a network element within the sending (i.e., ones own) PMN;

Ingress Diameter messages are received by the DEA from an external network element. They are only sent to their destination
if all the AVPs which determine the destination are addressing a recipient which is inside ones own PMN.

Conclusion
Diameter signaling is the lynchpin for successful 4G/LTE interconnection and roaming. IETF and GSMA have highlighted the
importance of Diameter security via their respective (RFC 6733 and IR.88) specifications.
Therefore Mobile Operators (MNO, GRX and IPX) must have the utmost confidence in their deployment decisions for Diameter
Edge Agent functionality in order to absolutely know their Diameter message exchange is secure at both the transport and
application level.
While this paper has shown how Diameter security is done at the transport and application level, it is still incumbent upon a
Mobile Operator to test and verify the compliance of their DEA suppliers to these two key specifications in real world conditions.
Specifically, Diameter message use is exponentially increasing, but many Diameter architectures cannot scale to perform securely at
high message rates.

The Sonus Diameter Signaling Controller (DSC) Advantage

The Sonus DSC adheres to IETF and 3GPP specifications for security, including the implementation of Datagram Transport Layer
Security (DTLS), Transport Layer Security (TLS) and optionally IP Security (IPsec). The DSC gives network operators the ability to
route or screen on any AVP or message. This screening capability gives mobile network operators and IPX providers unparalleled
control of information entering their network, including messages, AVPs and applications.
Not just providing security, the Sonus DSC has been architected to provide this level of security at scale, where it is predicted that
mobile network operators and IPX providers will be handling millions of Diameter messages per second.
The DSC enables the definition of separate DEAs within a single DSC platform. Each of these virtual DEAs has its own separate
routing and screening rules that include the ability to shape traffic on a per-peer basis. This shaping includes traffic flow control,
throttling and congestion per-peer. Architected for extensibility and straightforward evolution to future Diameter applications, this
high-powered platform makes the Sonus DSC ideal for LTE/EPC and IMS networks.

Appendix A. Differences between RFC 6733 and RFC 3588

An overview of some the major changes between RFC 6733 and RFC 3588 that are security-related, are given below:

Deprecated the use of the Inband-Security AVP for negotiating Transport Layer
Security (TLS) [RFC 5246].
It has been generally considered that bootstrapping of TLS via Inband-Security AVP creates certain security risks because it does
not completely protect the information carried in the CER/CEA ((Capabilities-Exchange-Request/Capabilities-Exchange-Answer). RFC
6733 adopts the common approach of defining a well-known secured port that peers should use when communicating via TLS/TCP
and DTLS/SCTP. This new approach augments the existing in-band security negotiation, but it does not completely replace it. The
old method is kept for backward compatibility reasons.

Deprecated the exchange of CER/CEA messages in the open state.

This feature was implied in the peer state machine table of RFC 3588, but it was not clearly defined anywhere else in that document.
As work on RFC 6733 progressed, it became clear that the multiplicity of meaning and use of Application-ID AVPs in the CER/CEA
messages (and the messages themselves) is seen as an abuse of the Diameter extensibility rules and thus required simplification.
Capabilities exchange in the open state has been re-introduced in a separate specification [RFC 6737], which clearly defines new
commands for this feature.

Simplified security requirements.

The use of a secured transport for exchanging Diameter messages remains mandatory. However, TLS/TCP and DTLS/SCTP have
become the primary methods of securing Diameter, with IPsec as a secondary alternative. The support for the End-to-End security
framework (E2E-Sequence AVP and P-bit in the AVP header) has also been deprecated.

Clarified Application ID usage.

Clarify the proper use of Application Id information, which can be found in multiple places within a Diameter message. This includes
correlating Application IDs found in the message headers and AVPs. These changes also clearly specify the proper Application ID
value to use for specific base protocol messages (ASR/ASA, STR/STA) as well as clarifying the content and use of Vendor-Specific
Application-ID.

Simplified Diameter peer discovery.

The Diameter discovery process now supports only widely used discovery schemes; the rest have been deprecated.
There are many other miscellaneous fixes that have been introduced in RFC 6733; however, a comprehensive list of all changes is
not shown here for practical reasons.

About Sonus Networks

Sonus brings intelligence and security to real-time communications. By helping the world embrace the next generation of Cloud-based
SIP and 4G/LTE solutions, Sonus enables and secures latency-sensitive, mission-critical traffic for VoIP, video, instant messaging and
online collaboration. With Sonus, enterprises can give priority to real-time communications based on smart business rules, while service
providers can offer reliable, comprehensive and secure on-demand network services to their customers. With solutions deployed in more
than 100 countries and nearly two decades of experience, Sonus offers a complete portfolio of hardware-based and virtualized Session
Border Controllers (SBCs), Diameter Signaling Controllers (DSCs), Network-as-a-Service (NaaS) capabilities, policy/routing servers, and
media and signaling gateways.

Sonus Networks
North American
Headquarters
4 Technology Park Drive
Westford, MA 01886
U.S.A.
Tel: +1-855-GO-SONUS

Sonus Networks
APAC Headquarters

Sonus Networks
EMEA Headquarters

Sonus Networks
CALA Headquarters

1 Fullerton Road #02-01

One Fullerton
Singapore 049213
Singapore
Tel: +65-68325589

Edison House
Edison Road
Dorcan, Swindon
Wiltshire
SN3 5JX
Tel: +44-14-0378-8114

Homero No. 1933-902

Col. Los Morales, C.P. 11510
Mexico City, Mexico
Distrito Federal
Mexico Tel: +52-55-1950-3036
Intl Tel: +1-978-614-8741

To learn more, call Sonus at 855-GO-SONUS

or visit us online at www.sonus.net
The content in this document is for informational purposes only and is subject to change by Sonus Networks without notice. While reasonable efforts have been made in the preparation
of this publication to assure its accuracy, Sonus Networks assumes no liability resulting from technical or editorial errors or omissions, or for any damages resulting from the use of
this information. Unless specifically included in a written agreement with Sonus Networks, Sonus Networks has no obligation to develop or deliver any future release or upgrade, or any
feature, enhancement or function.
Copyright 2015 Sonus Networks, Inc. All rights reserved. Sonus is a registered trademark of Sonus Networks, Inc. All other trademarks, service marks, registered trademarks or
registered service marks may be the property of their respective owners.

DS-1501 6/3