IDR Y. Cui Internet-Draft Tsinghua University Intended status: Standards Track Y. Gao Expires: 17 April 2027 Zhongguancun Laboratory S. Hares Hickory Hill Consulting 14 October 2026 Packet Content Filter for BGP FlowSpec draft-cui-idr-content-filter-flowspec-05 Abstract 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 network devices such as routers and switches to support controlled traffic handling, traffic optimization, and mitigation of simple volumetric DDoS attacks, reducing the overall processing cost of carrier networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 April 2027. Cui, et al. Expires 17 April 2027 [Page 1] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 2. Packet Content Filter for FSv1 . . . . . . . . . . . . . . . 3 2.1. Filter Encoding . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. PType Field . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. OType and Offset Fields . . . . . . . . . . . . . . . 4 2.1.3. Content Length, Content, and Mask Fields . . . . . . 6 2.2. Ordering of FSv1 Flow Specifications . . . . . . . . . . 6 2.3. Example of Encoding . . . . . . . . . . . . . . . . . . . 7 3. Packet Content Filter for FSv2 . . . . . . . . . . . . . . . 7 3.1. Filter Encoding . . . . . . . . . . . . . . . . . . . . . 8 3.2. Example of Encoding . . . . . . . . . . . . . . . . . . . 9 3.3. Component Ordering Rule . . . . . . . . . . . . . . . . . 11 3.4. Example of Component Ordering . . . . . . . . . . . . . . 12 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. FSv1 Error Handling . . . . . . . . . . . . . . . . . . . 13 4.2. FSv2 Error Handling . . . . . . . . . . . . . . . . . . . 14 5. Operational Considerations . . . . . . . . . . . . . . . . . 14 6. Scalability Considerations . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8.1. FSv1 Component Type . . . . . . . . . . . . . . . . . . . 16 8.2. FSv2 IP Basic Component Type . . . . . . . . . . . . . . 16 9. Normative References . . . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Cui, et al. Expires 17 April 2027 [Page 2] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 1. 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. 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, defined in [I-D.ietf-idr-fsv2-ip-basic]. 2. Packet Content Filter for FSv1 Cui, et al. Expires 17 April 2027 [Page 3] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 2.1. 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. 2.1.1. 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. +-------+-----------------------------+ | Value | Description of PType | +-------+-----------------------------+ | 1 | IPv4 | | 2 | IPv6 | +-------+-----------------------------+ Figure 1: PType Field 2.1.2. 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 [I-D.khare-idr-bgp-flowspec-payload-match]. The OType field is a 4-bit unsigned integer defined as follows: Cui, et al. Expires 17 April 2027 [Page 4] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 +-------+-----------------------------+ | Value | Description of OType | +-------+-----------------------------+ | 0 | IP Header | | 1 | IP Payload | | 2 | UDP Payload | | 3 | TCP Payload | +-------+-----------------------------+ 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. 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. Cui, et al. Expires 17 April 2027 [Page 5] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 * 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. 2.1.3. 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 in the range 1 through 255. 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. 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. 2.2. Ordering of FSv1 Flow Specifications When two FSv1 Flow Specifications are compared at a Packet Content Filter Component under Section 5.1 of [RFC8955], 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. Cui, et al. Expires 17 April 2027 [Page 6] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 2.3. 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 | +--------+----------------+-----------------------------+ Table 1 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 | +--------+----------------+---------------------------------+ Table 2 3. Packet Content Filter for FSv2 Cui, et al. Expires 17 April 2027 [Page 7] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 3.1. 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 [I-D.ietf-idr-fsv2-ip-basic]. In both Filter Families, the Packet Content Filter Component Type is 3000. The FSv2 encoding hierarchy is summarized in Figure 3. The complete definitions of the NLRI fields, Filter Family TLV, Filter Component TLV, flags, lengths, ordering requirements, and validation procedures are specified in [I-D.ietf-idr-fsv2-ip-basic]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Length | | (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dependent Filters Chain (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User Order (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filter Family Type | Filter Family Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Component Type | Component Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: FSv2 NLRI, Filter Family, and Filter Component Hierarchy 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 4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OType (1 octet)| Offset (2 octets) |Content Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Content | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Packet Content Filter Component Value Cui, et al. Expires 17 April 2027 [Page 8] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 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. 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. 3.2. 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 | shown | | | | 0a | below | +-------------+-------------------------+------------+------------+ Table 3 +=============+===============+=======================+ | Family type | Family length | Filter Component TLVs | +=============+===============+=======================+ | 03 e8 | 00 14 | shown below | +-------------+---------------+-----------------------+ Table 4 Cui, et al. Expires 17 April 2027 [Page 9] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 +====================+================+========+=============+ | 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 | +--------------------+----------------+--------+-------------+ Table 5 Description of each field of the FSv2 NLRI: Cui, et al. Expires 17 April 2027 [Page 10] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 +============+==========================+==========================+ | 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 | +------------+--------------------------+--------------------------+ Table 6 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. 3.3. 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 [I-D.ietf-idr-fsv2-ip-basic]. A Filter Component Type MUST NOT occur more than once in a given Filter Family TLV. Cui, et al. Expires 17 April 2027 [Page 11] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 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 [I-D.ietf-idr-fsv2-ip-basic]. 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. 3.4. 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. Cui, et al. Expires 17 April 2027 [Page 12] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 User Order – 10 FSv2 – NLRI with an IP Basic Filter Family Route 1: Destination Prefix + Packet Content Filter (OType 0, Offset 50, Content Length 2, Content 0x1111) + Rate Limit Route 2: Destination Prefix + Packet Content Filter (OType 0, Offset 50, Content Length 3, Content 0x111122) + Discard Route 3: Destination Prefix + Packet Content Filter (OType 2, Offset 70, Content Length 2, Content 0x1111) + Rate Limit Route 4: Destination Prefix + Packet Content Filter (OType 2, Offset 70, Content Length 3, Content 0x111122) + Discard Route 5: Destination Prefix + Packet Content Filter (OType 2, Offset 70, Content Length 3, Content 0x111133) + Rate Limit The rules will be installed as: User Order – 10 Route 4: Destination Prefix + Packet Content Filter (OType 2, Offset 70, Content Length 3, Content 0x111122) + Discard Route 5: Destination Prefix + Packet Content Filter (OType 2, Offset 70, Content Length 3, Content 0x111133) + Rate Limit Route 2: Destination Prefix + Packet Content Filter (OType 0, Offset 50, Content Length 3, Content 0x111122) + Discard Route 3: Destination Prefix + Packet Content Filter (OType 2, Offset 70, Content Length 2, Content 0x1111) + Rate Limit Route 1: Destination Prefix + Packet Content Filter (OType 0, Offset 50, Content Length 2, Content 0x1111) + Rate Limit 4. Error Handling 4.1. 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. Cui, et al. Expires 17 April 2027 [Page 13] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 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 [RFC8955], [RFC8956], and [RFC7606]. An FSv1 implementation MAY support a local maximum smaller than 255 octets 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. 4.2. 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 [I-D.ietf-idr-fsv2-ip-basic]. Other structural errors are handled according to those validation procedures. An FSv2 implementation MAY support a local maximum smaller than 255 octets 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. 5. 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, traffic steering points, mitigation points, or other devices where the traffic impact and rollback Cui, et al. Expires 17 April 2027 [Page 14] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 procedures are well understood. 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. 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 [I-D.ietf-idr-fsv2-ip-basic]. Propagation of a syntactically valid FSv2 route is governed by the FSv2 validation procedures and local BGP policy. 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. 6. 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. 7. 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 MUST apply appropriate import policies, validation procedures, and authorization controls before accepting Packet Content Filter rules. Such rules SHOULD be accepted only from trusted BGP peers, and their propagation scope SHOULD be restricted by local policy. Cui, et al. Expires 17 April 2027 [Page 15] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 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 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. 8. IANA Considerations 8.1. FSv1 Component Type IANA is requested to assign a new Type Value for the Packet Content Filter from the "Flow Spec Component Types" registry. +------------+---------------------------+---------------+ | Type Value | Name | Reference | +------------+---------------------------+---------------+ | TBD | Packet Content filter | this document | +------------+---------------------------+---------------+ 8.2. FSv2 IP Basic Component Type IANA is requested to register the following value in the "BGP FSv2 IP Basic Component Types" registry defined by [I-D.ietf-idr-fsv2-ip-basic]. This Component Type is used in both the IPv4 Basic Filter Family (type 1000) and the IPv6 Basic Filter Family (type 1100). +------------+---------------------------+---------------+ | Type Value | Name | Reference | +------------+---------------------------+---------------+ | 3000 | Packet Content Filter | this document | +------------+---------------------------+---------------+ 9. Normative References [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, . Cui, et al. Expires 17 April 2027 [Page 16] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.ietf-idr-fsv2-ip-basic] Hares, S., 3rd, D. E. E., Dong, J., Yadlapalli, C., Maduschke, S., and J. Haas, "BGP Flow Specification Version 2 - for Basic IP", September 2026, . [I-D.khare-idr-bgp-flowspec-payload-match] Khare, A., BERGEON, P., Kestur, V., Jalil, L., and K. Kasavchenko, "BGP Flow Specification for Payload Matching", n.d., . 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. Authors' Addresses Yong Cui Tsinghua University Beijing, 100084 China Email: cuiyong@tsinghua.edu.cn URI: http://www.cuiyong.net/ Cui, et al. Expires 17 April 2027 [Page 17] Internet-Draft Packet Content Filter for BGP FlowSpec October 2026 Yujia Gao Zhongguancun Laboratory Beijing, 100094 China Phone: +86-185-1028-7458 Email: gaoyj@zgclab.edu.cn Susan Hares Hickory Hill Consulting 7453 Hickory Hill Saline, Michigan 48176 United States of America Email: shares@ndzh.com Cui, et al. Expires 17 April 2027 [Page 18]