]> Tsinghua University

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

Zhongguancun Laboratory

Beijing 100094 China gaoyj@zgclab.edu.cn

Security IETF DDoS Mitigation, BGP flow specification 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 offset-type, offset value, content-length, and content-value, encoded in the Flowspec NLRI. This new filter aims to augment DDoS defense capabilities.

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 offset-type, offset value, content-length, and content-value within the Flowspec NLRI to enhance DDoS defense mechanisms.

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 when, and only when, they appear in all capitals, as shown here.

Definitions and Acronyms

• DDoS: Distributed Denial of Service
• NLRI: Network Layer Reachability Information
• FSv1: Flow Specification Version 1, defined in and
• FSv2: Flow Specification Version 2 define in [draft-hares-idr-flowspec-v2-ddos-00]

The Flow Specification for Packet Offset Filter This document specifies a new flow specification filter type that is encoded in the BGP FS NLRI and we follow the FSv1 definition format rightnow. The new filter is defined as follows: Type TBD – Packet-Content Encoding:< type (1 octet), [value]+> The value field is encoded using offset-type, offset-value, content-length and content-value. Encoding: < offset-type (4 bits), offset-value (2 octets), content-length (1 octets), content-value>

Offset-type and Offset-value The offset-type and offset-value 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 offset-tpye is defined as follows: Figure 1： offset-type Each offset-type is detailed as follows:

• Offset-type 0 is defined as the start of the IP header.
• Offset-type 1 is defined as the start of the data portion of the IP header after the IP options.
• Offset-type 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-value is defined as a 2-octet unsigned integer that specifies the count of bytes to be bypassed from the offset-type's starting position to match the packet content. Example:

• By setting offset-type 0 and an offset-value of 0, the match is configured to start precisely at the beginning of the IP header.
• By setting offset-type 1 and an offset-value 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 offset-type 2 and an offset-value of 10, the match will start ten bytes into the content of the TCP/UDP packet.

Content-length and Content-value The content-length is a one octet unsigned integer field that contains the length of the value field in octets. The content-value is encoded as {content, mask}. Content and mask have a same length which defined by the content-length. The content provides a string to be matched. Their length is defined by content-length. Based on the information provided by equipment vendors and operators, 8octets 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.

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

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

Normative References This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

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