Manage Mitigations

The following topics cover the Manage Mitigations page, where you make settings for mitigation platforms and methods:

• Manage Mitigations Page
• Mitigation Platform Settings
• Mitigation Method Settings
• RTBH Method Details
• Flowspec Method Details
• Third-party Method Details
• Manage Mitigation Platform
• Manage Mitigation Method

Notes:
- For an overview of mitigation, see Mitigation Overview.
- For information about the Kentik portal’s Mitigations page, see Mitigations.
- For information on initiating mitigation manually, see Manual Mitigation.

The Manage Mitigations page is covered in the following topics:

• Platforms and Methods
• Create Initial Platform
• Mitigation Configuration UI
• Platform Panes
• Mitigation Methods List
• Unassigned Methods List

The Manage Mitigations page is reached via the Settings page, which you can access from the portal's main navbar menu. The page enables you to define mitigations by creating and configuring both of the following main elements of a mitigation:

• Platform: The platform on which a mitigation will run (e.g. Flowspec, Cloudflare, Radware, etc.).
• Method: An individual mitigation configuration that runs on a mitigation platform.

The first time you access the Manage Mitigations page, you'll see a splash screen inviting you to create your first mitigation. Click the Create Your First Mitigation button to continue to the Add Mitigation Platform page. Your first platform need not be perfect right away; you can go back and edit it before you use it. For information about creating the platform, see Mitigation Platform Settings and Add a Mitigation Platform.

Once a mitigation platform exists in your system, you’ll see the Manage Mitigations page, which includes the following UI elements:

• Start a Manual Mitigation button: Opens the Start Manual Mitigation Dialog (see Manual Mitigation).
• Add Mitigation Platform button: Opens the Add Mitigation Platform page.
• Mitigation platform panes: A series of panes used to manage platforms and list each platform's associated methods (see Platform Panes).
• Unassigned Methods: A list of methods that are not currently assigned to a platform (see Unassigned Methods List).
• Understanding Mitigations: A pane at the right of the page that contains a brief explanation of mitigation and links to related KB topics.

Each mitigation platform pane contains information about both the platform and the mitigation methods that have been created and added to the platform. Each pane contains the following UI elements:

• Platform Type: The type of mitigation platform (e.g. RTBH, Radware, etc.) appears directly above the platform’s name and the logo for that type appears just to the left.
• Name: The user-assigned name for the mitigation platform.
• Description: User-defined description for the mitigation platform.
• ID: A system-assigned unique identification number for the mitigation platform.
• Platform Status: A button that opens the Platform Status Popup:
  - If the button is a green checkmark icon, the platform is available for mitigation.
  - If the button is an orange question mark icon, there is an error that will be detailed in the popup (e.g. the platform may not be currently active or there is an authentication error).
• Edit: A button that takes you to the Edit Mitigation Platform page (see Platform Settings Pages).
• Remove: A button that opens a popup in which you can click Remove to remove the platform from your organization's collection of platforms.
• Mitigation Methods: A list of the mitigation methods assigned to this platform (see Mitigation Methods List).
• Add New Method: A button that opens an Add Mitigation Method dialog (see Mitigation Method Dialogs), enabling you to add a method to this platform.
• Assign Existing Method: A drop-down from which you can choose to assign to this platform a method that was previously created for this platform.

The status popup for each platform contains information that can be used for troubleshooting by Kentik Customer Support. The popup contains the following elements:

• Status summary: Describes the current status, including whether the platform is currently active and whether Kentik is currently trying to connect to it.
• Copy to Clipboard: A button that copies the platform properties to the clipboard.
• Platform properties: A JSON object that identifies the platform and gives information about its status. You can paste the JSON into your correspondence with Customer Support.

Each row of the Mitigation Methods list represents a mitigation method created for this platform by a user in your organization. The list includes the following columns:

• Name: A user-assigned name for the mitigation method.
• Description: A user-assigned description for the mitigation method.
• ID: A system-assigned identification number for the mitigation method.
• Clone: A button that creates a duplicate of the mitigation method.
• Edit: A button that opens the Edit Mitigation Method dialog (see Mitigation Method Dialogs).
• Unassign Method (X icon):A button that immediately removes the mitigation method from the platform to which it was assigned. If a method is not assigned to any platforms, it appears on the Unassigned Methods List.

Each row of the Unassigned Methods list represents a previously created mitigation method that is not currently assigned to a platform. The list includes the following columns:

• Type: The platform type (e.g. RTBH, Flowspec, etc.) for which this method can be used.
• Name: A user-assigned name for the mitigation method.
• Description: A user-assigned description for the mitigation method.
• ID: A system-assigned identification number for the mitigation method.
• Clone: A button that creates a duplicate of the mitigation method, which is added to the bottom of the list.
• Edit: A button that opens the Edit Mitigation Method dialog (see Mitigation Method Settings).
• Remove: A button that opens a popup in which you can click Remove to remove the method from your organization's collection of mitigation methods (see Remove a Mitigation Method).

The settings pages for mitigation platforms are covered in the following topics:

• Platform Settings Pages
• Common Platform Settings
• Configure Platform Devices
• Configure Platform APIs

Depending on whether you are adding or editing a mitigation platform, the platform's settings are specified in one of the two platform settings pages:

• Add Mitigation Platform page: Use this page to register a new platform with Kentik. To access, click the Add Mitigation Platform button on the Manage Mitigations page.
• Edit Mitigation Platform page: Use this page to edit an already existing platform. To access, click Edit at the top of any existing platform’s pane on the Manage Mitigations page.

While there are some minor differences between these two pages (as noted in the following sections), they largely share the same settings and controls.

Note: In addition to configuring a mitigation platform and method in Kentik, you must also allow the IP ranges 209.50.158.0/23 (IPv4) and 2620:129:1::/48 (IPv6) on third-party mitigation platforms (e.g. Radware or A10) as well as on devices that will be used for Flowspec or RTBH mitigations.

The following controls on the platform settings pages are common to all types of mitigation platforms:

• Cancel button: Click to return to the Manage Mitigations page. All elements will be restored to their values at the time the page was opened.
• Create Mitigation Platform (Add Mitigation Platform only): A button that saves the settings for the new platform and returns you to the Manage Mitigations page.
• Update Mitigation Platform (Edit Mitigation Platform only): A button that saves the changes you've made to the platform settings and returns you to the Manage Mitigations page.
• Select Your Mitigation Type (Add Mitigation Platform page only): A list of the mitigation platform types supported by Kentik (Radware, Cloudflare Magic Transit, RTBH, A10 TPS, and Flowspec). Click on a type to select it.
  Notes:
  - This list includes all supported types, which may include types to which your organization does not actually have access (i.e. if you do not have a Radware, Cloudflare, or A10 mitigation system). Kentik does not automatically verify your choice of mitigation type.
  - 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 type (RTBH, Flowspec, etc.).
• Assign Mitigation Methods: A control set that enables you to assign mitigation methods to this platform:
  - Assigned methods: A list of the methods assigned to the platform. A placeholder appears until methods are assigned. Once methods are added they will be listed by name, and each will have the Copy, Edit, and Unassign Method buttons described in Mitigation Methods List.
  - Add New Method: A button that opens the Add Mitigation Method dialog for the selected mitigation type.
  - Assign Existing Method: A drop-down from which you can choose to add a method that was previously created for this platform.
• Configure: See settings for the following specific platforms:
  - RTBH or Flowspec: See Configure Platform Devices.
  - A10, Cloudflare, or Radware: See Configure Platform APIs.
• Finish Up:
  - Name: User-specified name for the mitigation platform.
  - Description: Optional user-provided description text.

If the type of the mitigation platform is RTBH or Flowspec, the following configure controls are used to set the devices to which mitigations run on this platform will apply:

• Devices list: A list of the devices assigned to the platform. A placeholder will appear unless at least one device is assigned.
• Select Devices: A button that opens a Data Sources Dialog.
  Note: The dialog will show only devices with the following settings in the BGP tab of the Add Devices or Edit Devices dialog in Settings » Network Devices (see Device BGP Settings):
  - For RTBH and Flowspec: The drop-down BGP Type setting is Peer with Device.
  - For Flowspec only: The BGP Flowspec Compatible switch is on. The devices will receive Flowspec rules via MP-BGP.

To choose the devices on which mitigation will be implemented with this platform, click the button and select devices from the dialog. Each selected device will be added to the list as a lozenge that shows the device's name. To remove a device from the list, use the X at the right of its lozenge.

Notes:
- For information about RTBH method configuration, see RTBH Method Details.
- For general information about RTBH, see RTBH Mitigation.
- For information about Flowspec method configuration, see Flowspec Method Details.
- For general information about Flowspec, see Flowspec Mitigation.

If the Mitigation Type is set to a third-party mitigation system (e.g. Cloudflare, A10, or Radware), the configure controls will include the following API-related settings, depending on platform:

• IP Address (A10) or Vision IP Address (Radware): The IP address or URL (https://ip or ip or https://name or name) of the management interface of the third-party mitigation device.
• API Login (Cloudflare or A10) or Vision API Login (Radware): User name from the credentials for the third-party mitigation system.
• API Token (Cloudflare or A10) or Vision API Token (Radware): Token or password for the third-party mitigation system.
• Cloudflare Account ID (Cloudflare): The ID of your Magic Transit account with Cloudflare.
  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.).
• Delete IP (Radware or A10): Kentik continually compares its internal list of mitigations with the third-party mitigation system’s list of resources utilized by Kentik-defined mitigations. This switch determines what happens when Kentik finds resources on the third-party system for mitigations that have been deleted from Kentik:
  - If the switch is on, Kentik will relay to the third-party mitigation system a list of these resources so that they can be deleted.
  - If the switch is off, Kentik will not notify the third-party system about the resources.

Notes:
- Kentik does not automatically verify the provided login username or password. Providing incorrect login information for your third-party mitigation system will cause mitigations based on this mitigation platform to fail.
- For information about third-party method configuration, see Third-party Method Details.
- For general information about third-party mitigation, see Third-party Mitigation.

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.

• Mitigation Method Dialogs
• Method Dialogs UI
• General Method Settings

Note: In addition to configuring a mitigation platform and method in Kentik, you must also allow the IP ranges 209.50.158.0/23 (IPv4) and 2620:129:1::/48 (IPv6) on third-party mitigation platforms (e.g. Radware, Cloudflare, or A10) as well as on devices that will be used for Flowspec or RTBH mitigations.

The settings for mitigation methods are managed in the following dialogs:

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

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

• RTBH: Kentik's implementation of remotely triggered black hole (RTBH) filtering uses BGP to drop undesirable traffic (forward it to a null0 interface) before it enters your network. See RTBH Method Details.
• Flowspec: Kentik's implementation of the traffic matching and traffic actions defined in RFC 8955, which require router support for MP-BGP. See Flowspec Method Details.
• 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 Method Details.

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 General Method Settings).
  - Details: Configurations specific to each platform (see RTBH Method Details, Flowspec Method Details, and Third-party Method Details).
  Note: Cloudflare Magic Transit does not have separate tabs. The only options available are the General Method Settings.
• 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.
• Update Mitigation Method button (Edit Mitigation Method dialog only): Save changes to method settings and exit the dialog.

The following settings and controls, found on the General tab 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.

• 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 Notifications page; see Notifications.
• Settings for Automated Mitigations: A section of settings that apply only to automated mitigations (not to manual mitigations); see Automated Mitigation Settings.

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 Alerting page (select Alerting from the main menu) before the mitigation can proceed.
• 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.

The Details tab of the settings dialog for an RTBH mitigation includes the following fields:

• Commonly Used Communities: Provided for reference only, this list is a helpful reminder of communities commonly used in RTBH (you are not restricted to using one of 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: Next-hop IP addresses (Ipv4 and Ipv6). In some environments these will be the destination IP to blackhole. These numbers have 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.
• Ensure at least /24: A switch that tells Kentik 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).

Notes:
- For an overview of setup procedures for RTBH mitigation, see Configuring RTBH Mitigation.
- For information about RTBH platform configuration, see Mitigation Platform Settings.
- For general information about RTBH, see RTBH Mitigation.

Flowspec mitigation methods are covered in the following topics:

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

Notes:
- For an overview of setup procedures for Flowspec mitigation, see Configuring Flowspec Mitigation.
- For information about Flowspec platform configuration, see Mitigation Platform Settings.
- For general information about Flowspec, see Flowspec Mitigation.

In addition to the settings on the General tab of a mitigation method dialog, configuring a Flowspec-based method involves settings in the following two panes on the Details tab:

• Traffic Matching: Settings (covered in Flowspec Condition Controls) that define a flow specification by identifying traffic with specific characteristics (values or ranges of values for one or more component types).
• Traffic Filtering Actions: Settings (covered in Flowspec Traffic Actions) that specify the actions to take on the traffic subset defined in the Traffic Matching pane.

A flow specification is a filter that matches traffic based on the values of Network Layer Reachability Information (NLRI) "component types" defined in RFC 8955, 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:

• Destination IP/CIDR (type 1): Matches on a range of destination IP addresses.
• Source IP/CIDR (type 2): Matches on a range of source 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. The mitigation can be applied to a very broad range, so carefully consider the values that may be inferred. See Infer From Alarm.
  - 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 enabled for one of these components, 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 (e.g., source or destination IP/CIDR).
• Do not enable the Infer From Alarm switch for both Source and Destination.
• These component types don't support multiple conditions or nested groups.

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

• Protocols (type 3): Matches on IP protocol, e.g. UDP (17). Enter a protocol number into the field at right.
• 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 method can't be used for manual mitigation.
• For an automated mitigation, the protocol or port will be derived by Kentik from the data provided by the alert. See Infer From Alarm.
• 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).

When you create an alert policy, you configure the conditions under which the system will generate an alert. When those conditions have been satisfied and the alert is triggered, the system can then use the data from the alert to construct the advertisement to send to the router (rather than having the user enter that information manually). Enabling the Infer From Alarm switch is what allows the system to do this.

The controls of the Traffic Matching pane are structured as a series of rows that each represents a group of one or more conditions for a specific "component type" (see Flowspec Component Types). 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 the switch beside the group’s title.
• Infer from Alarm: If this switch is on, the remaining fields in the condition group will be locked and ignored. See Infer From Alarm.
  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), Protocols, Ports (source and destination), ICMP codes, and Packet Lengths.
  - 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 RFC 7153).

As described in RFC 8955 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), 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 RFC 8955 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 RFC 8955 section 5, Traffic Filtering, 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 configuration of mitigation methods for use with a third-party mitigation platform is covered in the following topics:

• A10 Method Settings
• Cloudflare Method Settings
• Radware Method Settings

Notes:
- For information about third-party platform configuration, see Mitigation Platform Settings.
- For general information about third-party mitigation, see Third-party Mitigation.
- For a step-by-step setup workflow, see Third-party Mitigation Workflow.

For methods whose platform is A10 Thunder TPS, the controls on the Details tab of the settings dialog include Priority, A10 Mode, and Announce Via BGP Network Statement.

Note: To ensure correct operation of your A10 mitigation, the above settings should be made in consultation with A10 customer support.

For methods whose platform is Cloudflare Magic Transit the settings dialog has no Details tab (there are no Cloudflare-specific method settings).

Notes:
- 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.).
- Cloudflare throttles withdrawal operations to prevent “flapping.” Kentik recommends a minimum 30 minute grace period for Cloudflare methods.

For methods whose platform is Radware DefensePro (v2.7 or greater), the Details tab of the settings dialog includes settings such as Protocol, Use Protocol From Alert Dimension When Available, Ensure at least /24, and Protected Object Name.

Note: To ensure correct operation of your Radware mitigation, the above settings should be made in consultation with Radware and Kentik Customer Support.

The Details tab also includes a set of Mitigation Baselines drop-downs (ICMP Bytes/second, etc.), which each list all of the policies in your organization. You use these selectors to choose the policy in which your new method will be assigned to a policy threshold (see About Alert Thresholds). This ensures that the metric and protocol of the baseline information passed to Radware when the threshold is triggered are the same as the primary metric and protocol used for the threshold's baseline evaluation.

Unless you are creating a mitigation method for an "all traffic" policy, you'll choose a policy for only one of the metrics drop-downs. To choose the drop-down to set, you'll need to know the following information, which is set on the Dataset tab of the alert policy (see Data Funneling) and can also be found in the policy's Policy Details Drawer:

• Primary metric: The metric designated as primary in the tab's Metrics setting.
• Protocol: The protocol (if any) set in the tab's Filter setting.

The table below shows the situations in which the Protocol setting on the mitigation method's Details tab will be used.

To create a Radware-based mitigation method and assign it to a policy threshold:

1. On the Policies page, create the policy to which you'd like to attach a Radware method. For more information on creating a policy, see Adding a Policy.
2. On the Manage Mitigations Page, click the Add New Method button under the Radware platform to open the Add Mitigation Method dialog.
   Note: Each policy that will use baseline evaluation to trigger Radware mitigation should have only one method.
3. On the dialog's General tab, specify the settings in General Method Settings.
4. On the dialog's Details tab, specify the settings discussed above (Protocol, etc.).
5. In the Mitigation Baselines pane, find the dropdown for the protocol (TCP, UDP, or ICMP) and metric (Bytes/second or Packets/second) set on the Dataset tab of the alert policy (see Data Funneling).
   Note: If you didn't set protocol as a dimension in the policy or the method will use the protocol from the Details tab's Protocol selector (see table above) and you've set the selector to Other, please consult with Customer Support.
6. Once the settings of the Add Mitigation Method dialog are fully specified, click the Add Mitigation Method button to create the method and close the dialog.
7. Go to the Policies Page (choose Alerting from the portal's main navbar menu, then click the Manage Policies button at the upper right).
8. In the Policies list, find the policy that you created in step 1, and choose Edit Policy from the Action menu at the right of the row.
9. On the Thresholds tab of the policy's Edit Policy page (see Policy Threshold Settings), use the list at the left to choose the threshold (Critical, Severe, etc.) to which you'd like to attach the mitigation.
10. Scroll down to the Actions pane and use the Mitigations drop-down to choose the mitigation created above. Once a mitigation is selected you can click on the Add Mitigation button to attach the mitigation to this threshold of the policy.

Note: To view additional details regarding the mitigation method, go to the Manage Mitigations page and click on the status icon in the controls at the right of the heading row of the Radware platform pane (see Platform Panes). This will open a Platform Status popup with JSON-formatted information about the platform.

Adding and editing platforms via the Manage Mitigations page (Settings » Mitigations) is covered in the following sections:

• Add a Mitigation Platform
• Edit a Mitigation Platform
• Remove a Mitigation Platform

To add a new mitigation platform:

1. On the Manage Mitigations page, click the Add Mitigation Platform button to open the Add Mitigation Platform page.
2. Select your mitigation type and specify the necessary values for that platform (see Mitigation Platform Settings).
3. Save the new platform by clicking the Create Mitigation Platform button at upper right.

To edit the settings of an existing mitigation platform:

1. On the Manage Mitigations page, within a platform pane, click Edit beside the platform you’d like to edit.
2. Edit the platform’s settings by changing any fields that you'd like to modify (see Mitigation Platform Settings).
3. To save changes, click the Update Mitigation Platform button at upper right.

To remove a platform from your organization's collection of mitigation platforms:

1. On the Manage Mitigations page, click Remove in the top right corner of the pane of the platform you'd like to remove.
2. In the resulting confirmation popup, click the Remove button.

Methods are added, edited, and removed via the Manage Mitigations page (Settings » Manage Mitigations). These operations are covered in the following sections:

• Add a Mitigation Method
• Edit a Mitigation Method
• Remove a Mitigation Method

A mitigation method can only be added to a mitigation platform of the same type (see Add a Mitigation Platform). To add a new mitigation method to a platform:

1. Within a platform pane on the Manage Mitigations page (Settings » Mitigations), click the Add Mitigation Method button to open the Add Mitigation Method dialog.
2. On the General tab, specify general properties of the method (see General Method Settings).
3. On the Details tab, fill in the details fields, which vary by method type:
   - RTBH method: see RTBH Method Details.
   - Flowspec method: see Flowspec Method Details.
   - Third-party method: see Third-party Method Details.
   Note: Cloudflare methods have no Details tab.
4. Save the new method by clicking the Add Mitigation Method button (lower right).

The settings for an existing mitigation method may be edited from the following locations:

• On the Manage Mitigations page, from the Mitigation Methods List in the pane of a platform to which the method is assigned.
• On an Add Mitigation Platform or Edit Mitigation Platform page, from the list of methods under Assign Mitigation Methods (see Common Platform Settings).

In one of the lists above:

1. Click the edit icon (pencil) 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 General Method Settings).
3. To change settings that are specific to the method's mitigation type, use the Details tab:
   - Flowspec method: see Flowspec Method Details.
   - RTBH method: see RTBH Method Details.
   - A10 or Radware method: see Third-party Method Details.
   Note: Cloudflare methods have no details to edit.
4. To save changes, click the Update Mitigation Method button (lower right).
   Note: If you save the changes to your mitigation method, the method will be updated whether or not you saved any changes to the mitigation platform.

To remove a mitigation method from an existing platform:

1. On the Manage Mitigations page, click Edit at the upper right of the pane corresponding to a platform to which the method has been assigned.
2. On the Edit Mitigation Platform page, click the X at the left of the method in the Assign mitigation methods list (see Common Platform Settings).
   Note: The method will be removed from this platform (only) without a confirmation popup.
3. Click Update Mitigation Platform.

To remove a method from your organization's collection of mitigation methods:

1. In one of the following locations, click the Remove icon (red trash can) next to the mitigation method that you'd like to delete:
   - Manage Mitigations page: In the Mitigation Methods List of a mitigation platform pane.
   - Add Mitigation Platform or Edit Mitigation Platform page: In the list under Assign mitigation methods (see Common Platform Settings).
2. In the resulting confirmation popup, click the Remove button.
   Note: The method will be removed from all of the platforms to which it is assigned.