Mitigation Methods

The management of mitigation methods in Kentik Detect is covered in the following topics:

• Methods Page UI
• Mitigation Methods List
• Mitigation Method Dialogs
• Flowspec Mitigation Methods
• RTBH Mitigation Methods
• Third-party Mitigation Methods
• Add or Edit Mitigation Method

Notes:
- For a high-level overview of mitigation, see About Mitigation.
- For information on mitigation platforms, see Mitigation Platforms.
- 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.

A mitigation method is an individual mitigation configuration to be run on a mitigation platform (see Mitigation Platforms). The methods page includes the following UI elements:

• Filter field: Filters the Mitigation Methods List to show only rows containing the entered text (case insensitive) in one of the following fields: ID, Name, Method Type.
• Add Mitigation Method: A button that opens the Add Mitigation Method dialog. (see Mitigation Method Dialogs).
• Mitigation Methods List: A list of your organization’s existing mitigation methods (see Mitigation Methods List).

The Mitigation Methods List is a table that lists all of the mitigation methods that have been created by users in your organization. The table includes the following columns:

• ID: System-assigned unique ID (numeric) for the mitigation method.
• Name: User-assigned name for the mitigation method.
• Method Type: The type of mitigation method (e.g. RTBH, Radware, etc.).
• Actions: The following actions can be performed on a mitigation method:
  - Copy (duplicate icon): Duplicates the method so that it can be modified without altering the original.
  - Remove (trash icon): Removes the method from your organization’s available methods.

Adding or editing a mitigation method via the Kentik portal involves specifying information in the fields of the mitigation method dialogs, which are covered in the following topics.

• About Mitigation Method Dialogs
• Mitigation Method Dialogs UI
• Common Method Settings

Note: In addition to configuring a mitigation platform and method in Kentik Detect, you must also whitelist the IP range 209.50.158.0/23 on 3rd-party mitigation platforms (e.g. Radware, Cloudflare, or A10) as well as on devices that will be used for flowspec or RTBH mitigations.

The Kentik portal uses the mitigation method dialogs to enable management of mitigation method settings. The settings are entered into the fields of either of the following dialogs:

• Add Mitigation Method when registering a new method with Kentik Detect.
• Edit Mitigation Method when editing an already registered method.

The following types of mitigations are currently configured in the above dialogs:

• Flowspec: Kentik’s implementation of the traffic matching and traffic actions defined in IETF RFC5575bis, which require router support for MP-BGP. See Flowspec Mitigation Methods.
• RTBH: Kentik’s implementation of remotely triggered black hole (RTBH) filtering, which uses BGP to drop undesirable traffic (forward it to a null0 interface) before it enters your network. See RTBH Mitigation Methods.
• Third-party mitigations: Integrations developed by Kentik to enable mitigation by external systems from leading vendors such as Radware, Cloudflare, and A10. See Third-party Mitigation Methods.

The Add Mitigation Method and Edit Mitigation Method dialogs share the same layout and the following common UI elements:

• Close button: Click the X in the upper right corner to close the dialog. All elements will be restored to their values at the time the dialog was opened.
• Tabs: The tabs of the dialog:
  - General: Settings common to all mitigation platforms (see Common Method Settings).
  - Details: Configuration that is specific to each platform (platform is selected at the top of this tab).
• Remove button (Edit Mitigation Method dialog only): Remove the method from your organization’s collection of Kentik-registered methods.
• Cancel button: Cancel the add method or edit method operation and exit the dialog. All elements will be restored to their values at the time the dialog was opened.
• Add Mitigation Method button (Add Mitigation Method dialog only): Save settings for the new method and exit the dialog.
• Save button (Edit Mitigation Method dialog only): Save changes to method settings and exit the dialog.

The following settings and controls of the mitigation method dialogs (Add Mitigation Method and Edit Mitigation Method) are common to all mitigation method types; settings that are specific to each individual type are covered in separate topics. Except as noted, these settings are on the General tab of the dialog:

• Name: User-specified name for the mitigation method.
• Description: Optional user-provided description text.
• Notification Channels: A drop-down list from which to choose one or more notification channels for the mitigation method. Notification channels are created on the Channels page; see Alert Notifications.
• Settings for Automated Mitigations: A section of settings that apply only to automated mitigations (not to manual mitigations); see Automated Mitigation Settings.
• Platform: The type of the mitigation platform on which this method will be run (e.g. Radware, Cloudflare Magic Transit, RTBH, A10 TPS, or Flowspec).
  Note: This setting is at the top of the Details tab.

The following settings are applicable only to automated mitigations, which are triggered in response to an alarm (see Threshold Mitigations):

• Acknowledgement Required: If this switch is on, a mitigation alarm from this method must be manually (rather than automatically) cleared from the Alarms List on the Alarms Dashboard (Active page) after the mitigation itself is complete.
• IPs/CIDRs Excluded From Mitigation: IP addresses that should be excluded from being mitigated with this method, for example infrastructure addresses, point-to-point networks, or other addresses critical to the normal functioning of your network. Enter as a comma-separated list.
• Grace period: The grace period that Kentik should honor prior to ending mitigation (e.g. withdrawing a blackhole route). Default is 30 minutes.

Note: Automated mitigation settings have no effect on manual mitigations.

Flowspec mitigation methods are covered in the following topics:

• Flowspec Method Overview
• Flowspec Component Types
• Flowspec Condition Controls
• Flowspec Traffic Actions
• Configuring Flowspec Mitigation

Notes:
- For information about flowspec platform configuration, see Mitigation Platform Settings.
- For general information about flowspec, see Flowspec Mitigation.

Configuring a flowspec-based mitigation method is a two-part process corresponding to the aspects described above:

1. Use the Traffic Matching settings covered in Flowspec Condition Controls to define a flow specification by identifying traffic with specific characteristics (values or ranges of values for one or more component types).
2. Use Traffic Filtering Actions (see Flowspec Traffic Actions) to specify the actions to take on the traffic subset defined in Traffic Matching.

A flow specification is a filter that matches traffic based on the values of “component types” defined in RFC5575, each of which represents a property of a packet (IP, ports, etc.).

The Traffic Matching pane includes controls (condition groups; see Flowspec Condition Controls) that set the conditions for matching traffic based on the component types covered in the topics below.

Note: Except as noted below, all component types support multiple conditions and nesting of condition groups.

The first set of condition groups includes the following component types:

• Source IP/CIDR (type 2): Matches on a range of source IP addresses.
• Destination IP/CIDR (type 1): Matches on a range of destination IP addresses.

The following considerations apply to these component types:

• The lower the CIDR, the more broadly the flowspec actions will be applied. Setting CIDR to 0 means that all traffic will match.
• If the Infer From Alarm switch is on, the field will be locked:
  - For an automated mitigation, the IP will be derived by Kentik from an alarm, and the lower the CIDR setting is in the Dimensions section of the Data Funneling pane, the more broadly the flowspec actions will be applied.
  - For a manual mitigation, the user must enter the IP in the Start Manual Mitigation dialog (see Start a Manual Mitigation).
• If the Infer From Alarm switch is on for one of these components then a mitigation using this method will only be available to assign to an alert policy threshold (automated mitigation) if the policy’s key definition includes the dimension corresponding to that component (source or destination IP/CIDR).
• Do not set the Infer From Alarm switch to on for both Source and Destination.
• These component types don’t support multiple conditions or nested groups.

Note: A flowspec with no setting (either literal or via Infer From Alarm) for source and/or destination IP/CIDR is at greater risk of being overly broad (applying to more traffic than intended).

The next set of condition groups includes the following component types:

• Protocols (type 3): Matches on IP protocol, e.g. UDP (17). Select a protocol number from the drop-down value list at right (use the filter field at top to narrow the list).
• Source Ports (type 6): Matches on source port. Enter a port number into the value field at right.
• Destination Ports (type 5): Matches on destination port. Enter a port number into the value field at right.

If the Infer From Alarm switch is on for these component types:

• The other controls in this group will be locked.
• The method can’t be used for manual mitigation.
• For an automated mitigation, the protocol or port will be derived by Kentik.
• If the Infer From Alarm switch is on for one of these components then a mitigation using this method will only be available to assign to an alert policy threshold (automated mitigation) if the policy’s key definition includes the dimension corresponding to that component (protocol or source/destination port).

The last set of condition groups includes the following component types:

• ICMP Types (type 7): Matches on the type field of an ICMP packet. Choose an ICMP type from the drop-down value list at right (use the filter field at top to narrow the list).
• ICMP Codes (type 8): Matches on the code field of an ICMP packet. Enter an ICMP code into the value field at right.
• TCP Flags (type 9): Matches on flags in the TCP header. Select a TCP flag from the drop-down value list at right (use the filter field at top to narrow the list).
• Packet Lengths (type 10): Matches on total IP packet length (excluding Layer 2 but including IP header). Enter a packet length in bytes into the input field at right.
• DSCPs (type 11): Matches on 6-bit DSCP field (Diffserv Code Point). Select a DSCP value from the drop-down list at right (use the filter field at top to narrow the list).
• Fragments (type 12): Matches on fragment status header. Select a status value from the drop-down list at right (use the filter field at top to narrow the list).

The controls of the Traffic Matching pane are structured as a series of cards that each represents a group of one or more conditions for a specific “component type.” Each of these condition groups may be individually included or excluded from the flowspec.

Except as indicated in Flowspec Component Types, condition groups can support multiple conditions and may contain nested condition groups. When traffic is evaluated, the individual conditions in each nested condition group will be ANDed, the conditions and nested groups in each group will be ORed, and the main groups will be ANDed. The result is that only traffic matching the flowspec defined by all specified condition groups will be affected by the actions specified in Traffic Filtering Actions (see Flowspec Traffic Actions).

The controls for condition groups are largely the same, with some variation between component types as indicated below:

• Enable/Disable: To enable or disable a condition group, use this switch in the group’s title bar.
• Infer from Alarm: If this switch is on, the remaining fields in the condition group will be locked and ignored. Instead, the value of this component will be derived from the alarm that triggers the mitigation.
  Note: A mitigation method with this switch on in the Protocols, Source Ports, or Destination Ports condition groups can’t be used for manual mitigation.
• Operator: If the condition group is enabled and the Infer from Alarm switch is off, choose an operator (e.g. equals, greater than, less than, etc.) from the drop-down list at left.
  Note: This control is not included in the condition groups for source and destination IP/CIDR.
• Value: If the condition group is enabled and the Infer from Alarm switch is off, a condition group will include one of the following:
  - Value field: Enter a value into the value field. Applies to the following component types: IP/CIDR (source and destination), Ports (source and destination), and ICMP codes.
  - Value selector: Choose a value from the drop-down list at right (use the filter field at top to narrow the list). Applies to the component types not listed immediately above.
• Remove: To remove an individual condition, click the red X at the right of the condition.
• Add Condition: Add an individual condition to a conditions group. The condition will be ORed with other conditions in the group (match any).
• Add Group: Nest a conditions group within the top-level conditions group. The conditions in the nested group will be ANDed (match all).
  Note: Not available for IP/CIDR (source or destination).

Note: As with any powerful technique, flowspec-based mitigation requires attention to detail and carries with it the risk of unintended results and adverse consequences. Before attempting to configure and deploy flowspec, be sure that you fully understand the component-specific considerations noted in Flowspec Component Types.

Traffic actions are applied by a flowspec receiver (routing system) to traffic that has been matched to the flowspec defined in the Traffic Matching pane. The Traffic Filtering Actions pane contains the controls covered in the topics below.

The following primary actions are available from the drop-down Traffic Action menu:

• Rate Limit: The flowspec receiver will rate-limit matching traffic to the bytes/sec value entered into the input field that appears when you choose this menu item. Corresponds to the BGP Extended community ID 0x8006 (traffic-rate).
• Discard: The flowspec receiver will discard matching packets (same as setting rate limit to 0). Corresponds to the BGP Extended community ID 0x8006 (traffic-rate).
• Mark DSCP: The flowspec receiver will set the DSCP header of the matching packets to the Differentiated Services Code Point value entered into the input field that appears when you choose this menu item. Corresponds to the BGP Extended community ID 0x8009 (traffic-marking).
• Route-Target Redirect: The flowspec receiver will assign to matching packets the MP-BGP Route-Target value entered into the input field that appears when you choose this menu item. This allows packets to be redirected to another VRF, where a different action may be applied (useful, for example, for DDoS scrubbing VRFs). Corresponds to the BGP Extended community ID 0x8008 (rt-redirect).
• Next-Hop Redirect: The flowspec receiver will redirect all matching packets to the IP address entered into the input field that appears when you choose this menu item. Corresponds to the BGP Extended community ID 0x0800 (from RFC7153).

As described in RFC5575 section 7.3, the Sample setting “enables traffic sampling and logging for this flow specification.” The implementation of this logging feature is vendor-specific, both in terms of the type of logging (typically syslog or equivalent) and the location where the log is kept, e.g. the syslog file/server (Juniper), a separate log specified with a “sample-log” CLI syntax (Cisco), etc. Consult your router vendor documentation for information about configuring the log destination.

In a typical implementation, the receiver will begin to create log entries for packets that match the flowspec. The log entries can be used (via your own log-reading system, not within Kentik Detect), to accomplish the following:

• Check that flowspec rules are being correctly applied (the right traffic is being matched and the right actions are being taken).
• Examine traffic of interest (e.g. abnormal traffic pattern suggestive of DDoS attack) for diagnosis, troubleshooting, etc.

If the Sample switch is on then log entries will be created for matching packets as follows:

• If the volume of packets is below a router-configured threshold, log every packet matching the flowspec.
• If the volume of packets is above the threshold, log a subset of matching packets, sampled at a router-configured rate.

The Terminal setting (based on RFC5575 section 7.3) applies when a given packet is matched by the rules of more than one mitigation method. It tells a flowspec receiver how to proceed after a given action has been applied:

• Terminal ON: Continue to the next rule that applies to this packet.
• Terminal OFF: Skip subsequent rules, if any, and move directly to the next packet.

The follow sequence provides a simple example of how the Terminal setting works in practice:

1. An event occurs on the network that triggers flowspec mitigation methods A, B, and C.
2. The flowspec rules (traffic matching + action) for each method are broadcast by Kentik and received by the flowspec receiver (router).
3. The router prioritizes the rules based on RFC5575 section 5.1, Ordering of Traffic Filtering Rules, determining that the processing order is A, B, C.
4. The router receives and evaluates packet 1, finding that it matches the traffic filter of all three rules.
5. The action of rule A is applied to packet 1.
6. The Terminal value of rule A is ON, so the action of rule B is applied to packet 1.
7. The Terminal value of rule B is OFF, so the action of rule C is not applied to packet 1 and the filtering engine begins its evaluation of packet 2.

The following workflow outlines the general process of creating, configuring, and deploying a Flowspec mitigation (a linked combination of platform and method). If this is your first time working through the process, we recommend that you contact support@kentik.com before starting so that we can assist you.

The workflow involves the following tasks:

• Configure devices for flowspec
• Enable flowspec in Kentik device admin
• Create a flowspec mitigation method
• Specify flowspec conditions and actions
• Create a flowspec mitigation platform
• Deploy as an automated mitigation
• Deploy as a manual mitigation

Note: As with any mitigation, once the mitigation is applied to actual traffic (manually or automatically) it’s important to monitor it via the Active Alerts List.

You should be able to enable flowspec in the configuration of any routing system that supports MP-BGP. The specifics of how to achieve this vary depending on the brand, operating system, model, and version of the device. To find configuration information for your device:

1. Navigate to Kentik’s config-snippets repository on GitHub.
2. In the list of router brands, find and click on the directory corresponding to the manufacturer of your device. If the manufacturer makes multiple models that are configured differently, continue clicking until you reach the directory corresponding to the device that you want to configure.
3. Inside that directory, look for the file named flowspec.conf.
4. Open the file and configure your device as shown in the code snippet.

The following example is a config snippet for flowspec on Juniper MX routers:

# this configuration on JunOS assumes you already have a BGP session configured
# Kentik-provided peering IP.
set protocols bgp group route-consumers_v4 neighbor {{kentik_UI_bgp_peering_ipv4}} family inet flow
# Use the RFC 5575 defined ordering of the terms instead of the earlier draft version.
set routing-options flow term-order standard

Each device that you configure to enable flowspec (see part A above) must also be enabled for flowspec in the device settings in the Kentik portal:

1. On the Admin » Devices page, click on the device in the Device List to open the Edit Device dialog.
2. On the BGP tab, choose Peer with Device from the BGP Type drop-down menu.
3. Set the BGP Flowspec Compatible switch to on.
4. Click the Save button to save changes and exit the dialog.

1. Go to the Methods page (Alerting » Methods).
2. Click the Add Mitigation Method button.
3. On the General tab of the resulting dialog (see Mitigation Method Dialogs), give your method an informative name and description.
4. From the drop-down Notification Channels menu, assign a notification channel so that you can be notified when your alert triggers a mitigation.
   Note: If you’re not already part of a notification channel, go to the Channels page to add yourself to an existing channel or create a new channel for this mitigation method.
5. Turn on the Acknowledgement Required switch, which means that after a mitigation from this method is complete the corresponding alarm must be cleared manually (rather than automatically) from the Active Alerts List on the Active Alerts page. That way you’ll know if a mitigation was automatically triggered and then ended.
6. Next, use the IP/CIDRs Excluded field to enter any IP address that you’d like to exclude from the actions taken by this method (see Flowspec Traffic Actions). Good candidates might be infrastructure addresses, point-to-point networks, or other address critical to the normal functioning of your network.
7. Now select the Grace Period that Kentik should honor prior to withdrawing the flowspec action. Many operators are happy with the 30-minute default because it provides enough cushion to discourage repeat attacks while not being excessively punitive to the IP that was the attack destination.

1. On the Details tab of the Add Mitigation Method dialog, choose Flowspec from the Mitigation Type drop-down.
2. In the Traffic Matching pane, set the conditions that will be used to match traffic.
   Note: The components that are used for conditions are described in Flowspec Component Types, and the controls for setting conditions are explained in Flowspec Condition Controls. To avoid unintended consequences, familiarize yourself with the notes in those topics.
3. In the Traffic Filtering Actions pane, specify the actions that flowspec receivers are to take on traffic that matches the traffic matching conditions (see Flowspec Traffic Actions).
   Note: To save the method you must select one of the five actions available on the Traffic Filtering Actions drop-down. Setting only the Sample and/or Terminal switch is not sufficient to define a flowspec method.
4. Click the Add Mitigation Method button to save the new method and exit the dialog.

Once you’ve enabled devices for flowspec (both in the device config and in Kentik Detect) and created a mitigation method you can create the platform with which the method will combine to make a mitigation:

1. Go to the Platforms page (Alerting » Platforms).
2. Click the Add Mitigation Platform button.
3. In the resulting dialog, fill in the common settings for your new platform (see Mitigation Platform Settings).
4. From the drop-down Mitigation type menu choose Flowspec.
5. Click in the Devices field to open the Selected Devices dialog, then choose the routers that you enabled for flowspec in parts A and B of this workflow.

1. Click the Mitigation Methods field to open a drop-down list of flowspec-based mitigation methods. Click on the method that you saved in part D of this workflow.
   Note: By linking the method to the platform you create a mitigation that can be automatically or manually applied.
2. Click the Add Mitigation Platform button to save the new platform and exit the dialog.

Once configured, a mitigation can be deployed for either automated mitigation (initiated when an alarm is triggered by a threshold in an alert policy) or manual mitigation. To deploy your new flowspec mitigation automatically, assign the mitigation to an alert threshold (see Threshold Mitigations):

1. Go to the Policies page (Alerting » Policies).
2. In the Alert Policies List, click the policy to which you’d like to assign to an RTBH mitigation.
3. In the resulting Edit Alert Policy dialog, go to the Alert Thresholds tab. In the sidebar, click on the threshold (Critical, Major, etc.) to which you’d like to assign mitigation.
4. Click in the Mitigations pane at bottom to open a drop-down list of mitigations (each displayed as “platform - method”). Choose the mitigation that you created in tasks C-F above, then click the Add Mitigation button.
5. Next, use the Apply Mitigation menu to choose when you’d like to have the mitigation take effect, which could be immediately when Kentik raises the alarm, after a user manually acknowledges the alarm, or after a timer expires where no user has acknowledged the alarm.
6. Finally, use the Clear Mitigation menu to choose when the alarm about the mitigation should be cleared from the Active Alerts List.
7. Click the Save button (bottom right).
   Note: The creation and configuration of policies to which you can assign mitigations is covered in Alert Policies.

Notes:
- Flowspec-based mitigations can only be assigned to a threshold in an alert policy whose key definition includes the dimension IP/CIDR (see Dimensions in Data Funneling).
- If the Infer From Alarm switch is on for any conditions in a flowspec-based method (see Flowspec Condition Controls) then a mitigation using that method can only be assigned to a threshold in an alert policy whose key definition includes the corresponding dimensions.
Example: If a given method has Infer from Alarm on for Destination IP/CIDR, Protocols, and Source Ports, then a mitigation using that method will be available to assign to a threshold only in policies whose key definition includes the dimensions Destination IP/CIDR, Protocol, and Source Port Number.

Flowspec mitigations can be deployed manually as described in Start a Manual Mitigation. Before applying a flowspec-based manual mitigation, familiarize yourself with the special considerations discussed in Manual Mitigation with Flowspec.

The configuration of RTBH mitigation methods is covered in the following topics:

• IP Families in RTBH Mitigation
• RTBH Method Settings
• Configuring RTBH Mitigation

Notes:
- For information about RTBH platform configuration, see Mitigation Platform Settings.
- For general information about RTBH, see RTBH Mitigation.

An RTBH Mitigation in Kentik Detect involves using BGP to instruct devices that are part of a mitigation platform to redirect traffic destined for a given “target” IP/CIDR. To mitigate traffic to a given target, both of the following must be true:

• The BGP session between Kentik and each device assigned to the mitigation platform (see RTBH Platform Settings), which is set on the BGP tab of Edit Device dialog in Admin » Devices (see Device BGP Settings), must be established in the same address family (IPv4 or IPv6) as the target IP/CIDR of the traffic that will be mitigated.
• The address family (IPv4 or IPv6) of the Next Hop setting of the RTBH mitigation method (see RTBH Method Settings) must match that of the target IP/CIDR.

Kentik Detect applies the above requirements as follows:

• Manual mitigation: In the Start Manual Mitigation dialog, the family of the address you enter in the IP/CIDR to Mitigate field is checked against the family of the Next Hop setting of the RTBH mitigation method you chose with the Mitigation Platform and Method drop-down (see Manual Mitigation Settings). You will only be allowed to start the mitigation if the address families match.
• Automated mitigation: When a user associates a mitigation with an alert policy threshold (see Threshold Mitigations) it can’t be known in advance what addresses will trigger the mitigation. It is therefore up to the user to do one of the following to ensure that the mitigation is properly configured (and thus won’t fail when triggered):
  - Create family-specific policies using associated filters and mitigation options.
  - Associate multiple RTBH mitigations with the threshold to cover both IPv4 and IPv6.
  Note: This may result in attempted announcements on the wrong BGP sessions.

When the mitigation platform is set to RTBH (see Common Method Settings) on the Details tab of the Mitigation Method Dialogs, the following fields will be shown in that tab:

• Pre-defined Community Reference: A list of communities commonly used in RTBH; provided as a helpful reminder (you are not required to use these communities).
• Community to Advertise: The community that has been programmed on the customer’s router to induce a black hole next hop for the IPv4 address attached to the community.
• Next Hop: A next-hop IP address. In some environments this will be the destination IP to blackhole. This number has traditionally been selected from the 192.0.2.0/24 CIDR block, but may be any IP address.
• Local Preference: Set the priority for the RTBH route. A high setting helps ensure that when there is more than one route the RTBH route will be preferred by the BGP best path selection process.
• Convert IP to a /24: A switch that tells Kentik Detect to convert the provided next-hop IP address to CIDR notation. Use if you plan to withdraw blocks from certain routers and re-advertise in other locations (otherwise, leave unchecked).

The following workflow outlines the general process of creating, configuring, and deploying an RTBH mitigation (a linked combination of platform and method). If this is your first time working through the process, we recommend that you contact support@kentik.com before starting so that we can assist you.

The process involves the following tasks:

• 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

1. In the Kentik Detect portal, go to Admin » Devices.
2. In the Device List, check the BGP Status column (for V4 and/or V6; see screenshot below) for each device on which you wish to implement RTBH mitigation. If a given device doesn’t have a link icon in that column, click on that device’s row in the Device List.
3. In the resulting Edit Device dialog, go to the BGP tab.
4. Choose Peer with Device from the BGP Type drop-down menu.
5. Click the Save button to save changes and exit the dialog.
6. Repeat steps 2 through 5 above to enable direct peering with all of the devices that you’d like to use for RTBH mitigation.
7. Make a note of the names of the RTBH-ready devices.

1. Go to the Methods page (Alerting » Methods).
2. Click the Add Mitigation Method button.
3. On the General tab of the resulting dialog (see Mitigation Method Dialogs), give your method an informative name and description.
4. From the drop-down Notification Channels menu, assign a notification channel so that you can be notified when your alert triggers a mitigation.
   Note: If you’re not already part of a notification channel, go to the Channels page to add yourself to an existing channel or create a new channel for this mitigation method.
5. Turn on the Acknowledgement Required switch, which means that after a mitigation from this method is complete the corresponding alarm must be cleared manually (rather than automatically) from the Active Alerts List on the Active Alerts page. That way you’ll know if a mitigation was automatically triggered and then ended.
6. Next, use the IP/CIDRs Excluded field to enter any IP address that you’d like to exclude from being blackholed with this method. Good candidates might be infrastructure addresses, point-to-point networks, or other address critical to the normal functioning of your network.
7. Now select the Grace Period that Kentik should honor prior to withdrawing the blackhole route. Many operators are happy with the 30-minute default because it provides enough cushion to discourage repeat attacks while not being excessively punitive to the IP that was the attack destination.

1. Switch to the dialog’s Details pane and choose RTBH from the drop-down Mitigation Type menu.
2. In the Community to Advertise field, enter the community that has been programmed on the customer’s router to induce a black hole next hop for the IPv4 address attached to the community.
3. For the Next Hop field, enter a next-hop IP address. In some environments this will be the destination IP to blackhole. This number has traditionally been selected from the 192.0.2.0/24 CIDR block, but may be any IP address.
4. Use the Local Preference field (see RTBH Method Settings) to set the priority for the RTBH route.
5. If you plan to withdraw blocks from certain routers and re-advertise in other locations, you may want to turn on the Convert IP to a /24 checkbox. Otherwise, leave it off.
6. When you’re finished, click the Add Mitigation Method button to save the new method and exit the dialog.

Once you’ve enabled devices for RTBH and created a mitigation method you can create the platform with which the method will combine to make a mitigation:

1. Go to the Platforms page (Alerting » Platforms).
2. Click the Add Mitigation Platform button.
3. In the resulting dialog, fill in the common settings for your new platform (see Mitigation Platform Settings).
4. From the drop-down Mitigation type menu choose RTBH.
5. Click in the Devices field to open the Selected Devices dialog, then choose the routers that you identified in part A of this workflow.

1. Click the Mitigation Methods field to open a drop-down list of RTBH-based mitigation methods. Click on the method that you saved in part C of this workflow.
   Note: By linking the method to the platform you create a mitigation that can be automatically or manually applied.
2. Click the Add Mitigation Platform button to close the dialog.

Once configured, a mitigation can be deployed for either automated mitigation (initiated when an alarm is triggered by a threshold in an alert policy) or manual mitigation (described in Start a Manual Mitigation). To deploy your new RTBH mitigation automatically, assign the mitigation to an alert threshold (see Threshold Mitigations):

1. Go to the Policies page (Alerting » Policies).
2. In the Alert Policies List, click the policy to which you’d like to assign to an RTBH mitigation.
3. In the resulting Edit Alert Policy dialog, go to the Alert Thresholds tab. In the sidebar, click on the threshold (Critical, Major, etc.) to which you’d like to assign mitigation.
4. Click in the Mitigations pane at bottom to open a drop-down list of mitigations (each displayed as “platform - method”). Choose the mitigation that you created in tasks B-E above, then click the Add Mitigation button.
5. Next, use the Apply Mitigation menu to choose when you’d like to have the mitigation take effect, which could be immediately when Kentik raises the alarm, after a user manually acknowledges the alarm, or after a timer expires where no user has acknowledged the alarm.
6. Finally, use the Clear Mitigation menu to choose when the alarm about the mitigation should be cleared from the Active Alerts List.
7. Click the Save button (right top or bottom).
   Note: The creation and settings of policies to which you can assign mitigations is covered in Alert Policies.

The configuration of third-party mitigation methods is covered in the following topics:

• Configuring Third-party Mitigation
• Radware Method Configuration
• Cloudflare Method Configuration
• A10 Method Configuration

Notes:
- For information about third-party platform configuration, see Mitigation Platform Settings.
- For general information about third-party mitigation, see Third-party Mitigation.

To configure a method for third-party mitigation:

1. On the Alerting » Methods page in the Kentik Detect portal, click the Add Mitigation Method button, which opens the Add Mitigation Method dialog.
2. On the General tab of the dialog, fill in the fields described in Common Method Settings.
3. On the Details tab of the dialog, use the drop-down Platform menu to choose the third-party system (Radware, Cloudflare, or A10).
   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.).
4. The Details tab will then show additional (non-common) fields which vary depending on the third-party system. While some configuration information is provided below, customers are advised to make these settings in consultation with Kentik support (support@kentik.com) or a support representative of the third-party vendor.

Integration between Kentik Detect and Radware includes alert policies that enable Kentik to push detailed baseline data to Radware mitigation hardware. To take advantage of this integration you must be using DefensePro v2.7 or greater (see https://www.radware.com/products/defensepro/). Enabling the integration is a two step process:

1. On the Alerting » Library page in the Kentik Detect portal (see Alert Library List), copy the following alert policy templates to your company’s policies:
   - ICMP bps BASELINE for mitigation device
   - ICMP pps BASELINE for mitigation device
   - TCP bps BASELINE for mitigation device
   - TCP pps BASELINE for mitigation device
   - UDP bps BASELINE for mitigation device
   - UDP pps BASELINE for mitigation device
2. When you add or edit a Radware mitigation method (see Add or Edit Mitigation Method), the dialog will include a Mitigation Baselines pane that contains a set of drop-down menus. Use the menus to associate the policies with the method. For each menu type (e.g. ICMP bps, ICMP pps, etc.), choose the corresponding policy.

Note: For additional information or assistance, please contact support@kentik.com.

When Cloudflare Magic Transit (explained at https://blog.cloudflare.com/magic-transit/) is chosen as the mitigation type (see Common Platform Settings) for a mitigation method there are no Cloudflare-specific settings for the method.

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

The settings for mitigation methods whose platform is A10 TPS (see description at https://www.a10networks.com/products/thunder-tps/) should be made in consultation with either Kentik Customer Support or A10 support.

Methods are added and edited via the Methods page of the Kentik Detect portal (choose Alerting from the Kentik navbar, then Methods from the sidebar at left). Adding and editing methods is covered in the following sections:

• Adding a Mitigation Method
• Editing a Mitigation Method

To add a new mitigation method:

1. Open the Methods page (choose Alerting from the Kentik navbar, then Methods from the sidebar at left).
2. Click the Add Mitigation Method button to open the Add Mitigation Method dialog.
3. Specify general properties of the method on the General tab (see Common Method Settings).
4. On the Details tab, use the drop-down Platform menu to choose the type of mitigation method.
5. Fill in the fields for the chosen method type:
   - Flowspec method: see Flowspec Mitigation Methods.
   - RTBH method: see RTBH Mitigation Methods.
   - Third-party method: see Third-party Mitigation Methods.
6. Save the new method by clicking the Add Mitigation Method button (lower right).

To edit the settings for an existing mitigation method:

1. In the Mitigation Methods List, click in the row of the method that you’d like to edit. The Edit Mitigation Method dialog will open.
2. To change general properties of the method, use the General tab (see Common Method Settings).
3. To change settings that are specific to the method type, use the Details tab:
   - Flowspec method: see Flowspec Mitigation Methods.
   - RTBH method: see RTBH Mitigation Methods.
   - Third-party method: see Third-party Mitigation Methods.
4. To save changes, click the Save button (lower right).

To remove the method from your organization’s collection of mitigation methods, click Remove (lower left).