Mitigation Overview

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

• About Mitigation
• Supported Mitigation Types
• Using Mitigation
• Mitigation Setup Workflows

Notes:
- 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.

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:

• Flowspec: See Flowspec Mitigation.
• RTBH: See RTBH Mitigation.
• Third-party mitigation: see Third-party Mitigation.

Note: The IP range 209.50.158.0/23 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.

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

• RTBH Mitigation
• Flowspec Mitigation
• Third-party 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.

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).

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:

• Configure a mitigation method to run on the platform (see Third-party Mitigation Methods).
• Add a new mitigation platform specifying the third-party system (see Third-party Platform Settings).

Notes:
- For an example of the mitigation setup process described above, see Cloudflare MT Setup.
- 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.).

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

• Mitigation Platforms and Methods
• Mitigation Configuration
• Mitigation Deployment

Note: For examples of how to create and assign an individual type of mitigation, see Mitigation Setup Workflows.

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.

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

• Creating a mitigation method (see Mitigation Methods).
• Creating a mitigation platform (see Mitigation Platforms).
• 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.

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.

Note: For examples of how to create and assign an individual type of mitigation, see Mitigation Setup Workflows.

The topics below outline the procedures for setting up various types of mitigation:

• Cloudflare MT Setup
• RTBH Setup

The set up of a Cloudflare Magic Transit mitigation in the Kentik portal involves the following steps:

1. Go to the Mitigation Methods page:
   - In v4 portal: Use the main navbar menu to go to the Insights & Alerting page, click the Configure Custom Insights button at top right, and then, on the resulting Alerting Policies page, choose Mitigation Methods from the sidebar at left.
   - In v3 portal: Choose Alerting from the main navbar, and then, on the resulting Active Alerts page, choose Methods from the sidebar at left.
2. On the Mitigation Methods page, click the Add Mitigation Method button at top right to open the Add Mitigation Method dialog.
3. On the General tab, fill in the required fields (see Common Method Settings), including, if needed, Automated Mitigation Settings.
4. On the Details tab, choose Cloudflare Magic Transit from the Mitigation Type drop-down, then click the Add Mitigation Method button to close the dialog.
5. From the left sidebar on the Mitigation Methods page, choose Mitigation Platforms (v4) or Platforms (v3) to go to the Mitigation Platforms page.
6. On the Mitigation Platforms page, click the Add Mitigation Platform button at top right to open the Add Mitigation Platform dialog.
7. Enter a name and description for the platform, then choose Cloudflare Magic Transit from the Mitigation Type drop-down.
8. Fill in the required fields, including API Login, API Token, and Cloudflare Account ID (see Third-party Platform Settings). Then click in the Mitigation Methods field and choose the Cloudflare mitigation method you created in the Add Mitigation Method dialog. When the settings are complete, click the Add Mitigation Platform button to close the dialog.

Once you’ve created a Cloudflare MT mitigation for your organization it may be deployed manually or automatically (e.g. in response to conditions defined in a Custom Insight threshold); see Mitigation Deployment.

Notes:
- The procedure above covers only setup in the Kentik portal. You must also set up the mitigation in the Cloudflare account referenced in step 8. For further information please refer to Cloudflare’s documentation and support for Cloudflare Magic Transit.
- 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.).

The following steps a provide a general overview of what’s involved in setting up an RTBH mitigation in the Kentik portal; for detailed procedures, see Configuring RTBH Mitigation:

• Identify your routers
• Create a mitigation method
• Select RTBH as the mitigation type
• Create a mitigation platform
• Link the method to the platform
• Assign the mitigation to an alert threshold