IDR Y. Cui Internet-Draft Tsinghua University Intended status: Informational Y. Gao Expires: 10 November 2026 Zhongguancun Laboratory S. Hares Hickory Hill Consulting 9 May 2026 Packet Content Filter for BGP FlowSpec draft-cui-idr-content-filter-flowspec-04 Abstract The BGP Flow Specification enables the distribution of traffic filter policies (traffic filters and actions) via BGP, facilitating DDoS traffic filtering. However, the traffic filter in FSv1 and FSv2 predominantly focuses on IP header fields, which may not adequately address volumetric DDoS attack traffic characterized by fixed patterns within the packet content. This document introduces a new flow specification filter type designed for packet content filtering. The match field includes ptype, otype, offset, content-length, content, and mask encoded in the Flowspec NLRI. This new filter 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 10 November 2026. Cui, et al. Expires 10 November 2026 [Page 1] Internet-Draft Packet Content Filter for BGP FlowSpec May 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 3. The Packet Content Filter for FSv1 . . . . . . . . . . . . . 3 3.1. Ptype Field . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Otype and Offset Fields . . . . . . . . . . . . . . . . . 4 3.3. Content-length, Content and Mask Fields . . . . . . . . . 5 3.4. Example of Encoding . . . . . . . . . . . . . . . . . . . 6 4. The Packet Content Filter for FSv2 . . . . . . . . . . . . . 7 4.1. Filter Encoding . . . . . . . . . . . . . . . . . . . . . 7 4.2. Filter Ordering Rule . . . . . . . . . . . . . . . . . . 8 4.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Operational Considerations . . . . . . . . . . . . . . . . . 10 6. Scalability Considerations . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. 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 other actions. These filter rules can be propagated to all BGP peers simultaneously without necessitating router configuration changes. Despite their utility, the reliance of existing filters on IP header fields may be insufficient for some operational scenarios where packets can be identified by fixed content patterns. Such scenarios may include Cui, et al. Expires 10 November 2026 [Page 2] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 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 new FlowSpec filter type that supports packet content filtering by using ptype, otype, offset, content-length, content, and mask fields within the FlowSpec NLRI. This filter is intended for controlled operational use cases such as traffic filtering, traffic optimization, and DDoS mitigation. 1.1. 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. 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-flowspec-v2]. 3. The Packet Content Filter for FSv1 This document specifies a new flow specification filter type that is encoded in the BGP FS NLRI, following 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 octet), content (Variable), mask (Variable)> Cui, et al. Expires 10 November 2026 [Page 3] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 3.1. 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 3.2. 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 [I-D.khare-idr-bgp-flowspec-payload-match]. 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 | UDP Payload | | 3 | TCP 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 UDP payload. Otype 3 is defined as the start of the TCP payload. Otype 2 MUST only match packets whose upper-layer protocol is UDP (17). Otype 3 MUST only match packets whose upper-layer protocol is TCP (6). For other IP protocols, otype 2 and otype 3 MUST NOT match; otype 1 MAY 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 Cui, et al. Expires 10 November 2026 [Page 4] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 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, could be used to specifically target the IP payload starting after 2 octets. * By setting otype 2 and an offset of 10, the match will start ten octets into the UDP payload of the packet. * By setting otype 3 and an offset of 10, the match will start ten octets into the TCP payload of the packet. 3.3. Content-length, Content and Mask Fields The content-length is a one-octet unsigned integer field that specifies the length, in octets, of each of the Content field and the Mask field. The Content field and the Mask field have the same length as specified by the content-length. 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. 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) Cui, et al. Expires 10 November 2026 [Page 5] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 3.4. 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 | +========+================+================================+ | 0x0f | 01 18 c0 00 02 | TBD 40 12 00 00 02 58 58 ff ff | +--------+----------------+--------------------------------+ Table 1 Description of each field of the FlowSpec NLRI. +========+================+=================================+ | 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 | +--------+----------------+---------------------------------+ Table 2 Cui, et al. Expires 10 November 2026 [Page 6] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 4. The Packet Content Filter for FSv2 4.1. Filter Encoding To adapt to the updates of FlowSpec, this document also defines the Packet Content Filter for FSv2. The format follows the NLRI format for Extended IP Filters defined in [I-D.hares-idr-fsv2-more-ip-filters], as shown in Figure 3: +--------------------------------+ | NLRI length (2 octets) | +--------------------------------+ | TLVs+ | | +============================+ | | | order (4 octets) | | | +----------------------------+ | | | Dependent filter chain | | | | (8 octets) | | | +----------------------------+ | | | FSv2 Filter type = 2 | | | +----------------------------+ | | | length TLVs (2 octet) | | | +----------------------------+ | | | Value (variable) | | | +--------------------------- + | | +============================+ | +--------------------------------+ Figure 3: NLRI Format for Extended IP Filters The format of the dependent filter chain is shown in Figure 4: +----------------------------+ | Version (1 octet) | +----------------------------+ | Chain id (3 octet) | +----------------------------+ | Count of items (2 octets) | +----------------------------+ | Item (2 octets) | +----------------------------+ Figure 4: Format of the Dependent Filter Chain The format of the Component TLV is shown in Figure 5: Cui, et al. Expires 10 November 2026 [Page 7] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 +-----------------------------+ | Component Type (2 octets) | +-----------------------------+ | Component Length (2 octets)| +-----------------------------+ | Component Value (variable) | +-----------------------------+ Figure 5: format for Component-TLV The definition of the Packet Content Filter in the Component-TLV format is 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 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType | Otype | Offset | Content Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Content | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Definition of the Packet Content Filter where the fields have the same definitions as in the FSv1 encoding. Encoding: < ptype (4 bits), otype (4 bits), offset (2 octets), content-length (1 octet), content (Variable), mask (Variable)> 4.2. Filter Ordering Rule Compared to FSv1, FSv2 adds filter ordering function. According to the definition of ordering rules in FSv2, the transmission of Component-TLVs within a flow specification rule MUST be sent ascending order by Component-TLV type. If the Component-TLV 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 definition as follows: 1. Filters with a larger content-length are ordered first. Cui, et al. Expires 10 November 2026 [Page 8] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 2. If they have the same content-length, compare otype and the larger type is ordered first. 3. If they have the same content-length and otype, compare offset and the larger value is ordered first. 4. If they have the same content-length, otype, and offset, compare the content as an unsigned octet string in lexicographic order, starting from the first octet. If the common prefix is not equal, the string with the lower octet value at the first differing position has higher precedence. When multiple Packet Content Filter components exist across multiple NLRIs with the same user order, their relative order is determined according to the ordering rules above. 4.3. 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: Cui, et al. Expires 10 November 2026 [Page 9] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 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 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 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. Unsupported rules SHOULD be rejected or ignored locally according to local 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. Cui, et al. Expires 10 November 2026 [Page 10] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 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. 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. Unsupported rules SHOULD be rejected or ignored locally according to local policy. Implementations and operators SHOULD apply update-rate limits and resource limits to avoid excessive control-plane load and preserve BGP stability. 8. IANA Considerations 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 | +------------+---------------------------+---------------+ For FSv2, a Packet Content Filter Component Type will be requested from the appropriate FSv2 Extended IP Filters component registry after that registry is defined. 9. Normative References Cui, et al. Expires 10 November 2026 [Page 11] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 [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, . [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, . [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-flowspec-v2] Hares, S., 3rd, D. E. E., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2", April 2024, . [I-D.hares-idr-fsv2-more-ip-filters] Hares, S. and N. Kao, "BGP Flow Specification Version 2 - More IP Filters", n.d., . [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 Cui, et al. Expires 10 November 2026 [Page 12] Internet-Draft Packet Content Filter for BGP FlowSpec May 2026 Yong Cui Tsinghua University Beijing, 100084 China Email: cuiyong@tsinghua.edu.cn URI: http://www.cuiyong.net/ 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 10 November 2026 [Page 13]