Custom HTTP Headers for v2 Webhook Notification

The custom webhook notification method in v2 notifications (/v4/settings/notifications) now supports the ability to customize the HTTP headers and values sent with the request, in addition to the request body.

Among other uses, this allows users to provide authorization credentials for API endpoints that require it.

Additional v2 Notification Methods

Notifications v2 now supports all of the notification methods that were supported in notifications v1, along with a few new ones like Microsoft Teams, VictorOps and xmatters.

In addition, with customizable HTTP headers and request body templates in the Custom Webhook method, it should now be possible to do one-off integrations with virtually any third party API.

NOTE: Some notification methods are not yet available to select as destinations for Synthetics notifications. Template updates are required for these methods to properly present the different data fields associated with Syn notifications.

v2 Notification Support for v4 DDoS Policies

v4 DDoS policies now support the selection of both v1 and v2 notification methods as destinations for alert notifications. In the thresholds section of the policy configuration, users will now see both v1 and v2 methods shown in the drop-down list.

Each available notification channel is labeled with the notification method type, though we do not distinguish between v1 and v2 types since these are not user-facing designations. We’ve also temporarily removed the link to the v1 notifications configuration page until we have migrated all v1 methods to v2.

Native v4 UI Forms for Mitigation Configuration

Mitigation platforms and methods are now configured via a native v4 UI form. The new form combines platform and method configuration onto a single page with a better UX that shows which methods are associated with each platform.

The new form also removes the limitation on configuring both RTBH and flowspec mitigation methods on the same router.

Ratio-based Thresholds

We’ve added an additional threshold type for DDoS policies, which allows the user to compare two different metrics that are measured by the policy. Along with this, we’ve added some additional metrics that measure separate inbound and outbound packets/sec and bits/sec rates. The metrics that are compared in a ratio-based threshold must be metrics that are configured as primary or secondary metrics for the policy.

Some use cases where ratio-based thresholds can be useful:

• DDoS policies: Comparing bits/sec in to bits/sec out can make it very easy to detect attacks for content / server destinations, since these resources almost always have a much greater traffic volume out than in. If this ratio reverses, it can be indicative of an attack and ratio-based detection doesn’t require knowledge of the actual traffic volumes.
• Peering policy violation: Many settlement-free peering agreements are based on exchanging traffic with the other party at 1:1 ratio. Setting a ratio-based threshold on a policy that looks at interface traffic in / out can detect possible violation of agreement terms by the other party.

Ratio-based policy thresholds allow the ratio to be compared in both directions (i.e. A:B and B:A) or one direction only. In the both directions case, an optional margin parameter effectively lets the user define a “band” of acceptable ratios, with values above or below the band triggering the threshold condition.