Internet-Draft Packet Content Filter for BGP FlowSpec October 2026
Cui, et al. Expires 17 April 2027 [Page]
Workgroup:
IDR
Internet-Draft:
draft-cui-idr-content-filter-flowspec-05
Published:
Intended Status:
Standards Track
Expires:
Authors:
Y. Cui
Tsinghua University
Y. Gao
Zhongguancun Laboratory
S. Hares
Hickory Hill Consulting

Packet Content Filter for BGP FlowSpec

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.

▲

Table of Contents

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

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:

+-------+-----------------------------+
| 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.

  • 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.

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".

Table 1
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.

Table 2
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

3. Packet Content Filter for FSv2

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

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.

Table 3
NLRI Length Dependent Filters Chain User Order Filter Family TLV
00 20 00 00 00 00 00 00 00 0a shown below
Table 4
Family type Family length Filter Component TLVs
03 e8 00 14 shown below
Table 5
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:

Table 6
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.

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.

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.

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.

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 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.

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, , <https://www.rfc-editor.org/rfc/rfc8955>.
[RFC8956]
Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, , <https://www.rfc-editor.org/rfc/rfc8956>.
[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, , <https://www.rfc-editor.org/rfc/rfc7606>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[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", , <https://datatracker.ietf.org/doc/draft-ietf-idr-fsv2-ip-basic/08/>.
[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., <https://datatracker.ietf.org/doc/draft-khare-idr-bgp-flowspec-payload-match/>.

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
URI: http://www.cuiyong.net/
Yujia Gao
Zhongguancun Laboratory
Beijing, 100094
China
Phone: +86-185-1028-7458
Susan Hares
Hickory Hill Consulting
7453 Hickory Hill
Saline, Michigan 48176
United States of America