Mitigation Overview

Kentik Detect’s mitigation capabilities are covered in the following topics:

- For information on mitigation platforms, see Mitigation Platforms.
- For information on mitigation methods, see Mitigation Methods.
- For information on assigning mitigations in an alert policy, see Threshold Mitigations.
- For information on how mitigations are shown in alert dashboards (Active page and History page), see Alert Dashboards.
- For information on initiating mitigation manually, see Manual Mitigation.



About Mitigation

The Kentik Detect alerting system doesn’t just notify you about conditions defined in alert policies (see About Alerts and Policies), it can also take actions in response to those conditions. Among the most notable of these actions is mitigation, in which undesirable traffic (e.g. DDoS attack) is prevented from disrupting network availability.

As detailed in Supported Mitigation Types, Kentik Detect supports several different types of mitigation, including:

Note: The IP range must be whitelisted on 3rd-party mitigation platforms (e.g. Radware or A10) as well as on devices that will be used for flowspec or RTBH mitigations.



Supported Mitigation Types

Kentik Detect supports the mitigation types covered in the following topics:


 top  |  section

RTBH Mitigation

Remotely Triggered Black-Hole routing (RTBH) is an extremely powerful technique that network operators can use to protect their network infrastructure and their customers against Distributed Denial of Service (DDoS) attacks. By automating the redirection of undesirable traffic at discrete points in a network, RTBH gives operators the ability to mitigate DDoS and to enforce blacklist/bogon routing policy from a centralized station.

While there are a variety of methods to implement RTBH, including RFC 5634 and source-based RTBH, most network engineers consider destination-based RTBH to be their best first-line defense against DDoS attacks. In a traditional, non-automated RTBH setup, a customer might call and say, “Help! I think I’m under attack.” An operator would then log into a route server and configure the mitigation, which is a /32 host “black hole” route. The route is then redistributed via BGP — along with a ‘no-export’ community and a next-hop address — to the routers where the attack traffic is entering the network. These routers then route the traffic to a destination that doesn’t exist (the black hole), for example a null interface.

Destination-based RTBH is not only incredibly effective at protecting network infrastructure, it’s also relatively simple to implement and to automate with Kentik Detect alert policies that define any number of conditions that will trigger an alarm, and define as well as how the system should respond to an alarm depending on the specific situation. That response may be immediate, delayed, or manual, it may include notification and/or mitigation, and it may involve just a /32 host route or include an aggregate /24. The details of the mitigation are defined in the settings of Kentik’s RTBH Mitigation Methods.


 top  |  section

Flowspec Mitigation

Kentik Detect’s flowspec-based mitigation is effectively an implementation of IETF RFC5575bis. As a mitigation tool, flowspec has the advantage of being far more precise than RTBH in two respects:

  • Greater precision in defining which traffic is affected by a mitigation action.
  • Greater range of possible mitigation actions.

RFC5575bis defines two complementary aspects of what is commonly referred to as a “flowspec,” which are defined in the settings of Kentik’s Flowspec Mitigation Methods:

  • Traffic matching: A BGP Network Layer Reachability Information (BGP NLRI) encoding format is used to distribute a “flow specification” to a flowspec receiver, which can be any routing system that supports MP-BGP. The flow specification is a filter that matches traffic based on the values of certain “component types,” which are properties of packets (IP, ports, etc.; see Flowspec Component Types).
  • Traffic actions: An Extended community value is used to convey actions that a flowspec receiver can take on packets that match the flow specification (see Flowspec Traffic Actions).


 top  |  section

Third-party Mitigation

Kentik Detect offers third-party mitigation options that integrate with cloud or data-center mitigation systems offered by leading vendors such as Radware, Cloudflare, and A10. Third-party mitigation is implemented via APIs that support third-party orchestration servers like Radware DefenseFlow as well as hardware scrubbing appliances like Radware DefensePro or A10 Thunder TPS. Third-party mitigations can be automated or activated manually.

To use a third-party mitigation system with Kentik Detect:

Note: Cloudflare applies Magic Transit mitigation only when traffic volume exceeds protocol-dependent minimums (100K pps for TCP or UDP; 60K pps for ICMP or GRE). Assigning Cloudflare MT to a Kentik alert policy threshold whose traffic volume is below these minimums may result in Kentik indicating mitigation as active even when Cloudflare isn’t actually mitigating. For lower-volume thresholds, assign an alternative mitigation platform (RTBH, Flowspec, etc.).



Using Mitigation

The following topics cover how mitigation is structured, configured, and deployed:


 top  |  section

Mitigation Platforms and Methods

A mitigation involves two main components:

  • Mitigation Platform: The platform on which a mitigation will run.
  • Mitigation Method: An individual mitigation configuration to be run on a mitigation platform.


 top  |  section

Mitigation Configuration

Mitigations are defined on the Platforms and Methods pages of Kentik Detect’s Alerting section. Configuring a mitigation involves:

  • Creating a mitigation platform (see Mitigation Platforms).
  • Creating a mitigation method (see Mitigation Methods).
  • Linking the two together (in the mitigation platform), after which the combination is available to use.

To better understand how configuration of the mitigation method differs from configuration of the mitigation platform, consider a scenario where RTBH policies are differentiated based on transit providers, interface capacities, or available peers. Being able to create multiple methods for the same platform enables you to tailor your use of the RTBH platform for each different deployment scenario.


 top  |  section

Mitigation Deployment

Once a mitigation method is configured and linked to a platform, the method can be deployed in two ways:

  • Automated mitigation: The mitigation is assigned to a threshold in an alert policy (see Threshold Mitigations) and triggered when conditions match those specified in the threshold. Automated mitigations will escalate and de-escalate automatically as changing conditions match different thresholds of the underlying alert policy.
  • Manual mitigation: The mitigation is started and stopped manually (not in associated with an alarm triggered by an alert policy threshold); see Manual Mitigation.

Notes: To walk through an example of how to create and assign one type of mitigation, see Configuring RTBH Mitigation.

In this article: