Packet Content Filter for BGP FlowSpec
draft-cui-idr-content-filter-flowspec-02

IETF                                                              Y. Cui
Internet-Draft                                       Tsinghua University
Intended status: Informational                                    Y. Gao
Expires: 20 January 2025                         Zhongguancun Laboratory
                                                                S. Hares
                                                 Hickory Hill Consulting
                                                            19 July 2024

                 Packet Content Filter for BGP FlowSpec
                draft-cui-idr-content-filter-flowspec-02

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 20 January 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Cui, et al.              Expires 20 January 2025                [Page 1]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

   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 . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Otype and Offset Fields . . . . . . . . . . . . . . . . .   4
     3.3.  Content-length, Content and Mask Fields . . . . . . . . .   5
     3.4.  Example of Encoding . . . . . . . . . . . . . . . . . . .   5
   4.  The Packet Content Filter for FSv2  . . . . . . . . . . . . .   6
     4.1.  Filter Encoding . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Filter Ordering Rule  . . . . . . . . . . . . . . . . . .   8
     4.3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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, existing filters reliance on IP header fields for traffic
   filtering is increasingly inadequate for new kinds of DDoS attack.
   DDoS attacks such as ACK flood, UDP flood, ICMP flood and HTTP flood
   attacks, etc, have been found to potentially characterise a fixed
   content in the packet.

   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.

Cui, et al.              Expires 20 January 2025                [Page 2]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

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

Cui, et al.              Expires 20 January 2025                [Page 3]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

   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 [draft-khare-idr-bgp-flowspec-payload-
   match-08].  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     | TCP/UDP 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 TCP or UDP data.
   Type 2 will only be used if it is 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 octets to be bypassed from the otype's starting position
   to match the packet content.  It is worth noting that packet
   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, in UDP
      packets, specifically targets the start of the destination port
      information.

Cui, et al.              Expires 20 January 2025                [Page 4]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

   *  By setting otype 2 and an offset of 10, the match will start ten
      octets 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.

3.4.  Example of Encoding

   An example of a FlowSpec NLRI encoding for:"all packets to
   192.0.2.0/24 and have fixed content 5858 in the tcp payload with
   offset of 0".

       +========+================+================================+
       | length | destination    | packet content                 |
       +========+================+================================+
       | 0x0b   | 01 18 c0 00 02 | TBD 40 12 00 00 02 58 58 ff ff |
       +--------+----------------+--------------------------------+

                                 Table 1

   An example of a FlowSpec NLRI encoding for:"all packets to
   192.0.2.0/24 and have fixed content 5858 in the tcp payload with
   offset of 0".

Cui, et al.              Expires 20 January 2025                [Page 5]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

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

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 formate is as
   same as the NLRI formate for extented IP filters, as shown in
   Figure 3:

Cui, et al.              Expires 20 January 2025                [Page 6]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

   +--------------------------------+
   | NLRI length (2 octets)         |
   +--------------------------------+
   | TLVs+                          |
   | +============================+ |
   | | order (4 octets)           | |
   | +----------------------------+ |
   | | identifier (4 octets)      | |
   | +----------------------------+ |
   | | FSv2 Filter type = 2       | |
   | +----------------------------+ |
   | | length TLVs (2 octet)      | |
   | +----------------------------+ |
   | +----------------------------+ |
   | + +------------------------+ + |
   | + |FSv2 filters version    | + |
   | + +------------------------+ + |
   | + | Sub-TLVs               | + |
   | + +------------------------+ + |
   | +----------------------------+ |
   +--------------------------------+

   Figure 3： NLRI formate for extented IP filters

   The formate of Sub-TLVs is showns in Figure 4:

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

   Figure 4: formate for Sub-TLV

   The defination of packet content filter in sub-TLV formate are as
   follows:

Cui, et al.              Expires 20 January 2025                [Page 7]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

     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 5: Defination of the packet content 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.  According to
   the defination of ordering rules 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.

   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 defination as follows:

   1.  Filters with a larger content-length are implemented first.

   2.  If they have the same content-length, compare otype and the
       larger type is implemented first.

   3.  If they have the same content-lengte and otype, compare offset
       and the larger value will be implemented first.

   4.  If they have the same content-length, otype, and offset, compare
       the content as a binary string using the memcmp() function as
       defined by [ISO_IEC_9899].  The common prefix is compared.  If the
       common prefix is not equal, the string with the lower prefix has
       higher precedence.

Cui, et al.              Expires 20 January 2025                [Page 8]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

   When there are multiple component exist in multiple NLRI, determine
   the order of the packet content filters according to the above
   ordering rules.

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:

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

Cui, et al.              Expires 20 January 2025                [Page 9]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

   +------------+---------------------------+---------------+
   | 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, December 2020,
              <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, December 2020,
              <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, March 1997,
              <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,
              May 2017, <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.

Cui, et al.              Expires 20 January 2025               [Page 10]
Internet-Draft   Packet Content Filter for BGP FlowSpec        July 2024

Authors' Addresses

   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
   Phone: +1-734-604-0332
   Email: shares@ndzh.com

Cui, et al.              Expires 20 January 2025               [Page 11]