Packet Content Filter for BGP FlowSpec
Internet-Draft draft-cui-idr-content-filter-flowspec-02
Yong Cui
Tsinghua University
Beijing
100084
China
cuiyong@tsinghua.edu.cn
http://www.cuiyong.net/
Yujia Gao
Zhongguancun Laboratory
Beijing
100094
China
+86-185-1028-7458
gaoyj@zgclab.edu.cn
Susan Hares
Hickory Hill Consulting
7453 Hickory Hill
Saline
Michigan
48176
United States of America
+1-734-604-0332
shares@ndzh.com
19 July 2024
Security
IETF
DDoS Mitigation, BGP flow specification
The BGP Flow Specification enables the distribution of traffic filter policies (traffic filters and actions) via BGP, facilitating DDoS traffic filtering. However, the traffic filterer in FSv1 and FSv2 predominantly focuses on IP header fields, which may not adequately address new types of DDoS attack traffic characterized by constant patterns within the packet content. This document introduces a new flow specification filter type designed for packet content filtering. The match field includes otype, offset value, content-length, and content, encoded in the Flowspec NLRI. This new filter aims to augment DDoS defense capabilities.
Introduction
BGP flow specification describes the distribution of traffic filter policies through BGP, allowing for efficient traffic management and DDoS attack mitigation. Existing versions, FSv1 and FSv2, primarily offer n-tuple matching conditions for policy enforcement, enabling actions such as packet dropping, re-directing, or limitation, etc. These filter rules can be propagated to all BGP peers simultaneously without necessitating router configuration changes. Despite their utility, existing filters reliance on IP header fields for traffic filtering is increasingly inadequate for new kinds of DDoS attack. DDoS attacks such as ACK flood, UDP flood, ICMP flood and HTTP flood attacks, etc, have been found to potentially characterise a fixed content in the packet.
This document delineates a new flow specification filter type that facilitates packet content filtering, leveraging otype, offset value, content-length, and content within the Flowspec NLRI to enhance DDoS defense mechanisms.
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Definitions and Acronyms
- DDoS: Distributed Denial of Service
- NLRI: Network Layer Reachability Information
- FSv1: Flow Specification Version 1, defined in [RFC8955] and [RFC8956]
- FSv2: Flow Specification Version 2 define in [draft-hares-idr-flowspec-v2-ddos-00]
The Packet Content Filter for FSv1
This document specifies a new flow specification filter type that is encoded in the BGP FS NLRI and we follow the FSv1 definition format. The packet content filter is defined as follows:
Type TBD – Packet-Content
Encoding:< type (1 octet), value>
The value field is encoded using ptype, otype, offset, content-length, content and mask.
Encoding: < ptype (4 bits), otype (4 bits), offset (2 octets), content-length (1 octets), content (Variable), mask (Variable)>
Ptype Field
The ptype is defined as a 4-bit unsigned integer that defines the packet type via AFI, because some filters are added to hardware that are IPv4 or IPv6 specific.

+-------+-----------------------------+
| Value | Description of Ptype        |
+-------+-----------------------------+
| 1     | IPv4                        |
| 2     | IPv6                        |
+-------+-----------------------------+

Figure 1： Ptype field
Otype and Offset Fields
The otype and offset fields define the starting position of the packet content used for matching.
To avoid the effect of variable header length on the offset, we use the hierarchical way like [draft-khare-idr-bgp-flowspec-payload-match-08]. The Otype is defined as a 4-bit unsigned integer. The detail are as follows:

+-------+-----------------------------+
| Value | Description of Otype        |
+-------+-----------------------------+
| 0     | IP Header                   |
| 1     | IP Payload                  |
| 2     | TCP/UDP Payload             |
+-------+-----------------------------+

Figure 2： Otype field
Otype 0 is defined as the start of the IP header. Otype 1 is defined as the start of the data portion of the IP header after the IP options. Otype 2 is defined as the start of the TCP or UDP data. Type 2 will only be used if it is the Layer 4 transport protocol is TCP (6) or UDP (17). For other IP protocols, type 1 or type 2 can be used.
The offset is defined as a 2-octet unsigned integer that specifies the count of octets to be bypassed from the otype's starting position to match the packet content. It is worth noting that packet fragmentation will cause the offset value to change, so it is not enough to filter the fragmented packets through the packet content filter. One possible way is to filter the first packet through the payload filter, and then use its header information along with the fragment filter to filter the subsequent packets.
Example:
- By setting otype 0 and an offset of 0, the match is configured to start precisely at the beginning of the IP header.
- By setting otype 1 and an offset of 2, the match will start two octets past the initial data portion of the IP header, skipping over any IP options. This configuration, for example, in UDP packets, specifically targets the start of the destination port information.
- By setting otype 2 and an offset of 10, the match will start ten octets into the content of the TCP/UDP packet.
Content-length, Content and Mask Fields
The content-length is a one octet unsigned integer field that contains the length of the value field in octets. Content and mask fields have a same length which defined by the content-length.
The content provides a string to be matched. Based on the information provided by equipment vendors and operators, 8 octets is usually sufficient for the identification of DDoS attacks.
Mask is a string containing 0 and 1, where 1 represents what will be matched and 0 represents characters that can be ignored.
The content and mask are operated AND by bit to get the final content of the packet that needs to be matched.
Example of Encoding
An example of a FlowSpec NLRI encoding for:"all packets to 192.0.2.0/24 and have fixed content 5858 in the tcp payload with offset of 0".
length | destination | packet content
0x0b | 01 18 c0 00 02 | TBD 40 12 00 00 02 58 58 ff ff
An example of a FlowSpec NLRI encoding for:"all packets to 192.0.2.0/24 and have fixed content 5858 in the tcp payload with offset of 0".
Value | Description |
0x0f | length | 15 octets (if len<240, 1 octet)
0x01 | type | Type 1 - Destination Prefix
0x18 | length | 24 bits
0xc0 | prefix | 192
0x00 | prefix | 0
0x02 | prefix | 2
TBD | type | Type TBD - Packet Content
0x40 | length | 64 bits
0x12 | ptype, otype | IPv4, TCP payload
0x0000 | offset | 0 octets
0x02 | content-length | 2 octets
0x5858 | content | 0x5858
0xffff | mask | 0xffff
The Packet Content Filter for FSv2
Filter Encoding
To adapt to the updates of flowSpec, this document also gives the definition of the packet content filters in FSv2. The formate is as same as the NLRI formate for extented IP filters, as shown in Figure 3:

+--------------------------------+
| NLRI length (2 octets)         |
+--------------------------------+
| TLVs+                          |
| +============================+ |
| | order (4 octets)           | |
| +----------------------------+ |
| | identifier (4 octets)      | |
| +----------------------------+ |
| | FSv2 Filter type = 2       | |
| +----------------------------+ |
| | length TLVs (2 octet)      | |
| +----------------------------+ |
| +----------------------------+ |
| + +------------------------+ + |
| + |FSv2 filters version    | + |
| + +------------------------+ + |
| + | Sub-TLVs               | + |
| + +------------------------+ + |
| +----------------------------+ |
+--------------------------------+

Figure 3： NLRI formate for extented IP filters
The formate of Sub-TLVs is showns in Figure 4:

+----------------------------+
|  Component Type (1 octet)  |
+----------------------------+
|  Length (1 octet)          |
+ ---------------------------+
|  Value (variable)          |
+----------------------------+

Figure 4: formate for Sub-TLV
The defination of packet content filter in sub-TLV formate are as follows:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |Component Type | Component Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | Otype |             Offset            | Content Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Content                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Mask                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Defination of the packet content filter
where fileds have the same length as FSv1.
Encoding: < ptype (4 bits), otype (4 bits), offset (2 octets), content-length (1 octets), content (Variable), mask (Variable)>
Filter Ordering Rule
Compared to FSv1, FSv2 adds filter ordering function. According to the defination of ordering rules in FSv2, the transmission of SubTLVs within a flow specification rule MUST be sent ascending order by SubTLV type. If the SubTLV types are the same, then the value fields are compared using mechanisms defined in [RFC8955] and [RFC8956] and MUST be in ascending order.
However, due to multiple fields in the value of the packet content filter, the mechanisms defined in [RFC8955] and [RFC8956] do not apply. To give the default ordering rules of packet content filters, this document gives the defination as follows:
1. Filters with a larger content-length are implemented first.
2. If they have the same content-length, compare otype and the larger type is implemented first.
3. If they have the same content-lengte and otype, compare offset and the larger value will be implemented first.
4. If they have the same content-length, otype, and offset, compare the content as a binary string using the memcmp() function as deﬁned by [ISO_IEC_9899]. The common preﬁx is compared. If the common preﬁx is not equal, the string with the lower preﬁx has higher precedence.
When there are multiple component exist in multiple NLRI, determine the order of the packet content filters according to the above ordering rules.
Use Cases
Here is a use case for ordering rules with multiple NLRI and multiple components. There are five components, with the same destination IP and user order, each of which contains a packet content filter with different values:

User-Order – 10

FSv2 – NLRI with Extended IP Filters

Component 1 - Destination IP + Packet content filter (otype 0, offset 50, content-length 2, content 0x1111) - Rate Limit

Component 2 - Destination IP + Packet content filter (otype 0, offset 50, content-length 3, content 0x111122) – Discard

Component 3 - Destination IP + Packet content filter (otype 2, offset 70, content-length 2, content 0x1111) - Rate Limit

Component 4 - Destination IP + Packet content filter (otype 2, offset 70, content-length 3, content 0x111122) – Discard

Component 5 - Destination IP + Packet content filter (otype 2, offset 70, content-length 3, content 0x111133) - Rate Limit

The rules will be installed as:

User-Order – 10

Component 4 - Destination IP + Packet content filter (otype 2, offset 70, content-length 3, content 0x111122) – Discard

Component 5 - Destination IP + Packet content filter (otype 2, offset 70, content-length 3, content 0x111133) - Rate Limit

Component 2 - Destination IP + Packet content filter (otype 0, offset 50, content-length 3, content 0x111122) – Discard

Component 3 - Destination IP + Packet content filter (otype 2, offset 70, content-length 2, content 0x1111) - Rate Limit

Component 1 - Destination IP + Packet content filter (otype 0, offset 50, content-length 2, content 0x1111) - Rate Limit

IANA Considerations
In accordance with the procedures outlined for managing the "Flow Spec Component Types" registry, IANA is hereby requested to assign a new Type Value. This assignment is sought from the First Come First Served range, as detailed below:

+------------+---------------------------+---------------+
| Type Value | Name                      | Reference     |
+------------+---------------------------+---------------+
| TBD        | Packet Content filter     | this document |
+------------+---------------------------+---------------+

The introduction of the "Packet Content filter" Type Value is purposed to expand the capability of BGP FSv1 by enabling more granular control over traffic filtering.
This is especially pertinent for addressing complex patterns within packet content that are characteristic of Distributed Denial of Service (DDoS) attacks and other security challenges. The proposed Packet Content filter facilitate the specification of detailed criteria for traffic matching, including but not limited to, content inspection at specific packet offsets. In the following update we will add the definition of FSv2.
Security Considerations
No new security issues are introduced to the BGP protocol by this specification
Normative References
[RFC8955]

Dissemination of Flow Specification Rules
C. Loibl
S. Hares
R. Raszuk
D. McPherson
M. Bacher
December 2020
RFC 8955
DOI 10.17487/RFC8955
[RFC8956]

Dissemination of Flow Specification Rules for IPv6
C. Loibl, Ed.
R. Raszuk, Ed.
S. Hares, Ed.
December 2020
RFC 8956
DOI 10.17487/RFC8956
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Acknowledgements
We wish to thank Susan Hares, Jeffery Hass and Li Yang for their valuable comments and suggestions on this document.