Transport Layer Security
The Oracle Communications Session Border Controller provides support for Transport Layer Security (TLS) for SIP, which can be used to protect user and network privacy by providing authentication and guaranteeing the integrity for communications between the Oracle Communications Session Border Controller and the following:
- Another device in your network infrastructure (intra-network)
- Another Oracle Communications Session Border Controller when you are using a peering application (inter-network) for interior network signaling security
- An endpoint for authentication before allowing SIP messaging to take place

The SBC and TLS
Transport Layer Security (TLS) on the Oracle Communications Session Border Controller (SBC) depends on the presence of the Security Service Module (SSM) for hardware acceleration of encryption and decryption and random media generation. The SSM module is a plug-in that you can add to the SBC chassis given the installation of the necessary boot loader and minimum hardware revision levels.
With the required hardware revision levels, qualified field personnel can add the plug-in unit to the SBC onsite. This provision makes upgrades fast, and means that you do not need to return the SBC to Oracle manufacturing for a hardware upgrade. When you upgrade the SBC with the SSM card that supports TLS, field personnel will affix a new CLEI code label to the Oracle chassis. The code will also appear on the SSM card (also referred to as the plug-in unit) and is visible when the system’s chassis cover is opened. On a new SBC provisioned with the SSM card, the code labels are already affixed in all required locations.
With the SSM card installed on the SBC, TLS support is enabled and the SSM accelerator performs:
- RSA
- Diffie-Hellman
- DES
- 3DES
- AES256
- Random number generation
Supported Encryption
- TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3
Note:
Oracle does not support RC4 ciphers.Diffie-Hellman Key Size
In the context of TLS negotiations on SIP interfaces, the default
Diffie-Hellman key size offered by the SBC is
1024 bits. The key size is set in the diffie-hellman-key-size
attribute
within the tls-global configuration element.
While the key size can be increased, setting the key size to 2048 bits significantly decreases performance.
Suite B and Cipher List Support
The Oracle Communications Session Border Controller (SBC) supports full control of selecting the ciphers that you want to use for Transport Layer Security (TLS). The system defaults to DEFAULT for the Cipher List parameter in the TLS Profile configuration. Oracle recommends that you delete ALL and add only the particular ciphers that you want, choosing the most secure ciphers for your deployment.
- Key Algor—Public key algorithm. Supports RSA and ECDSA. Default: RSA Security. You must select ECDSA to support suite B.
- ECDSA Key Size—ECDSA key size. Supports p256 and p384.
Configure the list of ciphers that you want to use from the cipher-list element in the tls-profile configuration. Press Tab to display the list of supported ciphers. One-by-one, you can add as many ciphers as your deployment requires.
Minimum Advertised SSL/TLS Version
The sslmin option sets the minimum allowed TLS version. Use this option to mitigate the use of older, more vulnerable versions of TLS.
When the tls-version parameter is set to compatibility within a tls-profile configuration element, the sslmin option specifies the lowest TLS version allowed. By default, when tls-version is set to compatibility, the Oracle Communications Session Border Controller advertises only TLS1.1 and TLS1.2. To advertise TLS1.0 as well, set sslmin to tls1.0.
In security-config, the sslmin option values can be: tls1.0, tls1.1 or tls1.2.
Signaling Support
The Oracle Communications Session Border Controller ’s TLS functionality supports SIP and SIPS. In addition, the Oracle Communications Session Border Controller can accommodate a mixture of TLS and non-TLS sessions within a realm as because a request for TLS is controlled by the endpoint (TLS UA).
Endpoint Authentication
The Oracle Communications Session Border Controller does not operate as a CA. Instead, the Oracle Communications Session Border Controller ’s TLS implementation assumes that you are using one of the standard CAs for generating certificates:
- Verisign
- Entrust
- Thawte
- free Linux-based CA (for example, openssl)
Note:
Self-signed certificates are available only as an option for MSRP connectionsThe Oracle Communications Session Border Controller can generate a certificate request in PKCS10 format and to export it. It can also import CA certificates and a Oracle Communications Session Border Controller certificate in the PKCS7/X509 PEM format.
The Oracle Communications Session Border Controller generates the key pair for the certificate request internally. The private key is stored as a part of the configuration in 3DES encrypted form (with an internal generated password) and the public key is returned to the user along with other information as a part of PKCS10 certificate request.
The Oracle Communications Session Border Controller supports the option of importing CA certificates and marking them as trusted. However, the Oracle Communications Session Border Controller only authenticates client certificates that are issued by the CAs belonging to its trusted list. If you install only a specific vendor's CA certificate on the Oracle Communications Session Border Controller , it authenticates that vendor's endpoints. Whether the certificate is an individual device certificate or a site-to-site certificate does not matter because the Oracle Communications Session Border Controller authenticates the signature/public key of the certificate.
Keeping Pinholes Open at the Endpoint
The Oracle Communications Session Border Controller provides configurable TCP NAT interval on a per-realm basis. You need to configure a NAT interval for the applicable realm to support either all conforming or all non-conforming endpoints.
- Conforming endpoints use the draft-jennings sipping-outbound-01. It describes how to keep the endpoint keeps the connection alive.
Note:
Currently the endpoint uses REGISTER. - Non-conforming endpoints have short NAT interval, where the HNT application with the TCP connection for TLS operates as it does for regular TCP. We give the UA a shorter expires time so that it refreshes frequently, implicitly forcing the UA to keep the TVP socket open and reuse it for further requests (in-dialog or out-of-dialog). Regular requests using TLS sent from the Oracle Communications Session Border Controller to the UA reuse the same TCP connection so that further TLS certificate exchanges are not required.
Key Usage Control
You can configure the role of a certificate by setting key usage extensions and extended key usage extensions. Both of these are configured in the certificate record configuration.
Key Usage List
This section defines the values you can use (as a list) in the key-usage-list parameter. You can configure the parameter with more than one of the possible values.
Value | Description |
---|---|
digitalSignature
(default with keyEncipherment) |
Used when the subject public key is used with a digital signature mechanism to support security services other than non-repudiation, certificate signing, or revocation information signing. Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity. |
nonRepudiation | Used when the subject public key is used to verify digital signatures that provide a non-repudiation service protecting against the signing entity falsely denying some action, excluding certificate or CRL signing. |
keyEncipherment
(default with digitalSignature) |
Used with the subject public key is used for key transport. (For example, when an RSA key is to be used for key management.) |
dataEncipherment | Used with the subject public key is used for enciphering user data other than cryptographic keys. |
keyAgreement | Used with the subject public key is used key agreement. (For example, when a Diffie-Hellman key is to be used for a management key.) |
encipherOnly | The keyAgreement type must also be set.
Used with the subject public key is used only for enciphering data while performing key agreement. |
decipherOnly | The keyAgreement type must also be set.
Used with the subject public key is used only for deciphering data while performing key agreement. |
Extended Key Usage List
This section defines the values you may use in the extended-key-usage-list parameter.
Value | Description |
---|---|
serverAuth
(default) |
Used while the certificate is used for TLS server authentication. In Oracle Communications Session Border Controller access-side deployments, the system typically acts as a TLS server accepting TLS connections. You might use this setting while generating the end-entity-cert. |
clientAuth | Used while the certificate is used for TLS client authentication. In Oracle Communications Session Border Controller core-side deployments, the system typically acts as a TLS client initiating TLS connections. You might use this setting while generating the end-entity-cert. |
When you enable a tls-profile for mutual-authentication, you must also configure the extended-key-usage-list parameter within the associated end-entity-certificate to both the serverAuth and clientAuth values. The default for extended-key-usage-list is serverAuth only.
4096-bit RSA Key Support
The Oracle Communications Session Border Controller (SBC) supports 4096-bit RSA keys for SIP Transport Layer Security (TLS) on all platforms. The 4096-bit support enables you to import root certificates for SIP communications secured with TLS into the SBC.
Use the key-size parameter in the certificate-record configuration to set the key size.
Reusing a TLS Connection
TheOracle Communications Session Border Controller supports TLS connection reuse if and when an alias is included in the Via header by the originator of the TLS connection. When this is the case, the Oracle Communications Session Border Controller reuses the same connection for any outgoing request from the Oracle Communications Session Border Controller .
TLS Configuration Process
Configuring Transport Layer Security (TLS) on the Oracle Communications Session Border Controller (SBC) includes the following steps.
- Configure certificates. See "Configure Certificates."
- Configure and apply the TLS profile. See "Configure a TLS Profile."
Certificate Configuration Process
The process for configuring certificates on the Oracle Communications Session Border Controller (SBC) includes the following steps:
- Configure a certificate record on the SBC. See "Configure Certificates."
- Generate a certificate request by the SBC. See "Generate a Certificate Request."
- Import the certificate record into the SBC. See "Import a Certificate Using the ACLI" and "Import a Certificate Using SFTP."
- Reboot the system.
Configure the Certificate Record
The certificate record configuration represents either the end-entity certificate or the CA certificate on the Oracle Communications Session Border Controller (SBC). When you use the certificate record for an end-entity certificate, associate a private key with the certificate record configuration by using the ACLI generate-certificate-request command. You can import a requested certificate provided by a CA into a certificate record configuration using the ACLI import-certificate command.
Do not associate a private key with the certificate record configuration, if it was issued to hold a CA certificate.
Note:
You do not need to create a certificate record when importing a CA certificate or certificate in PKCS #12 format.- Create TLS profiles, using your certificate records, to further define the encryption behavior and create the configuration element that you can apply to a SIP interface.
Generate a Certificate Request
Using the ACLI generate-certificate-request command allows you to generate a private key and a certificate request in PKCS10 PEM format. You take this step after you configure a certificate record.
The Oracle Communications Session Border Controller stores the private key that is generated in the certificate record configuration in 3DES encrypted form with in internally generated password. The PKCS10 request is displayed on the screen in PEM (Base64) form.
You use this command for certificate record configurations that hold end-entity certificates. If you have configured the certificate record to hold a CA certificate, then you do not need to generate a certificate request because the CA publishes its certificate in the public domain. You import a CA certificate by using the ACLI import-certificate command.
This command sends information to the CA to generate the certificate, but you cannot have Internet connectivity from the Oracle Communications Session Border Controller to the Internet. You can access the internet through a browser such as Internet Explorer if it is available, or you can save the certificate request to a disk and then submit it to the CA.
To run the applicable command, you must use the value you entered in the name parameter of the certificate record configuration. You run the command from main Superuser mode command line:
ORACLE# generate-certificate-request acmepacket
Generating Certificate Signing Request. This can take several minutes...
-----BEGIN CERTIFICATE REQUEST-----
MIIDHzCCAoigAwIBAgIIAhMCUACEAHEwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UE
BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4w
DAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBDZXJ0aWZpY2F0ZSBB
dXRob3JpdHkwHhcNMDUwNDEzMjEzNzQzWhcNMDgwNDEyMjEzNzQzWjBUMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCTUExEzARBgNVBAcTCkJ1cmxpbmd0b24xFDASBgNV
BAoTC0VuZ2luZWVyaW5nMQ0wCwYDVQQDEwRhY21lMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCXjIeOyFKAUB3rKkKK/+59LT+rlGuW7Lgc1V6+hfTSr0co+ZsQ
bHFUWAA15qXUUBTLJG13QN5VfG96f7gGAbWayfOS9Uymold3JPCUDoGgb2E7m8iu
vtq7gwjSeKNXAw/y7yWy/c04FmUD2U0pZX0CNIR3Mns5OAxQmq0bNYDhawIDAQAB
o4HdMIHaMBEGA1UdEQQKMAiCBnBrdW1hcjAJBgNVHRMEAjAAMB0GA1UdDgQWBBTG
tpodxa6Kmmn04L3Kg62t8BZJHTCBmgYDVR0jBIGSMIGPgBRrRhcU6pR2JYBUbhNU
2qHjVBShtqF0pHIwcDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEx
ETAPBgNVBAcTCFNhbiBKb3NlMQ4wDAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lw
aXQgVGVzdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHmCAQAwDQYJKoZIhvcNAQEFBQAD
gYEAbEs8nUCi+cA2hC/lM49Sitvh8QmpL81KONApsoC4Em24L+DZwz3uInoWjbjJ
QhefcUfteNYkbuMH7LAK0hnDPvW+St4rQGVK6LJhZj7/yeLXmYWIPUY3Ux4OGVrd
2UgV/B2SOqH9Nf+FQ+mNZOlL7EuF4IxSz9/69LuYlXqKsG4=
-----END CERTIFICATE REQUEST-----;
WARNING: Configuration changed, run save-config command.
ORACLE# save-config
Save-config received, processing.
waiting 1200 for request to finish
Request to ‘SAVE-CONFIG’ has Finished,
Save complete
Currently active and saved configurations do not match!
To sync & activate, run ‘activate-config’ or ‘reboot-activate’
ORACLE# activate-config
Activate-Config received, processing.
waiting 12000 for request to finish
Add LI flows
LiSysClientMgr::handleNotifyReq
H323 Active Stack Cnt: 0
Request to ‘ACTIVATE-CONFIG’ has finished
Activate Complete
ORACLE#
Import a Certificate Using the ACLI
After the Certificate Authority (CA) generates the certificate, you can import it into the Oracle Communications Session Border Controller (SBC) with the import-certificate command.
Use the following syntax:
ORACLE # import-certificate [try-all|pkcs7|x509] [certificate-record file-name]
Update a Certificate
When you need to renew an expiring certificate on the SBC, you can either create a new certificate-record or you can overwrite the existing certificate-record with the renewed certificate.
- Send the original Certificate Signing Request to the Certificate Authority (CA) for renewal.
- Follow the procedure in "Configure the Certificate Record" to create a new certificate-record element.
- Update your tls-profile to point to that new certificate-record.
- Delete the old certificate-record.
- Reboot.
If you want to replace your expiring certificate by updating your existing certificate-record:
PKCS #12 Container Import and Export Capability
The SBC supports Public Key Cryptography Standard (PKCS) #12 for bundling a private key with the associated X.509 public key certificate in a file for archiving, importing, and exporting. The SBC does not support bundling all members of the chain of trust.
Note:
The SBC only supports PKCS12 files that are bundled with RSA private keys and their X.509 certificates.Note:
The SBC supports this functionality only by way of the ACLI.Export to a PKCS #12 File
You can export a local entity certificate from the Session Border Controller (SBC) to a PKCS #12 file by way of the ACLI. For the enterprise SBC, you cannot do so from the Web GUI.
Note:
When prompted for password and passphrase, use the ones that you entered in system-config.Import a PKCS #12 File
You can import a PKCS #12 key and certificate file that was generated elsewhere into the Oracle Communications Session Border Controller (SBC) by way of the ACLI.
-descert
flag or the -keypbe
and -certpbe
options. If
rsa.key
is a private key and cert.crt
is an X.509
certificate, either of the following commands generates a PKCS#12
file.# generate using -descert
openssl pkcs12 -export -in cert.crt -inkey rsa.key -out my_pkcs12.pfx -name "Test Cert" -descert
# generate using -keypbe and -certpbe options
openssl pkcs12 -export -in cert.crt -inkey rsa.key -out my_pkcs12.pfx -name "Test Cert" -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES
View Certificates
You can view either a brief version or a detailed version of your certificates.
Brief Version
Obtaining the brief version uses this syntax, and will appear like the following example:
ORACLE# show security certificates brief acmepacket
certificate-record:acmepacket
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
02:13:02:50:00:84:00:71
Issuer:
C=US
ST=California
L=San Jose
O=sipit
OU=Sipit Test Certificate Authority
Subject:
C=US
ST=MA
L=Burlington
O=Engineering
CN=acme
ORACLE#
Detailed Version
Obtaining the detailed version uses this syntax, and will appear like the following example:
ORACLE# show security certificates detail acmepacket
certificate-record:acmepacket
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
02:13:02:50:00:84:00:71
Signature Algorithm: sha1WithRSAEncryption
Issuer:
C=US
ST=California
L=San Jose
O=sipit
OU=Sipit Test Certificate Authority
Validity
Not Before: Apr 13 21:37:43 2005 GMT
Not After : Apr 12 21:37:43 2008 GMT
Subject:
C=US
ST=MA
L=Burlington
O=Engineering
CN=acme
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:pkumar
X509v3 Basic Constraints:
CA:FALSE
ORACLE#
Configure a TLS Profile
The TLS profile configuration contains the information required to run SIP over TLS.
- Obtain the necessary certificates.
- Confirm that the system displays the Superuser mode.
Notifications for Certificate Expiration
Traps
When a security certificate is installed locally on the Oracle Communications Session Border Controller, you can poll the expiration of the certificate using the apSecurityCertificateTable.
You can configure the SBC to generate the apSecurityCertExpiredNotification trap once a certificate has expired. The number of minutes between notifications sent is configured in the security-config parameter local-cert-exp-trap-int.
To send a warning of expiration, you can set the security-config parameter local-cert-exp-warn-period to the number of days before the locally installed certificate expires in which you would like a warning. The number of minutes between notifications sent is configured in thesecurity-config parameter local-cert-exp-trap-int.
Alarms
The SBC also generates an alarm when the certificate of a tls-profile is about to expire or has expired. The value of local-cert-exp-warn-period determines the number of days before a certificate expires in which the SBC generates a warning alarm.
When the certificate is about to expire:
ORACLE# display-alarms
1 alarms to show
ID Task Severity First Occurred Last Occurred
327731 3386 6 2019-01-29 21:47:55 2019-01-29 21:47:55
Count Description
1 Certificate: tempCert expiring on Jan 30 20:58:29 2019 GMT,
done
ORACLE#
When the certificate has expired:
ORACLE# display-alarms
1 alarms to show
ID Task Severity First Occurred Last Occurred
327730 3386 6 2019-02-01 16:20:45 2019-02-01 16:20:45
Count Description
1 Certificate: tempCert expired on Jan 30 20:58:29 2019 GMT,
done
ORACLE#
Denial of Service for TLS
This section explains the DoS for TLS feature. With this feature, the Oracle Communications Session Border Controller can provide protection from TCP/TLS message flood by limiting the number of connections from an end point and by limiting the number of simultaneous TCP/TLS connections to a SIP interface.
The Oracle Communications Session Border Controller protects against a flood of invalid TLS messages and against end points establishing TCP/TLS connections or doing an initial registration without then sending any messages. The Oracle Communications Session Border Controller protects against:
- Too many simultaneous TLS connections being requested by a single IP address by limiting the number of TLS connections from a single IP address. There is a maximum simultaneous number of TCP/TLS connections a SIP interface will allow from a single IP address.
- Too many simultaneous TLS connections being requested by limiting the maximum number of connections for a SIP interface. There is a maximum number of simultaneous TCP/TLS connections a SIP interface will allow in aggregate from all IP addresses served by that signaling interface.
- End points establishing TCP/TLS connections without then sending any messages (application layer messages post TLS handshake complete). Triggered by inactivity as measured by lack of any message from this peer.
- End points doing an initial registration without then sending any messages.
This timer could be used by the administrator to detect errors with the SIP configuration. It is expected that whenever an end point establishes a TCP/TLS connection, the end point will keep the connection active by sending messages with REGISTER or by using the NAT interval configuration. Whenever a connection is torn down because of inactivity, a log at the level ERROR is generated.)
- Malformed packets by counting and limiting the maximum number of malformed packets. Whenever an invalid TLS message is received, the internal counter corresponding to invalid-signal-threshold is incremented. When the invalid signal threshold reaches the configured value, the end point will be denied for the configured deny period. (Also requires configuration of the tolerance window in media manager.)
- The max-incoming-conns parameter is well under the maximum number of TLS connections supported by the system. You can set this parameter to it's maximum value of 20000. If you need more than 20000 TLS connections available on this SIP interface, you must set max-incoming-conns to 0 which allows up to the system maximum number of TLS connections, taken on a first come first served basis, on this SIP interface.
TLS Session Caching
Transport Layer Security (TLS) session caching allows the Oracle Communications Session Border Controller to cache key information for TLS connections, and to set the length of time that the information is cached.
When TLS session caching is not enabled, the Oracle Communications Session Border Controller and a TLS client perform the handshake portion of the authentication sequence in which they exchange a shared secret and encryption keys are generated. One result of the successful handshake is the creation of a unique session identifier. When an established TLS connection is torn down and the client wants to reinstate it, this entire process is repeated. Because the process is resource-intensive, you can enable TLS session caching to avoid repeating the handshake process for previously authenticated clients to preserve valuable Oracle Communications Session Border Controller resources.
When TLS session caching is enabled on the Oracle Communications Session Border Controller, a previously authenticated client can request re-connection using the unique session identifier from the previous session. The Oracle Communications Session Border Controller checks its cache, finds the session identifier, and reinstates the client. This process reduces the handshake to three messages, which preserves system resources.
If the client offers an invalid session identifier, for example, one that the Oracle Communications Session Border Controller has never seen or one that has been deleted from its cache, the system does not allow the re-connection. The system negotiates the connection as a new connection.
TLS Endpoint Certificate Data Caching
To provide a higher level of security for unified messaging (UM), the Oracle Communications Session Border Controller allows you configure enforcement profiles to cache data from TLS certificates. During the authentication process, the system caches the data so it can use that data in subsequent SIP message processing. Thus the Oracle Communications Session Border Controller can:
- Add custom SIP header populated with information from TLS certificates—When the Oracle Communications Session Border Controller receives an INVITE from a GW, it can write proprietary headers into the SIP message. It uses the certificate information the GW provided during the TLS authentication process with the Oracle Communications Session Border Controller to do so.
- Compare the host of the Request-URI with information from TLS certificates—When an INVITE is destined for the unified messaging server, the Oracle Communications Session Border Controller checks the domain of the Request-URI it has generated prior to HMR application. It does so to verify that the Request-URI matches the domain information the UM server provided during the TLS authentication process with the Oracle Communications Session Border Controller.
TLS endpoint certificate data caching can only applies to call-creating SIP INVITEs. The Oracle Communications Session Border Controller looks to the following configurations, in order, to apply an enforcement profile: session agent, realm, and SIP interface associated with the INVITE. As a final step, it checks the SIP profile for enforcement profile association.
Inserting Customized SIP Headers in an Outgoing INVITE
When the Oracle Communications Session Border Controller establishes a new TLS connection, it caches the following peer certificate attributes:
- Certificate Subject Name
- Certificate Subject Alternative Name (only DNS)
The Oracle Communications Session Border Controller constructs a customized P-Certificate-Subject-Common-Name SIP header and inserts the header into the outgoing INVITE with the Certificate Subject Name. The Oracle Communications Session Border Controller also constructs and inserts in the outgoing INVITE one or more P-Certificate-Subject-Alternative-Name SIP headers.
If you enable this capability and the incoming INVITE already has P-Certificate-Subject-Common-Name and P-Certificate-Subject-Alternative-Name headers, the Oracle Communications Session Border Controller strips them before inserting the new customized ones. It does so to avoid the risk of any attempt to spoof the headers and thereby gain unauthorized access to the UM server.
The following diagram shows a scenario where the calling party establishes a TLS connection with the Oracle Communications Session Border Controller. Because mutual authentication is enabled, the Oracle Communications Session Border Controller receives the peer certificate and caches required information from it. This information is inserted in the outgoing INVITE.

The peer certificate from the calling party during the TLS handshake with the Oracle Communications Session Border Controller looks like the following example.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9 (0x9)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=MA, L=Woburn, O=Smith Securities, OU=Certificate Authority Dept, CN=Smith Certificate Authority/emailAddress=Smith@CA.com
Validity
Not Before: Dec 10 21:14:56 2009 GMT
Not After : Jul 11 21:14:56 2019 GMT
Subject: C=US, ST=MA, L=Burlington, O=Acme Packet, OU=Certificate Authority Dept, CN=*.acme.com/emailAddress=ph1Client@acme.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Issuer Alternative Name:
email:Smith@CA.com
X509v3 Subject Alternative Name:
DNS:gw1.acme.com, DNS:gw3.ano.com, DNS:gw2.some.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
The outgoing SIP INVITE (INVITE 2 in the diagram) looks like the following sample. Bold text shows where the Oracle Communications Session Border Controller uses information from the certificate.
INVITE sip:222222@acme.com:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.27.113:5060;branch=z9hG4bK4jmg29cmm8l0cg7smmrn85o4q7
From: 111111 <sip:111111@acme.com>;tag=_ph1_tag
To: 222222 <sip:222222@acme.com>
Call-ID: _1-2_call_id-10147@acme.com-1-
CSeq: 1 INVITE
Contact: <sip:111111@172.16.27.113:5060;transport=udp>
P-Certificate-Subject-Common-Name: *.acme.com
P-Certificate-Subject-Alternative-Name: gw1.acme.com
P-Certificate-Subject-Alternative-Name: gw3.ano.com
P-Certificate-Subject-Alternative-Name: gw2.some.com
Max-Forwards: 69
Subject: TBD
Content-Type: application/sdp
Content-Length: 138
Route: <sip:222222@172.16.27.188:5060;lr>
v=0
o=user1 53655765 2353687637 IN IP4 172.16.27.113
s=-
c=IN IP4 172.16.27.113
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Validating the Request-URI Based on Certificate Information
When you configure the Oracle Communications Session Border Controller to cache TLS certificate information to validate Request-URIs, it stores the Certificate Subject Name and Certificate Subject Alternative Name (only DNS) it learns from peer certificate attributes. It then takes these actions:
- Extracts the host from the Request-URI of the outgoing INVITE
- Compares this host (exact or wildcard match) with the Certificate Common Name or Certificate Subject Alternative name of the certificate it has received
- Sends out an INVITE if the Certificate Common Name or Certificate Subject Alternative name match; Sends a 403 Forbidden rejection to the endpoint from it received the INVITE if there is no match
Wildcard matching applies only to the prefix of the Request-URI:
*.acme.com
*.*.acmepacket.com
This diagram shows a peering scenario where the Oracle Communications Session Border Controller receives an INVITE from the calling party, which it processes and prepares to send out INVITE 2. After establishing a TLS connection with the called party and caching the required information, the Oracle Communications Session Border Controller validates the Request-URI. Once validation occurs, the Oracle Communications Session Border Controller sends INVITE 2.

The peer certificate from the called party during the TLS handshake with the Oracle Communications Session Border Controller would look like this. Relevant information in the sample appears in bold font.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9 (0x9)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=MA, L=Woburn, O=Smith Securities, OU=Certificate Authority Dept, CN=Smith Certificate Authority/emailAddress=amith@CA.com
Validity
Not Before: Dec 10 21:14:56 2009 GMT
Not After : Jul 11 21:14:56 2019 GMT
Subject: C=US, ST=MA, L=Woburn, O=Acme Packet, OU=Certificate Authority Dept, CN=*.acme.com/emailAddress=ph2Server@acme.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Issuer Alternative Name:
email:Smith@CA.com
X509v3 Subject Alternative Name:
DNS:gw1.acme.com, DNS:*.ano.com, DNS:*.some.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
The outgoing SIP INVITE (INVITE 2 in the diagram) would then look like the sample below. The INVITE is sent because smith.acme.com matches the common name *.acme.com. Other valid SIP Request-URIs would be:
222222@gw1.acme.com
222222@smith.ano.com
222222@amith.some.com
You can see where the system uses information from the certificate; the text is bold.
INVITE sip:222222@smith.acme.com:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.27.113:5060;branch=z9hG4bK4jmg29cmm8l0cg7smmrn85o4q7
From: 111111 <sip:111111@acme.com>;tag=_ph1_tag
To: 222222 <sip:222222@acme.com>
Call-ID: _1-2_call_id-10147@acme.com-1-
CSeq: 1 INVITE
Contact: <sip:111111@172.16.27.113:5060;transport=udp>
Max-Forwards: 69
Subject: TBD
Content-Type: application/sdp
Content-Length: 138
Route: <sip:222222@172.16.27.188:5060;lr>
v=0
o=user1 53655765 2353687637 IN IP4 172.16.27.113
s=-
c=IN IP4 172.16.27.113
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Untrusted Connection Timeout for TCP and TLS
You can configure the Oracle Communications Session Border Controller for protection against starvation attacks for socket-based transport (TCP or TLS) for SIP access applications. During such an occurrence, the attacker would open a large number of TCP/TLS connections on the Oracle Communications Session Border Controller and then keep those connections open using SIP messages sent periodically. These SIP messages act as keepalives, and they keep sockets open and consume valuable resources.
Using its ability to promote endpoints to a trusted status, the Oracle Communications Session Border Controller now closes TCP/TLS connections for endpoints that do not enter the trusted state within the period of time set for the untrusted connection timeout. The attacking client is thus no longer able to keep connections alive by sending invalid messages.
This feature works by setting a value for the connection timeout, which the Oracle Communications Session Border Controller checks whenever a new SIP service socket for TCP or TLS is requested. If the timer’s value is greater than zero, then the Oracle Communications Session Border Controller starts it. If the timer expires, then the Oracle Communications Session Border Controller closes the connection. However, if the endpoint is promoted to the trusted state, then the Oracle Communications Session Border Controller will cancel the timer.
Caveats
This connection timeout is intended for access applications only, where one socket is opened per-endpoint. This means that the timeout is not intended for using in peering applications; if this feature were enabled for peering, a single malicious SIP endpoint might cause the connection to be torn down unpredictably for all calls.
Securing Communications Between the SBC and SDM with TLS
You can use the Transport Layer Security (TLS) protocol to secure the communications link between the Oracle Communications Session Border Controller (SBC) and the Oracle Communications Session Delivery Manager (SDM). Note that the systems use Acme Control Protocol (ACP) for this messaging.
- Configure a TLS profile. The tls-profile object is located under security, where you add certificates, select cipher lists, and specify the TLS version for each profile.
- Configure system-config element's acp-tls-profile parameter to specify this TLS profile.
You must reboot OCSBC after configuring ACP over TLS.
Note:
This feature requires SDM version 8.1 and above.