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.