1. Configuration Guide
  2. Security
  3. Denial of Service Protection

Denial of Service Protection

This section explains the Denial of Service (DoS) protection for the Oracle Communications Session Border Controller. The Oracle Communications Session Border Controller DoS protection functionality protects softswitches and gateways with overload protection, dynamic and static access control, and trusted device classification and separation at Layers 3-5. The Oracle Communications Session Border Controller itself is protected from signaling and media overload, but more importantly the feature allows legitimate, trusted devices to continue receiving service even during an attack. DoS protection prevents the Oracle Communications Session Border Controller host processor from being overwhelmed by a targeted DoS attack from the following:

  • IP packets from an untrusted source as defined by provisioned or dynamic ACLs
  • IP packets for unsupported or disabled protocols
  • Nonconforming/malformed (garbage) packets to signaling ports
  • Volume-based attack (flood) of valid or invalid call requests, signaling messages, and so on.
  • Overload of valid or invalid call requests from legitimate, trusted sources

The following diagram illustrates DoS protection applied to the softswitch and to the Oracle Communications Session Border Controller.

DDoS protection on the SBC

Levels of DoS Protection

The multi-level Oracle Communications Session Border Controller DoS protection consists of the following strategies:

  • Fast path filtering/access control: access control for signaling packets destined for the Oracle Communications Session Border Controller host processor as well as media (RTP) packets. The Oracle Communications Session Border Controller performs media filtering by using the existing dynamic pinhole firewall capabilities. Fast path filtering packets destined for the host processor require the configuration and management of a trusted list and a deny list for each Oracle Communications Session Border Controller realm (although the actual devices can be dynamically trusted or denied by the Oracle Communications Session Border Controller based on configuration). You do not have to provision every endpoint/device on the Oracle Communications Session Border Controller, but instead retain the default values.
  • Host path protection: includes flow classification, host path policing and unique signaling flow policing. Fast path filtering alone cannot protect the Oracle Communications Session Border Controller host processor from being overwhelmed by a malicious attack from a trusted source. The host path and individual signaling flows must be policed to ensure that a volume-based attack will not overwhelm the Oracle Communications Session Border Controller’s normal call processing; and subsequently not overwhelm systems beyond it.

    The Oracle Communications Session Border Controller must classify each source based on its ability to pass certain criteria that is signaling- and application-dependent. At first each source is considered untrusted with the possibility of being promoted to fully trusted. The Oracle Communications Session Border Controller maintains two host paths, one for each class of traffic (trusted and untrusted), with different policing characteristics to ensure that fully trusted traffic always gets precedence.

  • Host-based malicious source detection and isolation – dynamic deny list. Malicious sources can be automatically detected in real-time and denied in the fast path to block them from reaching the host processor.

About the Process

DoS attacks are handled in the Oracle Communications Session Border Controller’s host path. The Oracle Communications Session Border Controller uses NAT table entries to filter out undesirable IP addresses; creating a deny list. After a packet from an endpoint is accepted through NAT filtering, policing is implemented in the Traffic Manager subsystem based on the sender’s IP address. NAT table entries distinguish signaling packets coming in from different sources for policing purposes. The maximum number of policed calls that the Oracle Communications Session Border Controller can support is 16K (on 32K CAM / IDT CAM).

The Traffic Manager has two pipes, trusted and untrusted, for the signaling path. Each signaling packet destined for the host CPU traverses one of these two pipes.

Traffic Manager's trusted and untrusted pipes

Trusted Path

Packets from trusted devices travel through the trusted pipe in their own individual queues. In the Trusted path, each trusted device flow has its own individual queue (or pipe). The Oracle Communications Session Border Controller can dynamically add device flows to the trusted list by promoting them from the Untrusted path based on behavior; or they can be statically provisioned.

Trusted traffic is put into its own queue and defined as a device flow based on the following:

  • source IP address
  • source UDP/TCP port number
  • destination IP address
  • destination UDP/TCP port (SIP interface to which it is sending)
  • realm it belongs to, which inherits the Ethernet interface and VLAN it came in on

For example, SIP packets coming from 10.1.2.3 with UDP port 1234 to the Oracle Communications Session Border Controller SIP interface address 11.9.8.7 port 5060, on VLAN 3 of Ethernet interface 0:1, are in a separate Trusted queue and policed independently from SIP packets coming from 10.1.2.3 with UDP port 3456 to the same Oracle Communications Session Border Controller address, port and interface.

Data in this flow is policed according to the configured parameters for the specific device flow, if statically provisioned. Alternatively, the realm to which endpoints belong have a default policing value that every device flow will use. The defaults configured in the realm mean each device flow gets its own queue using the policing values. As shown in the previous example, if both device flows are from the same realm and the realm is configured to have an average rate limit of 10K bytes per second (10KBps), each device flow will have its own 10KBps queue. They are not aggregated into a 10KBps queue.

The individual flow queues and policing lets the Oracle Communications Session Border Controller provide each trusted device its own share of the signaling, separate the device’s traffic from other trusted and untrusted traffic, and police its traffic so that it can’t attack or overload the Oracle Communications Session Border Controller (therefore it is trusted, but not completely).

Address Resolution Protocol Flow

The Address Resolution Protocol (ARP) packets are given their own trusted flow with the bandwidth limitation of 8 Kbps. ARP packets are able to flow smoothly, even when a DoS attack is occurring.

Untrusted Path

Packets (fragmented and unfragmented) that are not part of the trusted or denied list travel through the untrusted pipe. In the untrusted path, traffic from each user/device goes into one of 2048 queues with other untrusted traffic. Packets from a single device flow always use the same queue of the 2048 untrusted queues, and 1/2048th of the untrusted population also uses that same queue. To prevent one untrusted endpoint from using all the pipe’s bandwidth, the 2048 flows defined within the path are scheduled in a fair-access method. As soon as the Oracle Communications Session Border Controller decides the device flow is legitimate, it will promote it to its own trusted queue.

All 2048 untrusted queues have dynamic sizing ability, which allows one untrusted queue to grow in size, as long as other untrusted queues are not being used proportionally as much. This dynamic queue sizing allows one queue to use more than average when it is available. For example, in the case where one device flow represents a PBX or some other larger volume device. If the overall amount of untrusted packets grows too large, the queue sizes rebalance, so that a flood attack or DoS attack does not create excessive delay for other untrusted devices.

In the usual attack situations, the signaling processor detects the attack and dynamically demotes the device to denied in the hardware by adding it to the deny ACL list. Even if the Oracle Communications Session Border Controller does not detect an attack, the untrusted path gets serviced by the signaling processor in a fair access mechanism. An attack by an untrusted device will only impact 1/1000th of the overall population of untrusted devices, in the worst case. Even then there’s a probability of users in the same 1/1000th percentile getting in and getting promoted to trusted.

IP Fragment Packet Flow

All fragment packets are sent through their own 1024 untrusted flows in the Traffic Manager. The first ten bits (LSB) of the source address are used to determine which fragment-flow the packet belongs to. These 1024 fragment flows share untrusted bandwidth with already existing untrusted-flows. In total, there are 2049 untrusted flows: 1024-non-fragment flows, 1024 fragment flows, and 1 control flow.

Fragmented ICMP packets are qualified as ICMP packets rather than fragment packets. Fragment and non-fragmented ICMP packets follow the trusted-ICMP-flow in the Traffic Manager, with a bandwidth limit of 8Kbs.

Fragment Packet Loss Prevention

You can set the maximum amount of bandwidth (in the max-untrusted-signaling parameter) you want to use for untrusted packets. However, because untrusted and fragment packets share the same amount of bandwidth for policing, any flood of untrusted packets can cause the Oracle Communications Session Border Controller to drop fragment packets.

To prevent fragment packet loss on the Acme Packet 3820 and Acme Packet 4500, you can set the fragment-msg-bandwidth. When you set any value other than 0 (which disables it), the Oracle Communications Session Border Controller:

  • Provides for a separate policing queue for fragment packets (separate from that used for untrusted packets)
  • Uses this new queue to prevent fragment packet loss when there is a flood from untrusted endpoints.

When you set up a queue for fragment packets, untrusted packets likewise have their own queue—meaning also that the max-untrusted-signaling and min-untrusted-signaling values are applied to the untrusted queue.

Static and Dynamic ACL Entry Limits

When deployed over its own hardware, the Oracle Communications Session Border Controller can simultaneously police a maximum of 250,000 trusted device flows, while at the same time denying an additional 32,000 attackers. If list space becomes full and additional device flows need to be added, the oldest entries in the list are removed and the new device flows are added.

Static Trusted and Untrusted ACL Limits for vSBC and vSR

When deployed as a Virtual SBC or a Virtual SR, the SBC supports static ACL entry counts based on virtual machine memory. Deployments under 8G of memory support 8K trusted and 4K untrusted entries. When memory is:

  • Between 8G and 64G, supported entries include:
    • Trusted static ACLs is 1024 per Gig
    • Untrusted static ACLs is 512 per Gig
  • Greater than 64G, supported entries include:
    • Trusted static ACLs is 65536
    • Untrusted static ACLs is 32768

Note:

Dynamic ACL entries are independent of this support.

System capacities vary across the range of platforms that support the SBC. To query the current system capacities for the platform you are using, execute the show platform limits command.

Dynamic Deny for HNT

Dynamic deny for HNT has been implemented on the Oracle Communications Session Border Controller for cases when callers are behind a NAT or firewall. Without this feature, if one caller behind a NAT or firewall were denied, the Oracle Communications Session Border Controller would also deny all other users behind the same NAT or firewall. This would be true even for endpoints behind the firewall that had not crossed threshold limits you set for their realm; all endpoints behind the firewall would go out of service. In the following diagram, both Phone A and Phone B would be denied because their IP addresses would be translated by the firewall to the same IPv4 address (192.168.16.2).

However, dynamic deny for HNT allows the Oracle Communications Session Border Controller to determine, based on the UDP/TCP port, which endpoints should be denied and which should be allowed. The Oracle Communications Session Border Controller can determine that even though multiple endpoints originating behind a firewall appear with the same IPv4 address, those addresses use different ports and are unique.

As shown in the diagram below, the ports from Phone A and Phone B remain unchanged. This way, if Phone A violates the thresholds you have configured, the Oracle Communications Session Border Controller can block traffic from Phone A while still accepting traffic from Phone B.

The Dynamic Deny for HNT diagram is described above.

Host and Media Path Protection Process

The Oracle Communications Session Border Controller Network Processors (NPs) check the deny and permit lists for received packets, and classify them as trusted, untrusted or denied (discard). Only packets to signaling ports and dynamically signaled media ports are permitted. All other packets sent to Oracle Communications Session Border Controller ports are filtered. Only packets from trusted and untrusted (unknown) sources are permitted; any packet from a denied source is dropped by the NP hardware. The Traffic Manager manages bandwidth policing for trusted and untrusted traffic, as described earlier. Malicious traffic is detected in the host processor and the offending device is dynamically added to denied list, which enables early discard by the NP. Devices become trusted based on behavior detected by the Signaling Processor, and dynamically added to the trusted list. This process enables the proper classification by the NP hardware. All other traffic is untrusted (unknown).

SBC Access Control

You an create static trusted/untrusted/deny lists with source IP addresses or IP address prefixes, UDP/TDP port number or ranges, and based on the appropriate signaling protocols. Furthermore, the Oracle Communications Session Border Controller can dynamically promote and demote device flows based on the behavior, and thus dynamically creates trusted, untrusted, and denied list entries.

Access Control for Hosts

ACLs are supported for all VoIP signaling protocols on the Oracle Communications Session Border Controller: SIP and H.323. The Oracle Communications Session Border Controller loads ACLs so they are applied when signaling ports are loaded. The following rules apply to static NAT entries based on your configuration:

  • If there are no ACLs applied to a realm that have the same configured trust level as that realm, the Oracle Communications Session Border Controller adds a default NAT entry using the realm parameters.
  • If you configure a realm with none as its trust level and you have configured ACLs, the Oracle Communications Session Border Controller only applies the ACLs.
  • If you set a trust level for the ACL that is lower than the one you set for the realm, the Oracle Communications Session Border Controller will not add a separate NAT entry for the ACL.

ACLs provide access control based on destination addresses when you configure destination addresses as a way to filter traffic. You can set up a list of access control exceptions based on the source or the destination of the traffic.

For dynamic ACLs based on the promotion and demotion of endpoints, the rules of the matching ACL are applied.

Access Control Endpoint Classification Capacity and DoS

To view endpoint classification capacity limits for your current platform, use the show platform limits command. The output is dependent on the combination of hardware and software you are running.

Media Access Control

The media access control consists of media path protection and pinholes through the firewall. Only RTP and RTCP packets from ports dynamically negotiated through signaling (SIP and H.323) are allowed, which reduces the chance of RTP hijacking. Media access depends on both the destination and source RTP/RTCP UDP port numbers being correct, for both sides of the call.

Host Path Traffic Management

The host path traffic management consists of the dual host paths discussed earlier:

  • Trusted path is for traffic classified by the system as trusted. You can initially define trusted traffic by ACLs, as well as by dynamically promoting it through successful SIP registration, or a successful call establishment. You can configure specific policing parameters per ACL, as well as define default policing values for dynamically-classified flows. Traffic for each trusted device flow is limited from exceeding the configured values in hardware. Even an attack from a trusted, or spoofed trusted, device cannot impact the system.
  • Untrusted path is the default for all unknown traffic that has not been statically provisioned otherwise. For example, traffic from unregistered endpoints. Pre-configured bandwidth policing for all hosts in the untrusted path occurs on a per-queue and aggregate basis.

Traffic Promotion

Traffic is promoted from untrusted to trusted list when the following occurs:

  • successful SIP registration for SIP endpoints
  • successful session establishment for SIP calls

Malicious Source Blocking

Malicious source blocking consists of monitoring the following metrics for each source:

  • SIP transaction rate (messages per second)
  • SIP call rate (call attempts per second)
  • Nonconformance/invalid signaling packet rate

Device flows that exceed the configured invalid signaling threshold, or the configured valid signaling threshold, within the configured time period are demoted, either from trusted to untrusted, or from untrusted to denied classification.

Blocking Actions

Blocking actions include the following:

  • Dynamic deny entry added, which can be viewed through the ACLI.
  • SNMP trap generated, identifying the malicious source

Dynamically added deny entries expire and are promoted back to untrusted after a configured default deny period time. You can also manually clear a dynamically added entry from the denied list using the ACLI.

Protecting Against Session Agent Overloads

You can prevent session agent overloads with registrations by specifying the registrations per second that can be sent to a session agent.

ARP Flood Protection Enhancements

Enhancements have been made to the way the Oracle Communications Session Border Controller provides ARP flood protection. In releases prior to Release C5.0, there is one queue for both ARP requests and responses, which the Oracle Communications Session Border Controller polices at a non-configurable limit (eight kilobytes per second). This method of ARP protection can cause problems during an ARP flood, however. For instance, gateway heartbeats the Oracle Communications Session Border Controller uses to verify (via ARP) reachability for default and secondary gateways could be throttled; the Oracle Communications Session Border Controller would then deem the router or the path to it unreachable, decrement the system’s health score accordingly. Another example is when local routers send ARP requests for the Oracle Communications Session Border Controller’s address are throttled in the queue; the Oracle Communications Session Border Controller never receives the request and so never responds, risking service outage.

The solution implemented to resolve this issue is to divide the ARP queue in two, resulting in one ARP queue for requests and a second for responses. This way, the gateway heartbeat is protected because ARP responses can no longer be flooded from beyond the local subnet. In addition, the Oracle Communications Session Border Controllers in HA nodes generate gateway heartbeats using their shared virtual MAC address for the virtual interface.

In addition, this solution implements a configurable ARP queue policing rate so that you are not committed to the eight kilobytes per second used as the default in prior releases. The previous default is not sufficient for some subnets, and higher settings resolve the issue with local routers sending ARP request to the Oracle Communications Session Border Controller that never reach it or receive a response.

As a security measure, in order to mitigate the effect of the ARP table reaching its capacity, configuring the media-manager option, active-arp, is advised. Enabling this option causes all ARP entries to get refreshed every 20 minutes.

Dynamic Demotion for NAT Devices

In addition to the various ways the Oracle Communications Session Border Controller already allows you to promote and demote devices to protect itself and other network elements from DoS attacks, it can now block off an entire NAT device. The Oracle Communications Session Border Controller can detect when a configurable number of devices behind a NAT have been blocked off, and then shut off the entire NAT’s access.

This dynamic demotion of NAT devices can be enabled for an access control (ACL) configuration or for a realm configuration. When you enable the feature, the Oracle Communications Session Border Controller tracks the number of endpoints behind a single NAT that have been labeled untrusted. It shuts off the NAT’s access when the number reaches the limit you set.

The demoted NAT device then remains on the untrusted list for the length of the time you set in the deny-period.

DoS Counter Notifications

The SBC provides ACL and DDOS statistics that track events for ARP, trusted, and untrusted traffic. These statistics include notifications about ARP watermarks and trusted and untrusted queue metrics to provide visibility into traffic management rates, based on traffic patterns in normal and peak times. You configure these thresholds as a percentage of the configured traffic rates within the media-manager configuration element. This provides you with early notification of traffic congestion so you can better tune the global media settings for DDOS. The SBC does not drop the packets affected through threshold events. Instead, it forwards them to a traffic manager for making permit/drop decisions prior to sending it to the host. In addition to host bound events, the SBC generates SMNP traps and alarms for TCAs that monitor ARP, trusted, untrusted and max-signaling rates. You can collect statistics on related traffic using the ACLI, SNMP walks, HDR and REST.

Threshold boundary configurations per counter type (ARP, untrusted and trusted) are configuration in the media-manager element. You perform this configuration within the media-manager element. These thresholds allow you to establish minor, major and critical levels upon which you receive notifications.

For example, a SBC, when configured with a max-signaling committed rate of 1MB/sec, and a trusted rate of 90%, allows up to 3 threshold levels from 8K – 800K (10% below the trusted drop rate of 900K in this example). You may configure watermark levels of, for example, 50% and 75% to notify you that the media manager settings for this peak rate of traffic may be insufficient.

You can retrieve these configurations using the show dos threshold command, which includes further command arguments to see more specific information. You can also configure the SBC to capture event counters using SNMP, HDR, and REST.

Statistics Output on the ACLI

You use the show dos threshold counters command to display DOS and ACL statistics, immediate threshold level alarms and the number of times each state changes. The Cleared column presents the number of times the DOS threshold dropped below its water mark since the last time the DOS timer fired. 

ORACLE# show dos threshold counters    
Traffic              Current Threshold level
Trusted traffic      No threshold crossed
Untrusted traffic    No threshold crossed
ARP traffic          Major threshold
Counters             ---------Lifetime ---------                     
                     Overloaded          Cleared
     ARP minor            574                0
     ARP major            574                0
     ARP critical         325               60
     untrusted minor      30                 3
     untrusted major      30                 3
     untrusted critical   24                 2
     trusted minor        28                 3
     trusted major        28                 3
     trusted critical     27                 3

Additional arguments to this command includes show dos threshold reset, which resets the dos threshold counters.

SNMP

The SBC provides the same data via SNMP using the DoS threshold counter objects within the ap-apps.mib. Similar to the CLI stats, these objects provide counters for the number of times traffic crosses each threshold.

See the SBC MIB Reference Guide for further detail about SNMP function, configuration, and DoS threshold OID detail.

HDR

You can also use the HDR group, dos-threshold-counters, to retrieve the same counter statistics available using the ACLI and SNMP. These objects provide counters for the number of times traffic crosses each threshold.

See the SBC HDR Resource Guide for further detail about HDR function, configuration, and DoS traffic objects.

REST API Interface

The SBC includes a KPI type called dosThresholdCounters that includes further objects you use to get the number of times the statistic crosses the applicable threshold. These counters are available from the Statistics' REST endpoints.

  • trustedMinorCounter—Counter incremented when trusted bandwidth crossed the minor threshold percentage
  • trustedMajorCounter—Counter incremented when trusted bandwidth crossed the major threshold percentage
  • trustedCriticalCounter—Counter incremented when trusted bandwidth crossed the critical threshold percentage
  • untrustedMinorCounter—Counter incremented, when untrusted bandwidth crossed the minor threshold percentage
  • untrustedMajorCounter—Counter incremented, when untrusted bandwidth crossed the major threshold percentage
  • untrustedCriticalCounter—Counter incremented, when untrusted bandwidth crossed the critical threshold percentage
  • arpMinorCounter—Counter incremented, when arp bandwidth crossed the minor threshold percentage
  • arpMajorCounter—Counter incremented, when arp bandwidth crossed the major threshold percentage
  • arpCriticalCounter—Counter incremented, when arp bandwidth crossed the critical threshold percentage

See the SBC REST API Documentation for further detail about these DoS threshold counters.

DDoS Alarms and SNMP Traps

Alarms on DoS threshold traffic are tightly aligned with SNMP traps. The SBC issues both simultaneously when the applicable traffic, trusted, untrusted or arp, exceed your configured thresholds. They both also clear as soon as the traffic falls below that threshold.

The SBC sends two SNMP traps that alert you when traffic crosses each threshold, and clear when the traffic falls back below the threshold:

  • apDosThresholdCrossTrap
  • apDosThresholdClearTrap

These traps break out into additional SNMP objects, one to specify the traffic type and one to specify the threshold cross status. You can see traffic type from the apDosThresholdTraffic object; a second object identifies cross status. The values that specify the detail include:

  • apDosThresholdTraffic—Three types of possible values. (1 = trusted, 2 = untrusted , 3 = ARP)
  • apDosThresholdMinorCrossed—Two types of possible values (0 = threshold not crossed, 1 = threshold crossed)
  • apDosThresholdMajorCrossed—Two types of possible values (0 = threshold not crossed, 1 = threshold crossed)
  • apDosThresholdCriticalCrossed—Two types of possible values (0 = threshold not crossed, 1 = threshold crossed)

The example below indicates that ARP traffic has exceeded your minor threshold:

  • apDosThresholdTraffic—Set to 3
  • apDosThresholdMinorCrossed—Set to 1

Similarly, the SBC issues alarms to present this same detail to you. These alarms align with the systems traffic queues, and include include:

  • Trusted traffic crosses DOS threshold
  • Untrusted traffic crosses DOS threshold
  • ARP traffic crosses DOS threshold

Unlike SNMP, these present type and 'threshold crossed' in a single alarm object.

DoS Protection at the Session Level

You can configure the SBC to implement DoS protection when any individual session appears to be conducting an attack. You can configure this protection on a realm-config or a session-agent, with the session-agent configuration taking precedence when applicable.

Without this feature, the SBC does not prevent cases where traffic overload or malicious attacks are generated by a trusted source IP within the context of an active session. The system simply forwards as much of this traffic as the system’s hardware and software capabilities can support.

Furthermore, the system normally does not demote any source IP when you configure the access-control-trust-level parameter in the applicable realm-config to high. Instead, the system allocates all of these packets to the trusted queue for processing.

This feature extends upon the system's existing DoS Prevention functionality by providing DoS attack detection and mitigation at the session level for an endpoint, thereby providing:

  • Session-based protection against traffic overload and malicious attacks sourced from trusted access or core devices in realms where you have configured the access-control-trust-level to high.
  • The implementation for preventing DoS attack especially from trusted parties on the core side of the system.

    The system triggers this DOS attack protection based on the rate of request/responses received per session and takes appropriate action, using your DOS configuration.

    With this feature enabled, the system can take action on the existing session only, rather than blocking the entire endpoint for further calls.

You enable this feature using the dos-action-at-session parameter, which allows you to specify the desired behavior, including:

  • Terminate sessions that are generating a detected DoS attack
  • Temporarily demote the endstation that is generating a detected DoS attack to untrusted and terminate that session. The system uses the untrusted queue for any further traffic from that system and promotes the system back to trusted after the standard demotion processes expire.
  • Demote the endstation that is generating a detected DoS attack to untrusted and terminate that session. If the system detects a subsequent DoS attack before promoting that endstation back to trusted, the system further demotes that endstation to the denied state. The system waits for the deny timer to expire, then promotes the endstation to untrusted, then promotes the system back to trusted after the standard demotion processes expire.

Note:

The system does not perform this feature's functionality if the attacking endpoint is behind a NAT.

Processing Session Based DoS Attacks

When the SBC receives an initial request, it creates a new session. The SBC processes session based DoS attack mitigation for all endstations with a trust level of high using the steps below:

  1. Identifies the associated endstation (or session agent) and realm for that session to monitor the traffic level.
  2. Creates an address variable for that endstation (or session agent) and sets the default state of that variable to permit that traffic through the trusted queue (MBCD_ACL_PERMIT).
  3. Tracks the burst rate of incoming requests and responses for that session.

    You configure packet rate and monitoring window size for a session at either session-agent or realm-config using the max-inbound-per-session-burst-rate and burst-rate-window-per-session parameters. For each session, the system maintains separate counters for ingress and egress endpoints. For this feature, the system calculates the packet rate of the received messages for a configured time period.

  4. Detects a DoS attack when a request or response rate in a session exceeds the configured max-inbound-per-session-burst-rate threshold value.
  5. Performs DoS mitigation per your configuration.

When the DoS attack is detected from either the ingress or egress endpoint in a session, the SBC controls the DoS attack in that session based on call state:

  • If the call is already established in a session when the DoS attack occurs, the SBC terminates the session by sending a BYE to both the UAC and UAS side.

    For forked calls, if the ingress UAC initiates a DoS attack at session, the SBC terminates the call by sending a 503 error response towards the UAC and a CANCEL towards all the forked UAS endpoints.

  • If the call session is in connecting state and the SBC has received only 1xx responses when the DoS attack occurs, the SBC disconnects the session by sending a CANCEL request towards the terminating UE side and a “503 DDoS Request Cancelled" response towards the originating UE side.

    Although there are multiple egress dialogs or multiple egress endpoints involved in a forked call, if the system detects a DoS attack within one of these sessions, it terminates the entire call session.

    For forked calls, the SBC only demotes the egress endpoint that initiates the DoS attack.

The SBC makes further decisions to demote or deny the IP address based on the applicable dos-action-at-session parameter setting. Behavior is further refined based on whether you have configured the feature at the session-agent or the realm-config.

  • If the value of dos-action-at-session is permit, the SBC can demote the endpoint from trusted to untrusted. If the DoS attack resumes, the system can then deny all traffic from the endpoint until the deny-period timer expires:
    1. If the endpoint makes the first DoS attack in a session, the system demotes this endpoint to the untrusted queue and starts the promotion timer, “UNTRUST_TMO timer”, which lasts for 180 seconds. The system sends all of that session's traffic through the untrusted queue.
    2. If the UNTRUST_TMO timer expires and there is no DoS attack in that time-period, then the system promotes that endpoint back to the trusted list.

      If the endpoint executes another session level DoS attack within the 180 second timer window, the system further demotes that endpoint from untrusted to the deny list, and starts your configured deny-period timer.

    3. The system drops all requests or responses from a denied endpoint.
    4. The system promotes the endpoint back to the untrusted list from denied list when the deny-period timer expires.
    5. The system promotes the endpoint back to the trusted from the untrusted list when the UNTRUST_TMO timer expires.
  • If the value of dos-action-at-session is no-deny, the SBC can demote the endpoint, but cannot deny the endpoint.
    1. If the endpoint sends messages that cross the DoS thresholds within a session, the SBC demotes the endpoint from trusted to untrusted queue and terminates the current session.

      At this point, the SBC can accept new calls from that endpoint.

      The SBC handles these calls through the untrusted queue, even though the access-control-trust-level is high, until the UNTRUST_TMO timer expires at 180 seconds

    2. When the UNTRUST_TMO timer expires, the SBC moves the endpoint back to the trusted list.
  • If the value of dos-action-at-session is session-drop, the SBC does not demote or deny the trusted endpoint. Instead, the SBC terminates the current DOS session and allows new calls from this trusted endpoint.
  • The dos-action-at-session parameter has an additional value, inherit, when configured at a session-agent. You use this value to instruct the session-agent to inherit its behavior from the max-inbound-per-session-burst-rate, burst-rate-window-per-session and dos-action-at-session settings on the realm-config.

    If dos-action-at-session at the realm-config is none, there is no inheritance process.

When the SBC receives multiple INVITE requests from an endpoint within the same timeframe, it saves the current DoS state. This prevents the system from repeating the same DoS action for each session initiated within that timeframe.

If you have configured the feature to inherit or no-deny and a trusted endpoint sends multiple initial INVITEs requests that eventually lead to a DoS attack, the SBC moves the endpoint from trusted to untrusted during first call’s DoS detection. For all the other INVITE sessions, the system takes no further action because the endpoint is already moved to the untrusted state. The system terminates these calls based on the current DoS state.

The table below presents actions the SBC takes when applying this feature to mitigate a DoS attack perpetrated within a normal call.

Request DOS attack Response DOS attack Action at originating UAC (ingress side) Action at terminating UAS (egress side)
PRACK, UPDATE or any subsequent request DoS attack from originating UE N/A Send 503 response towards originating UAC Send CANCEL towards terminating UAS
N/A 200 OK of PRACK, UPDATE or any subsequent request’s response DOS attack from terminating UE Send 503 response towards originating UAC Send CANCEL towards terminating UAS
UPDATE or any subsequent request DoS attack from terminating UE N/A Send 503 response towards originating UAC

Send CANCEL towards terminating UAS.
N/A 200 OK of UPDATE or any subsequent request’s response DoS attack from originating UE Send 503 response towards originating UAC Send CANCEL towards terminating UAS
N/A 18x response of INVITE DOS attack from terminating UE Send 503 response towards originating UAC Send CANCEL towards terminating UAS
N/A 200 OK response of INVITE DOS attack from terminating UE Send BYE towards originating UAC

• First send the ACK.

• Send BYE towards terminating UAS
Re-INVITE DoS attack from originating UE N/A Send BYE towards originating UAC Send BYE towards terminating UAS
N/A 200 OK of re-INVITE DoS attack from term UE Send BYE towards originating UAC Send BYE towards terminating UAS
Re-INVITE DoS attack from terminating UE N/A Send BYE towards originating UAC Send BYE towards terminating UAS
N/A 200 OK of re-invite DOS attack from originating UE Send BYE towards originating UAC SEND BYE towards terminating UAS

Reporting

This feature generates SNMP standard traps and updates the applicable statistic counters when it demotes an endstation from trusted to untrusted and from untrusted to deny. You must enable the trap-on-demote-to-deny and trap-on-demote-to-untrusted parameters in “media-manager-config to get the traps.

When the system generates these traps based on this feature, it uses the following reason strings:

  • If dos-action-at-session is permit, the reason string is “Too many in session (permit) inbound messages”.
  • If dos-action-at-session is no-deny, the reason string is “Too many in session (nodeny) inbound messages”.

Session Based DoS Protection and Static ACLs

Static ACLs, which can have a trust level of none (default), low, medium or high, interact with this feature based on their and their respective realm's trust levels:

  • Static ACLs and their Realms trust level is low/medium—Static ACLs at these levels follow standard DoS operation regardless of your dos-action-at-session configuration. The system does not monitor these ACLs SigAddress at the session level.
  • Static ACLs and their Realm's trust level is high—This configuration is not recommended. In these cases, you should delete these ACLs. After deletion, your dos-action-at-session configuration applies to the entire realm.
  • Static ACLs trust level is high and their Realm's trust level is low/medium—Your dos-action-at-session configuration is not applicable.

The following table explains whether or not this DoS feature is applicable based on the trust levels or your static ACLs and their applicable realms:

Access-control trust level (Static ACL) Realm-config trust level DDoS feature at session (dos-action-at-session parameter value) DoS detected on the ACL IP DoS detected on the Other IP Comments
high low OFF NO YES (Standard) Set dos-action-at-session to none
low high ON YES (Standard) Yes (Session)
high low OFF NO YES (Standard) Referring to the row above, the trust-level of above ACL was modified from low to high, trust-level of realm was modified from high to low, dos-action-at-session was set to none and SBC was not rebooted
delete ACL high ON YES (Session) Yes (Session) Referring to the two rows above, the ACL was deleted and SBC was not rebooted
high high ON Configuration not recommended Configuration not recommended It is not recommended to set the trust-level of both ACL and realm as high together, because of a legacy issue resulting in dead calls
delete ACL high ON YES (Session) Yes (Session) Referring to the row above, the ACL was deleted and SBC was not rebooted
low high ON YES (Standard) Yes (Session) Referring to the two rows above, the trust-level of above ACL was modified from high to low and SBC was not rebooted
off (not configured) low OFF YES (Standard) YES (Standard) Set dos-action-at-session to none
off (not configured) high ON YES (Session) YES (Session)

Session Based DoS Mitigation Examples

This section presents specific examples of the SBC performing session-based DoS mitigation.

The examples below presents the SBC performing Session Based DoS mitigation at the inbound and the outbound side of a session.

DOS Attack at the Ingress

When an endpoint sends an initial INVITE request to the SBC, it creates a new session. For every request or response received at the ingress side in the particular session, the system increments the ingress packet count for that session.

The SBC increments the ingress count counter until the burst-rate-window-per-session timer configured expires.

If the ingress count in a session reaches the threshold value, which you configure at either the realm-config or session-agent using the max-inbound-per-session-burst-rate parameter, the SBC detects traffic exceeding that value as a DOS attack from trusted endpoint.

The system resets the ingress count to 0 after the burst-rate-window-per-session timer window times out. The burst-rate-window-per-session timer window runs in a loop and the system monitors the ingress packet counters in that time frame against the threshold value.

The image below shows the SBC performing this feature with the max-inbound-per-session-burst-rate set to 50.

This image depicts the system reacting to a session-based DOS attack at the ingress

DOS Attack at the Egress

If the egress endpoint is trusted and is executing a DOS attack by pumping multiple requests/responses in a call, the SBC detects this attack at the session level.

The SBC associates any response to initial INVITE, or any subsequent request received at the egress side of a call with an existing session. It increments the egress count for that session for every request or response it receives at the egress side. The SBC increments this egress counter until the burst-rate-window-per-session timer expires. If this count reaches the maximum threshold value within that window, the SBC flags that call as generating a DOS attack.

The system resets the egress count to 0 after the burst-rate-window-per-session timer expires. For the duration of the session, the burst-rate-window-per-session timer window runs in a loop, and the system monitors the egress packet counters in that time frame against the threshold value.

The image below shows the SBC performing this feature with the max-inbound-per-session-burst-rate set to 50.

This image depicts the system reacting to a session-based DOS attack at the egress.

Session Based DOS Mitigation Configuration

You can configure this feature on an applicable realm-config or session-agent. The dos-action-at-session parameter is key to understanding and specifying operation of this feature.

Example syntax for the dos-action-at-session parameter on a realm is presented below. 

ORACLE(realm-config)#dos-action-at-session no-deny

Two other realm-config parameters, which the system uses for security functions, are also required for this feature:

  • You must set access-control-trust-level for the realm-config to high. This feature is not applicable for realms where access-control-trust-level is none, medium or low.

    If configuring dos-action-at-session on a session-agent, that agent must be associated with a realm that has access-control-trust-level set to high

  • You must set the deny-period for the realm-config. This feature uses this value as the timer that specifies the length of time before denied endpoints can try to start sessions again.

Required parameters that apply only to this feature include:

  • dos-action-at-session—Defines the feature mode for either the applicable session-agent or realm-config. On a realm. the default value is none; on a session agent the default value is inherit.
  • max-inbound-per-session-burst-rate—Defines the maximum allowed burst rate of requests/responses received in a session. The default value is 30.
  • burst-rate-window-per-session—Defines the total window size (in seconds) for which the system monitors packet burst rate in a session. The system run this timer window using your configured value, and resets it to 0 on a timeout. This timer window runs in a loop after each expiry. The default value is 1.

Note:

If you try to enable the dos-action-at-session feature on a realm that is not set to the high trust level, the system rejects the configuration. If you enable the dos-action-at-session feature on a session agent that operates in a realm that is not set to high trust level, the system allows the configuration, but provides verify messages indicating that the system is ignoring that configuration.

Configuration Precedence Behavior

For this feature, the session-agent configuration takes precedence over the realm-config configuration. The precedence will be decided based on dos-action-at-session parameter first.

  • If you set dos-action-at-session in session-agent to permit, no-deny or session-drop then session-agent config parameters will be used.
  • If dos-action-at-session in a session-agent is inherit, the system checks thedos-action-at-session in the applicable realm-config.

    If you have set the realm-config to a valid value, the system uses your realm-config values for max-inbound-per-session-burst-rate, burst-rate-window-per-session and dos-action-at-session on this session-agent traffic.

  • If you set the dos-action-at-session parameter on a session-agent to none, the feature is disabled for this session-agent.
  • Based on feature inheritance, this feature is not enabled if you leave dos-action-at-session set to:
    • inherit (default) on the applicable session-agent and
    • none (default) on the applicable realm-config