The ultimate weapon against DDoS — BGP Flowspec

By on 18 Sep 2024

Category: Tech matters

Tags: , ,

1 Comment

Blog home

As part of my role at FastNetMon, I have worked closely with BGP Flowspec since 2015 (ExaBGPGoBGP) from both the operational and implementation side. In this article, I’ll discuss how the BGP Flowspec protocol (RFC 8955) can allow you to mitigate volumetric Distributed Denial-of-Service (DDoS) attacks without using third-party cloud-based DDoS scrubbing centres. 

What is a volumetric DDoS attack?

A volumetric DDoS is a type of attack that generates a large volume of bandwidth or packet traffic directed at the victim. The bandwidth can range from hundreds of megabits to several hundreds of gigabits. These attacks typically use a method known as amplification.

What’s inside of DDoS packets?

There are hundreds of known volumetric attack types and basically all fields in IPv6 and IPv4 (legacy) headers can be used in an attack:

Figure 1 — IPv6 packet headers.
Figure 1 — IPv6 packet headers. Source.
Figure 2 —IPv4 packet headers.
Figure 2 — IPv4 packet headers. Source.

In reality, most likely we will have the following traffic types involved in DDoS attacks:

  • DNS amplification: UDP, source port 53, may be fragmented, large packets 
  • NTP amplification: UDP, source port 123, may be fragmented, large packets 
  • TCP SYN flood: TCP, SYN flag set, random source ports
  • SSDP amplification: UDP, source port 1900, large packets, may be fragmented 

As you can see, these common attacks do not use all types of L3 / L4 header fields, which allows us to simplify the filtering process.

What do we need to filter malicious traffic?

To filter out packets involved in attacks, we need either a software firewall or a hardware ASIC capable of filtering the most common DDoS attack vectors. Almost all routers (both software and hardware) and switches have an Access Control List (ACL) or firewall functionality, allowing them to filter traffic based on the content of L3 / L4 fields.

In addition to equipment that is capable of filtering malicious traffic, we need a DDoS sensor that can identify malicious traffic patterns and automatically generate filtering rules for particular devices.

What is the issue then?

The main challenge is that each vendor on the market uses a different approach for controlling and programming their ACLs and firewalls, including NETCONF, RESTCONF, gNMI, gRPC, vendor-specific APIs, and command line interfaces via SSH. Supporting and maintaining all these firewall management protocols from the DDoS sensor side is extremely challenging. This is where BGP Flowspec comes in, acting as a ‘lingua franca’ that works across a wide range of vendors with minimal differences.  

BGP Flowspec protocol filtering capabilities

To understand how useful BGP Flowspec is for traffic filtering, we need to familiarize ourselves with the BGP Flowspec filtering criteria, which include:

  • Source prefix (IPv4 or IPv6)
  • Destination prefix (IPv4 or IPv6)
  • IP protocol number
  • List or range of source ports for TCP and UDP
  • List or range of destination ports for TCP and UDP
  • ICMP code
  • TCP flags
  • Packet length
  • Fragmentation flags (do not fragment, is fragment, first or last fragment)
  • DSCP

It’s a fairly comprehensive list of filtering fields, enabling us to block many types of volumetric attacks. However, the absence of the time-to-live (TTL) field is unfortunate, as it could have helped filter out spoofed traffic more efficiently.

BGP Flowspec protocol traffic actions

For DDoS attack mitigation, the primary actions we focus on are discarding and rate-limiting traffic. However, in more complex scenarios, we may need the full range of traffic engineering options provided by BGP Flowspec, such as:

  • Drop
  • Rate limit
  • Accept
  • Mark (DSCP)
  • Redirect to VRF
  • Redirect to next-hop

Which vendors support the BGP Flowspec protocol?

Most of the largest telecom vendors offer robust support for the BGP Flowspec protocol in their BGP daemons, allowing them to receive and announce BGP Flowspec updates. To find out which devices can apply these rules to live traffic, please proceed to the next section.

  • Juniper routers
  • Cisco
  • Nokia
  • Huawei
  • Arista
  • Extreme
  • 6Wind
  • Netscout Arbor
  • Bird (only controller)
  • GoBGP (only controller)
  • ExaBGP (only controller)
  • FRR (only client, can do filtering only via Linux nftables)

In the list above, ‘only controller’ refers to devices that can receive and announce BGP Flowspec rules but cannot perform filtering. ‘Only client’ indicates devices that can receive BGP Flowspec announcements and apply filtering based on the received rules.

Which routers support BGP Flowspec-based filtering?

This is the most important part of the article, as it clearly identifies which models of network equipment can be used as BGP Flowspec-managed DDoS scrubbers:

  • Juniper MX, PTX
  • Cisco ASR 1000, ASR 9000, NCS 5500
  • Nokia SR
  • Huawei 
  • 6WIND VSR
  • Arista 
  • Extreme
  • FRR
  • Netscout Arbor

Is it that easy? Sadly, no, and I have a whole presentation (slides) about the caveats and intricacies of BGP Flowspec implementations on each vendor. 

Vendor-specific BGP Flowspec limitations

From the perspective of the most significant operational limitations in BGP Flowspec implementation, I would like to highlight a few vendors below. These limitations require substantial adjustments to DDoS sensors, making interoperability with other vendors more complex.

Arista

  • For fragment flags, only the ‘Is a fragment’ (IsF) bit is supported for IPv4 packets. Combining source and destination ports with fragment flags in the same rule is not supported.
  • For TCP flags, the ECE, CWR, and NS flags are not supported.

Source.

Extreme

  • Only the IsF bit is supported for BGP Flowspec NLRI sub-component type 12 (Fragment). DF, FF, and LF bit functionalities are not supported.
  • Two-byte TCP flags are not supported.
  • When a rate-limiting action is set under a BGP Flowspec rule, the operational rate value may differ from the specified rate value, as operational values are selected in multiples of 22 Kbps.
  • IPv4 BGP Flowspec rules are applied only to IPv4 data traffic and are not applied to IPv6 data traffic.
  • The following TCP flags are not supported: Explicit Congestion Notification Echo (ECE) and Congestion Window Reduced (CWR).

Source.

6Wind VSR

We received reports from customers using the previous version of VSR software on 5 August 2024, indicating that BGP Flowspec rules with the ‘is-fragment’ fragmentation flag do not apply to all fragmented traffic. 

Cisco ASR 9000

  • A maximum of five multi-value ranges can be specified in a Flowspec rule.
  • Simultaneous configuration of IPv6 first-fragment match and last-fragment match is not allowed on Cisco ASR 9000 series routers, as these options are mutually exclusive.

Source.

Juniper

There is an issue with extremely convoluted dropped traffic monitoring on the Juniper MX platform.

What about cross ASN BGP Flowspec?

You can definitely use BGP Flowspec across Autonomous System Number (ASN) boundaries, and many telecom companies permit it for their customers, often for an additional fee. This approach is highly effective because it enables you to leverage the significant capacity of your carrier to filter out volumetric DDoS attacks without incurring the high costs of expanding bandwidth.

Companies that offer BGP Flowspec support include Core Backbone, Sparkle, RETN, Rascom, SMARTNET (20 rules allowed for free), Inter.Link, and Hurricane Electric (via account manager).

Cross-ASN BGP Flowspec can be quite challenging because carriers must perform extensive rule validation before accepting Flowspec rules into their network. Unfortunately, almost none of the telecom equipment vendors offer a complete BGP Flowspec rule validation framework. As a result, companies often rely on third-party solutions (mainly based on GoBGP or ExaBGP) to handle validation before passing Flowspec rules into their networks.

Due to the lack of standardized communication mechanisms for reporting dropped traffic, we have limited visibility into the effectiveness of each rule (such as how much traffic is discarded by each rule). This can result in deploying more rules than necessary, potentially complicating network management.

Another issue is the hard limit on the number of BGP Flowspec rules. When a customer reaches this limit, the carrier has no choice but to terminate the BGP session. It’s crucial to carefully monitor the number of rules and promptly remove outdated ones once they are no longer effective.

Conclusions

BGP Flowspec is a mature protocol supported by the majority of telecom vendors, allowing you to mitigate the most dangerous volumetric DDoS attacks without the need for third-party DDoS scrubbing centres or proprietary on-premises scrubbing solutions.

If you’d like to add your vendor or company to the list of BGP Flowspec-capable providers, feel free to contact me via email or LinkedIn.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Top