Configuration Parameters for DDoS Prevention in Peering Environments
The following sections will discuss those DDoS prevention parameters pertinent to the scope of this appendix. These parameters are found in three configuration areas: Media Manager, Realm Configuration, and SIP Interface.
Media Manager
The following media-manager parameters have been calculated for each configuration model.
- max-untrusted-signaling - Maximum percentage of the allocated max-signaling-bandwidth for untrusted traffic (%)
- min-untrusted-signaling - Minimum percentage of the allocated max-signaling-bandwidth for untrusted traffic (%)
- max-signaling-bandwidth - The maximum bandwidth that the SBC can withstand (bytes/sec)
Typically, these parameters are not applied in peering configuration as the source of peer traffic is assumed to be trusted. However, because these parameters values are set at default '0', with the purpose of maximizing the CPU resource for trusted traffic, it is suggested to minimize these values to '1' so that to guarantee optimal performance on trusted peer traffic.
The recommended values for these media-manager parameters for each test scenario are listed later by system model.
Max-signaling-bandwidth is not present /supported with Software Datapath (VM, COTS, 1100, 3900).
The following are Media Manager parameters that have platform specific defaults (not configurable). show acl info ACLI command shows the details from each platform.
- min-media-allocation
- min-trusted-allocation
- Deny-allocation
For this appendix, these defaults will be used and are indicated in the platform results later by system model.
Realm Configuration
The following realm-config parameters are used in the basic DDoS configuration.
| Parameter | Peer Realm | Core Realm |
|---|---|---|
| access-control-trust-level | high | High |
| invalid-signal-threshold | 0 | 0 |
| average-rate-limit | 0 | 0 |
| maximum-signal-threshold | 0 | 0 |
| untrusted-signal-threshold | 0 | 0 |
SIP Interface
The following sip-interface->sip-ports parameter SHOULD be used for Peering environments.
Setting "allow-anonymous" to agents-only will allow the SBC to reject requests sent by any IP which has not yet been defined as a "Session-Agent" in the SBC configuration. In Peering configurations, the customer SHOULD define each IP of a peer's device as a "session-agent" for optimal purpose.
| Parameter | Peer Realm | Core Realm |
|---|---|---|
| allow-anonymous | agents-only | All |
Although it is not recommended, but it is still possible to allow packets from an IP that has not yet defined as a Session-Agent, by setting "allow-anonymous" to "all". In this setup, the SBC will simply allow the request under DDoS threshold opposed to rejecting it with a 403 Forbidden response.
Session Agent and Access-Control
Any peering signaling device SHOULD be defined as a Session-Agent in SBC configuration. Further, for proper DDoS prevention, it requires explicitly configuring one access control per address of each Session-Agent address or other address (that has not yet been defined as a session-agent).
| Parameter | Realm |
|---|---|
| realm-id | peer |
| constraints | enabled (optional) |
| max-sessions | X |
| max-burst-rate | Y |
| max-sustain-rate | Z |
| time-to-resume | 60 sec |
| burst-rate-window | 1 sec |
| sustain-rate-window | 30 sec |
There is no demotion event when access-control-trust-level in the realm-config is set "high" as packets from the trusted peer endpoint are always allocated in the trusted queue for processing. It becomes a concern when there is excessive amount of SIP traffic sent by a customer which is beyond the SLA. Session constraints under session-agent can be deployed to further mitigate this problem. Listed above are a small set of constraints to provide basic level of call admission control in order to ensure that a session-agent's capacity is not exceeded, or the SBC will reject the service with 503 Service Unavailable. Please be advised that these settings are only optional. Customers may consider them when deploying their service in a Peering environment with or without DDoS configuration.
- max-sessions (X) - Define a maximum number of sessions (inbound and outbound) allowed by the session agent. Once the session limit is reached, the SBC will start rejecting new service with 503 Service Unavailable until the number of seconds in time-to-resume has elapsed.
- max-burst-rate (Y) - Define a number to set the maximum rate of call (per second) this session agent will allow. Once the rate limit is reached, the SBC will start rejecting new service with 503 Service Unavailable until the number of seconds in time-to-resume has elapsed.
- max-sustain-rate (Z) - In general, set this to the average call rate (per second) which that SA can sustain. Once the average rate limit calculated in (Calls made in current + previous window) / Delta (current second - start of previous window), exceeds the limit Z , the SBC will be start rejecting new service with 503 Service Unavailable until the number of seconds in time-to-resume has elapsed.
| Parameter | Realm | Realm |
|---|---|---|
| realm-id | peer | Core |
| source-address | n.n.n.n/[mask bit is optional] (peer SA IP, or non-SA IP) | [m.m.m.m]/ [mask bit is optional] (core SA IP or non-SA IP) |
| application-protocol | SIP | SIP |
| transport | ALL | ALL |
| access | permit | Permit |
| trust-level | high | High |
| minimum-reserved-bandwidth | 0 | 0 |
| invalid-signal-threshold | 0 | 0 |
| maximum-signal-threshold | 0 | 0 |
| untrusted-signal-threshold | 0 | 0 |
| deny-period | 30 | 30 |
In core realm, it is recommended to configure an access-control on per session-agent basis instead of putting it into a single source-subnet/mask. That will give the core session-agent its own flow versus sharing one flow for multiple devices or the entire subnet.