bgp configuration signaling

Configuring Tiered Protection with MITIGATOR

The most effective approach to DDoS protection is a tiered defense architecture, in which surgical filtering of traffic entering the protected network is performed by an on-premise device at the network border, while mitigation mechanisms at the upstream telecom operator level prevent the channel from being saturated.

Always on protection at the upstream telecom operator side can cause problems and negatively affect legitimate traffic, so it should be activated only when necessary. For this scenario it is needed to configure interaction between the defense layers - cloud protection.

Let’s consider the case when both the operator and its client use MITIGATOR for traffic cleaning. For convenience, we introduce the following terms:

  • MITIGATOR CPE — MITIGATOR, installed at the client’s network border.
  • MITIGATOR ISP — MITIGATOR, installed at the upstream telecom operator.

When an attack is detected, MITIGATOR CPE starts traffic cleaning itself. If the attack’s volume is close to the available channel bandwidth, MITIGATOR CPE sends a BGP announcement to MITIGATOR ISP. The announcement contains the prefixes traffic to which MITIGATOR ISP should clean. Upon receiving the prefixes, MITIGATOR ISP starts sending BGP announcements to its neighbours, informing them that traffic to these prefixes should be sent to MITIGATOR ISP for cleaning. After the attack is over, the announcements are withdrawn, and the traffic continues to move along its original route. It is advisable to configure BGP interaction between MITIGATOR CPE and MITIGATOR ISP through an alternate channel, since if common channel is saturated, the signal may not be sent.

A detailed look at the configuration of such interaction between MITIGATOR CPE and MITIGATOR ISP is below.

Configuring MITIGATOR CPE

Configuring BGP Interaction

  1. MITIGATOR CPE needs to have permission to establish BGP connections.

  2. Create a BGP neighbour MITIGATOR ISP.

    2.1. In the BGP neighbour settings specify the network parameters of MITIGATOR ISP, such as IP address and AS number. The rest of parameters is optional and configured as needed. It is recommended to specify high TTL value for IP packets, since MITIGATOR ISP may be located far away.

    2.2. Specify one of the system .signaling. lists in the announcement policy for this BGP neighbour. Signaling lists can be populated according to different criteria, list selection depends on the scenario. As an example we use system.policy.signaling.prefixes list. Special nexthop and community are defined as needed, according to the requirements of MITIGATOR ISP.

Configuring Protection Policies

  1. Set autodetection thresholds for the announcement exchange control.

    1.1. Set Policy.BGP.Signaling.Input{Pps,Bps}.On thresholds at “Autodetection” tab of MITIGATOR CPE protection policy. When the traffic exceeds these thresholds, the destination prefixes from the protection policy routing rules will be added to system.policy.signaling.prefixes list.

    1.2. Set Policy.BGP.Signaling.Input{Pps,Bps}.Off thresholds at “Autodetection” tab of MITIGATOR CPE protection policy.When the traffic drops below these thresholds, the destination prefixes from the protection policy routing rules will be removed system.policy.signaling.prefixes list.

  2. If necessary, take action to reduce flapping. After completing the described steps, MITIGATOR CPE is ready to interact with MITIGATOR ISP.

Configuring MITIGATOR ISP

Configuring BGP Interaction

  1. Give MITIGATOR ISP permission to establish BGP connections.

  2. Create BGP neighbour MITIGATOR CPE. Specify the network parameters of MITIGATOR CPE, such as IP address and AS number. Activate the checkbox “Get prefixes under protection”, if necessary, specify maximum number of prefixes that MITIGATOR CPE can send. The rest of parameters is optional and configured as needed. It is recommended to specify high TTL value for IP packets, since MITIGATOR CPE may be located far away.

  3. Create BGP neighbours that MITIGATOR ISP will send BGP announcements for traffic redirection.

    3.1. Specify the network device parameters in the BGP neighbour settings.

    3.2. Specify one of the system .protected. lists in the announcement policy for these BGP neighbours. This list will be automatically populated with prefixes announced by MITIGATOR CPE. Lists for prefix protection are selected according to the scenario. As an example we use system.protected.prefixes list. Special nexthop and community are defined as needed.

    3.3. To prevent flapping specify system.policy.prefixes. list in the announcement policy for these BGP neighbours.

Configuring Protection Policies

  1. There is no need to set the thresholds for system.protected.prefixes list announcement control in the policies responsible for MITIGATOR CPE traffic. It will be automatically announced to all BGP neighbours for which it was added to the announcement policy, while BGP announcement is active and the list is not empty.

  2. Specify autodetection thresholds to prevent flapping.

    2.1. Set Policy.BGP.Input{Pps,Bps}.On thresholds at “Autodetection” tab of the policy responsible for MITIGATOR CPE traffic. When the traffic exceeds these thresholds, the destination prefixes from the protection policy routing rules will be added to system.policy.prefixes list.

    2.2. Set Policy.BGP.Input{Pps,Bps}.Off thresholds at “Autodetection” tab of the policy responsible for MITIGATOR CPE traffic. When the traffic drops below these thresholds, the destination prefixes from the protection policy routing rules will be removed from system.policy.prefixes list.

After completing these steps MITIGATOR ISP is ready to interact with MITIGATOR CPE.

Flapping

When incoming traffic on MITIGATOR CPE approaches the bandwidth, a BGP announcement towards MITIGATOR ISP is created. Upon receiving the announcement, MITIGATOR ISP reroutes the traffic to itself. As a result, the traffic rate on MITIGATOR CPE may drop below the threshold, and the BGP announcement towards MITIGATOR ISP is automatically removed. MITIGATOR ISP will detect that the announcement is removed, and stop routing the traffic to itself. The traffic will again start flowing to MITIGATOR CPE, will exceed the threshold again and so on. This process is called flapping. There are several mechanics created to reduce flapping effect on the protection efficiency in MITIGATOR.

Recommendations for Reducing Flapping on MITIGATOR CPE Side

One can increase the “Number of analysed intervals” at “Autodetection” tab of the MITIGATOR CPE protection policy. This will not completely exclude flapping, but its frequency will be reduced due to longer time waiting between the traffic rate reduction below the autodetection threshold and the BGP announcement removal. The number of analysed intervals is chosen empirically for a specific MITIGATOR CPE-MITIGATOR ISP pair and depends on the average duration of observed attacks.

Recommendations to Reduce Flapping on MITIGATOR ISP Side

When BGP announcement with prefixes, traffic to which must needs protection, is received from MITIGATOR CPE, these prefixes are automatically added to the system.protected.prefixes list. MITIGATOR ISP sends this list to BGP neighbours informing that the traffic of these prefixes must be routed to it. Thus traffic is routed to MITIGATOR ISP policies responsible for MITIGATOR CPE protection and the traffic is recorded to the counters of these policies. To avoid flapping, MITIGATOR can keep the traffic on itself. To enable this logic in the policies responsible for MITIGATOR CPE protection:

  1. Specify autodetection thresholds Policy.BGP.Input{Pps,Bps}.{On,Off}.

  2. In the BGP announcement policy of BGP neighbours, besides system.protected.prefixes, additionally specify system.policy.prefixes.

In this case the attacked prefixes will continue to be announced to BGP neighbours, even when MITIGATOR CPE stops announcing, until the traffic on MITIGATOR ISP drops below Policy.BGP.Input{Pps,Bps}.Off threshold.

To remove traffic from MITIGATOR ISP protection manually, the client must log in to MITIGATOR ISP Web interface and turn off BGP announcement in the policies responsible for the client’s service protection.

It must be noted that MTITIGATOR CPE often BGP announces /32 prefixes, while MITIGATOR ISP announces prefixes of larger subnets, for example /24. Thus, autodetection thresholds Policy.BGP.Signaling.Input{Pps,Bps}.{On,Off} on MITIGATOR CPE and autodetection thresholds Policy.BGP.Input{Pps,Bps}.{On,Off} on MITIGATOR ISP should have comparable values. In the opposite case, if the attack is not performed on the whole subnet, but only on a specific IP-address, the thresholds may be exceeded on MITIGATOR CPE, but not on MITIGATOR ISP and flapping still occurs.

Related Content