Diameter Security. Ensuring the Transport and Application Layer Integrity of Diameter across Network Interconnections

Transcription

1 Diameter Security Ensuring the Transport and Application Layer Integrity of Diameter across Network Interconnections

2 Table of Contents Introduction Diameter Security Transport Security Transport Security How does it work Application Security Topology Hiding Topology Hiding How does it work Application Security Admission Control Admission Control How does it work Conclusion The Sonus Diameter Signaling Controller (DSC) Advantage About Sonus Appendix A. Differences between RFC 6733 and RFC

3 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 entity the 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 security Guarantee the integrity of transmitted and received Diameter messages; Application security Topology hiding to prevent the exportation of network configuration information; Application security Admission control to ensure message validity. For reference, IETF originally defined Diameter in RFC 3588 and then updated it in RFC 6733, released in October 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. 3

4 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 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: 4

5 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 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 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 DEA s 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 Adherence to these rules and recommendations helps to secure and maintain LTE/EPC Diameter signaling networks at the application level. 5

6 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 one s 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., one s 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 one s own PMN. 6

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

8 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 Sonus Networks APAC Headquarters Sonus Networks EMEA Headquarters Sonus Networks CALA Headquarters 4 Technology Park Drive Westford, MA U.S.A. Tel: GO-SONUS 1 Fullerton Road #02-01 One Fullerton Singapore Singapore Tel: Edison House Edison Road Dorcan, Swindon Wiltshire SN3 5JX Tel: Homero No Col. Los Morales, C.P Mexico City, Mexico Distrito Federal Mexico Tel: Int l Tel: To learn more, call Sonus at 855-GO-SONUS or visit us online at 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 /3 8