| Internet-Draft | BGP FlowSpec v2 | October 2021 |
| Hares, et al. | Expires 27 April 2022 | [Page] |
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. Multiple applications have used BGP FSv1 to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion.¶
During the deployment of BGP FSv1 a number of issues were detected due to lack of consistent TLV encoding for rules for flow specifications, lack of user ordering of filter rules and/or actions, and lack of clear definition of interaction with BGP peers not supporting FSv1. 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.¶
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 27 April 2022.¶
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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. Upon a match, the traffic policy allows actions to be associated with each match 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 routing.¶
During the deployment of BGP flow specification v1, the following issues were detected:¶
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.¶
This document defines version 2 of the BGP flow specification protocol to address these shortcomings in BGP FSv1. Version 2 of BGP flow specification will be denoted as BGP FSv2.¶
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) or a SubTLV of the FSv2 NRLI.¶
FSv1 and FSv2 use different AFI/SAFIs to send flow specification filters. Since BGP AFI/SAFIs perform route selection per AFI/SAFI, this approach can be termed "ships in the night" based on AFI/SAFI.¶
FSv1 is a critical component of deployed applications. Therefore, this specification defines how FSv2 will interact with BGP peers that support either FSv2 or FSv1 or BGP peers that do not support either FSv1 or FSv2. 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.¶
This section contains a short review of FSv1 and an overview of FSv2.¶
Section 3 contains the definition of flow specification v2. Section 4 contains the encoding rules for FSv2 and user-based encoding sent via BGP, and section 5 describes how to validate FSv2 NLRI. Section 6 discusses how to combine 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 manageability.¶
The FSv1 NLRI defined in [RFC8955] and [RFC8956] for this policy include 13 match conditions encoded for the following AFI/SAFIs¶
If one considers the reception of the packet as an event, then BGP flow specification describes a set of Event-MatchCondition-Action (ECA) policies where:¶
The flow specification conditions and actions combine to make up FSv1 specification rules. Each FSv1 NLRI must have a type 1 component (destination prefix) and Extended Communities with FSv1 actions can be attached to a single NLRI or multiple NLRIs in a BGP packet.¶
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 a FSv1 rule with existing component type has higher precedence than one missing a specific component type,¶
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 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 work to 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 by FSv1 are:¶
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.¶
+--------------------------------------+
| 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 1: BGP Flow Specification v1 Policy
¶
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.¶
This FSv2 specification supports the components and actions for the following¶
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].¶
FSv2 operates in the ships-in-the night model with FSv1 so network operators can manipulate FSv2 and FSv1 using configuration parameters. Since deterministic ordering was a short coming in FSv1, this specification provides rules and protocol features to keep filters in a deterministic order.¶
The basic principles regarding ordering of rules are simple:¶
2) FSv2 rules are ordered based on user-specified order.¶
3) FSv2 rules are added starting with Rule 1 and FSv1 rules are added after FSv2 rules.¶
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¶
Examples of action chain¶
An action associated with FSv2 NLRI using in a SubTLV always has a user-defined order. If two actions have the same user-defined order and the same action type, the ordering of the actions within the same type is defined by the action type (see section 4.2).¶
The use case for the Action which always associated with an NRLI is the DDOS match case that always drops the packet in order to kill off a widespread DDoS attack. The idea is easy, but the deployment issues may be more complex. An example may help illustrate this point.¶
Suppose BGP Peer A has a configured value for FSv2ExtComActionStart of 10. Suppose BGP Peer A receives the following attributes associated with the same FSv2 NLRI to form an action chain:¶
The FSv2 data base would store the following action chain:¶
at user-defined action order 10:¶
at user-defined action order 11 in order:¶
When does the action chain stop?¶
The default process for the action chain is to stop on failure.¶
If setting the packet-based rate limit of 1000 works, the action chain would go on to set the value of zero. If this works, it would go on to set the value to 50. This set of actions may not be what the user wanted if this is a DDoS attack.¶
BGP FSv2 rules are ephemeral by default (just as BGP routes are ephemeral) upon a restart of a BGP session or a router.¶
After FSv2 NLRI are checked for errors in syntax, those with valid syntax are checked for the same validation procedure FSv1 NLRI uses [RFC8955] and [RFC9117]. See section 5 for for a detailed discussion of validation and error handling.¶
Names may be associated with rules or actions in order for network management protocols (NETCONF/RESTCONF) to be able to provide detailed reports in the BGP Yang models.¶
Figure 2 provides a logical diagram of the FSv2 structure¶
+--------------------------------+
| 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: Order Flow Specification Data storage
¶
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.¶
A BGP Flow Specification is an n-tuple containing several match criteria that can be applied to IP traffic, traffic encapsulated in IP traffic or traffic associated with IP traffic. The following traffic filters are examples of traffic associated with IP 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). Extended Community or Wide Community attributes (well-known or AS-specific) MAY be used to encode a set of pre-determined actions.¶
A particular application is identified by a specific AFI/SAFI (Address Family Identifier/Subsequent Address Family Identifier) and responds 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.¶
The BGP Flow Specification version 2 (BGP-FS v2) 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 two following SAFIs to support transmission of the flow specification which supports user ordering of traffic filters and actions for iP traffic and IP VPN traffic.¶
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 of 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 flow specification v2 (Code TBD4).¶
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 -Flow Specification v2 format¶
where:¶
length: length of field including all SubTLVs in octets.¶
type: contains a type for the TLV format of the NRLI (2 octets) which can be:¶
The format of the IP header TLV value field is shown in figure 4. The AFI/SAFI field includes the AFI (2 octets), SAFI (1 octet). The AFI will be 1 (IPv4) or 2 (IPv6) and the SAFI will be TBD1 or, for the VPN case, TBD2.¶
+-------------------------------+
| +--------------------------+ |
| | AFI/SAFI field (3) | |
| | (subTLVs)+ | |
| +==========================+ |
+-------------------------------+
Figure 4 - IP Header TLV
¶
Each SubTLV has the format:¶
+-------------------------------+
| SubTLV type (1 octet) |
+-------------------------------+
| length (1 octet) |
+ ------------------------------+
| value (variable) |
+-------------------------------+
Figure 5 – IP header SubTLV format
¶
Where:¶
value: dependent on the subTLV¶
Many of the components use the operators [numeric_op] and [bitmask_op] defined in [RFC8955]¶
Table 2¶
The list of valid subtypes are:¶
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]. 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 arises 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].¶
See [RFC8955] and [RFC8956], and [I-D.ietf-idr-flowspec-srv6]. for specific details.¶
IPv4 Name: IP Destination Prefix (reference: [RFC8955])¶
IPv6 Name: IPv6 Destination prefix (reference: [RFC8956])¶
IPv4 length: Prefix length¶
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.¶
IPv4 Name: IP Source Prefix (reference: [RFC8955])¶
IPv6 Name: IPv6 Source prefix (reference: [RFC8956])¶
IPv4 length: Prefix length¶
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.¶
IPv4 Name: IP Protocol IP Source Prefix (reference: [RFC8955])¶
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.¶
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: 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.¶
This problem comes from the inheritance of the FSv1 filter component for port. If better resolution is desired, a new FSv2 filter should be defined.¶
Note-2: Although IPv6 allows for more than one Next Header field in the packet, the main goal of the Type 3 FSv2 component is to match the first upper layer protocol value.¶
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]+¶
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]+¶
IPv4: ICMP Type : Source Port (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]+¶
IPv4: ICMP Type : Source Port (reference: [RFC8955])¶
Filter defines: a list of match criteria for ICMPv4 code.¶
IPv6: ICMPv6 Type (reference: [RFC8956])¶
Filter defines: a list of match criteria for ICMPv6 code.¶
IPv4/IPv6 length: variable¶
IPv4/IPv6 value: [numeric_op, value]+¶
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¶
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]+¶
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]+¶
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.¶
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 6
¶
Where:¶
IPv4/IPv6: Fragment (reference: [RFC8956])¶
Filter defines: a list of match criteria for 20-bit Flow Label in the IPv6 header field.¶
Length: variable¶
Component Value format: [numeric_op, value]+¶
IPv6: Service Identifier Matches (reference: [I-D.ietf-idr-flowspec-srv6]¶
Filter defines: a list of match bit match criteria for some combinations of the LOC, FUNCT and ARG in SID fields in the SID or or whole SID.¶
Length: variable¶
Component Value format: [type, LOC-Len, FUNCT-Len, ARG-Len, [op, value]+]¶
where:¶
The total of three lengths (i.e., LOC length + FUNCT length + ARG length) MUST NOT be greater than 128. If it is greater than 128, an error occurs and it is treated as a withdrawl [RFC7606] and [RFC4760].¶
The operator (op) byte is encoded as:¶
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | field type|lt |gt |eq |
+---+---+---+---+---+---+---+---+
Figure 7
¶
where:¶
field type:¶
The data' and value' used in lt, gt and eq are indicated by the field type in an operator and the value field following the operator.¶
The value field depends on the field type and has the value of SID's some parts rounding up to bytes (refer to the table 3 in figure 8 below ).¶
Table 3 - SID Parts fields
+-----------------------+------------------------------+
| Field Type | Value |
+=======================+==============================+
| SID's LOC | value of LOC bits |
+-----------------------+------------------------------+
| SID's FUNCT | value of FUNCT bits |
+-----------------------+------------------------------+
| SID's ARG | value of ARG bits |
+-----------------------+------------------------------+
| SID's LOC:FUNCT | value of LOC:FUNCT bits |
+-----------------------+------------------------------+
| SID's FUNCT:ARG | value of FUNCT:ARG bits |
+-----------------------+------------------------------+
| SID's LOC:FUNCT:ARG | value of LOC:FUNCT:ARG bits |
+-----------------------+------------------------------+
Figure 8
¶
The FSv2 actions may be sent in an Extended Community, a Wide Community or an NLRI.¶
The Extended Community encodes the Flow Specification actions in the Extended Community format [RFC4360].¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type high | Type low(*) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
¶
The Wide Community definition for FSv2 actions is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Flags |C|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |<sequence of FSv2-Action-TLV>+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------------------------
Figure 10
¶
where FSv2-Action-TLV is defined as:¶
FSv2-Action-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| action order | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<action-subTLVs>+ |
+--------------------------------
Figure 11
¶
Where FS-SubTLVs have the format:¶
FS-SubTLVs
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubTLV type (2 octet) | length type (2 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value (variable) |
+-------------------------------+
Figure 12
¶
The FSv2 Action TLV may be included in the NLRI to be associated with a specific NLRI. (Note inclusion with the FSv2 NLRI does not have good scaling properties.)¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| action-order | chain-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length-TLV | value <SubTLVs>+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13
¶
where:¶
Each Action SubTLV has the format:¶
+-------------------------------+
| SubTLV type (2 octet) |
+-------------------------------+
| length (2 octet) |
+-------------------------------+
| value (variable) |
+-------------------------------+
Figure 14
¶
Where:¶
Table 4 – FSv2 Action types
Action Description
====== ===========
00 reserved
01 Action Chain Operation
02 traffic actions per interface group
06 traffic rate limited by bytes
07 traffic action (terminal/sample)
08 redirect IPv4
09 mark DSCP value
10 associate L2 Information
11 associate E-Tree Information
12 traffic rate limited by packets
13 redirect to IPv6
14 SFC Classifier Info (moved from OD to OE)
15 redirect to Indirection-id (move from 0x00)
15-21 TBA (to be assigned)
22 VLAN-Action (0x16)[draft-ietf-idr-flowspec-l2vpn-17]
23 TPID-Action (0x17) [draft-ietf-idr-flowspec-l2vpn-17]
24-254 TBA (to be assigned)
255 reserved
Figure 15
¶
Ordering of actions within a rule¶
The actions are first stored in user-defined order. If multiple actions exist for a single action order value, then the actions will be ordered by action type followed by value.¶
Action specifications must include descriptions of order comparison for the values within the action.¶
SubTLV: 0x01¶
Length: variable¶
Value:¶
Actions may succeed or fail and an Action chain must deal with it. The default value stored for an action chain that does not have this action chain is "stop on failure".¶
where:¶
Interactions with other actions: Interactions with all other Actions¶
Ordering within Action type:By AC-Failure type¶
SubTLV: 0x2¶
Length: 8 octets (6 in extended community)¶
Value field: [4-octet-AS] [GroupID 2-octet] [action 2-octet]¶
where:¶
Group-ID: identifier for group in 2 octets (14 lower bits)¶
Action: determines inbound or outbound action where:¶
Value ordering: AS, then Group ID, then Action bytes.¶
Conflict: with any bi-direction action such as¶
Reference: [I-D.ietf-idr-flowspec-interfaceset]¶
SubTLV:0x6¶
Length: 8 octets¶
Value field:[4-octet-AS] [float (4 bytes)]¶
where:¶
[4-octet-AS]:4 byte AS number¶
Float: maximum byte rate in IEEE floating point [IEEE.754.19895 format] in units per second.¶
Value ordering: AS then float value¶
Action Conflict: traffic-rate-packets¶
SubTLV: 0x7¶
Length: 1¶
Value field: [1-octet action]¶
where the traffic action values are:¶
Value ordering: By traffic action values¶
Conflicts/Interactions: duplication of packets also occurs in:¶
SubTLV: 0x08¶
Length: 12 octets¶
Value field:¶
[4-byte-AS] [IPv4 address (4 octets] [ID (4 octets)] [Flag (1 octet)]¶
where:¶
Flag is 1 octet value with the following definitions:¶
Value ordering: 4-octet AS, then IP addres, then ID (lowest to highest) with:¶
Conflicts/Interactions: Any redirection or traffic sampling found in:¶
SubTLV: 0x9¶
Length: 1 octet¶
Value: DSCP field with the 2 left most bits zero¶
The DSCP field format is:¶
0 1 2 3 4 5 6 7 +---------------+ |R R DSCP bits | +---------------+ Figure 16¶
where:¶
Ordering within Value: Based on DSCP value¶
Conflicts: none¶
SubTLV= 12 (0xC)¶
Length: 8¶
Value field: [4-octet-AS] [float (4 octet)]¶
Where:¶
Float - specifies maximum rate [IEEE.754.185] format in packets per second.¶
Ordering within Value: Based on DSCP value¶
Conflicts: Traffic rate limited by bytes (0x06)¶
SubTLV = 13 (0xD)¶
Length = 24 octets¶
Value field: [4-octet-as] [IPv6-address (16 octets)] [local administrator (2 octets] [Flag (1 octets)]¶
where:¶
lag (1 octet) with the following definitions:¶
Ordering within Value: AS, then IPv6, the flag (low to high)¶
Conflicts/Interactions: Any redirection or traffic sampling found in:¶
SubTLV = (14, 0xE)¶
Length = 6 octets¶
Value field: [SPI (3 octets)][SI (1 octet)][SFT (2 octet)]¶
where:¶
Value ordering: SPI, then SI, then SFT (lowest to highest)¶
Conflicts/Interactions: Any redirection or traffic sampling found in:¶
SubTLV: 15, 0x0F¶
Length: 6 octets¶
Value field:¶
[Flags (1 octet)] [ID-Type (1 octet)][Generalized-ID (4 octets)]¶
where:¶
Flags: are defined as:¶
ID-Type: type of indirection ID with following values:¶
Value Ordering: first indirection ID, then Generalized ID¶
Action Value ordering: ID-Type by value (lowest to highest)¶
Conflicts/Interactions: Any redirection or traffic sampling found in:¶
reference: [I-D.ietf-idr-flowspec-path-redirect]¶
Function: Rewrite inner or outer VLAN header¶
SubTLV: 22 (0x16)¶
Length: 6 octets¶
Value:¶
where:¶
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PO1|PU1|SW1|RI1|RO1| Resv |PO2|PU2|SW2|RI2|RO2| Resv |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 17
¶
Value ordering: rewrite-actions, VLAN1, VLAN2, PCP-DE1, PCP-DE2¶
Conflicts: TIPD Action¶
reference: [I-D.ietf-idr-flowspec-l2vpn]¶
Function: Replace Inner or outer TP¶
SubTLV: 23 (0x17)¶
Length: 6 octets¶
Value:¶
Where: rewrite-actions are bitmask (2 octets) with 2 actions as follows:¶
0 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TI|TO| Resv |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 18
¶
TI: Mapping inner Tag Protocol (TP) ID (typically a VLAN) action. If the TI flag is one, it indicates the inner TP ID should be replaced by a new TP ID, the new TP ID is TP ID1.¶
TO: Mapping outer TP ID action. If the TO flag is one, it indicates the outer TP ID should be replaced by a new TP ID, the new TP ID is TP ID2.¶
Resv: Reserved for future use. MUST be sent as zero and ignored on receipt¶
Value Ordering: rewrite-actions, TP-ID-1, TP-ID-2¶
Conflicts: VLAN action¶
reference:[I-D.ietf-idr-flowspec-l2vpn]¶
The SubTLV format is used for the Wide communities and for the action subTLVs in the NLRI.¶
Sub-TLV Action Action SubTLV Extended Community
type Name format format
======= ===== =============== ====================
1 ACO type: 1 not applicable (n/a)
length:variable
2 TAIS type: 2 type: 0x0702 or 0x4702
length:8 length: 6
[4-octet-as] [4-octet-AS]
[group-3-octet] [flags-group] (2)
[flags-1-octet]
3-5 reserved
Sub-TLV Action Action SubTLV Extended Community
type Name format format
======= ===== =============== ====================
6 TRB type:6 type:8006
length:8 length: 6
[4-byte-AS] [2-byte-AS]
[float (4 octets)] [float (4 octets)]
7 TA type:7 type:8007
length:1 length:6 octets
flags: (1 octet) flags (6 octets)
8 RDIPv4 type:8 type:8008
length: 12 length: 6 octets
[4-byte-AS] [AS-2-octets]
[IPv4-address] [IPv4 address]
type:8108
length: 6 octets
[IPv4 address]
[ID-2 octets]
type:8208
length: 6 octets
[AS-4-octets]
[ID-2-octets]
9 TM type:9 type:8009
length:1 length:6
DSCP: 1 octet DSCP: 1 octet
10-11 reserved
12 TRP type:12 (0xC) type: 0x800C
length: 8 octets length: 6 octets
[4-byte-AS] [2-byte-AS]
[float-4-octet] [float-4-octet]
13 RDIPv6 type:13 (0xD) type:0x000C
length:22 length: 18
[4-byte-AS] [IPv6-address (16)]
[IPv6-address (16)] [local-admin (2)]
[local-admin (2)]
Sub-TLV Action Action SubTLV Extended Community
type Name format format
======= ===== =============== ====================
14 TISFC type:14 (0xE) type: 0xD (FSv1)
type: 0xE (FSv2)
length:6 length:6
SPI (3 octets) SPI (3 octets)
SI (1 octet) SI (1 octet)
SFT (2 octets) SFT (2 octets)
15 RDIID type:15 (0xF) Type: 0900 (FSv1)
length: 6 length 6
flags (1) flags (1)
ID-type (1) ID type (1)
G-ID (4 octets) G-ID (4-octets)
16-21 reserved
22 VLAN type:22 (0x16) Type: (TBD)
length:6 length:6
[rewrite-action(2)] [rewrite-actions (2)]
[vlan-pcp-de-1 (2)] [vlan-pcp-de-1 (2)]
[vlan-pcp-de-2 (2)] [vlan-pcp-de-2 (2)]
23 TPID type:23 (0x17) Type: (TBD)
length:6 length:6
[rewrite-action(2)] [rewrite-actions (2)]
[TP-ID-1 (2)] [TP-ID-1 (2)]
[TP-ID-2 (2)] [TP-ID-2 (2)]
¶
field includes the AFI (2 octets), SAFI (1 octet) and will be 6/TBD1 or, for the VPN case, 28/TBD2¶
+-------------------------------+
| +--------------------------+ |
| | L3 AFI-SAFI field (3) | |
| | <subTLVs>+ | |
| +==========================+ |
+-------------------------------+
Each SubTLV has the format:
+-------------------------------+
| SubTLV type (1 octet) |
+-------------------------------+
| length (1 octet) |
+ ------------------------------+
| value (variable) |
+-------------------------------+
Figure 19
¶
SubTLV type: A component type value defined in the "L2 Flow Specification Component Types" registry for L2 by [draft-ietf-idr-flowspec-l2vpn).¶
Where the SubTLVs have the following component types:¶
Component Types Table Component type Description ======= ================== 1 EtherType 2 Source MAC 3 Destination MAC 4 DSAP (destination service access point) 5 SSAP (source service access point) 6 control field in LLC 7 SNAP 8 VLAN ID 9 VPAN PCP 10 Inner VLAN ID 11 Inner VLAN PCP 12 VLAN DEI 13 VLAN DEI 14 Source MAC special bits 15 Destination MAC special bits Table 4 – L2 VPN components¶
See [I-D.ietf-idr-flowspec-l2vpn] for the details on the format and value fields for each component.¶
Value ordering: Ordering of L2 FSv2 rules will be by user-defined order of the rule. For FSv2 filters within the same rule, the ordering will be by component number and then by value within the component. See [I-D.ietf-idr-flowspec-l2vpn] for the ordering of the values within the component.¶
reference: [I-D.ietf-idr-flowspec-l2vpn]¶
The FSv2 filters allow for filtering of the SFC NLRI family of routes. The traffic NLRIs filtered are from SFC AFI/SAFI (AFI = 31, SAFI=9).¶
The FSv2 filters provide this filtering with SFC AFI (AFI=31) and SAFI for FSv2 filters (SAFI = TB1).¶
+--------------------------------------+
| +---------------------------------+ |
| | Tunneled AFI/SAFI field | |
| | <subTLVs>+ | |
| +=================================+ |
+--------------------------------------+
Figure 20
¶
Each SubTLV has the format:¶
+-------------------------------+
| SubTLV type (1 octet) |
+-------------------------------+
| length (1 octet) |
+ ------------------------------+
| value (variable) |
+-------------------------------+
Figure 21 – Tunneled SubTLV format
¶
The components listed are:¶
1 = SFIR RD Type (types 1, 2, 3)
2 = SFIR RD Value
3 = SFIR Pool ID
4 = SFIR MPLS context/label
5 = SFPR SPI
6 = SPF attribute fields
Table 6 – SFC Filter types
¶
Ordering is by: User-defined rule order, component number, and then value within component.¶
The BGP Flow specification version 2 actions are passed in a Wide Community [I-D.ietf-idr-wide-bgp-communities] atom with the following format:¶
+----------------------------+ | atom-id | +----------------------------+ | length (2 octets) | +----------------------------+ | <Action-Sub-TLVs>+ | +----------------------------+ Figure 22 - Flow Specification with IDs for Wide Community Actions¶
where:¶
The BGP Flow Specification (BGP-FS) atom can be part of the Wide Community container (type 1) or the BGP Flow Specification Atom can be part of the BGP Flow Specification container (type 2) which will have:¶
+-----------------------------+ | Source AS Number (4 octets)| +-----------------------------+ | list of atoms (variable) | +-----------------------------+ Figure 23: Atom format¶
The validation of FSv2 NLRI adheres to the combination of rules for general BGP FSv1 NLRI found in [RFC8955], [RFC8956], [RFC9117], and the specific additions made for SFC NLRI [RFC9015], L2VPN NLRI [I-D.ietf-idr-flowspec-l2vpn].¶
To provide clarity, the full validation process for flow specification routes (FSv1 or FSv2) is described in this section rather than simply refer to the portions of these RFCs. Validation only occurs after BGP UPDATE packet, the FSv2 NLRI and the path attributes relating to FSv2 (Extended community and Wide Community) have been determined to be well-formed. Any MALFORMED FSv2 NRLI is handled as a "TREAT as WITHDRAW".¶
Flow specification received from a BGP peer that are accepted in the respective Adj-RIB-In are used as input to the route selection process. Although the forwarding attributes of the two routes for same prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise.¶
The first step of the BGP Route selection procedure (section 9.1.2 of [RFC4271] is to exclude from the selection procedure routes that are considered unfeasible. In the context of IP routing information, this is used to validate that the NEXT_HOP Attribute of a given route is resolvable.¶
The concept can be extended in the case of the Flow Specification NLRI to allow other validation procedures.¶
The FSv2 validation process validates the FSv2 NLRI with following unicast routes received over the same AFI (1 or 2) but different SAFIs:¶
The FSv2 validates L2 FSv2 NLRI with the following L2 routes received over the same AFI (25), but a different SAFI:¶
In the absence of explicit configuration, a Flow specification NLRI (FSv1 or FSv2) MUST be validated such that it is considered feasible if and only if all of the conditions are true:¶
b) One of the following conditions must hold true:¶
2. The AS_PATH attribute of the flow specification is empty or contains only an AS_CONFED_SEQUENCE segment [RFC5065].¶
However, rule a may be relaxed by explicit configuration, permitting Flow Specifications that include no destination prefix component. If such is the case, rules b and c are moot and MUST be disregarded.¶
By "originator" of a BGP route, we mean either the address of the originator in the ORIGINATOR_ID Attribute [RFC4456] or the source address of the BGP peer, if this path attribute is not present.¶
BGP implementation MUST enforce that the AS in the left-most position of the AS_PATH attribute of a Flow Specification Route (FSv1 or FSv2) received via the Exterior Border Gateway Protocol (eBGP) matches the AS in the left-most position of the AS_PATH attribute of the best-match unicast route for the destination prefix embedded in the Flow Specification (FSv1 or FSv2) NLRI.¶
The best-match unicast route may change over time independently of the Flow Specification NLRI (FSv1 or FSv2). Therefore, a revalidation of the Flow Specification MUST be performed whenever unicast routes change. Revalidation is defined as retesting rules a to c as described above.¶
Flow Specification may be mapped using Extended Communities, Wide Communities or a FSv2 NLRI TLV. The scaling of FSv2 actions implies that Extended Communities and wide communities which can associate an action to a large number of NLRIs will be most often used. Therefore, it is likely the FSv2 NLRI TLV for actions will be very few actions (such as the "die-die-die Internet worm" use case).¶
The ordering of precedence for these actions in the absence of user-defined ordering, is to follow the precedence of the FSv2 NLRI action TLV values (lowest to highest). If multiple items exist for the same action type, then ordering is described within each Action SubTLV. Extended Community actions should be translated to the Action SubTLV format for internal comparison.¶
Actions may conflict, duplicate, or complementation other actions. An example of conflict is the packet rate limiting by byte and by packet. An example of a duplicate is the request to copy or sample a packet under one of hte redirect functions (RDIPv4, RDIPv6, RDIID, ) Each FSv2 actions in this document defines the potential conflicts or duplications. Specifications for new FSv2 actions outside of this specification MUST specify interactions or conflicts with any FSv2 actions (in this specification or subsequent specification).¶
Well-formed syntactically correct actions should be linked to a filtering rule in order the actions should be enacted. If one action in the ordered list fails, the default procedure is for the action process for this rule to stop and flag the error via system management. By explicit configuration, the action processing may continue after errors..¶
Implementations MAY wish to log the actions taken by FS actions (FSv1 or FSv2).¶
The following two error handling rules must be followed by all BGP speakers which support FSv2:¶
The above two rules prevent any ambiguity that arises 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'.¶
An implementation for a BGP speaker supporting both FSv1 and FSv2 must support the error handling for both FSv1 and FSv2. The storage of the BGP FSv1 and FSv2 must support both the AFI/SAFI and the configuration which translates FSv1 NLRI into FSv2 NLRI for order storage.¶
Flow Specification v2 allows the user to order flow specification rules and the actions associated with a rule. Each FSv2 rule has one or more match conditions and one or more actions associated with each rule.¶
This section describes how to order FSv2 filters received from a peer prior to transmission to another peer. The same ordering should be used for the ordering of forwarding filtering installed based on only FSv2 filters.¶
Section 7.0 describes how a BGP peer that supports FSv1 and FSv2 should order order the flow specification filters during the installation of these flow specification filters into FIBs or firewall engines in routers.¶
The BGP distribution of FSv1 NLRI and FSv2 NLRI and their associated path attributes for actions (Wide Communities and Extended Communities) is "ships-in-the-night" forwarding of different AFI/SAFI information. This recommended ordering provides for deterministic ordering of filters sent by the BGP distribution.¶
The basic principles regarding ordering of rules are simple:¶
1) Rule-0 (zero) is defined to be 0/0 with the "permit-all" action¶
3) If multiple FSv2 NLRI have the same user-defined order, then the filters are ordered by type of FSv2 NRLI filters (see Table 1, section 4) with lowest numerical number have the best precedence.¶
For component types inherited from the FSv1 component types, there are the following two types of comparisons:¶
Notes:¶
The FSv2 specification allows for actions to be associated by:¶
Actions may be ordered by user-defined action order number from 1-n (where n is 2**16-2 and value of 2**16-1 is reserved.¶
Extended community actions are associated with order number 32768 [0x8000] or a specific configured value for the FSv2 domain.¶
Action user-order number zero is defined to have an Action type of "Set Action Chain operation" (ACO) (value 0x01) that defines the default action chain process. For details on "set action chain operation" see section 4.2.0 and section 6.2.1 below.¶
If the user-defined action number for an action is the same, then the actions are ordered by FSv2 action types (see Table 3 for a list of action types). If the user-defined action number and the FSv2 action types are the same, then the order must be defined by the FSv2 action.¶
The "Action Chain Operation" (ACO) changes the way the actions after this action in an action chain handles a failure. If no action chain operations are set, then the default action of "stop upon failure" (value 0x00) will be used for the chain.¶
An example may help illustrate how failure impacts an action chain. Suppose we have the following 4 actions defined for a match:¶
These 4 filters rate limit a potential DDoS attack by: a) redirect the packet to indirection ID (for slower speed processing), sample to local hardware, and forward the attack traffic via a SFC to a data collection box.¶
The FSv2 action list for the match would look like this¶
If the redirect to a redirection ID fails, then Traffic Sample and sending the data to an SFC classifier for forwarding via SFC will not happen. The traffic is limited, but not redirect away from the network and a sample sent to DDOS processing via a SFC classifier.¶
Suppose the following 5 actions were defined for a FSV2 filter:¶
The FSv2 action list for the match would look like this:¶
If the redirect to a redirection ID fails, the action chain will continue on to sample the data and enact SFC classifier actions.¶
Note:The scaling for associating actions is better with Wide or Extended Communities which can be associated with many FSv2 filters. The FSv2 action with FSv2 NLRI should be used in rare cases such the use case of an pernicious Internet worm. In this case, Suppose we call the filter "Internet worm" particular filter match identifies the pernicious Internet worm that must be die off and not be forwarded. Let us call the actions in the action chain "Die-Die-Internet-worm". For such a use case, the the FSV2 actions to stop the packets are tied to the filter even though it may not scale or have issues in some deployments.¶
Operators should use user-defined ordering to clearly specify the actions desired upon a match. The FSv2 actions default ordering is specified to provide deterministic order for actions which have the same user-defined order and same type.¶
FS Action Value Order
(lowest value to highest) (lowest to highest)
============================= =================================
0x01: Action chain operation Failure flag
0x02: traffic actions per AS, then Group-ID, then Action ID
Interface group
0x03-0x05 to be assigned TBD
0x06: Traffic rate limit AS, then float value
0x07 – Traffic Action traffic Action value
0x08 – Redirect to IP AS, then IP Address, then ID
0x09 – Traffic Marking DSCP value (lowest to highest)
0x0C – Redirect to Indirect ID AS, then Float value
0x0D – Traffic Redirect to IPv6 AS, IPv6 value, then local Admin
0x0E – Traffic insertion to SFC SPI, then SI, the SFT
0xOF – Redirect to
Indirection-ID ID-type, then Generalized-ID
0x10-0x15 – to be assigned TBD
0x16 – VLAN action rewrite-actions, VALN1, VLAN2,
PCP-DE1, PCP-DE2
0x17 – TPID action rewrite actions, TP-ID-1, TP-ID-2
Figure 24
¶
FSv2 allows the user to order flow specification rules and the actions associated with a rule. Each FSv2 rule has one or more match conditions and one or more actions associated with each rule.¶
Some BGP peers will support FSv1 and FSv2. This section describes the best practice for ordering the FSv1 and FSv2 filter rules.¶
One simple rule captures the best practice: Order the FSv1 filters after the FSv2 filter by placing the FSv1 filters after the FSv2 filters.¶
To operationally make this work, all flow specification filters should be included the same data base with the FSv1 filters being assigned a user- defined order beyond the normal size of FSv2 user-ordered values.¶
Suppose you might have 10,000 rules for the FSv2 filters. Assign all the FSv1 user defined rules to 10,001 (or better yet 20,000). The FSv1 rules will be ordered by the components and component values.¶
All FSv1 actions are defined ordered actions in FSv2. Translate your FSv1 actions into FSv2 ordered actions for storing in a common FSv1-FSv2 flow specification data base.¶
Operational issues drive the deployment of BGP flow specification as a quick and scalable way to distribute filters. The early operations accepted the fact validation of the distribution of filter needed to be done outside of the BGP distribution mechanism. Other mechanisms (NETCONF/RESTCONF or PCEP) have reply-request protocols.¶
These features within BGP have not changed. BGP still does not have an action-reply feature.¶
NETCONF/RESTCONF latest enhancements provide action/response features which scale. The combination of a quick distribution of filters via BGP and a long-term action in NETCONF/RESTCONF that ask for reporting of the installation of FSv2 filters may provide the best scalability.¶
The combination of NETCONF/RESTCONF NM protocols and BGP focuses each protocol on the strengths of scalability.¶
FSv2 will be deployed in webs of BGP peers which have some BGP peers passing FSv1, some BGP peers passing FSv2, some BGP peers passing FSv1 and FSv2, and some BGP peers not passing any routes.¶
The TLV encoding and deterministic behaviors of FSv2 will not deprecate the need for careful design of the distribution of flow specification filters in this mixed environment. The needs of networks for flow specification are different depending on the network topology and the deployment technology for BGP peers sending flow specification.¶
Suppose we have a centralized RR connected to DDoS processing sending out flow specification to a second tier of RR who distribute the information to targeted nodes. This type of distribution has one set of needs for FSv2 and the transition from FSv1 to FSv2¶
Suppose we have Data Center with a 3-tier backbone trying to distribute DDoS or other filters from the spine to combinational nodes, to the leaf BGP nodes. The BGP peers may use RR or normal BGP distribution. This deployment has another set of needs for FSv2 and the transition from FSv1 to FSV2.¶
Suppose we have a corporate network with a few AS sending DDoS filters using basic BGP from a variety of sites. Perhaps the corporate network will be satisfied with FSv1 for a long time.¶
These examples are given to indicate that BGP FSv2 like so many BGP protocols needs to be carefully tuned to aid the mitigation services within the network. This protocol suite starts the migration toward better tools using FSv2, but it does not end it. With FSv2 TLVs and deterministic actions, new operational mechanisms can start to be understood and utilized.¶
This FSv2 specification is merely the start of a revolution of work - not the end.¶
This section discusses the optional BGP Security additions for BGP-FS v2 relating to BGPSEC [RFC8205] and ROA.¶
Flow specification v1 ([RFC8955] and [RFC8956]) do not comment on how BGP Flow specifications to be passed BGPSEC [RFC8205] BGP Flow Specification v2 can be passed in BGPSEC, but it is not required.¶
FSv1 and FSv2 may be sent via BGPSEC.¶
BGP Flow Specification v2 can utilize ROAs in the validation. If BGP-FS v2 is used with BGPSEC and ROA, the first thing is to validate the route within BGPSEC and second to utilize BGP ROA to validate the route origin.¶
The BGP-FS peers using both ROA and BGP-FS validation determine that a BGP Flow specification is valid if and only if one of the following cases:¶
If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in destination address match filter and the following is true:¶
If a BGP ROA has not been received that matches the IPv4 or IPv6 destination address in the destination filter, the match filter must abide by the [RFC8955] and [RFC8956] validation rules of:¶
The best match is defined to be the longest-match NLRI with the highest preference.¶
This section complies with [RFC7153]¶
IANA is required to assign two SAFI Values from the registry at https://www.iana.org/assignments/safi-namespace from the Standard Action Range as follows:¶
Value Description Reference
----- ------------- ---------------
TBD1 BGP-FS V2 [This document]
TBD2 BGP-FS V2 VPN [this document]
¶
IANA is requested to assign a Capability Code from the registry at https://www.iana.org/assignments/capability-codes/ from the IETF Review range as follows:¶
Value Description Reference Controller
----- --------------------- --------------- ----------
TBD3 Flow Specification V2 [this document] IETF
¶
IANA is requested to indicate [this draft] as a reference on the following assignments in the Flow Specification Component Types Registry:¶
Value Description Reference
----- -------------------- ------------------------
1 Destination filter [RFC8955][RFC8956][this draft]
2 Source Prefix [RFC8955][RFC8956][this draft]
3 IP Protocol [RFC8955][RFC8956][this draft]
4 Port [RFC8955][RFC8956][this draft]
5 Destination Port [RFC8955][RFC8956][this draft]
6 Source Port [RFC8955][RFC8956][this draft]
7 ICMP Type [v4 or v6] [RFC8955][RFC8956][this draft]
8 ICMP Code [v4 or v6] [RFC8955][RFC8956][this draft]
9 TCP Flags [v4] [RFC8955][RFC8956][this draft]
10 Packet Length [RFC8955][RFC8956][this draft]
11 DSCP marking [RFC8955][RFC8956][this draft]
12 Fragment [RFC8955][RFC8956][This draft]
13 Flow Label [RFC8956] [This draft]
14 Partial SID {draft-ietf-idr-flowspec-srv6]
[This draft]
¶
IANA is requested to create the following two new registries on a new "Flow Specification v2 TLV types".¶
Name: BGP FSv2 TLV types
Reference: [this document]
Registration Procedures: 0x01-0x3FFF Standards Action.
Type Use Reference
----- --------------- ---------------
0x00 Reserved [this document]
0x01 IP traffic rules [this document]
0x02 FSv2 Actions [this document]
0x03 L2 traffic rules [this document]
0x04 tunnel traffic rules [this document]
0x05 SFC AFI filter rules [this document]
0x06-0x3FFF Unassigned [this document]
0x4000-0x7FFF Vendor specific [this document]
0x8000-
0xFFFFFFFF Reserved [this document]
¶
Name: BGP FSv2 Action types
Reference: [this document]
Registration Procedure: 0x01-0x3FFF Standards Action.
Type Use Reference
----- --------------- ---------------
0x00 Reserved [this document]
0x01 Action Chain Operation (ACO) [this document]
0x02 Traffic actions per
interface group [this document]
0x03 Unassigned [this document]
0x04 Unassigned [this document]
0x05 Unassigned [this document]
0x06 traffic rate limited by bytes [this document]
0x07 traffic action (terminal/sample)[this document]
0x08 redirect IPv4 [this document]
0x09 mark DSCP value [this document]
0x0a associate L2 Information [this document]
0x0b associate E-Tree Information [this document]
0xoc traffic rate limited by packets [this document]
0x0D Redirect to IPv6 [this document]
0x0E Traffic insertion to SFC [this document]
0x0F Redirect to indirection-iD [this document]
0x10 unassigned [this document]
0x11 unassigned [this document]
0x12 unassigned [this document]
0x13 unassigned [this document]
0x14 unassigned [this document]
0x15 unassigned [this document]
0x16 VLAN action [this document]
0x17 TIPD action [this document]
0x18-
0x3ff Unassigned [this document]
0x4000-
0x7fff Vendor assigned [this document]
0xc800-
0xFFFFFFFFF [this document]
¶
The use of ROA improves on [RFC8955] by checking to see of the route origination. This check can improve the validation sequence for a multiple-AS environment.¶
>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 an 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.¶