Supported Platforms

Observations/Limitations

The settings outlined in this appendix are beneficial when facing malicious or non-malicious flood attacks, such as a REGISTER avalanche following a network outage. By limiting the amount of untrusted traffic to the SBC, the registration rate allowed will be throttled and the SBC will not be overrun by the high rate of registrations. However, there is an opportunity cost between the level of protection against a DDoS flood attack and the convergence time for this type of avalanche condition. For example, raising the percentage of untrusted bandwidth allowed will inevitably allow more untrusted traffic to traverse the SBC, and minimize the convergence time. The opportunity cost here is higher CPU usage during the flood, a result of higher demand on the processor due to the increased level of registrations it's required to process.

Additionally, when set as an option in the sip-configuration, reg-overload-protect requires the SBC temporarily promote a registering endpoint upon receipt of a 401/407 response from the "real" registrar. This temporary promotion is in advance of the real and final promotion, which takes place following the 200 OK response to a REGISTER request containing authentication credentials. During a registration avalanche from untrusted sources, temporary promotion based on the initial REGISTER request sent from a specific source helps minimize the amount of time it will take to promote the collective untrusted sources, to trusted sources, effectively restoring service in the event of an outage as quickly as possible. This is also referred to as: minimizing the convergence time. The addition of any SIP option relevant to DDoS, including reg-overload-protect, would require additional testing. For customers with specific convergence requirements, additional research must be conducted to arrive at an appropriate DDoS configuration prior to deployment.

A limitation of the configuration parameters described in this appendix is the handling of SIP message spoofing. When a trusted user is "spoofed" by another user or a defective trusted user sends many SIP messages, the CPU utilization of the SBC may spike to 100%. One safe-guard implemented as part of this appendix is the establishment of a setting for maximum-signaling-threshold, defined in the realm-configuration object. When set, this provides an entry level amount of protection by removing a violating source from the trusted queue once the defined threshold is exceeded. To further handle this scenario, there are additional advanced DDoS configurations that can be set. For example: if the desired outcome is to deny violating sources from the hardware level, the access-control-trust-level should be set to low in the realm-configuration object. This also requires the configuration of the untrusted-signal-threshold to properly demote offending untrusted users to the deny list. If one wishes to move an endpoint back into the untrusted queue the access-control-trust-level of "medium" should be used.

The DDoS configuration recommendations in this appendix are meant as a general baseline to help protect the SBC from DDoS. For more complete protection, DDoS configurations should be determined by the examining the applicable environment and customizing based on the environment driven traffic flows and load levels.