BGP Flowspec technology provides a more granular approach to Denial of Service (DoS) attacks mitigation when compared to old-school methods, such as Remotely Triggered Black Hole (RTBH).
RTBH allows a customer to signal an upstream service provider (SP) to block customer prefixes on the provider’s edge routers when a DoS attack is conducted against these prefixes. The benefits and drawbacks of such an approach are obvious. While this method prevents the customer’s network from being overwhelmed, it also drops legitimate traffic as the customer’s server becomes completely unreachable.
The FlowSpec method, on the other hand, allows operators to define flows rules based on L3 and L4 match criteria (filters) and actions configured on the FlowSpec server. Thus, flow specifications rules are a combination of filters and actions. The rules are then automatically redistributed to FlowSpec clients (BGP speakers) using MP-BGP (SAFI 133), so the clients can take action defined in flow rules.
| NOTE: Filters (match conditions) are transported within the BGP update messages in the BGP FlowSpec NLRI. RFC 8955 (FlowSpec v1) and RFC 8956 (FlowSpec v1 for IPv6) define 13 types of match filters such as destination/source prefixes, IP protocol, upper layer protocol, port, destination/source port, etc. Actions are carried in the extended BGP Communities included as the path attributes in BGP Update messages. There are ten actions defined by RFCs 8955 and 8956, such as traffic rate limited by bytes 0x8006, traffic action 0x8007, etc. |
Figure 1 – Traffic Rate Limited by Bytes 0x8006
We will not go into how FlowSpec works because we explained all the technical details and nuances of FlowSpec along with its configuration in the DDoS Mitigation and BGP Flowspec article. Instead, we will summarize the shortcomings of the current FlowSpec and what improvements the new version of FlowSpec should bring.
As stated in the BGP Flow Specification Version 2 draft, the following issues were detected during the deployment of BGP flow specification v1:
desire to order filters rules ordering of actions to provide deterministic actions problems due to the lack of clear TLV encoding for rules for flow specifications
FlowSpec v2 takes a different approach to rules ordering compared to version 1. FlowSpec v1 does not provide a mechanism where the originator of a BGP Flowspec NLRI can influence its processing order.
In a typical firewall, rules are applied from top to bottom, and the first rule that matches the traffic overrides all the other rules below. The other rules are not checked, and the appropriate action is taken. Unlike the firewall, FlowSpec v1 starts by comparing the left-most components of each FlowSpec NLRI to order FlowSpec rules based on the following algorithm:
Based on the experience of the authors behind the draft, the sorting order provided by FlowSpec v1 is usually sufficient for mitigating DDoS. However, in some cases, rules are sorted in such a way that firewall optimizations are not run efficiently. Therefore, BGP FlowSpec v2 proposes a more explicit approach to rules ordering so the rule processing order can be explicitly defined by the FlowSpec server.
As in version 1, the ordering function to be implemented in FlowSpec v2 is independent of the order of arrival of the flow rules in BGP FlowSPec NLRI. Unlike FlowSpec v1, version 2 defines an order indicator for each rule that specifies the order in which rules are processed.
Furthermore, the inclusion of a name for each rule, filter, and action allows logical indirection. The existing extended community which tags multiple NLRIs could be saved as an indirect reference by name, and the action can be linked to multiple NLRIs. Figure 2 provides a logical diagram of the ordering of rules and the association of names per rule, rule match action, and rule action.
Figure 2 – Order Flow Specification Data FlowSpec v2
The TLV (Type-Length-Value) format of the BGP attribute allows BGP speakers that understand the new attributes to be compatible with BGP speakers that do not support the new attributes. If a path attribute is not recognized, it is ignored and skipped to the next attribute. This is only possible because the length of the attribute is carried along the path in BGP UPDATE packets and is thus known to the receiving BGP speaker.
The AFI/SAFI NLRI for BGP Flow Specification v2 has the following format:
Figure 3 – Flow Specification v2 format
1. Length
The value of the initial length of the field in overall bytes of the Sub-TLVs.
2. Order
The 2 octet field Order indicates the flow specification rule order.
3. Type can be one of the following:
identifier (value = 00),
match rule (value = 01) with default action of block traffic,
match rule (value = 02) with default action of permit traffic,
match rule (value = 03) with action TLVs,
match rule (value = 04) with Wide Communities Action TLVs,
match rule (value = 05) with tunnel matching from [I-D.ietf-idr-flowspec-l2vpn]
match rule (value = 06) with tunnel matching from [I-D.ietf-idr-flowspec-nvo3] 4. Length-tlv
The length of the value part of the Sub-TLV.
5. Value
The series of sub-TLVs fields (TLV) depended on the type value above.
The sort order implemented in BGP FlowSpec v1 works well for DDoS mitigation, but sometimes the implicit order may be problematic. Version 2 of the BGP flow specification protocol addresses this issue and also specifies TLV encoding for rules. However, five years after the first version was released, the document is only a draft, and vendors seem far from implementing it.