]> Tsinghua University

Beijing 100084 China cuiyong@tsinghua.edu.cn http://www.cuiyong.net/

Zhongguancun Laboratory

Beijing 100094 China +86-185-1028-7458 gaoyj@zgclab.edu.cn

Hickory Hill Consulting

7453 Hickory Hill Saline Michigan 48176 United States of America shares@ndzh.com

Huawei

156 Beiqing Road Beijing 100095 China jie.dong@huawei.com

Routing IDR DDoS Mitigation, BGP flow specification The BGP FlowSpec mechanism enables the distribution of traffic filter policies (traffic filters and actions) via BGP, facilitating DDoS traffic filtering. The IP filter components defined for FSv1 and the FSv2 IP Basic Filter Families primarily match fields in the IP and transport-layer headers, which may not adequately address volumetric DDoS attack traffic characterized by fixed patterns within the packet content. This document defines a Packet Content Filter Component for FSv1 and FSv2. The match is encoded using OType, Offset, Content Length, Content, and Mask fields in the FlowSpec NLRI. The FSv1 encoding additionally carries a PType field. This new component aims to leverage capable network devices to support controlled traffic handling, traffic optimization, and mitigation of simple volumetric DDoS attacks, reducing the overall processing cost of carrier networks.

Introduction BGP FlowSpec describes the distribution of traffic filter policies through BGP, allowing for efficient traffic management and DDoS attack mitigation. The IP filter components in FSv1 and the FSv2 IP Basic Filter Families primarily offer n-tuple matching conditions for policy enforcement, enabling actions such as packet dropping, re-directing, or other actions. FlowSpec routes can be distributed to participating BGP speakers subject to AFI/SAFI negotiation and local BGP policy. Despite their utility, these IP filter components may be insufficient for some operational scenarios where packets can be identified by fixed content patterns. Such scenarios may include DDoS mitigation, traffic filtering, and traffic optimization. Some attacks or traffic classes may contain fixed patterns in the packet payload that can be matched at known offsets. This document defines a Packet Content Filter Component for FSv1 and FSv2. It supports packet content filtering by using OType, Offset, Content Length, Content, and Mask fields within the FlowSpec NLRI. The FSv1 encoding additionally carries a PType field. This component is intended for controlled operational use cases such as traffic filtering, traffic optimization, and DDoS mitigation.

Requirements Language 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 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 and .
• FSv2: Flow Specification Version 2, defined in .

Packet Content Filter for FSv1

Filter Encoding This document defines a new FlowSpec Component Type for FSv1. It is encoded in the FlowSpec NLRI using the FSv1 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 octet), content (Variable), mask (Variable)> The same value format is used in IPv4 and IPv6 FlowSpec NLRIs. PType distinguishes the IP version and MUST be consistent with the AFI of the containing FlowSpec NLRI. The OType semantics for IPv4 and IPv6 are specified below.

PType Field In the FSv1 encoding, PType is a 4-bit unsigned integer that identifies the IP version. PType MUST be 1 when the component is carried in an IPv4 FlowSpec NLRI and MUST be 2 when it is carried in an IPv6 FlowSpec NLRI. 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 account for variable header lengths, this specification uses a hierarchical offset scheme similar to . The OType field is a 4-bit unsigned integer defined as follows: Figure 2: OType Field OType 0 identifies the first octet of the IP header. OType 1 identifies the first octet of the IP payload. For IPv4, this is the first octet following the complete IPv4 header, including any IPv4 options, as determined by the Internet Header Length (IHL) field. For IPv6, this is the first octet following the fixed 40-octet IPv6 header. Consequently, any IPv6 extension headers are part of the data addressable using OType 1. For IPv6, an Offset into the extension header chain can refer to different content if extension headers are added, removed, or modified along the forwarding path. Matching is performed against the packet as observed at the device applying the filter. When an Offset points into IPv6 extension headers, operators SHOULD confirm that the extension header layout at the target device is as expected; otherwise, they SHOULD avoid relying on a fixed-offset match. OType 2 identifies the first octet of the UDP payload. A Packet Content Filter Component with OType 2 matches only when the applicable upper- layer protocol is UDP (17). OType 3 identifies the first octet of the TCP payload. A Packet Content Filter Component with OType 3 matches only when the applicable upper-layer protocol is TCP (6). For IPv6, locating a UDP or TCP payload requires processing the IPv6 extension header chain. If an implementation cannot locate the applicable transport-layer header or payload, a Packet Content Filter Component with OType 2 or OType 3 does not match. An implementation is not required to reassemble fragmented packets. In the absence of reassembly, a Packet Content Filter Component with OType 2 or OType 3 MUST NOT match a non-initial fragment. An implementation that performs reassembly MAY apply the match to the reassembled packet. The Offset field is a 2-octet unsigned integer that specifies the number of octets to skip from the starting position selected by OType before matching the packet content. Example:

• By setting OType 0 and an Offset of 0, the match starts at the first octet of the IP header.
• By setting OType 1 and an Offset of 2, the match starts two octets after the beginning of the IP payload.
• By setting OType 2 and an Offset of 10, the match starts ten octets into the UDP payload.
• By setting OType 3 and an Offset of 10, the match starts ten octets into the TCP payload.

Content Length, Content, and Mask Fields The Content Length field is a one-octet unsigned integer that specifies the length, in octets, of each of the Content and Mask fields. Content Length MUST be nonzero. Its one-octet encoding permits values from 1 through 255; this is an encoding limit, not a required implementation capacity. The Content and Mask fields each contain exactly Content Length octets. The encoded FSv1 Packet Content Filter value length is therefore 4 + (2 * Content Length) octets. An FSv1 implementation MAY limit the Content Length it supports for local installation because of parsing or filtering resource limits. A component that exceeds such a local limit but otherwise satisfies the FSv1 encoding requirements is unsupported for local installation, not malformed. The Content field carries the octet sequence to be matched. Based on information provided by equipment vendors and operators, 8 octets is usually sufficient for identifying many fixed packet-content patterns used in operational filtering scenarios. The Mask field is an octet string used as a bit mask for the Content field and the corresponding packet data. Each bit set to 1 indicates that the corresponding bit is significant for matching. Each bit set to 0 indicates that the corresponding bit is ignored. The Mask field MUST contain at least one bit set to 1. A packet matches the Packet Content filter if the following comparison is true for the packet data at the specified offset: (packet_content & mask) == (content & mask) If fewer than Content Length octets are available from the selected offset, the packet does not match the component.

Ordering of FSv1 Flow Specifications When two FSv1 Flow Specifications are compared at a Packet Content Filter Component under Section 5.1 of , their component values MUST be compared using the type-specific rules in the Component Ordering Rule section below. These are the same rules used for the FSv2 Packet Content Filter Component. PType is not included in this comparison because it is fixed by the AFI of the containing FlowSpec NLRI.

Example of Encoding An example of a FlowSpec NLRI encoding is provided for the following rule: "match all packets destined to 192.0.2.0/24 that have the fixed content 0x5858 at offset 0 in the TCP payload".

length	destination	packet content
0x0e	01 18 c0 00 02	TBD 13 00 00 02 58 58 ff ff

Description of each field of the FlowSpec NLRI.

Value	Description
0x0e	length	14 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
0x13	PType, OType	IPv4, TCP payload
0x0000	offset	0 octets
0x02	Content Length	2 octets
0x5858	content	0x5858
0xffff	mask	0xffff

Packet Content Filter for FSv2

Filter Encoding This document also defines the Packet Content Filter for FSv2. The Packet Content Filter Component is carried in either the IPv4 Basic Filter Family (Filter Family Type 1000) or the IPv6 Basic Filter Family (Filter Family Type 1100) defined in . In both Filter Families, the Packet Content Filter Component Type is 3000. An FSv2 NLRI can contain multiple Filter Family TLVs, each containing multiple Filter Component TLVs. The complete definitions of the NLRI fields, Filter Family TLV, Filter Component TLV, flags, lengths, ordering requirements, and validation procedures are specified in . The Filter Family Type is 1000 for IPv4 Basic and 1100 for IPv6 Basic. The Packet Content Filter Component Type is 3000. Its Component Value is shown in Figure 3. Figure 3: Packet Content Filter Component Value OType is encoded as a 1-octet unsigned integer and uses the values defined in the OType and Offset Fields section. Offset, Content Length, Content, and Mask have the same definitions as in the FSv1 encoding. The IP version is identified by the IPv4 Basic or IPv6 Basic Filter Family and is not repeated in the Component Value. An FSv2 implementation MAY limit the Content Length it supports for local installation because of parsing or filtering resource limits. A component that exceeds such a local limit but otherwise satisfies the FSv2 encoding requirements is unsupported for local installation, not malformed. Because the Packet Content Filter Component is mandatory, the corresponding FSv2 route is ineligible for local installation. Encoding: < OType (1 octet), Offset (2 octets), Content Length (1 octet), Content (variable), Mask (variable)> The Packet Content Filter Component MUST be encoded as mandatory by setting the Optional flag to zero. Omitting this component when an implementation cannot support packet-content inspection could broaden the match criteria of the FlowSpec route.

Example of Encoding The following example encodes an FSv2 rule that matches IPv4 packets destined to 192.0.2.0/24 and containing the fixed value 0x5858 at Offset 0 in the TCP payload. The rule has a User Order of 10 and no Dependent Filters Chain. Both Filter Components are mandatory. The FSv2 NLRI is encoded as follows. The Filter Family TLV and its Filter Component TLVs are expanded in the subsequent tables.

NLRI Length	Dependent Filters Chain	User Order	Filter Family TLV
00 20	00 00 00 00	00 00 00 0a	shown below

Family type	Family length	Filter Component TLVs
03 e8	00 14	shown below

Component	Flags and type	Length	Value
Destination Prefix	03 e8	00 04	18 c0 00 02
Packet Content	0b b8	00 08	03 00 00 02 58 58 ff ff

Description of each field of the FSv2 NLRI:

Value	Description	Meaning
0x0020	NLRI Length	32 octets
0x00000000	Dependent Filters Chain	No dependency
0x0000000a	User Order	10
0x03e8	Filter Family Type	IPv4 Basic, type 1000
0x0014	Filter Family Length	20 octets
0x03e8	Flags and Component Type	Destination Prefix, 1000
0x0004	Component Length	4 octets
0x18	Prefix Length	24 bits
0xc00002	Prefix	192.0.2.0
0x0bb8	Flags and Component Type	Packet Content, 3000
0x0008	Component Length	8 octets
0x03	OType	TCP Payload
0x0000	Offset	0 octets
0x02	Content Length	2 octets
0x5858	Content	0x5858
0xffff	Mask	0xffff

In the combined Flags and Component Type fields, the high-order four bits are zero. This sets the Optional flag to zero and the reserved flag bits to zero. The remaining 12 bits carry the Component Type.

Component Ordering Rule FSv2 Filter Family TLVs and Filter Component TLVs within an NLRI MUST be encoded in strictly increasing type order as specified in . A Filter Component Type MUST NOT occur more than once in a given Filter Family TLV. When route comparison reaches a Packet Content Filter Component in both FSv1 Flow Specifications, or reaches that component in two FSv2 NLRIs with the same User Order, the component values MUST be compared using the following rules. These rules define a deterministic default ordering for Packet Content Filter Components in both versions. The order does not imply that an earlier component matches a strict subset of a later one: Mask bits can make a longer Content field less restrictive, and OType and Offset select different packet positions. Operators that require a particular order for rules with different actions SHOULD assign appropriate User Order values, as specified in .

1. Filters with a larger Content Length are ordered first.
2. If they have the same Content Length, compare OType; the larger value is ordered first.
3. If they have the same Content Length and OType, compare Offset; the larger value is ordered first.
4. If they have the same Content Length, OType, and Offset, compare Content as an unsigned octet string in lexicographic order, starting from the first octet. The string with the lower octet value at the first differing position has higher precedence.
5. If the Content fields are equal, compare Mask as an unsigned octet string in lexicographic order. The string with the lower octet value at the first differing position has higher precedence.

These rules compare components in different NLRIs. They do not permit duplicate Packet Content Filter Components in one FSv1 NLRI or one FSv2 Filter Family TLV.

Example of Component Ordering The following example contains five FSv2 routes with the same destination prefix and User Order. Each route contains a Packet Content Filter Component with a different value. All Packet Content Filter Components in this example use an all-ones Mask. The rules will be installed as:

Error Handling

FSv1 Error Handling An FSv1 Packet Content Filter Component is malformed if any of the following conditions apply:

• PType is inconsistent with the AFI of the containing FlowSpec NLRI;
• OType contains a value not defined by this document;
• Content Length is zero;
• fewer than 4 + (2 * Content Length) octets remain for the component value within the containing NLRI, or the bytes following that value cannot be parsed as subsequent components up to the NLRI boundary; or
• Mask contains no bit set to one.

A malformed FSv1 Packet Content Filter Component renders the containing FlowSpec NLRI malformed. The NLRI is handled according to the applicable error-handling procedures in , , and .

FSv2 Error Handling An FSv2 Packet Content Filter Component is malformed if any of the following conditions apply:

• the Optional flag is not zero;
• OType contains a value not defined by this document;
• Content Length is zero;
• Filter Component Length is not 4 + (2 * Content Length) octets; or
• Mask contains no bit set to one.

When the NLRI boundaries remain parseable, an FSv2 NLRI containing such a malformed component MUST be handled using treat-as-withdraw, and the operator MUST be notified, as specified by the FSv2 NLRI validation procedures in . Other structural errors are handled according to those validation procedures.

Operational Considerations The Packet Content Filter is intended for controlled deployment scenarios, such as traffic filtering, traffic optimization, and DDoS mitigation based on known fixed packet-content patterns. Operators SHOULD deploy this filter only at controlled filtering locations, such as provider edge devices, firewalls, traffic steering points, mitigation points, or other devices where the traffic impact and rollback procedures are well understood. Receiving or propagating a FlowSpec rule does not itself require local installation. Whether a device is a target for local installation is determined by applicable target identification and local policy. The mechanism in is one possible way to identify target nodes, subject to deployment and implementation support. Operators SHOULD enable Packet Content Filter processing only on devices that support packet-content parsing and have sufficient filtering resources for the expected rule scale. Reception and propagation of FSv2 routes follow the applicable BGP and FSv2 validation and import policies. Before local installation, a target device also needs to determine that it can implement the mandatory match components and actions and that the rule satisfies local authorization and resource policies. For FSv2, an implementation that cannot install a mandatory Packet Content Filter Component MUST consider the corresponding FlowSpec route ineligible for local installation, as specified in . When encapsulation is present, such as MPLS, GRE, or other tunnels, the offset base can become ambiguous if matching is applied to the outer packet. Operators SHOULD apply matching to the decapsulated inner IP packet when applicable, or otherwise ensure that the offset base is unambiguous.

Scalability Considerations Packet-content matching may consume limited implementation resources, such as UDF, ACL, or TCAM entries. Operators SHOULD limit Packet Content Filter rules to a small set of high-value entries, such as confirmed attack signatures, operationally validated filtering rules, or traffic optimization policies. When FSv2 is used, rule ordering SHOULD be used to reduce the amount of traffic requiring packet-content inspection, for example by combining packet-content matching with more specific header-based conditions. Operators SHOULD restrict the propagation scope of Packet Content Filter rules to avoid unnecessary inter-domain scale impact. Inter-domain propagation SHOULD be used only with explicit operational agreement and suitable policy control.

Security Considerations This specification does not change the security properties of BGP itself. However, Packet Content Filter rules can affect traffic treatment and may cause packets to be dropped, redirected, rate-limited, or other actions according to local policy. Operators SHOULD apply appropriate import policies and validation procedures to Packet Content Filter rules. Such rules SHOULD be accepted only from trusted BGP peers, and their propagation scope SHOULD be restricted by local policy. FSv2 specifies installation eligibility for unsupported mandatory components; it does not define per-rule source authorization or content inspection policy for this component. Those controls are determined by local policy before installation. To reduce false positives, Packet Content Filter rules SHOULD be combined with other FlowSpec match conditions, such as destination prefix, source prefix, protocol, port, TCP flags, or fragment-related conditions, when applicable. For IPv6, changes to extension headers along the forwarding path can cause a fixed-offset content filter to miss intended traffic or match unintended traffic. For FSv2, unsupported mandatory Packet Content Filter Components make the corresponding FlowSpec route ineligible for local installation; they MUST NOT be silently omitted while the remaining match conditions and actions are installed. Implementations and operators SHOULD apply update-rate limits and resource limits to avoid excessive control-plane load and preserve BGP stability.

Implementation and Evaluation The Packet Content Filter has been tested with OpenBGPD, FRRouting, and programmable switches. The tests covered control-plane and data-plane behavior. Details of the implementation evaluation were presented to the IDR Working Group at IETF 125, IETF 126, and the IDR interim meeting on 26 October 2026.

IANA Considerations

FSv1 Component Type IANA is requested to assign a new Type Value for the Packet Content Filter from the "Flow Spec Component Types" registry.

FSv2 IP Basic Component Type IANA is requested to register the following value in the "BGP FSv2 IP Basic Component Types" registry defined by . This Component Type is used in both the IPv4 Basic Filter Family (type 1000) and the IPv6 Basic Filter Family (type 1100).

References Normative References This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. n.d. Informative References

Acknowledgements We wish to thank Jeffrey Haas and Li Yang for their valuable comments and suggestions on this document. We also wish to thank Rui Xu and Yannan Hu for their contribution in the implementation and validation of the packet content filter software.