Transport Layer Security
The Oracle® Enterprise 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® Enterprise Session Border Controller and the following:
- Another device in your network infrastructure (intra-network)
- Another Oracle® Enterprise 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 E-SBC and TLS
Transport Layer Security (TLS) on the Oracle® Enterprise Session Border Controller E-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 E-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 E-SBC onsite. This provision makes upgrades fast, and means that you do not need to return the E-SBC to Oracle manufacturing for a hardware upgrade. When you upgrade the E-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 E-SBC provisioned with the SSM card, the code labels are already affixed in all required locations.
With the SSM card installed on the E-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
Note:
Oracle does not support RC4 ciphers.Suite B and Cipher List Support
The Oracle® Enterprise Session Border Controller (E-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.
TLS Ciphers
The Oracle® Enterprise Session Border Controller (E-SBC) supports TLS v1, TLSv1.1, and TLSv1.2 ciphers.
The tls-profile object contains the cipher list parameter, and the tlsCipherList command displays the list of ciphers that you may specify. For a complete list of supported ciphers, see the Oracle Enterprise Session Border Controller Release Notes.
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® Enterprise 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® Enterprise Session Border Controller ’s TLS functionality supports SIP and SIPS. In addition, the Oracle® Enterprise 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® Enterprise Session Border Controller does not operate as a CA. Instead, the Oracle® Enterprise 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® Enterprise Session Border Controller can generate a certificate request in PKCS10 format and to export it. It can also import CA certificates and a Oracle® Enterprise Session Border Controller certificate in the PKCS7/X509 PEM format.
The Oracle® Enterprise 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® Enterprise Session Border Controller supports the option of importing CA certificates and marking them as trusted. However, the Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller authenticates the signature/public key of the certificate.
Keeping Pinholes Open at the Endpoint
The Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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. |
4096-bit RSA Key Support
The Oracle® Enterprise Session Border Controller (E-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 E-SBC.
Use the key-size parameter in the certificate-record configuration to set the key size.
Reusing a TLS Connection
TheOracle® Enterprise 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® Enterprise Session Border Controller reuses the same connection for any outgoing request from the Oracle® Enterprise Session Border Controller .
TLS Configuration Process
Configuring Transport Layer Security (TLS) on the Oracle® Enterprise Session Border Controller (E-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® Enterprise Session Border Controller (E-SBC) includes the following steps:
- Configure a certificate record on the E-SBC. See "Configure Certificates."
- Generate a certificate request by the E-SBC. See "Generate a Certificate Request."
- Import the certificate record into the E-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® Enterprise Session Border Controller (E-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.
Generating 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 once you have configured a certificate record.
The Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller (E-SBC) with the import-certificate command.
Use the following syntax:
ORACLE # import-certificate [try-all|pkcs7|x509] [certificate-record file-name]
Viewing Certificates
You can view either a brief version or detailed information about the 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.
Denial of Service for TLS
This section explains the DoS for TLS feature. With this feature, the Oracle® Enterprise 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® Enterprise 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® Enterprise 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.
Securing Communications Between the E-SBC and SDM with TLS
You can use the Transport Layer Security (TLS) protocol to secure the communications link between the Oracle® Enterprise Session Border Controller (E-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-profileparameter to specify this TLS profile.
acp-tls-profile parameter is empty by default, which means that ACP over TLS is disabled. When ACP over TLS is disabled, the SDM establishes a TCP connection with the
E-SBC. When the
acp-tls-profile parameter specifies a valid TLS profile, the
E-SBC negotiates a TLS connection with SDM.
Note:
This feature requires SDM version 8.1 and above.TLS Session Caching
Transport Layer Security (TLS) session caching allows the Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller resources.
When TLS session caching is enabled on the Oracle® Enterprise Session Border Controller, a previously authenticated client can request re-connection using the unique session identifier from the previous session. The Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller can:
- Add custom SIP header populated with information from TLS certificates—When the Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller.
TLS endpoint certificate data caching can only applies to call-creating SIP INVITEs. The Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller. Because mutual authentication is enabled, the Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller validates the Request-URI. Once validation occurs, the Oracle® Enterprise Session Border Controller sends INVITE 2.
The peer certificate from the called party during the TLS handshake with the Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller starts it. If the timer expires, then the Oracle® Enterprise Session Border Controller closes the connection. However, if the endpoint is promoted to the trusted state, then the Oracle® Enterprise 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 E-SBC and SDM with TLS
You can use the Transport Layer Security (TLS) protocol to secure the communications link between the Oracle® Enterprise Session Border Controller (E-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-profileparameter to specify this TLS profile.
acp-tls-profile parameter is empty by default, which means that ACP over TLS is disabled. When ACP over TLS is disabled, the SDM establishes a TCP connection with the
E-SBC. When the
acp-tls-profile parameter specifies a valid TLS profile, the
E-SBC negotiates a TLS connection with SDM.
Note:
This feature requires SDM version 8.1 and above.
