In this section:
The SBC Core supports the exchange of SIP signaling over Transport Layer Security (TLS), an IETF protocol for securing communications across an untrusted network. Normally, SIP packets travel in plain text over TCP or UDP connections. Secure SIP is a security measure that uses TLS, the successor to the Secure Sockets Layer (SSL) protocol. TLS operates just above the transport layer (Layer 4) and provides peer authentication, confidentiality and message integrity.
The SBC supports TLS versions 1.0, 1.1 and 1.2 with server-only authentication (in which only the server is authenticated at the TLS layer) and mutual authentication (in which both the TLS client and server are authenticated at the TLS layer). TLS is an effective measure to a number of threats including theft of service, disruption of service, compromise of confidentiality, and compromise of service integrity.
SIP over TLS may be independently configured on each hop between SIP devices. SIP transport type selection is typically configured via the IP Signaling Profile, and may also be provisioned on the SIP trunk group or identified via a DNS lookup.
If a zone's sipSigPort
is configured for transportProtocolsAllowed
= sip-tls-tcp
, the SBC increments the configured portNumber
by 1 and uses it as the new port number for SIP over TLS signaling. The SBC then opens a TCP socket for SIP over TLS for the new TCP port number.
Example: When sipSigPort
is configured with a portNumber
of 5060 and transportProtocolsAllowed
= sip-tls-tcp
, the SBC listens on TCP port 5061 for SIP over TLS.
The SBC uses SIP over TLS in several scenarios as illustrated in the figure below .
In most scenarios, the SBC Core does not support ECC certificates for TLS Handshake. Specifically, the SBC Core does not support ECC certificates for TLS handshake when it acts as a TLS “server-only,” although it can support the certificates when acting as TLS client in the configured “server-and-client” role.
The table below describes the interrelationship between each of these scenarios, the TLS role (server or client/server), and the authentication requirements.
Deployments may involve two or more of the above scenarios and include different transports (SIP over TLS, SIP over TCP, or SIP over UDP) simultaneously on separate legs of the same signaling path.
When FIPS-140-2 mode is enabled, do not use the SBC releases 5.1, 6.2 and 7.2 are officially FIPS-compliant.rsa-with-null-sha
option.
The SBC and its peer devices use X.509 digital certificates to authenticate themselves for TLS. Local certificates in PKSC # 12 format (attesting to the identity of the SBC) and remote Certificate Authority (CA) certificates may be installed on the SBC in a common area (/opt/sonus/external/) where they are available to TLS.