Overview:

BGP FlowSpec (Border Gateway Protocol Flow Specification) is an extension of the BGP protocol used to define traffic filtering rules on routers or, more simply, to generate firewall rules on routers from a BGP announcement. Unlike conventional BGP, which routes based on IPv4/IPv6 and prefix information, BGP FlowSpec allows network administrators to specify more granular criteria for packet forwarding, including layer 4 information (TCP/UDP ports) and even packet patterns.

To find out more about BGP Flowspec, visit our article on what BGP Flowspec is here.

Operation:

BGP FlowSpec works by adding new types of attributes to BGP, allowing network administrators to specify detailed filtering rules. These rules can include criteria such as:

  • IPv4/IPv6 source and destination addresses
  • TCP/UDP ports
  • Protocols
  • Bit masks
  • Package field values

The following actions can be taken with BGP FlowSpec:

  1. deny: Blocks the traffic corresponding to the rule.
  2. rate-limit: Limits the traffic rate corresponding to the rule.
  3. redirect: Redirects the traffic corresponding to the rule.
  4. sample: Collects a sample of the traffic corresponding to the rule.
  5. mark: Marks packages matching the rule with a specific mark.
  6. redirect-to-ip: Redirects the traffic corresponding to the rule to a specific IP address.
  7. traffic-rate: Limits the traffic rate corresponding to the rule to a specific value.
  8. traffic-action: Defines action for the corresponding traffic, such as accept, discard or forward.
  9. redirect-to-blackhole: Silently discards all traffic corresponding to the rule.

When these rules are propagated through the BGP network, routers can use this information to filter or manipulate traffic according to the defined policies.

Operation – More Details:

In the context of BGP FlowSpec, the actions are specified as part of the filter rules. Each filter rule contains three main parts:

  • Matching Fields: These specify the Matching Fields: criteria, such as source and destination IP addresses, TCP/UDP ports, protocols, bit masks and packet field values.
  • Action Fields: These specify the actions to be taken for the traffic that corresponds to the rule.
  • Protocol Fields: Specify the protocol that the filter rule should apply.

Actions in BGP FlowSpec are coded using BGP communities. Each action is mapped to a specific BGP community:

  • The‘deny‘ action can be represented by a specific BGP community, such as ‘65535:666’.
  • The‘rate-limit‘ action can be represented by another specific BGP community, such as ‘65535:777’.
  • The‘redirect‘ action can be represented by a different BGP community, such as ‘65535:888’.

When you create a BGP FlowSpec rule, you specify the matching fields, the desired action and, optionally, protocol fields. This rule is then encoded as a BGP community and included in a BGP update message that is sent to neighboring routers. The routers that receive this rule apply the specified actions to the packets that match the matching criteria.

Please note that the specific BGP communities for each action may vary depending on the BGP FlowSpec implementation on your network equipment. I recommend consulting your equipment’s documentation for detailed information on the BGP communities associated with each action in BGP FlowSpec.

Use Cases:

1. **DDoS attack mitigation:

BGP FlowSpec can be used to block or redirect malicious traffic during distributed denial of service (DDoS) attacks. Precise rules can be applied to filter out unwanted traffic and keep services online.

2. **QoS (Quality of Service) policies:

Network administrators can use BGP FlowSpec to guarantee quality of service by prioritizing certain types of traffic based on specific ports or protocols.

3. **Implementing Security Policies**:

BGP FlowSpec can be used to implement granular security policies, blocking traffic associated with malware or suspicious activity.

Configuration examples:

The BGP FlowSpec configuration may vary depending on the network equipment used.

This example explores how to design a DDoS mitigation solution in which a service provider allows its customers to advertise BGP FlowSpec routes to it.

It also discusses some of the best practices that should be considered before implementing this type of solution and, finally, some of the Junos commands available to help you check that your Flow-spec solution is working correctly.

Topology scenario for the example:

Let’s start by taking a look at how our solution will be configured:

As we can see from the topology above, there is the BORDA, which is a Juniper device that acts as the network’s BGP router. Made4Flow which is the software that will analyze the flows and generate rules of BGP FlowSpec dynamically and announce it via BGP to the BGP router called BORDA.

In this scenario, the example attack is a DNS amplification attack. This means that the network is receiving a large volume of UDP port 53 packets that it doesn’t actually need for the ISP to function normally.

The attack fills the circuit between the ISP and the operators and effectively renders the network inoperable.

When the attacker decides to launch the attack, the ISP can use the Made4Flow to generate a BGP FlowSpec route for UDP port 53 packets only and announce it to the BORDA BGP Router, which can turn this route into a firewall filter on its communication interfaces with the Operators.

And then this blocks the DNS amplification packets at the edge of the ISP’s network and also at the carrier (if the carrier supports FlowSpec sessions), but allows legitimate traffic to continue arriving.

First, let’s look at the BGP FlowSpec session settings on the BORDA BGP router with Made4Flow, assuming that the router is already configured for normal BGP unicast routing (Normal BGP session for announcing Blackhole or Mitigation/Scrubbing Center routes).

To configure a BGP FlowSpec session on Juniper devices, we use the following commands:

set routing-options flow term-order standard
set protocols bgp group MADE4FLOW type internal
set protocols bgp group MADE4FLOW local-address 10.70.0.67
set protocols bgp group MADE4FLOW family inet unicast
set protocols bgp group MADE4FLOW family inet flow no-validate FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 description IBGP_MADE4FLOW
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 local-adddress 10.70.0.67
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 import FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow prefix-limit maximum 1000
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow no-validate FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow legacy-redirect-ip-action receive
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 export DENY-ALL
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 peer-as XXXXXX

Good practices:

There are best practices for protecting this solution. Both the BGP FlowSpec routes and the resulting firewall filters they create are finite resources in the router.

Therefore, the BGP BORDA router can filter incoming routes to ensure that it receives too many unexpected routes or wrong routes.

Prefix Limit:

So the first thing to do is to set a prefix limit for BGP FlowSpec routes.

You could simply define a single prefix limit for the routes inet unicast e inet flowroutes, however, this example will define a separate limit for the inet flow. So that Made4Flow can only send ten BGP Flowspec routes at a time, let’s set the prefix limit to 10 (this setting should be adjusted according to each scenario):

set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow prefix-limit maximum 10

Route Policy :

The next thing to do is to apply an inbound route policy. This policy will limit the router to receiving prefixes that are from the ISP itself with prefixes /24 to /32, which are those announced by Made4Flow.

Let’s also add a Community 64496:86 so that it can identify the routes as BGP FlowSpec routes.

For all other routes, you can simply filter them based on the client’s route assignment:

1. Create the policy definition:

set policy-options community COMM-FLOWSPEC members 64496:86
set policy-options policy-statement FLOWSPEC_IMPORT term 1 from rib inetflow.0
set policy-options policy-statement FLOWSPEC_IMPORT term 1 from route-filter 203.0.113.0/24 prefix-length-range /24-/32;
set policy-options policy-statement FLOWSPEC_IMPORT term 1 then community add COMM-FLOWSPEC
set policy-options policy-statement FLOWSPEC_IMPORT term 1 then accept 
set policy-options policy-statement FLOWSPEC_IMPORT term 999 then reject

2. Apply the policy as an import policy in the BGP session with Made4Flow:

set protocols bgp group MADE4FLOW family inet flow no-validate FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 import FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow no-validate FLOWSPEC_IMPORT

Maximum prefixes:

The last thing to do is to set a maximum number of BGP FlowSpec prefixes that can be installed in the routing table.

This example sets a maximum of 10,000 routes, but let’s also configure the router to notify the administrator via a syslog message when a 90% limit is reached. This setting must be applied to all routers in the example ISP’s network:

set routing-options rib inetflow.0 maximum-prefixes 10000 threshold 90

It may not be very intuitive to understand in the syntax above, but the conf. threshold 90 is what tells the router that you want a syslog message when the 90% threshold is reached.

Verification:

The first thing to check is that BGP FlowSpec is configured correctly. Let’s look at the NLRIs that are activated in the BGP peer.

Checking the NLRI: From operational mode on the BORDA router, enter the Junos OS command show bgp neighbor 10.70.0.68 and look for the inet-flow capability in the output:

lab@BORDA> show bgp neighbor 10.70.0.68
Peer: 10.70.0.68+45824 AS 64511 Local: 192.0.2.0+63720 AS 64496
 Type: External State: Established Flags: <Sync>
 Last State: OpenConfirm Last Event: RecvKeepAlive
 Last Error: None
 Import: [ CUST-IN ]
 Options: <Preference LocalAddress AddressFamily PeerAS PrefixLimit Refresh>
 Address families configured: inet-unicast inet-flow
 Local Address: 10.70.0.67 Holdtime: 90 Preference: 170
 Number of flaps: 0
 Peer ID: 10.70.0.68 Local ID: 10.70.0.67 Active Holdtime: 90
 Keepalive Interval: 30 Group index: 1 Peer index: 0
 BFD: disabled, down
 Local Interface: ge-0/0/3.0
 NLRI for restart configured on peer: inet-unicast inet-flow
 NLRI advertised by peer: inet-unicast inet-flow
 NLRI for this session: inet-unicast inet-flow
 Peer supports Refresh capability (2)
 Stale routes from peer are kept for: 300
 Peer does not support Restarter functionality
 NLRI that restart is negotiated for: inet-unicast inet-flow
 NLRI of received end-of-rib markers: inet-unicast inet-flow
 NLRI of all end-of-rib markers sent: inet-unicast inet-flow
 Peer supports 4 byte AS extension (peer-as 64511)
 Peer does not support Addpath
 Table inetflow.0 Bit: 10000
 RIB State: BGP restart is complete
 Send state: in sync
 Active prefixes: 1
 Received prefixes: 1
 Accepted prefixes: 1
 Suppressed due to damping: 0
 Advertised prefixes: 0
 Table inet.0 Bit: 20000
 RIB State: BGP restart is complete
 Send state: in sync
 Active prefixes: 1
 Received prefixes: 1
 Accepted prefixes: 1
 Suppressed due to damping: 0
 Advertised prefixes: 0
 Last traffic (seconds): Received 13 Sent 28 Checked 4
 Input messages: Total 392 Updates 4 Refreshes 0Octets 7552
 Output messages: Total 386 Updates 0 Refreshes 0Octets 7435
 Output Queue[0]: 0 (inetflow.0, inet-flow)
 Output Queue[1]: 0 (inet.0, inet-unicast)

Checking Routes:

The next thing to look at is the flow route that was sent by Made4Flow and received at the BORDA:

lab@BORDA> show route receive-protocol bgp 10.70.0.68 extensive table inetflow.0
inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
* 203.0.113.1,*,proto=17,dstport=53/term:1 (1 entry, 1 announced)
 Accepted
 Nexthop: Self
 AS path: 64511 I
 Communities: traffic-rate:0:0

And here the route is being received from Made4Flow. Note that the only community attached to the route is the one that specifies that you should set a rate of 0 for the traffic.

Now let’s take a look at the route in the BGP BORDA router’s routing table:

lab@BORDA> show route table inetflow.0 extensive
inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
203.0.113.1,*,proto=17,dstport=53/term:1 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): discard,count
Page 0 idx 1, (group ibgp type Internal) Type 1 val 0x966ef08 (adv_entry)
 Advertised metrics:
 Nexthop: Self
 Localpref: 100
 AS path: [64496] 64511 I
  Communities: 64496:86 traffic-rate:0:0
Page 0 idx 2, (group RR-CLIENT-FLOWSPEC type Internal) Type 1 val 0x966f11c (adv_
entry)
 Advertised metrics:
 Nexthop: Self
 Localpref: 100
 AS path: [64496] 64511 I
 Communities: 64496:86 traffic-rate:0:0
Path 203.0.113.1,*,proto=17,dstport=53 from 10.70.0.68 Vector len 4. Val: 1 2
 *BGP Preference: 170/-101
 Next hop type: Fictitious
 Address: 0x9358c04
 Next-hop reference count: 1
 State: <Active Ext>
 Local AS: 64496 Peer AS: 64511
 Age: 3:27:43
 Validation State: unverified
 Task: BGP_64511.10.70.0.68+45824
 Announcement bits (2): 0-Flow 1-BGP_RT_Background
 AS path: 64511 I
 Communities: 64496:86 traffic-rate:0:0
 Accepted
 Validation state: Accept, Originator: 10.70.0.68
 Via: 203.0.113.0/24, Active
 Localpref: 100
 Router ID: 10.70.0.68

The route has been installed in the route table in BORDA and Community 64496:86 that was assigned was added to the route.

See that the flow has been matched to the unicast route and validated for consistency.

So we continue…

Checking the firewall filters:

Now that the flow routes have been validated, they are turned into firewall filters.

Let’s take a look at the firewall filter:

lab@BORDA> show firewall filter __flowspec_default_inet__
Filter: __flowspec_default_inet__
Counters:
Name Bytes Packets
203.0.113.1,*,proto=17,dstport=53 0 0

All OK.

Check the system log:

EXAMPLE: If you have followed the best practices above and set a prefix limit in the BGP session, you will see a log message when the maximum is reached:

lab@BORDA> show log messages | match BGP_PREFIX
Sep 5 17:51:04 pe3 rpd[2812]: BGP_PREFIX_LIMIT_
EXCEEDED: 10.70.0.68 (External AS 64511): Configured maximum prefixlimit(1) exceeded for inet-flow nlri: 2 (instance master)

Final summary of the example:

As we can see, configuring a BGP FlowSpec solution is simple.

Between ISPs it can become a little more complicated, as it requires coordination between the client and the service provider. Unfortunately, not all operators provide FlowSpec sessions.

Check with your operator about this possibility, as it is essential to have this configured in advance of a DDoS attack.

Find out more about how to optimize traffic forwarding with BGP FlowSpec and simplify network security management! Explore Made4Flow, our netflow analysis tool, and take your network infrastructure to the next level.

Get to know Made4Flow