Security Considerations for Signaling Transport (SIGTRAN) Protocols
Extracted elements (29)
A simple static IPsec policy ('initiate IPsec from me to any, destination port P' outbound; 'require IPsec from any to me, destination port P' inbound) is recommended for peer-to-peer use because it avoids per-peer policy configuration and does not require dynamic policy modification when new SIGTRAN sessions are created.
IPsec ESP in transport mode protects both the SCTP payload and SCTP control information, while TLS only protects the payload leaving SCTP control chunks exposed. This difference motivated making IPsec mandatory and TLS optional.
IPsec is considerably less flexible than TLS for configuring trust anchors in peer-to-peer scenarios because IKE Phase 1 prohibits port identifiers, making it impossible to configure per-application trust anchors; a trust anchor trusted for SIGTRAN must also be trusted for other protocols such as SNMP.
Traditional telephony network security was based on the closed network principle, with SS7 networks physically secured and end-users never directly connected to them. SIGTRAN protocols carry these signals over IP networks that lack this closed-network assumption, motivating the need for explicit cryptographic security.
Section 6 describes STARTTLS/STARTTLS_ACK as using message class 10, but Section 10 (IANA Considerations) reserves message class 12 for these messages. The IANA registration in Section 10 (class 12) is the authoritative assignment; the class 10 reference in Section 6 is an inconsistency.
An SCTP implementation used for TLS over SCTP MUST support fragmentation of user data and may need to support the partial delivery API, even if all SIGTRAN messages are small. The SCTP 'unordered delivery' feature cannot be used in conjunction with TLS.
RFC 3436 requires support of the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA for TLS over SCTP; SIGTRAN nodes MAY negotiate other TLS cipher suites.
SCTP supports multi-homed hosts, which requires multiple IPsec security associations for a single SCTP association. Implementations should support RFC 3554 (SCTP with IPsec) to handle this case correctly.
SIGTRAN protocols use the same SCTP port number and payload protocol identifier when run over TLS as when run without TLS; the session upgrade procedure (STARTTLS) is required to initiate TLS-based communication on an established SCTP association.
A SIGTRAN node MUST support IPsec and MAY support TLS, establishing IPsec as the mandatory baseline security mechanism for all SIGTRAN implementations.
All SIGTRAN nodes MUST support IKE for peer authentication, negotiation of security associations, and key management using the IPsec DOI. Implementations MUST support pre-shared key peer authentication, and MAY support certificate-based authentication using digital signatures. Peer authentication using IKE public key encryption methods (sections 5.2 and 5.3 of RFC 2409) SHOULD NOT be used.
All SIGTRAN nodes using IPsec MUST implement IPsec ESP in transport mode with non-null encryption and authentication algorithms to provide per-packet authentication, integrity protection, and confidentiality, and MUST implement IPsec replay protection mechanisms.
Conformant implementations MUST support IKE Main Mode and Aggressive Mode. For transport mode with pre-shared keys, IKE Aggressive Mode SHOULD be used and Main Mode SHOULD NOT be used. When digital signatures are used, either mode MAY be used.
For peer-to-peer SIGTRAN sessions using IPsec, IPsec policy SHOULD be set to require IPsec protection for inbound connections and to initiate IPsec protection for outbound connections, accomplished via inbound and outbound filter policy.
IKE negotiators SHOULD use Certificate Request Payloads to specify trusted CAs when digital signatures are used, and SHOULD perform pertinent certificate revocation checks before accepting a PKI certificate for IKE authentication.
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.
IPsec implementations used by SIGTRAN nodes SHOULD support the SCTP-IPsec feature described in RFC 3554, which addresses the multi-homing problem requiring multiple SAs for a single SCTP association.
Phase 2 Quick Mode exchanges for SIGTRAN sessions MUST explicitly carry Identity Payload fields (IDci and IDcr). Each ID Payload MUST carry a single IP address and a single non-zero port number, and MUST NOT use IP Subnet or IP Address Range formats, so Phase 2 SAs correspond to specific TCP and SCTP connections.
Receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down a SIGTRAN session; it is preferable to leave the connection up so another IKE Phase 2 SA will be brought up if additional traffic is sent, avoiding continually cycling connections.
SIGTRAN peers implementing TLS MUST mutually authenticate as part of TLS session establishment. The TLS server MUST request a certificate from the TLS client, and the TLS client MUST be prepared to supply a certificate on request.
TLS MUST be used on all bi-directional SCTP streams. Other uni-directional streams MUST NOT be used.
A TLS session upgrade procedure is defined for SIGTRAN. If an ASP is configured for TLS, it sends a STARTTLS message on stream 0 and starts timer T_TLS as the first adaptation layer message. The peer responds with STARTTLS_ACK (TLS supported) or ERROR (unsupported), or T_TLS expiry terminates the association.
Message class 12 has been reserved in the Signaling User Adaptation Layer Assignments Registry. Within this class, message type 1 is reserved for the STARTTLS message and message type 2 for the STARTTLS_ACK message.
Because TLS only protects the SCTP payload, the SCTP header and all control chunks are not encrypted or protected by TLS. This can be exploited for DoS attacks and is a general limitation of transport-layer security.
During the TLS upgrade handshake, a man-in-the-middle can perform a denial-of-service attack by injecting an ERROR message indicating the peer does not support TLS, causing the SCTP association to be terminated. This is an inherent limitation of the in-band STARTTLS upgrade approach.
It is recommended that SIGTRAN peers use the same security mechanism (IPsec or TLS) across all sessions with other SIGTRAN peers. Inconsistent use can result in redundant security mechanisms (e.g., TLS over IPsec) or security vulnerabilities.
SCTP provides transport-level resistance against blind Denial of Service attacks including flooding, masquerade, and improper monopolization of services, providing a baseline security benefit for all SIGTRAN protocols independent of IPsec or TLS.
TLS upgrade state machine: (1) ASP sends STARTTLS on stream 0, starts T_TLS, sends no other messages. (2a) If peer sends ERROR (unsupported), SCTP association is terminated and management is notified. (2b) If peer sends STARTTLS_ACK, client starts TLS. (2c) If T_TLS expires, association is terminated and failure reported.
The STARTTLS message uses message class 10 and message type 1, consisting of a common SIGTRAN header only with no parameters. The STARTTLS_ACK message uses message class 10 and message type 2, also consisting of a common header only with no parameters.