Security Features
This section outlines specific SBC security mechanisms.
The Security Model
The Oracle Communications SBC is a purpose built device providing customers both centralized and distributed control of the management and security of UC networks. The SBC is a critical network security element for VoIP services designed to effectively manage sessions and protect core network elements from various types of DDoS attacks, including malicious and non-malicious signaling overload attacks. The SBC is the sole ingress and egress point for all signaling messages (SIP/H.323) and media streams to/from the core network and is therefore generally the demarcation point between trusted and untrusted network boundaries. Hence it is vital that the SBC be as secure and available as possible.
Oracle provides a number of industry leading techniques through SBC configuration to secure the network border. Some of these features are enabled “out of the box” and some require further analysis of the network architecture to determine the most optimal configuration for security.
For example, the SBC performs access control based on layer 5 signaling messages as one of its primary functions. The SBC is designed to allow authorized VoIP communications into the core network by opening/closing firewall ports and by performing NAPT (network address and port translations) on all signaling and media IP packets as one of its core functions. Signaling messages, going to and from the SIP core servers and residential gateways and/or peering affiliate infrastructure is therefore inspected and rewritten as necessary by the SBC.
The SBC follows a “closed” philosophy where ports and interfaces are closed by default and opened on an as-needed basis. Therefore the system will generally have ports, services and processes disabled unless configured.
R.226 Security Recommendations
- Users should change their login password after upgrading. Changing the login password forces the SBC to use the more secure SHA-2 hashing algorithm for storing password hashes.
- An Oracle Communications Session Border Controller ignores attempts to modify security related boot flags from the ACLI. The OCSBC still supports changing security related boot flags through the bootloader. See the R.226 Chapter in the Configuration Guide for details.
- The li-admin user should set the lawful intercept configuration password. Setting the li-config password encrypts the lawful intercept configuration.
- Users should only use IKEv2 for X2/X3 traffic.
- Users should configure the X1 interface (on a management interface) on a dedicated VLAN.
WARNING:
Selecting IKEv2 disables IKEv1.Net-SAFE Architecture: SBC & Core Infrastructure Protection
The SBC provides several techniques for protecting the SBC, and therefore the service, from DDoS attacks.
First, traditional static ACLs should be configured to only permit signaling traffic from trusted devices. Permit ACLs are applicable for both unsecured networks (peering partner’s SBCs, proxies, gateways) and secure network devices (core network softswitches, media servers, application servers, gateways). All other devices should be denied access to the SBC through the use of deny ACLs.
This solution does not scale for hosted NAT traversal (or hosted access) based applications where thousands of remote endpoint devices with dynamic IP addresses communicate directly to the SBC signaling interfaces.
- Protect the SBC core CPU via configurable sized queues and separation of signaling packets (trusted, untrusted)
- Configurable trust-level (none, low, medium, high)
- Wire speed hardware classification of every remote device trust-level
- Provide fair access for new/untrusted devices to signaling queue
- Multi-queue access fairness for unknown traffic
- Automatic behaviorally driven promotion/demotion/denial of devices
- Per-device constraints and authorization
- Protection against attack from behind NAT
Each device is classified as untrusted, trusted or denied. The entire system bandwidth is allocated for the trusted and untrusted queues according to the characteristics of the customer Access deployment (e.g. number of endpoints, rate of registration, packet size, etc.). The allocation of the CAM is configurable to tailor the sizes of the entries available for media, trusted and deny NAT entries according to the scale of the customer Access network. Separate configurable sized queues also exist for fragmented packets and ARP requests. In addition, a whole NAT device can be demoted based on the collective behavior of endpoints behind the NAT.
- None: Device is always untrusted, no promotion or demotion
- Low: Device is initially untrusted, can be promoted to trusted, or demoted to denied
- Medium: Device is initially untrusted, can be promoted to trusted, cannot be denied
- High: Device is always trusted
A low or medium trust level is appropriate for Access or untrusted networks (realms). In contrast, a high trust level is appropriate only for Core or trusted networks (realms).
Promotion Criteria Examples: SIP: 200OK received for either Register or Invite method
o
Demotion Criteria Examples
- invalid-signal-threshold: maximum number of non-compliant signaling packets acceptable
- maximum-signal-threshold: maximum number of signaling packets acceptable while an endpoint is classified as trusted
- untrusted-signaling-threshold: maximum number of signaling packets while an endpoint is classified as untrusted
These thresholds are all measured in the configurable system wide tolerance-window (default 30s)
If an endpoint crosses one of these thresholds then a deny ACL is written to the CAM, and checked by the Network Processors (NP) upon receipt of a packet from the denied endpoint. The endpoint is denied for a configurable period of time.
The Whole NAT device demotion Criteria Examples
- max-endpoints-per-nat: maximum number of end points behind a NAT at a realm level
- nat-invalid-message-threshold: Maximum number of invalid messages from all endpoints behind a NAT
Another related configuration is wait-time-for-invalid-register, the time period which the SBC will wait before counting the absence of the REGISTER message as an invalid message.
The goal of the DDoS protection tools detailed above is to assess and plan for a configuration that allows service to continue whether the SBC is under malicious attack or a non-malicious attack such as a recovery from a Softswitch outage or registration flood from endpoints. This involves allowing enough untrusted traffic such that endpoints can over time register successfully yet constraining all queues sufficiently to protect SBC resources (i.e. core CPU threshold).
- cache-challenges and reg-overload-protect: The SBC will temporarily promote the endpoint to trusted level after the registrar challenges the REGISTER message with a 401/407 response.
- max-register-forward: Limit rate of REGISTERs to forward to the registrar. Set to 75% of max registers/sec the registrar can handle.
- max-register-refresh: Limit rate of REGISTER refreshes from endpoints. Set to 150% of number of endpoints divided by the refresh interval.
- register-grace-timer: Grace period in seconds before a cached registration is deleted from the SBC after expiration. Recommended to set this value to 32.
- reject-register=refresh: Lets the REGISTER in, but will check the load limit if there is not a cached registration that it can use for a response.
For the session-agent representing the core Registrar, the max-register-burst-rate should be configured to throttle REGISTER messages sent to it. In addition, session-constraints should be enabled with rate-constraints configured to limit the rate of REGISTER messages coming into the core network. Session-constraints are applied on the Access sip-interface or realm. In the sip-config parameter, extra-method-stats must be enabled for rate-constraints to take effect.
Please contact your Oracle Systems Engineer to discuss planning for DDoS protection configuration and deployment. Basic DDoS configuration is found in Appendix C: DDoS Prevention for Peering Environments and Appendix D: DDoS Prevention for Access or Hybrid Environments. Configuration is detailed in “SIP Signaling Services” and “Security” of the ACLI Configuration Guide.
Net-SAFE Architecture: Topology Hiding & SIP Manipulation
Topology hiding is primarily performed by the SBC’s Back-to-Back User Agent (B2BUA) function. Use of the SIP-NAT configuration object or the flexible SIP Manipulation feature provide capabilities to dynamically alter any identifying information pertaining to a customer core network in signaling messages.
SIP Manipulation rules allow the customer to check for a value in any element of any SIP message and take action if a rule matches. Actions include changing a value, deleting an element or parameter, completing a header, or adding a completely new header to the message. Requests can be rejected, and MIME types and bodies can also be manipulated. To provide further topology hiding in the SDP portion of a SIP message, the customer should enable SDP anonymization.
An example of the SIP-NAT feature used for topology hiding is available in the document “520-0005-04 BCP - SIP Access Configuration.” An example of the SIP Manipulation feature used for topology hiding is presented in Section 7 “HMR Bridging” of “520-0038-01 BCP SIP Peering Configuration”.
Configuration of SIP HMR (Header Manipulation Rules) is detailed in SIP Signaling Services” of the ACLI Configuration Guide. Configuration of SDP anonymization is detailed in “Security” of the ACLI Configuration Guide.
Security Specific Feature Sets
This section details security-focused feature sets on the SBC.
IDS Reporting
The SBC supports a wide range of intrusion detection and protection capabilities for vulnerability and attack profiles identified to date. The IDS reporting feature provides more detailed reporting of intrusions the system detects. It is useful for enterprise customers’ requirement to report on intrusions and suspicious behavior that it currently monitors. This feature requires the IDS Reporting license, which is included in new purchases but was not in some older deployments. The “IDS Advanced” feature should be present in the output of the show features command.
See Appendix F: Intrusion Detection System for a detailed description of the functionality enabled. Configuration is also detailed in Section 15 “Security” of the ACLI Configuration Guide.
FIPS Feature (Optional)
FIPS is supported on the enterprise software release ECZ80 on the Acme Packet1100, VME, Acme Packet3900, Acme Packet 4600 and Acme Packet 6300 platforms. See “Oracle Enterprise Session Border Controller FIPS Compliance Guide”.
Administrative Security Features (Optional)
See “Oracle Enterprise Session Border Controller Administrative Security Guide”
This feature set includes support for: multiple administrative users, enhanced password strength, password usage policies, user roles, management of administrative users, and serial console port control.
- This feature set requires the Admin Security license.
- This feature set is not intended for all customer use. The customer should consult their Oracle Systems Engineer to understand the security and restriction ramifications of enabling these features.
- The following system features are disabled: ACP (affects acquiring new configs from the HA peer); telnet and FTP access; operating system access.
- Passwords can only be reset to factory defaults by running the diags image.
- Deletion of the Admin Security license alone does not remove its features. Equipment must be returned to manufacturing once the license is enabled.
With the Admin Security feature, access to the SBC is much more restrictive. For example, telnet and FTP cleartext login is disabled in favor of SSH and SFTP secure logins. The SBC can be configured to lock out an interface if the threshold of unsuccessful login attempts is exceeded and for how long. The new user model for administrative login is single-user, single-class. The 3 supported local user names are user, admin and li-admin.
Login parameters are changed with the login-config. When RADIUS login is enabled then local logins are disabled. Furthermore, when a local or RADIUS user logs into the system via console or SSH connection, a banner appears and must be acknowledged. The banner informs the user when they last logged in and whether there have been unsuccessful login attempts. Customers can also create a custom banner by uploading a banner.txt file in /code/banners. (Custom banners are available without the Admin Security license) Banners can be disabled by the customer. No banner appears for SFTP connections.
Upon initial login, passwords must be changed from the factory defaults. Password strength and history are imposed only on local users. Password aging is applied from the date since the last password change. Password-policy can be configured to change password properties. With RADIUS enabled, user passwords are stored on the remote RADIUS server, not on the SBC. Password policy doesn’t apply when RADIUS logins are enabled.
Optionally, SSH public keys can be imported into the SBC. Parameters surrounding SSH re-keying are set in the ssh-config. Key aging will be applied from the date of activating the config.
- sftpForAudit - allows audit log access.
- sftpForAccounting - allows system logs to be accessed.
- sftpForHDR - allows HDR to be accessed.
- sftpForAll - allows all logs to be accessed.
Furthermore, a new RADIUS authorization class is added for Acme-User-Class called SystemAdmin. It shares the same permissions as admin except it cannot access security related information and issue “show security” commands. The login prompt for this user is ACMEPACKET$.
The Security Admin license enables audit logs which provide data on all user driven system events such as changes to configuration and public keys. It is recommended to configure push servers to SFTP audit logs periodically to remote servers.
Configuration is detailed in the Administrative Essentials.
Configuring Monitoring and Performance Management Features
This section describes ways to monitor health and performance of your SBC.
SNMP
Simple Network Management Protocol (SNMP) is supported on the SBC Wancom0 management interface for polling and traps. To secure your SNMP interface, it is recommended to use a community name other than the standard “public”. Sufficiently obscure community names should adhere to the customer’s corporate naming policies. Further, the list of configured SNMP polling servers and trap receivers must be restricted to only those authorized (via SBC configuration) to manage the SBC. All management stations used for SNMP access should have a permit ACL configured.
The Oracle Communications Session Border Controller supports SNMPv3 by default. To secure your SNMPv3 system, you must configure SNMP users and groups, SNMP managers, and view access to MIB trees. SNMPv3 provides the SNMP agent and SNMP Network Management System (NMS) with protocol security enhancements used to protect your system against a variety of attacks, such as increased authentication, privacy, MIB object access control and trap filtering capabilities.
- Set system, system-config, snmp-agent-mode to v3
- Set system, snmp-user-entry, auth-protocol to SHA-256 or SHA-512
- Set system, snmp-user-entry, priv-protocol to AES-128
Further detail on SNMP traps and MIBS that should be examined can be found in the MIB Reference Guide.
RADIUS Accounting
The SBC Wancom0 management interface uses RADIUS requests to send accounting and monitoring data to remote RADIUS servers. For reliability, the SBC supports the configuration of multiple RADIUS servers deployed in a number of HA schemes: hunt, failover, round robin, fastest round trip time (RTT) and fewest pending.
The most appropriate scheme according to customer’s corporate policies should be chosen. It is recommended that at least two RADIUS servers be deployed. The secret shared between the SBC and the RADIUS server should be configured to be suitably obscure according to the customer’s corporate naming policies. All management stations used for accounting monitoring services should have a permit ACL configured.
Configuration is detailed in the ACLI Accounting Guide.
HDR over SFTP
The Historical Data Recording (HDR) feature allows the SBC to record data in comma-separated files and periodically sends them to a remote file server. For added security, transfer the HDR record files using SFTP. Note that public key authentication is not available for this feature so the SBC uses password authentication. All management stations used for SFTP access should have a permit ACL configured.
Configuration is detailed in “System Configuration” of the ACLI Configuration Guide.
Syslog
The syslog service should be used for sending system events from the SBC to a Security Event & Incident Monitoring (SEIM) platform or to another operations monitoring platform. The information sent via syslog is also contained locally on the SBC in the acmelog file.
See Appendix I: for examples of important syslog messages to monitor. The default syslog log level is WARNING.
Configuration is detailed in “Syslog and Process Logs” of the ACLI Configuration Guide.
Configuring AAA Integration
The SBC supports RADIUS and TACACS+.
SSH RADIUS Authentication
The SBC management interface sends RADIUS requests containing login authentication and authorization data to remote RADIUS servers.
The SBC supports the use of the Cisco Systems Inc.™ “Cisco-AVPair” vendor specific attribute (VSA). The Vendor-ID is 1 and the Vendor-Type is 9. This attribute allows for successful administrator login to servers that do not support the Oracle authorization VSA. While using RADIUS-based authentication, the SBC authorizes you to enter Superuser mode locally even when your RADIUS server does not return the ACME_USER_CLASS VSA or the Cisco-AVPair VSA.
All management stations used for SSH access should have a permit ACL configured. An ACL should also be configured to allow RADIUS traffic to the RADIUS server.
For more information, see Section 4 “System Management” of the Maintenance and Troubleshooting Guide.
TACACS+
TACACS+ is a protocol that was originally developed by Cisco Systems. It provides functions for authentication, authorization, and encryption of the administrative traffic. Unlike RADIUS, it separates authentication and authorization functions. The SBC acts as a TACACS+ client.
The SBC uses TACACS+ services to provide administrative authorization. With TACACS+ authorization enabled, each individual ACLI command issued by an admin user is authorized by the TACACS+ authorization service. The SBC replicates each ACLI command in its entirety, sends the command string to the authorization service, and suspends command execution until it receives an authorization response. If TACACS+ grants authorization, the pending command is executed; if authorization is not granted, the SBC does not execute the ACLI command, and displays an appropriate error message.
All management stations used for SSH access should have a permit ACL configured. An ACL should also be configured to allow TACACS+ traffic to the Network Access Server. TACACS+ is disabled by default.
Refer to “TACACS+ AAA” in Section 2 “Getting Started” of the ACLI Configuration Guide.
Signaling and Media Interface Security Configuration
Securing the service interfaces is an important consideration because they are typically deployed in public unsecured networks and are usually the demarcation or access point to the core network infrastructure.
Signaling and Media Management Functions
The phy-card is intended for signaling and media traffic, only. The SBC disables ICMP, Telnet, SNMP, and FTP on signaling and media interfaces by default. Oracle recommends that you do not enable any of these protocols on a service interface for any length of time longer than required for troubleshooting purposes.
See “System Configuration” in the ACLI Configuration Guide.
SIP Interface Security
As well as the layer 3 ACLs, the SBC provides layer 5 SIP protection to its signaling interfaces. By default, the SBC sip-interface, sip-port parameter allows and routes signaling from any device.
- registered: This is the most widely deployed setting, allowing only non-REGISTER SIP requests from either a defined session-agent or a previously registered device. (All REGISTER requests are processed.)
- realm-prefix: Allows SIP requests only from defined session-agents or previously registered endpoints. Allows only REGISTER requests from endpoints within the configured realm-prefix (subnet).
Although SIP interface security will deny service to a malicious user, the SIP daemon and the core CPU is utilized to parse and process each request. Oracle recommends deploying this feature in conjunction with the Net-SAFE architecture.
For SIP-interfaces communicating with non-registering devices (peering partner SBCs or core devices such as softswitches), Oracle recommends that you set allow-anonymous for agents-only.
Oracle recommends that you configure an Enforcement Profile with the list of allowable SIP methods, and that you configure only the minimum set of SIP methods necessary for your deployment. You can configure more protection in Access scenarios where SIP endpoints send SUBSCRIBE dialogs. You can limit the rate of these messages per user.
Oracle recommends that you apply session constraints to the sip-interface to limit the max-sessions, max-burst-rate, max-sustain-rate, and rate constraints for individual method types. For more information, see Section 5.3 “Constraint Limiting” of “520-0013-05 TECH NOTE Theory of the Session-agent.”
The SBC default SIP routing behavior is to comply with Route headers, as received. This behavior leaves a security gap, where a trusted device can construct a Route header and use the SBC as a reflector for signaling to another known device. The SBC also uses the Request-URI to route traffic, even when there is no matching local policy. This is mitigated by using techniques such as stripping Route headers on ingress (proceed with caution) and configuring null routes with 0.0.0.0, as the next hop.
See “SIP Signaling Services” and “Session Routing and Load Balancing” in the ACLI Configuration Guide.
Service ACLs
ACLs on service ports provide more functions than the basic permit and deny operations provided by the ACLs on management ports. Service ACLs effect traffic management through average rate limitations, trust level, and signaling thresholds similar to those specified on a realm.
- Define an ACL for all peering partners and all core systems to which traffic will be routed. The ACL is used to permit trusted hosts, deny untrusted hosts, and guarantee bandwidth in peak periods.
- Note that the minimum-reserved-bandwidth setting does not permanently reserve bandwidth. The setting is used only in peak periods to prioritize traffic. Set the minimum-reserved-bandwidth to the maximum signaling bandwidth capable for the system. If more than one core device is used, divide the bandwidth number equally. The number is not really bandwidth, but a priority metric.
- Hosts with a trust levels of high will never be demoted or blacklisted. However, if an invalid-signal-threshold of one is configured on the ACL, a syslog event will be written which might help detect attempted abuse.
- The trust level specified on the ACL should match the trust level on the realm from which it will communicate. Trust level mismatches can have unintended consequences such as permitting traffic that is intended to be denied. Refer to the following scenario that illustrates how this can be problematic.
This scenario shows a trusted core PBX on a private network, and two
PBXs on an external public network. The trust level on the ACL applied to the
external interface and the trust level on the external realm are depicted in
the following tables, along with what happens to traffic sent from a source IP
of “.100” or “.111.” In the first table: IP .111 permitted in ACL, the effects
of having the 192.168.1.111 address permitted are depicted. The second table
shows the opposite, when the 192.168.1.111 address is denied. Note what access
the 192.168.1.100 address has is based on the trust level of the realm and
ACL.
Table 3-1 .111 permitted in ACL
| Realm Trust Level | ACL Trust Level | src:100 | src:111 |
|---|---|---|---|
| None | none | Permit | Permit |
| None | low | Deny | Permit |
| None | medium | Deny | Permit |
| None | high | Deny | Permit |
| Low | none | Permit | Permit |
| Low | low | Deny | Permit |
| Low | medium | Permit | Permit |
| Low | high | Permit | Permit |
| Medium | none | Permit | Permit |
| Medium | low | Permit | Permit |
| Medium | medium | Deny | Permit |
| Medium | high | Permit | Permit |
| High | none | Permit | Permit |
| High | low | Permit | Permit |
| High | medium | Permit | Permit |
| High | high | Deny | Permit |
Table 3-2 .111 denied in ACL
| Realm Trust Level | ACL Trust Level | src:100 | src:111 |
|---|---|---|---|
| None | none | Deny | Deny |
| None | low | Deny | Deny |
| None | medium | Deny | Deny |
| None | high | Deny | Deny |
| Low | none | Permit | Deny |
| Low | low | Permit | Deny |
| Low | medium | Permit | Deny |
| Low | high | Permit | Deny |
| Medium | none | Permit | Deny |
| Medium | low | Permit | Deny |
| Medium | medium | Permit | Deny |
| Medium | high | Permit | Deny |
| High | none | Permit | Deny |
| High | low | Permit | Deny |
| High | medium | Permit | Deny |
| High | high | Permit | Deny |
TLS for SIP
Transport Layer Security (TLS) provides end-to-end authentication and encryption of SIP signaling. TLS protects against eavesdropping, tampering, forgery, and potential theft of service. For this reason, Oracle recommends using TLS wherever possible.
All supported products have TLSv1.1 and TLS1.2.
The SBC supports mutual-authentication within a TLS profile. Although disabled by default, Oracle recommends enabling mutual-authentication when endpoints support it.
- Basic—The client authenticates the SBC certificate by using the CA public key, and checks expiration, common name, and ciphers supported. Basic provides confidentiality and integrity through encryption, but does not establish the identity of the endpoint. Credential cracking is still possible, and the move to TLS (based on TCP) may make port exhaustion DoS a bit easier for an attacker.
- Mutual—A step is added in which the client certificate is sent to the SBC for verification. You can use single or individual client certificates. Mutual provides the same characteristics of the basic model with the advantage of verifying that the client is likely trusted because an issued certificate is present. If a single certificate is used for all clients then theft or compromise of an endpoint may allow access to an attacker. Individual certificates are more secure, but require more administrative effort to issue and manage.
- Mutual with certificate revocation—Certificate revocation for individual clients is possible, which guarantees only expired or revoked clients are refused access. An external Online Certificate Status Protocol (OCSP) server is required to check against the Certificate Revocation List.
Note:
The SBC does not support local CRLs due to onboard storage limitations.- Certificates installed on the SBC must be derived from a local Certificate Signing Request in PKCS-10 PEM/Base 64 format. Certificates cannot be installed without a CSR.
- Certificate key lengths can go up to 2048 bits, with 4096 possible with SSM3 (currently on supported on 6300) after SC7.2.
- Certificates are currently signed with a SHA-1 hash by default. Oracle recommends signing with SHA-2 or above.
- If site-to-site failover is required, the main site’s fully qualified domain name (FQDN) and the FQDN for any alternate site should be specified as alternate-names in the certificate record prior to CSR generation.
- TLS session caching (tls-global element) allows a previously authenticated user to reuse a previous session so authentication is sped up. This may help reduce time to recovery due to outages, though it is best suited for environments where user IP does not vary significantly.
The list of available TLS ciphers is located in the Release Notes. The default cipher list when creating a tls-profile is "DEFAULT." The default list includes all current, secure ciphers. The "ALL" cipher list includes all available, non-debug ciphers, some of which may be potentially unsecure. The “NONE” cipher list does not provide encryption; only authentication.
- sip-config, inactive-dynamic-conn—Defines global timer for tearing down idle TCP and TLS connections where no SIP data has been sent. The timer used is twice as long for TLS.
- sip-interface settings to
limit connections:
- untrusted-conn-timeout—Closes socket if untrusted entity does not become trusted, such as if the register didn’t complete.
- inactive-conn-timeout—Tears down idle TCP/TLS connections when no further data is being sent, such as if a trusted host sends an INVITE but nothing else.
- max-incoming-conns—Set to max incoming sessions you want the SIP interface to host plus overhead for setup / teardown (depends on call rate).
- per-src-ip-max-incoming-conns—Usually 1 or 2 but affected by NAT use and application.
See “Security” in the ACLI Configuration Guide.
OCSP
The Online Certificate Status Protocol (OCSP) is defined in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. The protocol enables you to determine the revocation state of a specific certificate, and may provide a more efficient source of revocation information than is possible with Certificate Revocation Lists (CRL).
The protocol specifies the data exchanged between an OCSP client (such as the Oracle Communications SBC) and an OCSP responder, the Certification Authority (CA), or its delegate, that issued the target certificate. An OCSP client issues a request to an OCSP responder and suspends acceptance of the certificate in question until the responder replies with a certificate status. Certificate status is reported as
- good
- revoked
- unkown
OCSP can be especially useful in environments where individual certificates have been issued to a single user or user device. Certificates for devices that are stolen or misplaced can be revoked, so even if valid credentials are known the device will not be able to connect.
See “Security” in the ACLI Configuration Guide.
SRTP
Many customers require the ability to encrypt and authenticate the content and signaling of their real time communications sessions. The SBC supports the Secure Real-Time Transport Protocol (SRTP). Authentication provides assurance that packets are from the purported source, and that the packets have not been tampered with during transmission. Encryption provides assurance that the call content and associated signaling has remained private during transmission.
With two exceptions, SRTP requires an IPsec NIU. The 1100 and 3900 platforms support software-based SRTP.
RTP and RTCP traffic are encrypted as described in RFC 3711, The Secure Real-time Transport Protocol (SRTP). The negotiation and establishment of keys and other cryptographic materials that support SRTP is described in RFC 4568, Session Description Protocol (SDP) Security Description for Media Streams. Cryptographic parameters are established with only a single message or in single round-trip exchange using the offer–answer model defined in RFC 3264. An Offer–Answer Model with the Session Description Protocol (SDP).
See Appendix L: and “Security” in the ACLI Configuration Guide.
Securing Media Interfaces with IPsec
IPsec provides another mechanism for encrypting and securing media interface traffic, including SIP, RADIUS, etc, on supported platforms.
Security Associations and Security Policies allow for flexibility in defining local and remote IP address, ports and subnet masks. These should be defined to only allow IPsec communications between authorized gateways or hosts and the SBC.
The SBC supports IKE to create IPsec tunnels dynamically. This is based on the Internet Key Exchange (IKE) Protocol as defined in RFC5996 and RFC 2409, Internet Key Exchange, and for the Dead Peer Detection (DPD) protocol as defined in RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.
- IKE pre-shared secret support
- IKE/ISAKMP Main Mode support
- IKE/ISAKMP Aggressive Mode support
- Phase 2 Quick Mode support
- IKE pre-shared secret support
- X.509 certificate-based authentication
In addition, with IKE enabled, the SBC can support IPsec between itself and an endpoint behind a NAT device.
Oracle recommends you use IKEv2.. See “Security” in the ACLI Configuration Guide.
Call Admission Control
Call Admission Controls (CAC) limit the number of allowed resources such as bandwidth or sessions to abide by customer Service Level Agreements (SLA) and to avoid abuse. Oracle recommends that you enable the following features wherever possible:
- Bandwidth (codec) based—for bandwidth CAC settings see “Media Profiles”
- SIP Per-User CAC
- Session Capacity
- Session Rate (sustained and burst)
Bandwidth CAC
You can implement bandwidth based CAC through a media profile on the realm level. Media profiles specify or limit the range of the codecs, bandwidth, and packet rate used. See “Realms and Nested Realms” in the ACLI Configuration Guide.
SIP Per-User CAC
When you enable SIP per-user CAC, the SBC changes its default behavior to allow only the configured number of calls or total bandwidth to and from each individual user in a particular realm. You can apply CAC to an individual Address of Record (AoR) or IP address. Tracking based on IP address can cause complications when a NAT is involved, so the use of a nat-trust-threshold may be required to set the maximum number of untrusted endpoints behind NAT devices. This also enables the ability of the SBC to track endpoints based on both IP and the TCP or UDP port in use.
See “SIP Signaling Services” in the ACLI Configuration Guide.
Session Capacity and Session Rate using Constraints
Constraints is a CAC method that limits messaging based on session count and rate. You can apply constraints to SIP interfaces or realms. Oracle recommends using constraints on all external interfaces and core session-agents.
A session-agent can be configured for max-outbound-sessions, max-sessions, max-burst-rate and max-sustain-rate.
Max-outbound-sessions and max-sessions give the max number of allowed concurrent sessions. Set these to match what should be sent to an upstream session-agent (for example a service provider) or accepted into a core session-agent.
The session-agent's max-burst-rate and max-sustain-rate are used to throttle the calls per second (CPS) of traffic sent to and by that session-agent. Each of these parameters has its own configurable window by which the statistics are gauged for constraint exceptions.
For the sustained-rate, the average is calculated over the previous window (equal to the sustained-rate-window) and current window fragment. The window fragment will be between 0 and the configured sustained-rate-window upon receipt of an Invite. Once the window fragment increments and reaches the sustained-rate-window, this rotates and becomes the previous window -- and a new window fragment begins at 0. At this point all calculations are re-calibrated accordingly.
For example, consider the scenario where the sustain-rate is set to 15 and the sustain-rate-window is set to 10 seconds. When an invite is received the SD will add the amount of Invites received in the current window fragment and the previous window and divide by the number of seconds to get the average for that period. This average is then compared to the 15 CPS derived from the sustain-rate and the sustain-rate window. If the session-agent per the previous and current window is above 15 CPS when the Invite is received, the Invite will be rejected.
The max-burst-rate and burst-rate-window interact by limiting the CPS rate for a burst of traffic over the window. Using the example below, with a max-burst-rate of 20 and a burst-rate-window of 10, the SD will permit 200 sessions within the first 10 seconds and then reject all new sessions until it exits constraint mode.
Burst rate is much easier to understand and configure, so it is preferable over sustain rate.
As for a session-agent in constraint, it does not come out of constraint mode when traffic drops below its constraint thresholds; it comes out of constraint mode after 60 seconds, unless a configured time-to-resume value dictates otherwise. Even though the session-agent is out of the constraint mode after time-to-resume seconds “show sipd agent” will show it back into In-Service mode only if the traffic flows to or from that session-agent. On exceeding its constraint the session-agent is marked “C”.
Core registrars should have a max registration burst rate configured to the maximum rate (or just below) what the registrar can handle.
See “SIP Signaling Services” and “Admission Control and Quality of Service Reporting” in the ACLI Configuration Guide.
Media Policing
Media policing controls the throughput of individual session media flows (RTP and RTCP) in the SBC. It also allows the SBC to police static flows. Oracle recommends enabling media policing to protect against RTP media flooding and bandwidth piracy.
For each individual codec being used in sessions, a media-profile must be created with average-rate-limit thresholds configured.
See “Security” in the ACLI Configuration Guide.
DoS/DDoS Prevention
DoS and DDoS settings can protect against malicious and non-malicious SIP flooding attacks from untrusted sources without adversely affecting service to trusted peers.
You can prevent attacks through configuration of Access Control Lists, appropriately sized traffic queues, and trust level settings that limit or blacklist endpoints that become abusive.
Configuration of these parameters will differ based upon the configuration model used – peering, access, or hybrid. Refer to either Appendix C: DDoS Prevention for Peering Environments or Appendix D: DDoS Prevention for Access or Hybrid Environments, depending on the architectural model implemented.
Note:
Note that a comprehensive and effective DDoS prevention design requires analysis of traffic patterns, SIP message contents and performance characteristics of all peer devices to provide message thresholds, CAC, and traffic policing settings. Please contact your Oracle Sales representative for information on professional services designed to implement customized DDoS settings.Attack Tool Prevention
Many SIP scanning and attack tools employed by fraudsters can be prevented through employment of restrictive signaling thresholds and trust levels – the same ones used for DDoS protection. However, some deployments do not allow for this without impacting legitimate traffic. Attackers may also use commonly available tools that have identifiable signaling patterns. In these situations, additional attack tool identification and prevention may limit or prevent an attack from being successful.
Oracle recommends that any deployment with internet-connected interfaces comply with the settings described in Appendix E: Mitigating SIP Attacks.
Lawful Interception
Note:
LI applies to Service Provider products, only. Enterprise products do not support Lawful Interception.
