In traditional methods for DDoS mitigation, such as RTBH (remotely triggered blackhole), a BGP route is injected, advertising the IP address of the server under attack with a special community (666). This special community on the border routers sets the next hop to a special next hop to discard/null, thus preventing traffic from suspect sources into your network. This method enables customers to signalize providers to drop DDoS traffic sent to a prefix under attack on their edge routers. However, the legitime traffic is being dropped as well so the server is completely unreachable.
| Note: Typically, the IP address 192.0.2.1 is used for the next hop that should not be reachable. The IP is reserved for use in test networks. It is not used as a deployed IP address. |
BGP Flowspec is an alternative and a more granular method to RTBH described in RFC5575 that can be used to mitigate a distributed denial-of-service (DDoS) attack. Match criteria allow network operators to define a particular flow with source, destination, L4 parameters and packet specifics such as length. These are sent in a BGP UPDATE message to BGP border routers within FLOW_SPEC_NLRI along with the action criteria. Actions are carried in the extended communities Path attribute. They can drop traffic matching the flow specification, redirect traffic to a particular VRF for further analysis or policy traffic at a defined rate.
In other words, BGP Flowspec resembles access lists created with class-maps and policy-maps that provide matching criteria and traffic filtering actions. They are injected to BGP and propagated to BGP peers. This mechanism allows an upstream AS system to perform inbound filtering in their ingress routers of traffic that a downstream AS wishes to drop or policy.
BGP uses NLRI to exchange routing details between BGP speakers. Each of the Multi-protocol BGP (MP-BGP) extensions have their own NLRI that are identified by their Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI). BGP flowspec defines a new Multiprotocol Network Layer Reachable Information (MP_REACH_NLRI) with AFI 1 (IPv4) and Subsequent AFI (SAFI) 133 (Flow Spec Filter). The Flow Spec NLRI collects 12 types of Layer 3 and Layer 4 filters used to define a flow specification. Those are the fields that are added to NLRI within the BGP Update Message and advertised to peers.
| Note: The default routes for BGP peers are IPv4 unicast routes. MP-BGP specifies the relevant NLRI when non-IPv4 unicast routes (e.g. IPv6 or Flowspec) are exchanged between BGP peers. Flowspec (SAFI 133) as another Multiprotocol extension is negotiated during the BGP Open phase (Picture 1). |
Network infrastructure with the enabled BGP Flowspec consists of a Flowspec controller (server), one or more Flowspec clients and optionally a route-reflector. Rules that contain matching criteria and actions are created on the server and are redistributed to clients via MP-BGP. The client receives the rules from the controller and programs rules to TCAM. An additional optional route reflector component can be used to receive rules from the controller and distribute to its clients.
Picture 1: BGP OPEN Message with Flowspec Capability (SAFI 133)
A BGP UPDATE message with the Flow Spec NLRI is depicted in Picture 2. The FlOW_SPEC_NLRI contains the following matching criteria. We can define up to 12 different types of criteria. A specific packet is considered to match the flow specification when it matches the intersection (AND) of all the components presented.
Type 1 – Destination prefix (195.165.0.1/32)
Type 3 – IP Protocol – 17 (UDP)
Type 5 – Destination port – 53 (DNS)
Picture 2: MP_REACH_NLRI – AFI 1 / SAFI 133 with Flow Spec NLRI
The action for matching criteria is carried out as extended communities (Picture 3). The traffic rate 0 means that traffic, matching criteria specified in Flow Spec NLRI, is dropped.
Picture 3: Path Attribute EXTENDED_COMMUNITIES Dropping Traffic
Picture 4 depicts a network topology with a central controller configured on the CE1 (AS64501) router and two clients in ISP1 (AS64500) network. Once Customer1 detects a DDoS attack targeting a destination UDP port 53 (DNS) on the server 196.156.0.1/24, the BGP update with Flowspec SAFI 133 is advertised to ISP1 PE1. The UPDATE message contains flow specification, matching the 195.165.0.1/32 prefix, UDP protocol (17) and destination port 53 (Picture 2). The action criterion that drops traffic matching flow specification, are carried as BGP extended communities (Picture 3). Subsequently, the router PE1 sends the BGP update to the router PE2. The provider edge router PE2 with enabled Flowspec on the interface Gi0/0/0/1 programs the rules into TCAM. Traffic received from CE2 that corresponds to the match criteria is dropped.
Picture 4: Flowspec Controller on Customer Side and Two Flowspec Clients in Provider’s Network
Create class-map attack-fs matching the IP address of the Web/DNS server – 195.165.0.1, protocol (17) – UDP and destination port 53 (DNS).
class-map type traffic match-all attack-fs match destination-address ipv4 195.165.0.1 255.255.255.255 match protocol 17 match destination-port 53 end-class-map
Configure policy-map attack_pbr and associate class-map attack-fs. Use the class-map to define an action.
policy-map type pbr attack_pbr class type traffic attack-fs drop class type traffic class-default end-policy-map
We need to define a route policy that allows exporting and importing routes to/from eBGP peers.
route-policy PASS pass end-policy router bgp 64501 bgp router-id 4.4.4.4 address-family ipv4 unicast network 195.165.0.0/24 address-family ipv4 flowspec
Configure eBGP neighbor 12.0.0.2 with inbound and outbound IPv4 policy for IPv4 Unicast address family in order to send and/or receive IPv4 routes.
neighbor 12.0.0.2 remote-as 64500 address-family ipv4 unicast route-policy PASS in route-policy PASS out
Configure inbound and outbound IPv4 Flowspec policy for eBGP neighbor 12.0.0.2.
address-family ipv4 flowspec route-policy PASS in route-policy PASS out
Configure flowspec and assign service-policy type PBR policy-map attack_pbr.
flowspec address-family ipv4 service-policy type pbr attack_pbr
Picture 5 depicts the Flowspec definition and action drop on the BGP-FS server (CE1 router).
RP/0/0/CPU0:CE1# show flowspec ipv4 detail
Picture 5: Flow Definition with Action Drop on Flowspec Server CE1
router bgp 64500 bgp router-id 2.2.2.2 address-family ipv4 unicast address-family ipv4 flowspec neighbor 10.0.0.2 remote-as 64500 address-family ipv4 unicast next-hop-self address-family ipv4 flowspec
Configure eBGP neighbor 12.0.0.1 with inbound and outbound IPv4 policy for IPv4 Unicast address family in order to send and/or receive routes.
neighbor 12.0.0.1 remote-as 64501 address-family ipv4 unicast route-policy PASS in route-policy PASS out
Configure inbound and outbound IPv4 Flowspec policy for eBGP neighbor 12.0.0.1.
address-family ipv4 flowspec route-policy PASS in route-policy PASS out
Install flowspec policy locally to all interfaces.
flowspec address-family ipv4 local-install interface-all
route-policy PASS pass end-policy router bgp 64500 bgp router-id 1.1.1.1 address-family ipv4 unicast address-family ipv4 flowspec neighbor 10.0.0.1 remote-as 64500 address-family ipv4 unicast next-hop-self address-family ipv4 flowspec
Configure eBGP neighbor 11.0.0.1 with inbound and outbound IPv4 policy for IPv4 Unicast address family in order to send and/or receive routes.
neighbor 11.0.0.1 remote-as 64502 address-family ipv4 unicast route-policy PASS in route-policy PASS out address-family ipv4 flowspec
Install flowspec policy locally to all interfaces.
flowspec address-family ipv4 local-install interface-all
BGP table for address family IPv4 Flowspec is depicted in Picture 6. The table contains a single entry a destination network 195.165.0.1/32, UDP protocol and destination port 53.
RP/0/0/CPU0:PE2# show bgp ipv4 flowspec
Picture 6: BGP IPv4 Flowspec Table on PE2
BGP Flowspec technology provides a more granular approach to DDoS attacks mitigation when compared to old-school methods, such as RTBH. This is accomplished by a specific definition of flows based on L3 and L4 matching criteria and action, configured on the FlowSpec server. The rules are automatically redistributed to FlowSpec clients using MP-BGP (SAFI 133), so the clients can take action defined in rules.
So far, multiple network vendors such as Cisco, Juniper, Arista, Nokia support BGP FlowSpec in their product, at least in a controller role. For instance, FlowSpec client is implemented in Cisco Series Aggregation Services Routers ASR9000 (IOX-XR), ASR1000 (IOS-XE), while FlowSpec controller in ASR9000, CRS, NCS6000, XR12000 routers. FlowSpec controller can be found in Quagga, Bird, Arbor, ExaBGP as well, and also in the software implementation of hardware routers/switches (Cisco IOS-XRv, Arista vEOS).
However, to use BGP Flowspec as a viable DDoS attack mitigation solution there is a need for a collaborative approach with other ISPs and Service providers. Unfortunately, there is still a small number of carriers that allow one to propagate the rules. To get more traction with BGP Flowspec network professionals should ask their providers for it more often.