bgp configuration signaling

Configuring Tiered Protection with FastPPS

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 FastPPS for traffic cleaning. For convenience, we introduce the following terms:

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

When an attack is detected, FastPPS CPE starts traffic cleaning itself. If the attack’s volume is close to the available channel bandwidth, FastPPS CPE sends a BGP announcement to FastPPS ISP. The announcement contains the prefixes traffic to which FastPPS ISP should clean. Upon receiving the prefixes, FastPPS ISP starts sending BGP announcements to its neighbours, informing them that traffic to these prefixes should be sent to FastPPS 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 FastPPS CPE and FastPPS 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 FastPPS CPE and FastPPS ISP is below.

Configuring FastPPS CPE

Configuring BGP Interaction

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

  2. Create a BGP neighbour FastPPS ISP.

    2.1. In the BGP neighbour settings specify the network parameters of FastPPS 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 FastPPS 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 FastPPS ISP.

Configuring Protection Policies

  1. Set autodetection thresholds for the announcement exchange control.

    1.1. Set BGP.Signaling.Input{Pps,Bps}.On thresholds at “Autodetection” tab of FastPPS 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 BGP.Signaling.Input{Pps,Bps}.Off thresholds at “Autodetection” tab of FastPPS 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, FastPPS CPE is ready to interact with FastPPS ISP.

Configuring FastPPS ISP

Configuring BGP Interaction

  1. Give FastPPS ISP permission to establish BGP connections.

  2. Create BGP neighbour FastPPS CPE. Specify the network parameters of FastPPS CPE, such as IP address and AS number. Activate the checkbox “Get prefixes under protection”, if necessary, specify maximum number of prefixes that FastPPS 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 FastPPS CPE may be located far away.

  3. Create BGP neighbours that FastPPS 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 FastPPS 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 FastPPS 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 BGP.Input{Pps,Bps}.On thresholds at “Autodetection” tab of the policy responsible for FastPPS 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 BGP.Input{Pps,Bps}.Off thresholds at “Autodetection” tab of the policy responsible for FastPPS 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 FastPPS ISP is ready to interact with FastPPS CPE.

Flapping

When incoming traffic on FastPPS CPE approaches the bandwidth, a BGP announcement towards FastPPS ISP is created. Upon receiving the announcement, FastPPS ISP reroutes the traffic to itself. As a result, the traffic rate on FastPPS CPE may drop below the threshold, and the BGP announcement towards FastPPS ISP is automatically removed. FastPPS ISP will detect that the announcement is removed, and stop routing the traffic to itself. The traffic will again start flowing to FastPPS 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 FastPPS.

Recommendations for Reducing Flapping on FastPPS CPE Side

One can increase the “Number of analysed intervals” at “Autodetection” tab of the FastPPS 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 FastPPS CPE-FastPPS ISP pair and depends on the average duration of observed attacks.

Recommendations to Reduce Flapping on FastPPS ISP Side

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

  1. Specify autodetection thresholds 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 FastPPS CPE stops announcing, until the traffic on FastPPS ISP drops below BGP.Input{Pps,Bps}.Off threshold.

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

It must be noted that FastPPS CPE often BGP announces /32 prefixes, while FastPPS ISP announces prefixes of larger subnets, for example /24. Thus, autodetection thresholds BGP.Signaling.Input{Pps,Bps}.{On,Off} on FastPPS CPE and autodetection thresholds BGP.Input{Pps,Bps}.{On,Off} on FastPPS 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 FastPPS CPE, but not on FastPPS ISP and flapping still occurs.

Related Content