IDR Working Group S. Hares Internet-Draft Hickory Hill Consulting Intended status: Standards Track D. Eastlake Expires: 25 April 2024 Futurewei Technologies C. Yadlapalli ATT S. Maduscke Verizon 23 October 2023 BGP Flow Specification Version 2 draft-hares-idr-flowspec-v2-ddos-00 Abstract BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. IDR requires two implementations prior to standardization. Implementers feedback on FSv2 was that the complete FSv2 has the contains the correct information, but that breaking FSv2 into a progression of documents would be helpful. The first priority in this progression is expanded IP DDOS capabilities. This document contains original FSv2 IP DDOS capabilities in FlowSpec v2 using just the extended communities to define actions. 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 25 April 2024. Hares, et al. Expires 25 April 2024 [Page 1] Internet-Draft BGP FlowSpec v2 October 2023 Copyright Notice Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Why Flow Specification v2 . . . . . . . . . . . . . . . . 3 1.2. Definitions and Acronyms . . . . . . . . . . . . . . . . 5 1.3. RFC 2119 language . . . . . . . . . . . . . . . . . . . . 6 2. Flow Specification Version 2 Primer . . . . . . . . . . . . . 6 2.1. Flow Specification v1 (FSv1) Overview . . . . . . . . . . 7 2.2. Flow Specification v2 (FSv2) Overview . . . . . . . . . . 9 2.3. Flow Specification v2 (FSv2) Series of Specifications . . 12 3. FSv2 Filters and Actions . . . . . . . . . . . . . . . . . . 13 3.1. Basic IP Filters . . . . . . . . . . . . . . . . . . . . 15 3.1.1. IP header SubTLV (type=1(0x01)) . . . . . . . . . . . 15 3.1.2. FS Filter Error handling (type=250(0xFA)) . . . . . . 23 3.2. Encoding of FSV2 Actions for Basic DDOS . . . . . . . . . 24 3.2.1. FSV2 Basic DDOS Actions . . . . . . . . . . . . . . . 25 3.2.2. Summary of all FSv2 Actions (informative only) . . . 29 4. Validation and Ordering . . . . . . . . . . . . . . . . . . . 30 4.1. Validation of FSv2 NLRI . . . . . . . . . . . . . . . . . 30 4.1.1. Validation of FS NLRI (FSv1 or FSv2) . . . . . . . . 31 4.1.2. Validation of Flow Specification Actions . . . . . . 33 4.1.3. Error handling and Validation . . . . . . . . . . . . 33 4.2. Ordering for Flow Specification v2 (FSv2) . . . . . . . . 34 4.2.1. Ordering of FSv2 NLRI Filters . . . . . . . . . . . . 34 4.2.2. Ordering of the Actions . . . . . . . . . . . . . . . 36 4.3. Ordering of FS filters for BGP Peers support FSv1 and FSv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5. Scalability and Aspirations for FSv2 . . . . . . . . . . . . 42 6. Optional Security Additions . . . . . . . . . . . . . . . . . 43 6.1. BGP FSv2 and BGPSEC . . . . . . . . . . . . . . . . . . . 43 6.2. BGP FSv2 with ROA . . . . . . . . . . . . . . . . . . . . 44 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 7.1. Flow Specification V2 SAFIs . . . . . . . . . . . . . . . 44 7.2. BGP Capability Code . . . . . . . . . . . . . . . . . . . 45 Hares, et al. Expires 25 April 2024 [Page 2] Internet-Draft BGP FlowSpec v2 October 2023 7.3. Filter IP Component types . . . . . . . . . . . . . . . . 45 7.4. FSV2 NLRI TLV Types . . . . . . . . . . . . . . . . . . . 46 7.5. Wide Community Assignments . . . . . . . . . . . . . . . 47 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1. Normative References . . . . . . . . . . . . . . . . . . 48 9.2. Informative References . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction Version 2 of BGP flow specification was original defined in [I-D.ietf-idr-flowspec-v2] (denoted FSv2). However, the full FSv2 specification contains more than initial implementers desired. Therefore, the original FSv2 draft will remain a WG draft, but the content will be split out into functions that implementers can manage. This draft provides the FSv2 specification for DDOS for IP filtering using Extended communities with the following action features: * Minimal ordering of actions (4 actions) * Failure instructions (continue or stop) This flowspecification will be denoted as FSv2-DDOS. As BGP FSv1 as defined in [RFC8955], [RFC8956], and [RFC9117] specified 2 SAFIs (133, 134) to be used with IPv4 AFI (AFI = 1) and IPv6 AFI (AFI=2). This document specifies 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended). FSv1 and FSv2 use different AFI/SAFIs to send flow specification filters. Since BGP route selection is performed per AFI/SAFI, this approach can be termed “ships in the night” based on AFI/SAFI. 1.1. Why Flow Specification v2 Modern IP routers have the capability to forward traffic and to classify, shape, rate limit, filter, or redirect packets based on administratively defined policies. These traffic policy mechanisms allow the operator to define match rules that operate on multiple fields within header of an IP data packet. The traffic policy allows actions to be taken upon a match to be associated with each match Hares, et al. Expires 25 April 2024 [Page 3] Internet-Draft BGP FlowSpec v2 October 2023 rule. These rules can be more widely defined as “event-condition- action” (ECA) rules where the event is always the reception of a packet. BGP ([RFC4271]) flow specification as defined by [RFC8955], [RFC8956], [RFC9117] specifies the distribution of traffic filter policy (traffic filters and actions) via BGP to a mesh of BGP peers (IBGP and EBGP peers). The traffic filter policy is applied when packets are received on a router with the flow specification function turned on. The flow specification protocol defined in [RFC8955], [RFC8956], and [RFC9117] will be called BGP flow specification version 1 (BGP FSv1) in this draft. Some modern IP routers also include the abilities of firewalls which can match on a sequence of packet events based on administrative policy. These firewall capabilities allow for user ordering of match rules and user ordering of actions per match. Multiple deployed applications currently use BGP FSv1 to distribute traffic filter policy. These applications include: 1) mitigation of Denial of Service (DoS), 2) traffic filtering in BGP/MPLS VPNS, and 3) centralized traffic control for networks utilizing SDN control of router firewall functions, 4) classifiers for insertion in an SFC, and 5) filters for SRv6 (segment routing v6). During the deployment of BGP flow specification v1, the following issues were detected: * lack of consistent TLV encoding prevented extension of encodings, * inability to allow user defined order for filtering rules, * inability to order actions to provide deterministic interactions or to allow users to define order for actions, and * no clearly defined mechanisms for BGP peers which do not support flow specification v1. Networks currently cope with some of these issues by limiting the type of traffic filter policy sent in BGP. Current Networks do not have a good workaround/solution for applications that receive but do not understand FSv1 policies. Hares, et al. Expires 25 April 2024 [Page 4] Internet-Draft BGP FlowSpec v2 October 2023 FSv1 is a critical component of deployed applications. Therefore, this specification defines how FSv2 will interact with BGP peers that support either FSv2, FSv1, FSv2 and FSv1,or neither of them. It is expected that a transition to FSv2 will occur over time as new applications require FSv2 extensibility and user-defined ordering for rules and actions or network operators tire of the restrictions of FSv1 such as error handling issues and restricted topologies. Section 2 contains the definition of Flow specification, a short review of FSv1 and an overview of FSv2. Section 3 contains the encoding rules for FSv2 and user-based encoding sent via BGP. Section 4 describes how to validate FSv2 NLRI. Section 5 discusses how to order FSV2 rules. Section 6 covers combining FSv2 user- ordered match rules and FSv1 rules. Section 6 also discusses how to combine user-ordered actions, FSv1 actions, and default actions. Sections 7-10 address an alternate security mechanism, considerations for IANA, security in deployments, and scalability aspirations. 1.2. Definitions and Acronyms AFI - Address Family Identifier AS - Autonomous System BGPSEC - secure BGP [RFC8205] updated by [RFC8206] BGP Session ephemeral state - state which does not survive the loss of BGP peer session. Configuration state - state which persist across a reboot of software module within a routing system or a reboot of a hardware routing device. DDOs - Distributed Denial of Service. Ephemeral state - state which does not survive the reboot of a software module, or a hardware reboot. Ephemeral state can be ephemeral configuration state or operational state. FSv1 - Flow Specification version 1 [RFC8955] [RFC8956] FSv2 - Flow Specification version 2 (this document) NETCONF - The Network Configuration Protocol [RFC6241]. RESTCONF - The RESTCONF configuration Protocol [RFC8040] RIB - Routing Information Base. Hares, et al. Expires 25 April 2024 [Page 5] Internet-Draft BGP FlowSpec v2 October 2023 ROA - Route Origin Authentication [RFC6482] RR - Route Reflector. SAFI – Subsequent Address Family Identifier 1.3. RFC 2119 language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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. Flow Specification Version 2 Primer A BGP Flow Specification (v1 or v2) is an n-tuple containing one or more match criteria that can be applied to IP traffic, traffic encapsulated in IP traffic or traffic associated with IP traffic. The following are examples of such traffic: IP packet or an IP packet inside a L2 packet (Ethernet), an MPLS packet, and SFC flow. A given Flow Specification NLRI may be associated with a set of path attributes depending on the particular application, and attributes within that set may or may not include reachability information (e.g., NEXT_HOP). FSv1 and FSv2-DDOS use only the Extended Community to encode a set of pre-determined actions. The full FSv2 uses either Extended Communities or Wide Communities to encode actions. A particular application is identified by a specific AFI/SAFI (Address Family Identifier/Subsequent Address Family Identifier) and corresponds to a distinct set of RIBs. Those RIBs should be treated independently of each other in order to assure noninterference between distinct applications. BGP processing treats the NLRI as a key to entries in AFI/SAFI BGP databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics which are application dependent. Standard BGP mechanisms such as update filtering by NLRI or by attributes such as AS_PATH or large communities apply to the BGP Flow Specification defined NLRI-types. Network operators can control the propagation of BGP routes by enabling or disabling the exchange of routes for a particular AFI/ SAFI pair on a particular peering session. As such, the Flow Specification may be distributed to only a portion of the BGP infrastructure. Hares, et al. Expires 25 April 2024 [Page 6] Internet-Draft BGP FlowSpec v2 October 2023 2.1. Flow Specification v1 (FSv1) Overview The FSv1 NLRI defined in [RFC8955] and [RFC8956] include 13 match conditions encoded for the following AFI/SAFIs: * IPv4 traffic: AFI:1, SAFI:133 * IPv6 Traffic: AFI:2, SAFI:133 * BGP/MPLS IPv4 VPN: AFI:1, SAFI: 134 * BGP/MPLS IPv6 VPN: AFI:2, SAFI: 134 If one considers the reception of the packet as an event, then BGP FSv1 describes a set of Event-MatchCondition-Action (ECA) policies where: * event is the reception of a packet, * condition stands for “match conditions” defined in the BGP NLRI as an n-tuple of component filters, and * the action is either: the default condition (accept traffic), or a set of actions (1 or more) defined in Extended BGP Community values [RFC4360]. The flow specification conditions and actions combine to make up FSv1 specification rules. Each FSv1 NLRI must have a type 1 component (destination prefix). Extended Communities with FSv1 actions can be attached to a single NLRI or multiple NLRIs in a BGP message Within an AFI/SAFI pair, FSv1 rules are ordered based on the components in the packet (types 1-13) ordered from left-most to right-most and within the component types by value of the component. Rules are inserted in the rule list by component-based order where an FSv1 rule with existing component type has higher precedence than one missing a specific component type, Hares, et al. Expires 25 April 2024 [Page 7] Internet-Draft BGP FlowSpec v2 October 2023 Since FSv1 specifications ([RFC8955], [RFC8956], and [RFC9117]) specify that the FSv1 NLRI MUST have a destination prefix (as component type 1) embedded in the flow specification, the FSv1 rules with destination components are ordered by IP Prefix comparison rules for IPv4 ([RFC8955]) and IPv6 ([RFC8956]). [RFC8955] specifies that more specific prefixes (aka longest match) have higher precedence than that of less specific prefixes and that for prefixes of the same length the lower IP number is selected (lowest IP value). [RFC8955] specifies that if the offsets within component 1 are the same, then the longest match and lowest IP comparison rules from [RFC8955] apply. If the offsets are different, then the lower offset has precedence. These rules provide a set of FSv1 rules ordered by IP Destination Prefix by longest match and lowest IP address. [RFC8955] also states that the requirement for a destination prefix component “MAY be relaxed by explicit configuration” Since the rule insertions are based on comparing component types between two rules in order, this means the rules without destination prefixes are inserted after all rules which contain destination prefix component. The actions specified in FSv1 are: * accept packet (default), * traffic flow limitation by bytes (0x6), * traffic-action (0x7), * redirect traffic (0x8), * mark traffic (0x9), and * traffic flow limitation by packets (12, 0xC) Figure 1 shows a diagram of the FSv1 logical data structures with 5 rules. If FSv1 rules have destination prefix components (type=1) and FSv1 rule 5 does not have a destination prefix, then FSv1 rule 5 will be inserted in the policy after rules 1-4. Hares, et al. Expires 25 April 2024 [Page 8] Internet-Draft BGP FlowSpec v2 October 2023 +--------------------------------------+ | Flow Specification (FS) | | Policy | +--------------------------------------+ ^ ^ ^ | | | | | | +--------^----+ +-------^-------+ +-------------+ | FS Rule 1 | | FS Rule 2 | ... | FS rule 5 | +-------------+ +---------------+ +-------------+ : : : : ...: :........ : : +---------V---------+ +----V-------------+ | Rule Condition | | Rule Action | | in BGP NLRIs | | in BGP extended | | AFIs: 1 and 2 | | Communities | | SAFI 133, 134 | | | +-------------------+ +------------------+ : : : : : : .....: . :..... .....: . :..... : : : : : : +----V---+ +---V----+ +--V---+ +-V------+ +--V-----++--V---+ | Match | | match | |match | | Action | | action ||action| |Operator| |Variable| |Value | |Operator| |variable|| Value| |*1 | | | | | |(subtype| | || | +--------+ +--------+ +------+ +--------+ +--------++------+ *1 match operator may be complex. Figure 2-1: BGP Flow Specification v1 Policy 2.2. Flow Specification v2 (FSv2) Overview Flow Specification v2 allows the user to order the flow specification rules and the actions associated with a rule. Each FSv2 rule may have one or more match conditions and one or more associated actions. The IDR WG draft [I-D.ietf-idr-flowspec-v2] contains the complete solution for FSv2. However, this complete solution makes implementation of these features a large task so, please see the next section on how the complete solution is broken into a series of solutions. This section describres the complete solution. This FSv2 specification supports the components and actions for the following: * IPv4 (AFI=1, SAFI=TBD1) [defined in FSv2-DDOS], Hares, et al. Expires 25 April 2024 [Page 9] Internet-Draft BGP FlowSpec v2 October 2023 * IPv6 (AFI=2, SAFI=TBD2) [defined in FSv2-DDOS], * L2 (AFI=6, SAFI=TDB1) [defined in FSv2-L2], * BGP/MPLS IPv4 VPN: (AFI=1, SAFI=TBD2), * BGP/MPLS IPv6 VPN: (AFI=2, SAFI=TBD2), * BGP/MPLS L2VPN (AFI=25, SAFI=TDB2) [defined in FSv2-L2], * SFC: (AFI=31, SAFI=TBD1) [defined in FSv2-SFC], and * SFC VPN (AFI=31, SAFI=TBD2) [defined in FSv2-SFC]. The FSv2 specification for tunnel traffic is outside the scope of this specification. The FSv1 specification for tunneled traffic is in [I-D.ietf-idr-flowspec-nvo3]. The FSv2 tunnel traffic will be defined in [FSv2-Tunnel]. FSv2 operates in the ships-in-the night model with FSv1 so network operators can manipulate which the distribution of FSv2 and FSv1 using configuration parameters. Since the lack of deterministic ordering was an FSv1 problem, this specification provides rules and protocol features to keep filters in a deterministic order between FSv1 and FSv2. The basic principles regarding ordering of flow specification filter rules are: 1) Rule-0 (zero) is defined to be 0/0 with the “permit-all” action. 2) FSv2 rules are ordered based on user-specified order. - The user-specified order is carried in the FSv2 NLRI and a numerical lower value takes precedence over a numerically higher value. For rules received with the same order value, the FSv1 rules apply (order by component type and then by value of the components). 3) FSv2 rules are added starting with Rule 1 and FSv1 rules are added after FSv2 rules - For example, BGP Peer A has FSv2 data base with 10 FSv2 rules (1-10). FSv1 user number is configured to start at 301 so 10 FSv1 rules are added at 301-310. Hares, et al. Expires 25 April 2024 [Page 10] Internet-Draft BGP FlowSpec v2 October 2023 4) An FSv2 peer may receive BGP NLRI routes from a FSv1 peer or a BGP peer that does not support FSv1 or FSv2. The capabilities sent by a BGP peer indicate whether the AFI/SAFI can be received (FSv1 NLRI or FSv2 NLRI). 5) Associate a chain of actions to rules based on user-defined action number (1-n). (optional) - If no actions are associated with a filter rule, the default is to drop traffic the filter rules match - An action chain of 1-n actions can be associated with a set of filter rules can via Extended Communities or Wide Communities. Only Wide Communities can associate a user-defined order for the actions. Extended Community actions occur after actions with a user specified order (see section 5.2 for details). Figure 2-2 provides a logical diagram of the FSv2 structure Hares, et al. Expires 25 April 2024 [Page 11] Internet-Draft BGP FlowSpec v2 October 2023 +--------------------------------+ | Rule Group | +--------------------------------+ ^ ^ ^ | |--------- | | | ------ | | | +--------^-------+ +-------^-----+ +---^-----+ | Rule1 | | Rule2 | ... | Rule-n | +----------------+ +-------------+ +---------+ : : : : :.................: : : : : |.........: : : +--V--+ +--V--+ : : | name| |order| .........: :..... +-----+ +-----+ : : : : +----------------V----+ +-----V----------------+ |Rule Match condition | | Rule Action | +---------------------+ +----------------------+ : : : : : : : : | +--V--+ : : : +--V---+ : : : V | Rule| : : : |action| : : : +-----------+ | name| : : : |order | : : : |action name| +-----+ : : : +------+ : : : +-----------+ : : : : : :............. : : : : : : .....: . :..... ..: :...... : : : : : : : +----V---+ +---V----+ +--V---+ +-V------+ +--V-----+ +--V---+ | Match | | match | |match | | Action | | action | |action| |Operator| |variable| |Value | |Operator| |Variable| | Value| +--------+ +--------+ +------+ +--------+ +--------+ +------+ Figure 2-2: BGP FSv2 Data storage 2.3. Flow Specification v2 (FSv2) Series of Specifications The full FSV2 information is contained in [I-D.ietf-idr-flowspec-v2] Feedback from the implementers indicate that the Flow Specification v2 needs to broken into drafts based on the use cases the technology supports. These include IPv4/IPv6 DDOS, IPv4/IPv6 filters beyond DDOS, BGP/MPLS IPv4 VPN, BGP/MPLS IPv6 VPN, BGP/MPLS L2VPN, Segment routing (SRMPLS, SRv6), SFC, SFC VPN, and tunnel. The following is the list of planned drafts: Hares, et al. Expires 25 April 2024 [Page 12] Internet-Draft BGP FlowSpec v2 October 2023 FSv2 IP DDOS (FSv2 IP DDOS): The first draft will support IP filter functions (Type 1) and Extended Community actions supported by [RFC8955] and [RFC8956] with additions to provide the following: * user ordering of IP filters * new filter for filtering of unknown FSv2 types and filters (type = 250) * no support for user ordering of actions * a new action (Action Chain Operation) for handling failures when multiple actions are associated with a set of filters. This draft provides the basic functions all other FSv2 drafts will extend. FSv2 IP Extensions (FSv2 IP DDOS Extra): This draft provides extensions for proposed filters for IP FSv2. FSv2 Non-IP (FSv2 Non-IP): This draft provides Non-IP Filters filters for BGP/MPLS IPv4 VPNS, BGP/MPLS IPv6 VPNs, Segment Routing (SRMPLS and SRV6). FSv2 L2VPN: [I-D.ietf-idr-flowspec-l2vpn] provides user ordered filters for L2VPNs. FSv2 Additional Extended Community Actions (FSv2 EC Actions Extra) : This draft provides additional Flow Specification Actions that can be implemented safely with action chain failures, but without user ordering. FSv2 Wide Community Actions in Type 1 (FSv2 Wide Action T1): This draft provides the Wide Community actions in the Type 1 format of Wide communities. FSv2 Wide Community Actions in Type 2 (FSv2 Wide Action T2): This draft provides Wide Community actions in the type 2 format of Wide communities. 3. FSv2 Filters and Actions The BGP FSv2 uses an NRLI with the format for AFIs for IPv4 (AFI = 1), IPv6 (AFI = 2), L2 (AFI = 6), L2VPN (AFI=25), and SFC (AFI=31) with SAFIs TBD1 and TBD2 to support transmission of the flow specification which supports user ordering of traffic filters and actions for IP traffic and IP VPN traffic. Hares, et al. Expires 25 April 2024 [Page 13] Internet-Draft BGP FlowSpec v2 October 2023 This NLRI information is encoded using MP_REACH_NLRI and MP_UNREACH_NLRI attributes defined in [RFC4760]. When advertising FSv2 NLRI, the length of the Next-Hop Network Address MUST be set to 0. Upon reception, the Network Address in the Next-Hop field MUST be ignored. Implementations wishing to exchange flow specification rules MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) as defined in [RFC4760], and indicate a capability for FSv1, FSv2 (Code TBD3), or both. The AFI/SAFI NLRI for BGP Flow Specification version 2 (FSv2) has the format: +-------------------------------+ |length (2 octets) | +-------------------------------+ | Sub-TLVs (variable) | | +===========================+ | | | order (4 octets) | | | +---------------------------+ | | | identifier (4 octets) | | | +---------------------------+ | | | type (2 octets) | | | +---------------------------+ | | | length-Subtlv (2 octets) | | | +---------------------------+ | | | value (variable) | | | +===========================+ | +-------------------------------+ Figure 3-1: FSv2 format where: * length: length of field including all SubTLVs in octets. - The combined lengths of any FSv2 NLRI in the MP_REACH_NLRI or MP_UNREACH_NLRI. The BGP NLRI length must be less than the packet size minus the other fields (BGP header, BGP Path Attributes, and NLRI). * order: flow-specification global rule order number (4 octets). * identifier: identifier for the rule (used for NM/Logging) (4 octets) Hares, et al. Expires 25 April 2024 [Page 14] Internet-Draft BGP FlowSpec v2 October 2023 * type: contains a type for FSv2 TLV format of the NRLI (2 octets) which can be: - 0 - reserved, - 1 - IP Traffic Rules - 2 - Extended IP rules - 3- L2 traffic rules - 4- SFC Traffic rules - 5- SFC VPN Traffic rules - 6 - BGP/MPLS VPN IP Traffic Rules - 7 - BGP/MPLS VPN L2 Traffic Rules - 8 - Tunneled traffic * length-Subtlv: is the length of the value part of the Sub-TLV, * value: value depends on the subTLV (see sections below). The FSv2 Basic DDOS function must recognize that the defined types are valid even if the implementation does not support anything except 3.1. Basic IP Filters 3.1.1. IP header SubTLV (type=1(0x01)) The format of the IP header TLV value field is shown in figure 3-2. The IP header for the VPN case is specified in section 3.5. +-------------------------------+ | +--------------------------+ | | | (subTLVs)+ | | | +==========================+ | +-------------------------------+ Figure 3-2 - IP Header TLV Where: Each SubTLV has the format: Hares, et al. Expires 25 April 2024 [Page 15] Internet-Draft BGP FlowSpec v2 October 2023 +-------------------------------+ | SubTLV type (1 octet) | +-------------------------------+ | length (1 octet) | + ------------------------------+ | value (variable) | +-------------------------------+ Figure 3-3 – IP header SubTLV format Where: SubTLV type: component values are defined in the “Flow Specification Component types” registry for IPv4 and IPv6 by [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6] length: length of SubTLV (varies depending on SubTLV type). value: dependent on the subTLV - For descriptions of value portions for components 1-13 see [RFC8955] and [RFC8956]. For component 14 see [I-D.ietf-idr-flowspec-srv6]. Many of the components use the operators [numeric_op] and [bitmask_op] defined in [RFC8955] The list of valid SubTLV types appears in Table 2. Hares, et al. Expires 25 April 2024 [Page 16] Internet-Draft BGP FlowSpec v2 October 2023 Table 2 IP SubTLV Types for IP Filters DDOS support SubTLV -type Definition ====== ============ 1 - IP Destination prefix 2 - IP Source prefix 3 – IPv4 Protocol / IPv6 Upper Layer Protocol 4 – Port 5 – Destination Port 6 – Source Port 7 – ICMPv4 type / ICMPv6 type 8 – ICMPv4 code / ICPv6 code 9 – TCP Flags 10 – Packet length 11 – DSCP 12 – Fragment 13 – Flow Label 14 - TTL 15-63 reserved for IP Extensions (standards action) Table 2b IP SubTLV types for non-IP Filters SubTLV IP SubTLV types -type Definition ====== =========== 64 Parts of SID 65 MPLS LAbel Match-1 66 MPLS Label Match-2 67-127 Match reserved for Non-IP 128-191 reserved (standards action) 192-249 FCFS 250- FSv2 Filter Error handling 251-255 Reserved 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. NLRIs having TLVs which do not follow the above ordering rules MUST be considered as malformed by a BGP FSv2 propagator. This rule prevents any ambiguities that arise from the multiple copies of the same NLRI from multiple BGP FSv2 propagators. A BGP implementation SHOULD treat such malformed NLRIs as "Treat-as- withdraw" [RFC7606]. Hares, et al. Expires 25 April 2024 [Page 17] Internet-Draft BGP FlowSpec v2 October 2023 See [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6]. for specific details. 3.1.1.1. IP Destination Prefix (type = 1) IPv4 Name: IP Destination Prefix (reference: [RFC8955]) IPv6 Name: IPv6 Destination Prefix (reference: [RFC8956]) IPv4 length: Prefix length in bits IPv4 value: IPv4 Prefix (variable length) IPv6 length: length of value IPv6 value: [offset (1 octet)] [pattern (variable)] [padding(variable)] If IPv6 length = 0 and offset = 0, then component matches every address. Otherwise, length must be offset "less than" length "less than" 129 or component is malformed. 3.1.1.2. IP Source Prefix (type = 2) IPv4 Name: IP Source Prefix (reference: [RFC8955]) IPv6 Name: IPv6 Source Prefix (reference: [RFC8956]) IPv4 length: Prefix length in bits IPv4 value: Source IPv4 Prefix (variable length) IPv6 length: length of value IPv6 value: [offset (1 octet)] [pattern (variable)][padding(variable)] If IPv6 length = 0 and offset = 0, then component matches every address. Otherwise, length must be offset < length < 129 or component is malformed. 3.1.1.3. IP Protocol (type = 3) IPv4 Name: IP Protocol IP Source Prefix (reference: [RFC8955]) Hares, et al. Expires 25 April 2024 [Page 18] Internet-Draft BGP FlowSpec v2 October 2023 IPv6 Name: IPv6 Upper-Layer Protocol: (reference: [RFC8956]) IPv4 length: variable IPv4 value: [numeric_op, value]+ IPv6 length: variable IPv6 value: [numeric_op, value}+ where the value following each numeric_op is a single octet. 3.1.1.4. Port (type = 4) IPv4/IPv6 Name: Port (reference: [RFC8955]), [RFC8956]) Filter defines: a set of port values to match either destination port or source port. IPv4 length: variable IPv4 value: [numeric_op, value]+ IPv6 length: variable IPv6 value: [numeric_op, value]+ where the value following each numeric_op is a single octet. Note-1: (from FSV1) In the presence of the port component (destination or source port), only a TCP (port 6) or UDP (port 17) packet can match the entire flow specification. If the packet is fragmented and this is not the first fragment, then the system may not be able to find the header. At this point, the FSv2 filter may fail to detect the correct flow. Similarly, if other IP options or the encapsulating security payload (ESP) is present, then the node may not be able to describe the transport header and the FSv2 filter may fail to detect the flow. The restriction in note-1 comes from the inheritance of the FSv1 filter component for port. If better resolution is desired, a new FSv2 filter should be defined. Hares, et al. Expires 25 April 2024 [Page 19] Internet-Draft BGP FlowSpec v2 October 2023 Note-2: FSv2 component only matches the first upper layer protocol value. 3.1.1.5. Destination Port (type = 5) IPv4/IPv6 Name: Destination Port (reference: [RFC8955]), [RFC8956]) Filter defines: a list of match filters for destination port for TCP or UDP within a received packet Length: variable Component Value format: [numeric_op, value]+ 3.1.1.6. Source Port (type = 6) IPv4/IPv6 Name: Source Port (reference: [RFC8955]), [RFC8956]) Filter defines: a list of match filters for source port for TCP or UDP within a received packet IPv4/IPv6 length: variable IPv4/Ipv6 value: [numeric_op, value]+ 3.1.1.7. ICMP Type (type = 7) IPv4: ICMP Type (reference: [RFC8955]) Filter defines: Defines: a list of match criteria for ICMPv4 type IPv6: ICMPv6 Type (reference: [RFC8956]) Filter defines: a list of match criteria for ICMPv6 type. IPv4/IPv6 length: variable IPv4/IPv6 value: [numeric_op, value]+ 3.1.1.8. ICMP Code (type = 8) IPv4: ICMP Type (reference: [RFC8955]) Filter defines: a list of match criteria for ICMPv4 code. IPv6: ICMPv6 Type (reference: [RFC8956]) Hares, et al. Expires 25 April 2024 [Page 20] Internet-Draft BGP FlowSpec v2 October 2023 Filter defines: a list of match criteria for ICMPv6 code. IPv4/IPv6 length: variable IPv4/IPv6 value: [numeric_op, value]+ 3.1.1.9. TCP Flags (type = 9) IPv4/IPv6: TCP Flags Code (reference: [RFC8955]) Filter defines: a list of match criteria for TCP Control bits IPv4/IPv6 length: variable IPv4/IPv6 value: [bitmask_op, value]+ Note: a 2 octets bitmask match is always used for TCP-Flags 3.1.1.10. Packet length (type = 10 (0x0A)) IPv4/IPv6: Packet Length (reference: [RFC8955], [RFC8956]) Filter defines: a list of match criteria for length of packet (excluding L2 header but including IP header). IPv4/IPv6 length: variable IPv4/IPv6 value: [numeric_op, value]+ Note:[RFC8955] uses either 1 or 2 octet values. 3.1.1.11. DSCP (Differentiaed Services Code Point)(type = 11 (0x0B)) IPv4/IPv6: DSCP Code (reference: [RFC8955], [RFC8956]) Filter defines: a list of match criteria for DSCP code values to match the 6-bit DSCP field. IPv4/IPv6 length: variable IPv4/IPv6 value: [numeric_op, value]+ Hares, et al. Expires 25 April 2024 [Page 21] Internet-Draft BGP FlowSpec v2 October 2023 Note: This component uses the Numeric Operator (numeric_op) described in [RFC8955] in section 4.2.1.1. Type 11 component values MUST be encoded as single octet (numeric_op len=00). The six least significant bits contain the DSCP value. All other bits SHOULD be treated as 0. 3.1.1.12. Fragment (type = 12 (0x0C)) IPv4/IPv6: Fragment (reference: [RFC8955], [RFC8956]) Filter defines: a list of match criteria for specific IP fragments. Length: variable Component Value format: [bitmask_op, value]+ Bitmask values are: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 |LF |FF |IsF| DF| +---+---+---+---+---+---+---+---+ Figure 3-4 Where: DF (don’t fragment): match If IP header flags bit 1 (DF) is 1. IsF(is a fragment other than first: match if IP header fragment offset is not 0. FF (First Fragment): Match if [RFC0791] IP Header Fragment offset is zero and Flags Bit-2 (MF) is 1. LF (last Fragment): Match if [RFC7091] IP header Fragment is not 0 And Flags bit-2 (MF) is 0 0: MUST be sent in NLRI encoding as 0, and MUST be ignored during reception. 3.1.1.13. Flow Label(type = 13 (0xOD)) IPv4/IPv6: Fragment (reference: [RFC8956]) Filter defines: a list of match criteria for 20-bit Flow Label in the IPv6 header field. Hares, et al. Expires 25 April 2024 [Page 22] Internet-Draft BGP FlowSpec v2 October 2023 Length: variable Component Value format: [numeric_op, value]+ 3.1.1.14. TTL (type=14 (0x0E)) TTL: Defines matches for 8-bit TTL field in IP header Encoding: <[numeric_op, value]+> where: value is a 1 octet value for TTL. ordering: by full value of number_op concatenated with value conflict: none reference: draft-bergeon-flowspec-ttl-match-00.txt 3.1.2. FS Filter Error handling (type=250(0xFA)) Editor note: This filters FSv2 information. Is it useful? If not, it can be moved to the non-IP section. Type Filter Error handling(0xFA) Function: This function suggests additional for unknown types and missing fields in the FSv2 NLRI reference: none Encoding: The use of BGPSEC [RFC8205] to secure the packet can increase security of BGP flow specification information sent in the packet. The use of the reduced validation within an AS [RFC9117] can provide adequate validation for distribution of flow specification within a single autonomous system for prevention of DDoS. Distribution of flow filters may provide insight into traffic being sent within an AS, but this information should be composite information that does not reveal the traffic patterns of individuals. 9. References 9.1. Normative References [I-D.ietf-idr-bgp-flowspec-label] liangqiandeng, Hares, S., You, J., Raszuk, R., and D. Ma, "Carrying Label Information for BGP FlowSpec", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-flowspec- label-02, 20 October 2022, . Hares, et al. Expires 25 April 2024 [Page 48] Internet-Draft BGP FlowSpec v2 October 2023 [I-D.ietf-idr-flowspec-interfaceset] Litkowski, S., Simpson, A., Patel, K., Haas, J., and L. Yong, "Applying BGP flowspec rules on a specific interface set", Work in Progress, Internet-Draft, draft-ietf-idr- flowspec-interfaceset-05, 18 November 2019, . [I-D.ietf-idr-flowspec-l2vpn] Weiguo, H., Eastlake, D. E., Litkowski, S., and S. Zhuang, "BGP Dissemination of L2 Flow Specification Rules", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec- l2vpn-22, 16 October 2023, . [I-D.ietf-idr-flowspec-mpls-match] Yong, L., Hares, S., liangqiandeng, and J. You, "BGP Flow Specification Filter for MPLS Label", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-mpls-match-02, 20 October 2022, . [I-D.ietf-idr-flowspec-nvo3] Eastlake, D. E., Weiguo, H., Zhuang, S., Li, Z., and R. Gu, "BGP Dissemination of Flow Specification Rules for Tunneled Traffic", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-nvo3-18, 5 July 2023, . [I-D.ietf-idr-flowspec-path-redirect] Van de Velde, G., Patel, K., and Z. Li, "Flowspec Indirection-id Redirect", Work in Progress, Internet- Draft, draft-ietf-idr-flowspec-path-redirect-12, 24 November 2022, . [I-D.ietf-idr-flowspec-srv6] Li, Z., Li, L., Chen, H., Loibl, C., Mishra, G. S., Fan, Y., Zhu, Y., Liu, L., and X. Liu, "BGP Flow Specification for SRv6", Work in Progress, Internet-Draft, draft-ietf- idr-flowspec-srv6-04, 8 October 2023, . Hares, et al. Expires 25 April 2024 [Page 49] Internet-Draft BGP FlowSpec v2 October 2023 [I-D.ietf-idr-wide-bgp-communities] Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., and P. Jakma, "BGP Community Container Attribute", Work in Progress, Internet-Draft, draft-ietf-idr-wide-bgp- communities-11, 9 March 2023, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, . [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, . Hares, et al. Expires 25 April 2024 [Page 50] Internet-Draft BGP FlowSpec v2 October 2023 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, . [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, August 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC9015] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for the Network Service Header in Service Function Chaining", RFC 9015, DOI 10.17487/RFC9015, June 2021, . [RFC9117] Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", RFC 9117, DOI 10.17487/RFC9117, August 2021, . [RFC9184] Loibl, C., "BGP Extended Community Registries Update", RFC 9184, DOI 10.17487/RFC9184, January 2022, . 9.2. Informative References [I-D.ietf-idr-flowspec-v2] Hares, S., Eastlake, D. E., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2", Work in Hares, et al. Expires 25 April 2024 [Page 51] Internet-Draft BGP FlowSpec v2 October 2023 Progress, Internet-Draft, draft-ietf-idr-flowspec-v2-02, 21 May 2023, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [RFC8206] George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, September 2017, . Authors' Addresses Susan Hares Hickory Hill Consulting 7453 Hickory Hill Saline, MI 48176 United States of America Phone: +1-734-604-0332 Email: shares@ndzh.com Donald Eastlake Futurewei Technologies 2386 Panoramic Circle Apopka, FL 32703 United States of America Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Chaitanya Yadlapalli ATT United States of America Email: cy098d@att.com Hares, et al. Expires 25 April 2024 [Page 52] Internet-Draft BGP FlowSpec v2 October 2023 Sven Maduschke Verizon Germany Email: sven.maduschke@de.verizon.com Hares, et al. Expires 25 April 2024 [Page 53]