RFC 3788

Security Considerations for Signaling Transport (SIGTRAN) Protocols

📅 published June 2004, from ietf

RFC 3788 ✨ Security Considerations for Signaling Transport (SIGTRAN) Protocols

okay bestie, the title block 🎀 this is RFC 3788, a Standards Track doc from the Network Working Group, dated June 2004. The authors are J. Loughney (Nokia Research Center), M. Tuexen, Ed. (Univ. of Applied Sciences Muenster), and J. Pastor-Balbas (Ericsson Espana S.A.). The header doesn't list any Obsoletes or Updates, so it isn't replacing or updating anything. 💅

Status of This Memo 🌸

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2004).

Abstract ✨

this doc talks about how Transport Layer Security (TLS) and IPsec can keep SIGTRAN communication secure 🔐. The big goal is to recommend the minimum security tools a SIGTRAN node has to implement to get secured communication. IPsec support is mandatory for every node running SIGTRAN protocols 💜. TLS support is optional.

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
    1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  2
    1.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . .  3
2.  Convention . . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Security in Telephony Networks . . . . . . . . . . . . . . . .  4
4.  Threats and Goals  . . . . . . . . . . . . . . . . . . . . . .  4
5.  IPsec Usage  . . . . . . . . . . . . . . . . . . . . . . . . .  6
6.  TLS Usage  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
7.  Support of IPsec and TLS . . . . . . . . . . . . . . . . . . .  8
8.  Peer-to-Peer Considerations  . . . . . . . . . . . . . . . . .  9
9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
    12.1. Normative References . . . . . . . . . . . . . . . . . . 11
    12.2. Informative References . . . . . . . . . . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

1. Introduction ✨

1.1. Overview 🎀

okay so SIGTRAN protocols carry signaling messages for telephony services 📞. they get used between:

  • customer premise and service provider equipment, for ISDN Q.921 User Adaptation Layer (IUA) [9].
  • service provider equipment only. this is the case for SS7 MTP2 User Adaptation Layer (M2UA) [12], SS7 MTP2 Peer-to-Peer User Adaptation Layer (M2PA) [15], SS7 MTP3 User Adaptation Layer (M3UA) [13] and SS7 SCCP User Adaptation Layer (SUA) [16]. the carriers can be different and can use other transport network providers 🌈.

the security needs for these situations can be different 🫶.

SIGTRAN protocols involve the security needs of several parties: the end-users of the services, the service providers, and the applications involved. local regulation can add more security requirements too. these needs overlap a bit, but any security solution should cover all the different parties' needs 💅.

the SIGTRAN protocols assume that messages are secured by using either IPsec or TLS ✨.

1.2. Abbreviations 🧚

this document uses these abbreviations:

ASP: Application Server Process

CA: Certification Authority

DOI: Domain Of Interpretation

ESP: Encapsulating Security Payload

FQDN: Full-Qualified Domain Names

IPsec: IP Security Protocol

IKE: Internet Key Exchange Protocol

ISDN: Integrated Services Digital Network

IUA: ISDN Q.921 User Adaptation Layer

M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer

M2UA: SS7 MTP2 User Adaptation Layer

M3UA: SS7 MTP3 User Adaptation Layer

PKI: Public Key Infrastructure

SA: Security Association

SCTP: Stream Control Transmission Protocol

SS7: Signaling System No. 7

SUA: SS7 SCCP User Adaptation Layer

TLS: Transport Layer Security

2. Convention 🌸

the BCP 14 keywords are used here the way [1] describes. the list is MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL. they're in caps when they show up in this doc, and they mean what [1] says they mean 🎀.

3. Security in Telephony Networks 📞

telephony security is mostly based on the closed network principle 🔒. there are two main protocols: access protocols (ISDN and others) handle signaling in the access network, and the SS7 protocol stack handles the core network.

SS7 networks are often physically remote and/or hard for users to reach, so it's assumed they're protected from malicious users. the equipment is usually under lock and key 🗝️. at the boundaries between SS7 networks, packet filtering is sometimes used. end-users aren't directly connected to SS7 networks.

the access protocols carry end-user signaling. telephone switches run by network operators translate end-user signaling protocols into SS7-based protocols 🧚.

Regulatory Authorities often require SS7 switches with connections to different SS7 switches to conform to national and/or international test specifications 📋.

there are no standardized ways to use encryption technologies for confidentiality, or to use technologies for authentication 💀.

this description applies to telephony networks operated by a single operator, and also to multiple telephony networks connected and operated by different operators 🌈.

4. Threats and Goals 🔥

Internet threats split into two main types. the first is called "passive attacks". it happens whenever the attacker reads packets off the network but doesn't write them. examples include confidentiality violations, password sniffing and offline cryptographic attacks, amongst others 👀.

the second kind is called "active attacks". here the attacker also writes data to the network. examples include replay attacks, message insertion, message deletion, message modification or man-in-the-middle attacks, amongst others 😭.

in general, Internet protocols have these security objectives:

  • Communication Security:
    • Authentication of peers
    • Integrity of user data transport
    • Confidentiality of user data
    • Replay protection
  • Non-repudiation
  • System Security, avoidance of:
    • Unauthorized use
    • Inappropriate use
    • Denial of Service

communication security is mandatory in some network scenarios to prevent malicious attacks 💅. the main goal of this document is to recommend the minimum security means a SIGTRAN node must implement to get secured communication. to get there, we'll look at the different existing security options for communication 🫶.

all SIGTRAN protocols use the Stream Control Transmission Protocol (SCTP) defined in [8] and [11] as their transport protocol. SCTP has some transport-related security features, like resistance against:

  • Blind Denial of Service Attacks such as:
    • Flooding.
    • Masquerade.
    • Improper Monopolization of Services.

there is no quick fix or one-size-fits-all solution for security 😤.

when a network using SIGTRAN protocols involves more than one party, it may not be reasonable to expect that all parties have implemented security well enough 🥺. end-to-end security should be the goal, so it's recommended that IPsec or TLS be used to ensure confidentiality of user payload 🔐. see [3] for more info on configuring IPsec services 📚.

5. IPsec Usage 🦋

this section only matters for SIGTRAN nodes that use IPsec to secure communication between SIGTRAN nodes 💜.

every SIGTRAN node using IPsec MUST implement IPsec ESP [4] in transport mode, with non-null encryption and authentication algorithms, to provide per-packet authentication, integrity protection and confidentiality. it also MUST implement the replay protection mechanisms of IPsec. in scenarios where IP layer protection is needed, ESP in tunnel mode SHOULD be used. non-null encryption should be used when using IPSec ESP 🎀.

all SIGTRAN nodes MUST support IKE for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [5]. IPsec implementations MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. peer authentication using the public key encryption methods outlined in IKE's sections 5.2 and 5.3 [6] SHOULD NOT be used 🙈.

conformant implementations MUST support IKEs Main Mode and Aggressive Mode. in transport mode, when pre-shared keys are used for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used. when digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. when using ESP tunnel mode, IKE Main Mode MAY be used to create an ISAKMP association with identity protection during Phase 1 ✨.

when digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certification authority (or authorities) it trusts, according to its local policy 📜. IKE negotiators SHOULD use pertinent certificate revocation checks before accepting a PKI certificate for IKE's authentication procedures. see [10] for certificate revocation and [7] for online-checking 🔍.

the Phase 2 Quick Mode exchanges used to negotiate protection for SIGTRAN sessions MUST explicitly carry the Identity Payload fields (IDci and IDcr). the DOI supports several types of identification data. but in conformant implementations, each ID Payload MUST carry a single IP address and a single non-zero port number, and MUST NOT use the IP Subnet or IP Address Range formats. this lets the Phase 2 security association match specific TCP and SCTP connections 🧠.

IPsec acceleration hardware may only handle a limited number of active IKE Phase 2 SAs, so Phase 2 delete messages may be sent for idle SAs to keep the number of active Phase 2 SAs low 🍓. getting an IKE Phase 2 delete message SHOULD NOT be read as a reason to tear down a SIGTRAN session. it's better to leave the connection up, so another IKE Phase 2 SA gets brought up to protect it if more traffic is sent. this avoids the risk of constantly bringing connections up and down 🙃.

also, SCTP supports multi-homed hosts, which means one SCTP association may need multiple security associations. this drawback of IPsec has been addressed by [17], so IPsec implementations used by SIGTRAN nodes SHOULD support the IPsec feature described in [17] 🌸.

6. TLS Usage 🎀

okay so this part is only for SIGTRAN nodes that use TLS to secure the chat between SIGTRAN nodes 🔐 if that's not you, you can skip ahead bestie 💅

a SIGTRAN node that starts an SCTP association to another SIGTRAN node acts as a TLS client according to [2], and a SIGTRAN node that accepts the connection acts as a TLS server 🧚 SIGTRAN peers using TLS for security MUST mutually authenticate as part of TLS session establishment 🫶 to make that happen, the server node has to ask the client node for a certificate, and the client node MUST be prepared to supply one when asked 📜 the full mutual-auth energy is giving ✨

[14] requires support for the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. SIGTRAN nodes MAY negotiate other TLS cipher suites 🌸

TLS MUST be used on all bi-directional streams. Other uni-directional streams MUST NOT be used 🚫 no exceptions, periodt 💀

also, an SCTP implementation used for TLS over SCTP MUST support fragmentation of user data, and it might also need to support the partial delivery API 🍓 this holds even if every SIGTRAN message is small 🙈 and the 'unordered delivery' feature of SCTP can not be used together with TLS 🚫 see [14] for more details 📖

because TLS only protects the payload, the SCTP header and all control chunks are not protected 😭 that can be used for DoS attacks, and it's a general problem with security at the transport layer 💔

the SIGTRAN protocols use the same SCTP port number and payload protocol identifier when they run over TLS 🦋 to start the TLS based communication, you have to run a session upgrade procedure ✨

the session upgrade procedure should be as follows:

  • If an ASP has been configured to use TLS, it sends a STARTTLS message on stream 0 and starts a timer T_TLS. This is the first message sent, and the ASP sends no other adaptation layer messages until the TLS based communication has been established.
  • If the peer does not support TLS, it sends back an ERROR message indicating an unsupported message type. In this case, the SCTP association is terminated and it is reported to the management layer that the peer does not support TLS.
  • If the peer does support TLS, it sends back a STARTTLS_ACK message. The client then starts TLS based communication.
  • If T_TLS expires without getting any of the above answers, the association is terminated and the failure is reported to the management layer.

all SIGTRAN adaptation layers share one common message format 🧩 the STARTTLS message is just a common header using message class 10 and message type 1 🎀 the STARTTLS_ACK message uses the same message class 10 and message type 2 💜 neither message contains any parameters, so it's giving minimalism 🌷

ngl, a man-in-the-middle can do a denial of service attack here by claiming the peer doesn't support TLS 😤 but that kind of attack is always possible for a man-in-the-middle, so... 🙄

7. Support of IPsec and TLS 🦋

if the content of SIGTRAN protocol messages needs protecting, you can use either IPsec ESP or TLS 🔐 in both IPsec ESP Transport Mode and the TLS cases, the IP header information is neither encrypted nor protected 👀 with IPsec ESP, the SCTP control information is encrypted and protected 🙌 with the TLS based solution, the SCTP control information is not encrypted and is only protected by SCTP procedures 🥲

in general, both IPsec and TLS have enough mechanisms to secure SIGTRAN communications ✨ so to get a secured model working as soon as possible, here's the recommendation: a SIGTRAN node MUST support IPsec and MAY support TLS 👑 IPsec is the must-have, TLS is the bonus 💖

8. Peer-to-Peer Considerations 🧚

M2PA, M3UA and SUA support the peer-to-peer model, which generalizes the client-server model that IUA and M2UA support 🌈 a SIGTRAN node running M2PA, M3UA or SUA and operating in peer-to-peer mode is called a SIGTRAN peer 💅

as with any peer-to-peer protocol, configuring the trust model inside a peer is essential for security 🔥 when certificates are used, you have to configure the trust anchors that the peer trusts 🏰 these trust anchors are likely to be unique to SIGTRAN usage and different from the ones used for other stuff like Web browsing 🕸️ they're generally expected to be configured to reflect the business relationships between the organization hosting the peer and other organizations 🤝 so a peer typically won't be configured to allow connectivity with any arbitrary peer 🙅‍♀️ and when certificate-authenticated peers may not be known beforehand, peer discovery may be required 🔍

now, IPsec is considerably less flexible than TLS when it comes to configuring trust anchors 😩 since using Port identifiers is prohibited within IKE Phase 1, you can't uniquely configure trusted trust anchors for each application separately in IPsec 💔 the same policy has to be used for all applications 😬 for example, a trust anchor trusted for a SIGTRAN protocol must also be trusted to protect other protocols (like SNMP) 🙃 these restrictions are awkward at best 💀

when pre-shared key authentication is used with IPsec to protect SIGTRAN based communication, unique pre-shared keys are configured with peers that are identified by their IP address (Main Mode), or possibly their FQDN (AggressivenMode) 🗝️ so the set of peers has to be known beforehand, and therefore peer discovery is typically not necessary 🧠

the following is meant to give some guidance on the issue 🫶

it is recommended that SIGTRAN peers use the same security mechanism (IPsec or TLS) across all their sessions with other SIGTRAN peers 🌸 inconsistent use of security mechanisms can result in redundant security mechanisms being used (e.g., TLS over IPsec) or, worse, potential security vulnerabilities 😱 when IPsec is used with a SIGTRAN protocol, a typical security policy for outbound traffic is "Initiate IPsec, from me to any, destination port P"; for inbound traffic, the policy would be "Require IPsec, from any to me, destination port P" 📋 here, P denotes one of the registered port numbers for a SIGTRAN protocol 🔢

this policy causes IPsec to be used whenever a SIGTRAN peer initiates a session to another SIGTRAN peer, and to be required whenever an inbound SIGTRAN session occurs ✨ it's super attractive because you don't need to set policy for each peer or dynamically modify it every time a new SIGTRAN session is created 🙌 an IPsec SA is automatically created based on one simple static policy 🦋 since IPsec extensions are typically not available to the sockets API on most platforms, and IPsec policy functionality is implementation dependent, a simple static policy is often the simplest route to IPsec-enabling a SIGTRAN peer 🧚

if IPsec is used to secure a SIGTRAN peer-to-peer session, IPsec policy SHOULD be set so as to require IPsec protection for inbound connections, and to initiate IPsec protection for outbound connections. This can be accomplished via use of inbound and outbound filter policy. 🚨

9. Security Considerations 🔥

this document discusses the usage of IPsec and TLS for securing SIGTRAN traffic 🔐 that's the whole security story, and it's a big one 😤💜

10. IANA Considerations 📚

the message class 12 has been reserved in the Signaling User Adaption Layer Assignments Registry 🎀 for this message class, message type 1 has been reserved for the STARTTLS message, and message type 2 has been reserved for the STARTTLS_ACK message 🌈

11. Acknowledgements 🫶

the authors would like to thank B. Aboba, K. Morneault and many others for their invaluable comments and suggestions 💖 iconic behavior 👑

12. References 🍓

12.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2. Informative References

  • [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
  • [3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
  • [5] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
  • [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
  • [7] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
  • [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
  • [9] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.
  • [10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
  • [11] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
  • [12] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J. Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer", RFC 3331, September 2002.
  • [13] Sidebottom, G., Ed., Morneault, K., Ed. and J. Pastor-Balbas, Ed., "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", RFC 3332, September 2002.
  • [14] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
  • [15] George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Work in Progress, February 2004.
  • [16] Loughney, J., "Signalling Connection Control Part User Adaptation Layer (SUA)", Work in Progress, December 2003.
  • [17] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.

13. Authors' Addresses 💅

John Loughney
Nokia Research Center
PO Box 407
FIN-00045 Nokia Group
Finland

EMail: john.loughney@nokia.com


Michael Tuexen (editor)
Univ. of Applied Sciences Muenster
Stegerwaldstr. 39
48565 Steinfurt
Germany

EMail: tuexen@fh-muenster.de


Javier Pastor-Balbas
Ericsson Espana S.A.
Via de los Poblados, 13
28033 Madrid
Spain

EMail: j.javier.pastor@ericsson.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ✨

Intellectual Property ✨

okay so this bit is the legal stuff, but make it cute 🎀 The IETF doesn't take a stance on whether any Intellectual Property Rights or other rights could be claimed over the tech in this doc, or whether any license for them is out there. It also doesn't claim it went hunting for those rights itself 🕵️‍♀️ If you want the details on how rights work for RFC docs, check out BCP 78 and BCP 79 💅

Copies of IPR disclosures sent to the IETF Secretariat, plus any promises of licenses, or the results of trying to get a general license or permission for implementers or users of this spec to use those proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 💖

The IETF also invites anyone to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🦋

Acknowledgement ✨

Funding for the RFC Editor function is currently provided by the Internet Society 🌸🫶

📦 where this page comes from