Internet-Draft Packet Content Filter for BGP FlowSpec May 2024
Cui & Gao Expires 9 November 2024 [Page]
Workgroup:
IETF
Internet-Draft:
draft-cui-idr-content-filter-flowspec-01
Published:
Intended Status:
Informational
Expires:
Authors:
Y. Cui
Tsinghua University
Y. Gao
Zhongguancun Laboratory

Packet Content Filter for BGP FlowSpec

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 filterer in FSv1 and FSv2 predominantly focuses on IP header fields, which may not adequately address new types of DDoS attack traffic characterized by constant patterns within the packet content. This document introduces a new flow specification filter type designed for packet content filtering. The match field includes otype, offset value, content-length, and content, encoded in the Flowspec NLRI. This new filter aims to augment DDoS defense capabilities.

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 9 November 2024.

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 limitation, etc. These filter rules can be propagated to all BGP peers simultaneously without necessitating router configuration changes. Despite their utility, FSv1 and FSv2 reliance on IP header fields for traffic filtering is increasingly inadequate for countering DDoS attack. DDoS attacks such as application-level Challenge Collapsar (CC) attacks, ACK flood attacks, etc, feature distinct patterns within the packet content with a large traffic.

This document delineates a new flow specification filter type that facilitates packet content filtering, leveraging otype, offset value, content-length, and content within the Flowspec NLRI to enhance DDoS defense mechanisms.

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 define in [draft-hares-idr-flowspec-v2-ddos-00]

3. The Packet Content Filter for FSv1

This document specifies a new flow specification filter type that is encoded in the BGP FS NLRI and we follow the FSv1 definition format. The packet content filter is defined as follows:

Type TBD – Packet-Content

Encoding:< type (1 octet), value>

The value field is encoded using ptype, otype, offset, content-length, content and mask.

Encoding: < ptype (4 bits), otype (4 bits), offset (2 octets), content-length (1 octets), content (Variable), mask (Variable)>

3.1. Ptype field

The ptype field defines the type of the packet, which are IPv4 or IPv6., because, some filters are added to hardware that are IPv4 or IPv6 specific.

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 [draft-khare-idr-bgp-flowspec-payload-match-08].The otype is defined as follows:

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

Figure 1: Otype field

Each otype is detailed as follows:

  • 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 start of the TCP or UDP data. Type 2 will only be used if it is the first packet of a fragment and the Layer 4 transport protocol is TCP (6) or UDP (17). For other IP protocols, type 1 or type 2 can be used.

The offset is defined as a 2-octet unsigned integer that specifies the count of bytes to be bypassed from the otype's starting position to match the packet content.

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 bytes past the initial data portion of the IP header, skipping over any IP options. This configuration, for example, in UDP packets, specifically targets the start of the destination port information.

  • By setting otype 2 and an offset of 10, the match will start ten bytes into the content of the TCP/UDP packet.

3.3. Content-length, Content and Mask fields

The content-length is a one octet unsigned integer field that contains the length of the value field in octets. Content and mask fields have a same length which defined by the content-length.

The content provides a string to be matched. Based on the information provided by equipment vendors and operators, 8 octets is usually sufficient for the identification of DDoS attacks.

Mask is a string containing 0 and 1, where 1 represents what will be matched and 0 represents characters that can be ignored.

The content and mask are operated AND by bit to get the final content of the packet that needs to be matched.

4. The Packet Content Filter for FSv2

4.1. Filter Encoding

To adapt to the updates of flowSpec, this document also gives the definition of the packet content filters in FSv2. The TLVs is as same as the FSv2 Component TLVs:

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

Figure 2: Sub-TLVs

The defination of packet content filter are as follows:

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

Figure 3: Defination of the filter

where fileds have the same length as FSv1.

Encoding: < ptype (4 bits), otype (4 bits), offset (2 octets), content-length (1 octets), content (Variable), mask (Variable)>

4.2. Filter Ordering Rule

Compared to FSv1, FSv2 adds filter ordering function. Ordering within the TLV in FSv2: The transmission of SubTLVs within a flow specification rule MUST be sent ascending order by SubTLV type. If the SubTLV types are the same, then the value fields are compared using mechanisms defined in [RFC8955] and [RFC8956] and MUST be in ascending order.

As there is no default ordering definition for filters, this document gives the ordering rules. Matching conditions with a smaller content-length are implemented first. If they have the same content-length, compare Otype and the smaller type is implemented first. If otype is the same, compare offset, smaller value will be implemented first.

When multiple packet content filters exist in a component, determine the order of the filters according to the above ordering rules. When there are multiple components and each component has packet content filters, compare the content-length of the first filter, and implement the component with the smaller value first.

5. IANA Considerations

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

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

The introduction of the "Packet Content filter" Type Value is purposed to expand the capability of BGP FSv1 by enabling more granular control over traffic filtering.

This is especially pertinent for addressing complex patterns within packet content that are characteristic of Distributed Denial of Service (DDoS) attacks and other security challenges. The proposed Packet Content filter facilitate the specification of detailed criteria for traffic matching, including but not limited to, content inspection at specific packet offsets. In the following update we will add the definition of FSv2.

6. Security Considerations

No new security issues are introduced to the BGP protocol by this specification

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

Acknowledgements

We wish to thank Susan Hares, Jeffery Hass and Li Yang for their valuable comments and suggestions on this document.

Authors' Addresses

Yong Cui
Tsinghua University
Beijing, 100084
China
Yujia Gao
Zhongguancun Laboratory
Beijing, 100094
China