idnits 2.17.1 draft-hares-idr-flowspec-v2-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 15 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1674 has weird spacing: '... Name form...' == Line 1688 has weird spacing: '... Name for...' == Line 1719 has weird spacing: '... octets len...' == Line 1730 has weird spacing: '... Name for...' == Line 2516 has weird spacing: '... 0xoc traf...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (24 October 2021) is 916 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7091' is mentioned on line 956, but not defined == Missing Reference: '4-octet-AS' is mentioned on line 1681, but not defined == Missing Reference: 'TBD5' is mentioned on line 1297, but not defined == Missing Reference: '4-byte-AS' is mentioned on line 1725, but not defined == Missing Reference: 'IEEE.754.185' is mentioned on line 1423, but not defined == Missing Reference: '4-octet-as' is mentioned on line 1681, but not defined == Missing Reference: 'C' is mentioned on line 1522, but not defined == Missing Reference: '2-byte-AS' is mentioned on line 1720, but not defined == Missing Reference: 'AS-2-octets' is mentioned on line 1701, but not defined == Missing Reference: 'IPv4-address' is mentioned on line 1702, but not defined == Missing Reference: 'AS-4-octets' is mentioned on line 1709, but not defined == Missing Reference: 'ID-2-octets' is mentioned on line 1710, but not defined == Missing Reference: 'TBD' is mentioned on line 1866, but not defined == Missing Reference: 'RFC4456' is mentioned on line 1995, but not defined == Missing Reference: '0x8000' is mentioned on line 2163, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-17 == Outdated reference: A later version (-19) exists of draft-ietf-idr-flowspec-nvo3-14 == Outdated reference: A later version (-12) exists of draft-ietf-idr-flowspec-path-redirect-11 == Outdated reference: A later version (-05) exists of draft-ietf-idr-flowspec-srv6-00 == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-05 Summary: 0 errors (**), 0 flaws (~~), 28 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group S. Hares 3 Internet-Draft Hickory Hill Consulting 4 Intended status: Standards Track D. Eastlake 5 Expires: 27 April 2022 Futurewei Technologies 6 C. Yadlapalli 7 ATT 8 S. Maduscke 9 Verizon 10 24 October 2021 12 BGP Flow Specification Version 2 13 draft-hares-idr-flowspec-v2-03 15 Abstract 17 BGP flow specification version 1 (FSv1) defined in RFC 8955, RFC 18 8956, and RFC 9117 describes the distribution of traffic filter 19 policy (traffic filters and actions) distributed via BGP. Multiple 20 applications have used BGP FSv1 to distribute traffic filter policy. 21 These applications include the following: mitigation of denial of 22 service (DoS), enabling traffic filtering in BGP/MPLS VPNs, 23 centralized traffic control of router firewall functions, and SFC 24 traffic insertion. 26 During the deployment of BGP FSv1 a number of issues were detected 27 due to lack of consistent TLV encoding for rules for flow 28 specifications, lack of user ordering of filter rules and/or actions, 29 and lack of clear definition of interaction with BGP peers not 30 supporting FSv1. Version 2 of the BGP flow specification (FSv2) 31 protocol addresses these features. In order to provide a clear 32 demarcation between FSv1 and FSv2, a different NLRI encapsulates 33 FSv2. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 27 April 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Flow Specification v1 Review . . . . . . . . . . . . . . 5 69 1.2. Ordering for Flow Specification v2 (FSv2) . . . . . . . . 8 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 2.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 12 72 2.2. RFC 2119 language . . . . . . . . . . . . . . . . . . . . 13 73 3. Flow Specification . . . . . . . . . . . . . . . . . . . . . 13 74 4. Distribution of Flow Specification Information . . . . . . . 14 75 4.1. IP header SubTLV (type=1) . . . . . . . . . . . . . . . . 16 76 4.1.1. IP Destination Prefix (type = 1) . . . . . . . . . . 17 77 4.1.2. IP Source Prefix (type = 2) ) . . . . . . . . . . . . 18 78 4.1.3. IP Protocol (type = 3) . . . . . . . . . . . . . . . 18 79 4.1.4. Port (type = 4) . . . . . . . . . . . . . . . . . . . 19 80 4.1.5. Destination Port (type = 5) . . . . . . . . . . . . . 19 81 4.1.6. Source Port (type = 6) . . . . . . . . . . . . . . . 20 82 4.1.7. ICMP Type (type = 7) . . . . . . . . . . . . . . . . 20 83 4.1.8. ICMP Code (type = 8) . . . . . . . . . . . . . . . . 20 84 4.1.9. TCP Flags (type = 9) . . . . . . . . . . . . . . . . 21 85 4.1.10. Packet length (type = 10) . . . . . . . . . . . . . . 21 86 4.1.11. DSCP (DiffServe Code Point)(type = 11) . . . . . . . 21 87 4.1.12. Fragment (type = 12) . . . . . . . . . . . . . . . . 22 88 4.1.13. Flow Label(type = 13) . . . . . . . . . . . . . . . . 22 89 4.1.14. Parts of SID (type = 14 . . . . . . . . . . . . . . . 23 90 4.2. Encoding of Actions (type=2) . . . . . . . . . . . . . . 25 91 4.2.1. Action 1 - Action Chain operation (ACO) (0x01) . . . 28 92 4.2.2. Traffic Actions per interface set (TAIS) (0x02) . . . 29 93 4.2.3. Traffic rate limited by bytes (TRB) (0x6) . . . . . . 30 94 4.2.4. Traffic Action (TA)(0x7) . . . . . . . . . . . . . . 30 95 4.2.5. Redirect to IPv4 (RDIPv4)[0x8) . . . . . . . . . . . 31 96 4.2.6. Traffic marking (TM) (0x9) . . . . . . . . . . . . . 32 97 4.2.7. Traffic rate limited by packets (TRP) (12/0xC) . . . 32 98 4.2.8. Traffic redirect to IPv6 (RDIPv6) (13, 0xD) . . . . . 33 99 4.2.9. Traffic insertion in SFC (TISFC)(14, OXE) . . . . . . 34 100 4.2.10. Flow Specification Redirect to Indirection-ID (RDIID) 101 (0x0F) . . . . . . . . . . . . . . . . . . . . . . . 34 102 4.2.11. VLAN action (VLAN) (action 0x16, 22) . . . . . . . . 36 103 4.2.12. TPID action (TPID) (action 0x17, 23) . . . . . . . . 37 104 4.2.13. Extended Community vs. Action SubTLV formats . . . . 38 105 4.3. L2 and L2VPN FSv2 Filters . . . . . . . . . . . . . . . . 40 106 4.4. FSv2 SFC NLRI Traffic Filters . . . . . . . . . . . . . . 42 107 4.5. Encoding of Actions passed in Wide Communities . . . . . 43 108 5. Validation of FSv2 NLRI . . . . . . . . . . . . . . . . . . . 44 109 5.1. Validation of FS NLRI (FSv1 or FSv2) . . . . . . . . . . 44 110 5.2. Validation of Flow Specification Actions . . . . . . . . 46 111 5.3. Error handling and Validation . . . . . . . . . . . . . . 47 112 6. Ordering for Flow Specification v2 (FS-v2) . . . . . . . . . 47 113 6.1. Ordering of FSv2 NLRI Filters . . . . . . . . . . . . . . 48 114 6.2. Ordering of the Actions . . . . . . . . . . . . . . . . . 49 115 6.2.1. Action Chain Operation . . . . . . . . . . . . . . . 50 116 6.2.2. Summary of FSv2 ordering . . . . . . . . . . . . . . 51 117 7. Ordering of FS filters for BGP Peers support FSv1 and FSv2 . 52 118 8. Scalability and Aspirations for FSv2 . . . . . . . . . . . . 53 119 9. Optional Security Additions . . . . . . . . . . . . . . . . . 54 120 9.1. BGP FS v2 and BGPSEC . . . . . . . . . . . . . . . . . . 54 121 9.2. BGP FS v2 with with ROA . . . . . . . . . . . . . . . . . 54 122 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 123 10.1. Flow Specification V2 SAFIs . . . . . . . . . . . . . . 55 124 10.2. BGP Capability Code . . . . . . . . . . . . . . . . . . 55 125 10.3. Filter IP Component types . . . . . . . . . . . . . . . 55 126 10.4. Filter IP component types . . . . . . . . . . . . . . . 56 127 11. Security Considerations . . . . . . . . . . . . . . . . . . . 57 128 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 129 12.1. Normative References . . . . . . . . . . . . . . . . . . 58 130 12.2. Informative References . . . . . . . . . . . . . . . . . 60 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 133 1. Introduction 135 Modern IP routers have the capability to forward traffic and to 136 classify, shape, rate limit, filter, or redirect packets based on 137 administratively defined policies. These traffic policy mechanisms 138 allow the operator to define match rules that operate on multiple 139 fields within header of an IP data packet. Upon a match, the traffic 140 policy allows actions to be associated with each match rule. These 141 rules can be more widely defined as "event-condition-action" (ECA) 142 rules where the event is always the reception of a packet. 144 BGP ([RFC4271]) flow specification as defined by [RFC8955], 145 [RFC8956], [RFC9117] specifies the distribution of traffic filter 146 policy (traffic filters and actions) via BGP to a mesh of BGP peers 147 (IBGP and EBGP peers). The traffic filter policy is applied when 148 packets are received on a router with the flow specification function 149 turned on. The flow specification protocol defined in [RFC8955], 150 [RFC8956], and [RFC9117] will be called BGP flow specification 151 version 1 (BGP FSv1) in this draft. 153 Some modern IP routers also include the abilities of firewalls which 154 can match on a sequence of packet events based on administrative 155 policy. These firewall capabilities allow for user ordering of match 156 rules and user ordering of actions per match. 158 Multiple deployed applications currently use BGP FSv1 to distribute 159 traffic filter policy. These applications include: 1) mitigation of 160 Denial of Service (DoS), 2) traffic filtering in BGP/MPLS VPNS, and 161 3) centralized traffic control for networks utilizing SDN control of 162 router firewall functions, 4) classifiers for insertion in an SFC, 163 and 5) filters for SRv6 routing. 165 During the deployment of BGP flow specification v1, the following 166 issues were detected: 168 * lack of consistent TLV encoding prevented extension of encodings, 170 * inability to allow user defined order for filtering rules, 172 * inability to order actions to provide deterministic interactions 173 or to allow users to define order for actions, and 175 * no clearly defined mechanisms for BGP peers which do not support 176 flow specification v1. 178 Networks currently cope with some of these issues by limiting the 179 type of traffic filter policy sent in BGP. Current Networks do not 180 have a good workaround/solution for applications that receive but do 181 not understand FSv1 policies. 183 This document defines version 2 of the BGP flow specification 184 protocol to address these shortcomings in BGP FSv1. Version 2 of BGP 185 flow specification will be denoted as BGP FSv2. 187 BGP FSv1 as defined in [RFC8955], [RFC8956], and [RFC9117] specified 188 2 SAFIs (133, 134) to be used with IPv4 AFI (AFI = 1) and IPv6 AFI 189 (AFI=2). 191 This document specifies 2 new SAFIs (TBD1, TBD2) for FSv2 to be used 192 with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of 193 traffic match filters for user-ordered traffic match actions encoded 194 in Communities (Wide or Extended) or a SubTLV of the FSv2 NRLI. 196 FSv1 and FSv2 use different AFI/SAFIs to send flow specification 197 filters. Since BGP AFI/SAFIs perform route selection per AFI/SAFI, 198 this approach can be termed "ships in the night" based on AFI/SAFI. 200 FSv1 is a critical component of deployed applications. Therefore, 201 this specification defines how FSv2 will interact with BGP peers that 202 support either FSv2 or FSv1 or BGP peers that do not support either 203 FSv1 or FSv2. It is expected that a transition to FSv2 will occur 204 over time as new applications require FSv2 extensibility and user- 205 defined ordering for rules and actions or network operators tire of 206 the restrictions of FSv1 such as error handling issues and restricted 207 topologies. 209 This section contains a short review of FSv1 and an overview of FSv2. 211 Section 3 contains the definition of flow specification v2. 212 Section 4 contains the encoding rules for FSv2 and user-based 213 encoding sent via BGP, and section 5 describes how to validate FSv2 214 NLRI. Section 6 discusses how to combine FSv2 user-ordered match 215 rules and FSv1 rules. Section 6 also discusses how to combine user- 216 ordered actions, FSv1 actions, and default actions. Sections 7-10 217 address an alternate security mechanism, considerations for IANA, 218 security in deployments, and manageability. 220 1.1. Flow Specification v1 Review 222 The FSv1 NLRI defined in [RFC8955] and [RFC8956] for this policy 223 include 13 match conditions encoded for the following AFI/SAFIs 225 * IPv4 traffic: AFI:1, SAFI:133 227 * IPv6 Traffic: AFI:2 SAFI:133 229 * BGP/MPLS IPv4 VPN: AFI:1, SAFI: 134 231 * BGP/MPLS IPv6 VPN: AFI:2, SAFI: 134 233 If one considers the reception of the packet as an event, then BGP 234 flow specification describes a set of Event-MatchCondition-Action 235 (ECA) policies where: 237 * event is the reception of a packet 238 * condition stands for "match conditions" defined in the BGP NLRI as 239 an n-tuple of component filters, and 241 * the action is defined taken is either: the default condition 242 (accept traffic), or a set of actions (1 or more) defined in 243 Extended BGP Community values [RFC4360]. 245 The flow specification conditions and actions combine to make up FSv1 246 specification rules. Each FSv1 NLRI must have a type 1 component 247 (destination prefix) and Extended Communities with FSv1 actions can 248 be attached to a single NLRI or multiple NLRIs in a BGP packet. 250 Within an AFI/SAFI pair, FSv1 rules are ordered based on the 251 components in the packet (types 1-13) ordered from left-most to 252 right-most and within the component types by value of the component. 253 Rules are inserted in the rule list by component-based order where a 254 FSv1 rule with existing component type has higher precedence than one 255 missing a specific component type, 257 Since FSv1 specifications ([RFC8955], [RFC8956], and [RFC9117]) 258 specify that the FSv1 NLRI MUST have a destination prefix (as 259 component type 1) embedded in the flow specification, the FSv1 rules 260 with destination components are ordered by IP Prefix comparison rules 261 for IPv4 ([RFC8955]) and IPv6 ([RFC8956]). [RFC8955] specifies that 262 more specific prefixes (aka longest match) have higher precedence 263 than that of less specific prefixes AND for prefixes of the same 264 length the lower IP number is selected (lowest IP value). [RFC8955] 265 specifies that if the offsets within component 1 are the same, then 266 the longest match and lowest IP comparison rules from [RFC8955] 267 apply. If the offsets are different, then the lower offset has 268 precedence. 270 These rules work to provide a set of FSv1 rules ordered by IP 271 Destination Prefix by longest match and lowest IP address. [RFC8955] 272 also states that the requirement for a destination prefix component 273 "MAY be relaxed by explicit configuration" Since the rule insertions 274 are based on comparing component types between two rules in order, 275 this means the rules without destination prefixes are inserted after 276 all rules which contain destination prefix component. 278 The actions specified by FSv1 are: 280 * accept packet (default) 282 * traffic flow limitation by bytes (6) 284 * traffic-action (7) 285 * redirect traffic (8) 287 * mark traffic (9) 289 * traffic flow limiation by packrts (12) 291 Figure 1 shows a diagram of the FSv1 logical data structures with 5 292 rules. If FSv1 rules have destination prefix components (type=1) and 293 FSv1 rule 5 does not have a destination prefix, then FSv1 rule 5 will 294 be inserted in the policy after rules 1-4. 296 +--------------------------------------+ 297 | Flow Specification (FS) | 298 | Policy | 299 +--------------------------------------+ 300 ^ ^ ^ 301 | | | 302 | | | 303 +--------^----+ +-------^-------+ +-------------+ 304 | FS Rule 1 | | FS Rule 2 | ... | FS rule 5 | 305 +-------------+ +---------------+ +-------------+ 306 : : 307 : : 308 ...: :........ 309 : : 310 +---------V---------+ +----V-------------+ 311 | Rule Condition | | Rule Action | 312 | in BGP NLRIs | | in BGP extended | 313 | AFIs: 1 and 2 | | Communities | 314 | SAFI 133, 134 | | | 315 +-------------------+ +------------------+ 316 : : : : : : 317 .....: . :..... .....: . :..... 318 : : : : : : 319 +----V---+ +---V----+ +--V---+ +-V------+ +--V-----++--V---+ 320 | Match | | match | |match | | Action | | action ||action| 321 |Operator| |Variable| |Value | |Operator| |variable|| Value| 322 |*1 | | | | | |(subtype| | || | 323 +--------+ +--------+ +------+ +--------+ +--------++------+ 325 *1 match operator may be complex. 327 Figure 1: BGP Flow Specification v1 Policy 329 1.2. Ordering for Flow Specification v2 (FSv2) 331 Flow Specification v2 allows the user to order the flow specification 332 rules and the actions associated with a rule. Each FSv2 rule may 333 have one or more match conditions and one or more associated actions. 335 This FSv2 specification supports the components and actions for the 336 following 338 * IPv4 (AFI=1, SAFI: TBD1), 340 * IPv6 (AFI=2, SAFI: TBD2), 342 * L2 (AFI=6, SAFI: TDB1), 344 * BGP/MPLS IPv4 VPN: (AFI=1, SAFI: TBD2), 346 * BGP/MPLS IPv6 VPN: (AFI=2, SAFI: TBD2), 348 * BGP/MPLS L2VPN (AFI=25, SAFI: TDB2), 350 * SFC: (AFI=31, SAFI: TBD1), and 352 * SFC VPN (AFI=31, SAFI: TBD2). 354 The FSv2 specification for tunnel traffic is outside the scope of 355 this specification. The FSv1 specification for tunneled traffic is 356 in [I-D.ietf-idr-flowspec-nvo3]. 358 FSv2 operates in the ships-in-the night model with FSv1 so network 359 operators can manipulate FSv2 and FSv1 using configuration 360 parameters. Since deterministic ordering was a short coming in FSv1, 361 this specification provides rules and protocol features to keep 362 filters in a deterministic order. 364 The basic principles regarding ordering of rules are simple: 366 1) Rule-0 (zero) is defined to be 0/0 with the "permit-all" 367 action. 369 2) FSv2 rules are ordered based on user-specified order. 371 - The user-specified order is carried FSv2 NLRI with the sentence 372 that the numerical lower value takes precedence over the 373 numerically higher value. For rules received with the same 374 order value, the FSv1 rules apply (order by component type and 375 then by value of the components). 377 3) FSv2 rules are added starting with Rule 1 and FSv1 rules are 378 added after FSv2 rules. 380 - For this example, BGP Peer A has FSv2 data base with 10 FSv2 381 rules (1-10) and 10 FSv1 rules (301-310). 383 4) An FSv2 peer may receive BGP NLRI routes from a FSv1 peer or a 384 BGP peer that does not support FSv1 or FSv2. The capabilities 385 sent by a BGP peer indicate whether the AFI/SAFI can be received 386 (FSv1 NLRI or FSv2 NLRI). 388 - Suppose an FSv2 peer (BGP Peer A) has the capability to send 389 either FSv1 or FSv2. BGP Peer A peers with BGP Peers B, C, D 390 and E. 392 - BGP Peer B can only send FSv1 routes (NLRI + Extended 393 Community). BGP Peer C can send FSv2 routes (NLRI + path 394 attributes (wide community or extended community or none)). 395 BGP Peer D cannot send any FS routes. BGP E can send FSv2 and 396 FSv1 routes 398 - BGP Peer A sends FSv1 routes in its databases to BGP B. Since 399 the FSv2 NLRI cannot be sent to the FSv1 peer, only the FSv1 400 NLRI is sent. BGP Peer A sends to BGP C the FSv2 routes in its 401 database (configured or received). 403 - BGP peer A would not send the FSv1 NLRI or FSv2 NLRI to BGP 404 Peer D. The BGP Peer D does not support for these NLRI. 406 - BGP Peer A sends the NLRI for both FSv1 and FSv2 to BGP Peer E. 408 5) Associate a chain of actions to rules based on user-defined 409 action number 411 - FSv2 allows actions to be associated by the following: a) 412 actions in an Extended Community, b) actions in a wide 413 community, or c) actions within the FSv2 NRLI associated as a 414 SubTLV. 416 - Action user-order value zero is reserved. 418 - An action associated with FSv2 NLRI using in a SubTLV always 419 has a user-defined order. 421 - The precedence between two actions with user-defined order 422 (Wide community) is discussed in detail in section 6.2. 424 Examples of action chain 425 An action associated with FSv2 NLRI using in a SubTLV always has a 426 user-defined order. If two actions have the same user-defined order 427 and the same action type, the ordering of the actions within the same 428 type is defined by the action type (see section 4.2). 430 The use case for the Action which always associated with an NRLI is 431 the DDOS match case that always drops the packet in order to kill off 432 a widespread DDoS attack. The idea is easy, but the deployment 433 issues may be more complex. An example may help illustrate this 434 point. 436 Suppose BGP Peer A has a configured value for FSv2ExtComActionStart 437 of 10. Suppose BGP Peer A receives the following attributes 438 associated with the same FSv2 NLRI to form an action chain: 440 * a Wide Community action with user-defined order 10 from AS 2020 441 that limits packet-based rate limit of 600 packets per second 443 * an action SubTLV with a user order of 11 from AS 10 that limits 444 the packet base rate to zero packets per second, 446 * a Wide Community with a user order of 11 from AS 2021 that limits 447 the packet-based rate limit of 50. 449 The FSv2 data base would store the following action chain: 451 * at user-defined action order 10: 453 - a user action type of 12 (packet-based rate limit) with values 454 of AS 2020 and float value of 1000. 456 * at user-defined action order 11 in order: 458 - 1.A user action of type 12 with values of AS 10 and float value 459 of zero, 461 - 2. A user action of type 12 with value of AS 2021 and float 462 value of 50. 464 When does the action chain stop? 466 The default process for the action chain is to stop on failure. 468 If setting the packet-based rate limit of 1000 works, the action 469 chain would go on to set the value of zero. If this works, it would 470 go on to set the value to 50. This set of actions may not be what 471 the user wanted if this is a DDoS attack. 473 BGP FSv2 rules are ephemeral by default (just as BGP routes are 474 ephemeral) upon a restart of a BGP session or a router. 476 After FSv2 NLRI are checked for errors in syntax, those with valid 477 syntax are checked for the same validation procedure FSv1 NLRI uses 478 [RFC8955] and [RFC9117]. See section 5 for for a detailed discussion 479 of validation and error handling. 481 Names may be associated with rules or actions in order for network 482 management protocols (NETCONF/RESTCONF) to be able to provide 483 detailed reports in the BGP Yang models. 485 Figure 2 provides a logical diagram of the FSv2 structure 486 +--------------------------------+ 487 | Rule Group | 488 +------------------------------ -+ 489 ^ ^ ^ 490 | ---------- | 491 | | ------ 492 | | | 493 +--------^-------+ +-------^-----+ +---^-----+ 494 | Rule1 | | Rule2 | ... | Rule-n | 495 +----------------+ +-------------+ +---------+ 496 : : : : 497 :.................: : : : 498 : |.........: : : 499 +--V--+ +--V--+ : : 500 | name| |order| .........: :..... 501 +-----+ +-----+ : : 502 : : 503 +----------------V----+ +-----V----------------+ 504 |Rule Match condition | | Rule Action | 505 +---------------------+ +----------------------+ 506 : : : : : : : : | 507 +--V--+ : : : +--V---+ : : : V 508 | Rule| : : : |action| : : : +-----------+ 509 | name| : : : |order | : : : |action name| 510 +-----+ : : : +------+ : : : +-----------+ 511 : : : : : :........... 512 : : : : : : 513 .....: . :..... ..: :..... : 514 : : : : : : 515 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 516 | Match | | match | |match | | Action || action ||action| 517 |Operator| |variable| |Value | |Operator||Variable|| Value| 518 +--------+ +--------+ +------+ +--------++--------++------+ 520 Figure 2: Order Flow Specification Data storage 522 2. Terminology 524 2.1. Definitions and Acronyms 526 AFI - Address Family Identifier 528 BGPSEC - secure BGP [RFC8205] updated by [RFC8206] 530 BGP Session ephemeral state - state which does not survive the 531 loss of BGP peer, 532 Ephemeral state - state which does not survive the reboot of a 533 software module, or a hardware reboot. Ephemeral state can be 534 ephemeral configuration state or operational state. 536 configuration state - state which persist across a reboot of 537 software module within a routing system or a reboot of a hardware 538 routing device. 540 NETCONF: The Network Configuration Protocol [RFC6241]. 542 RESTCONF: The RESTCONF configuration Protocol [RFC8040] 544 ROA: Route Origin Authentication [RFC6482] 546 SAFI - Subsequent Address Family Identifier 548 2.2. RFC 2119 language 550 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 551 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 552 document are to be interpreted as described in BCP 14 [RFC2119] 553 [RFC8174] when, and only when, they appear in all capitals as shown 554 here. 556 3. Flow Specification 558 A BGP Flow Specification is an n-tuple containing several match 559 criteria that can be applied to IP traffic, traffic encapsulated in 560 IP traffic or traffic associated with IP traffic. The following 561 traffic filters are examples of traffic associated with IP traffic: 562 IP packet or an IP packet inside a L2 packet (Ethernet), an MPLS 563 packet, and SFC flow. 565 A given Flow Specification NLRI may be associated with a set of path 566 attributes depending on the particular application, and attributes 567 within that set may or may not include reachability information 568 (e.g., NEXT_HOP). Extended Community or Wide Community attributes 569 (well-known or AS-specific) MAY be used to encode a set of pre- 570 determined actions. 572 A particular application is identified by a specific AFI/SAFI 573 (Address Family Identifier/Subsequent Address Family Identifier) and 574 responds to a distinct set of RIBs. Those RIBs should be treated 575 independently of each other in order to assure noninterference 576 between distinct applications. 578 BGP processing treats the NLRI as a key to entries in AFI/SAFI BGP 579 databases. Entries that are placed in the Loc-RIB are then 580 associated with a given set of semantics which are application 581 dependent. Standard BGP mechanisms such as update filtering by NLRI 582 or by attributes such as AS_PATH or large communities apply to the 583 BGP Flow Specification defined NLRI-types. 585 Network operators can control the propagation of BGP routes by 586 enabling or disabling the exchange of routes for a particular AFI/ 587 SAFI pair on a particular peering session. As such, the Flow 588 Specification may be distributed to only a portion of the BGP 589 infrastructure. 591 4. Distribution of Flow Specification Information 593 The BGP Flow Specification version 2 (BGP-FS v2) uses an NRLI with 594 the format for AFIs for IPv4 (AFI = 1), IPv6 (AFI = 2), L2 (AFI = 6), 595 L2VPN (AFI=25), and SFC (AFI=31) with two following SAFIs to support 596 transmission of the flow specification which supports user ordering 597 of traffic filters and actions for iP traffic and IP VPN traffic. 599 This NLRI information is encoded using MP_REACH_NLRI and 600 MP_UNREACH_NLRI attributes defined in [RFC4760]. When advertising 601 FSv2 NLRI, the length of the Next-Hop Network Address MUST be set to 602 0. Upon reception, the Network Address of the Next-Hop field MUST be 603 ignored. 605 Implementations wishing to exchange flow specification rules MUST use 606 BGP's Capability Advertisement facility to exchange the Multiprotocol 607 Extension Capability Code (Code 1) as defined in [RFC4760], and 608 indicate a capability for flow specification v2 (Code TBD4). 610 The AFI/SAFI NLRI for BGP Flow Specification version 2 (FSv2) has the 611 format: 613 +-------------------------------+ 614 |length (2 octets) | 615 +-------------------------------+ 616 | Sub-TLVs (variable) | 617 | +===========================+ | 618 | | order (4 octets) | | 619 | +---------------------------+ | 620 | | identifier (4 octets) | | 621 | +---------------------------+ | 622 | | type (2 octets) | | 623 | +---------------------------+ | 624 | | length-Subtlv (2 octets) | | 625 | +---------------------------+ | 626 | | value (variable) | | 627 | +===========================+ | 628 +-------------------------------+ 630 Figure 3 -Flow Specification v2 format 632 where: 634 * length: length of field including all SubTLVs in octets. 636 - The combined lengths of any FSv2 NLRI in the MP_REACH_NLRI or 637 MP_UNREACH_NLRI plus the BGP path attributes, the BGP NLRI 638 length and the BGP header must be less than the packet size. 640 * order: flow-specification global rule order number (4 octets). 642 * identifier: identifier for the rule (used for NM/Logging) (4 643 octets) 645 * type: contains a type for the TLV format of the NRLI (2 octets) 646 which can be: 648 - 0 - reserved, 650 - 1 - FSv2 IP header traffic rules 652 - 2 - FSv2 Actions 654 - 3- FSv2 L2 traffic rules 656 - 4- FSv2 SFC Traffic rules 658 * length-tlv: is the length of the value part of the Sub-TLV, 659 * value: value depends on the subTLV (see sections below). 661 4.1. IP header SubTLV (type=1) 663 The format of the IP header TLV value field is shown in figure 4. 664 The AFI/SAFI field includes the AFI (2 octets), SAFI (1 octet). The 665 AFI will be 1 (IPv4) or 2 (IPv6) and the SAFI will be TBD1 or, for 666 the VPN case, TBD2. 668 +-------------------------------+ 669 | +--------------------------+ | 670 | | AFI/SAFI field (3) | | 671 | | (subTLVs)+ | | 672 | +==========================+ | 673 +-------------------------------+ 675 Figure 4 - IP Header TLV 677 Each SubTLV has the format: 679 +-------------------------------+ 680 | SubTLV type (1 octet) | 681 +-------------------------------+ 682 | length (1 octet) | 683 + ------------------------------+ 684 | value (variable) | 685 +-------------------------------+ 686 Figure 5 – IP header SubTLV format 688 Where: 690 SubTLV type: component values are defined in the "Flow 691 Specification Component types" registry for IPv4 and IPv6 by 692 [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6] 694 length: length of SubTLV (varies depending on SubTLV type). 696 value: dependent on the subTLV 698 - For descriptions of value portions for components 1-13 see 699 [RFC8955] and [RFC8956]. For components 14 see 700 [I-D.ietf-idr-flowspec-srv6]. 702 Many of the components use the operators [numeric_op] and 703 [bitmask_op] defined in [RFC8955] 705 Table 2 706 The list of valid subtypes are: 708 1 - IP Destination prefix 710 2 - IP Source prefix 712 3 - IPv4 Protocol / IPv6 Upper Layer Protocol 714 4 - Port 716 5 - Destination Port 718 6 - Source Port 720 7 - ICMPv4 type / ICMPv6 type 722 8 - ICMPv4 code / ICPv6 code 724 9 - TCP Flags 726 10 - Packet length 728 11 - DSCP (Diffserv Code Point) 730 12 - Fragment 732 13 - Flow Label 734 14 - Parts of SID 736 Ordering within the TLV in FSv2: The transmission of SubTLVs within a 737 flow specification rule must be sent ascending order by SubTLV type. 738 If the SubTLV types are the same, then the value fields are compared 739 using mechanisms defined in [RFC8955] and [RFC8956]. NLRIs having 740 TLVs which do not follow the above ordering rules MUST be considered 741 as malformed by a BGP FSv2 propagator. This rule prevents any 742 ambiguities that arises from the multiple copies of the same NLRI 743 from multiple BGP FSv2 propagators. A BGP implementation SHOULD 744 treat such malformed NLRIs as "Treat-as-withdraw" [RFC7606]. 746 See [RFC8955] and [RFC8956], and [I-D.ietf-idr-flowspec-srv6]. for 747 specific details. 749 4.1.1. IP Destination Prefix (type = 1) 751 IPv4 Name: IP Destination Prefix (reference: [RFC8955]) 753 IPv6 Name: IPv6 Destination prefix (reference: [RFC8956]) 754 IPv4 length: Prefix length 756 IPv4 value: IPv4 Prefix (variable length) 758 IPv6 length: length of value 760 IPv6 value: [offset (1 octet)] [pattern (variable)] 761 [padding(variable)] 763 If IPv6 length = 0 and offset = 0, then component matches every 764 address. Otherwise, length must be offset "less than" length "less 765 than" 129 or component is malformed. 767 4.1.2. IP Source Prefix (type = 2) ) 769 IPv4 Name: IP Source Prefix (reference: [RFC8955]) 771 IPv6 Name: IPv6 Source prefix (reference: [RFC8956]) 773 IPv4 length: Prefix length 775 IPv4 value: Source IPv4 Prefix (variable length) 777 IPv6 length: length of value 779 IPv6 value: [offset (1 octet)] [pattern 780 (variable)][padding(variable)] 782 If IPv6 length = 0 and offset = 0, then component matches every 783 address. Otherwise, length must be offset < length < 129 or 784 component is malformed. 786 4.1.3. IP Protocol (type = 3) 788 IPv4 Name: IP Protocol IP Source Prefix (reference: [RFC8955]) 790 IPv6 Name: IPv6 Upper-Layer Protocol: (reference: [RFC8956]) 792 IPv4 length: variable 794 IPv4 value: [numeric_op, value]+ 796 IPv6 length: variable 797 IPv6 value: [numeric_op, value}+ 799 where the value following each numeric_op is a single octet. 801 4.1.4. Port (type = 4) 803 IPv4/IPv6 Name: Port (reference: [RFC8955]), [RFC8956]) 805 Filter defines: a set of port values to match either destination port 806 or source port. 808 IPv4 length: variable 810 IPv4 value: [numeric_op, value]+ 812 IPv6 length: variable 814 IPv6 value: [numeric_op, value]+ 816 where the value following each numeric_op is a single octet. 818 Note-1: In the presence of the port component (destination or source 819 port), only a TCP (port 6) or UDP (port 17) packet can match the 820 entire flow specification. If the packet is fragmented and this is 821 not the first fragment, then the system may not be able to find the 822 header. At this point, the FSv2 filter may fail to detect the 823 correct flow. Similarly, if other IP options or the encapsulating 824 security payload (ESP) is present, then the node may not be able to 825 describe the transport header and the FSv2 filter may fail to detect 826 the flow. 828 This problem comes from the inheritance of the FSv1 filter component 829 for port. If better resolution is desired, a new FSv2 filter should 830 be defined. 832 Note-2: Although IPv6 allows for more than one Next Header field in 833 the packet, the main goal of the Type 3 FSv2 component is to match 834 the first upper layer protocol value. 836 4.1.5. Destination Port (type = 5) 838 IPv4/IPv6 Name: Destination Port (reference: [RFC8955]), [RFC8956]) 840 Filter defines: a list of match filters for destination port for TCP 841 or UDP within a received packet 842 Length: variable 844 Component Value format: [numeric_op, value]+ 846 4.1.6. Source Port (type = 6) 848 IPv4/IPv6 Name: Source Port (reference: [RFC8955]), [RFC8956]) 850 Filter defines: a list of match filters for source port for TCP or 851 UDP within a received packet 853 IPv4/IPv6 length: variable 855 IPv4/Ipv6 value: [numeric_op, value]+ 857 4.1.7. ICMP Type (type = 7) 859 IPv4: ICMP Type : Source Port (reference: [RFC8955]) 861 Filter defines: Defines: a list of match criteria for ICMPv4 type 863 IPv6: ICMPv6 Type (reference: [RFC8956]) 865 Filter defines: a list of match criteria for ICMPv6 type. 867 IPv4/IPv6 length: variable 869 IPv4/IPv6 value: [numeric_op, value]+ 871 4.1.8. ICMP Code (type = 8) 873 IPv4: ICMP Type : Source Port (reference: [RFC8955]) 875 Filter defines: a list of match criteria for ICMPv4 code. 877 IPv6: ICMPv6 Type (reference: [RFC8956]) 879 Filter defines: a list of match criteria for ICMPv6 code. 881 IPv4/IPv6 length: variable 883 IPv4/IPv6 value: [numeric_op, value]+ 885 4.1.9. TCP Flags (type = 9) 887 IPv4/IPv6: TCP Flags Code (reference: [RFC8955]) 889 Filter defines: a list of match criteria for TCP Control bits 891 IPv4/IPv6 length: variable 893 IPv4/IPv6 value: [bitmask_op, value]+ 895 Note: a 2 octets bitmask match is always used for TCP-Flags 897 4.1.10. Packet length (type = 10) 899 IPv4/IPv6: Packet Length (reference: [RFC8955], [RFC8956]) 901 Filter defines: a list of match criteria for length of packet 902 (excluding L2 header but including IP header). 904 IPv4/IPv6 length: variable 906 IPv4/IPv6 value: [numeric_op, value]+ 908 Note:[RFC8955] uses either 1 or 2 octet values. 910 4.1.11. DSCP (DiffServe Code Point)(type = 11) 912 IPv4/IPv6: DSCP Code (reference: [RFC8955], [RFC8956]) 914 Filter defines: a list of match criteria for DSCP code values to 915 match the 6-bit DSCP field. 917 IPv4/IPv6 length: variable 919 IPv4/IPv6 value: [numeric_op, value]+ 921 Note: This component uses the Numeric Operator (numeric_op) described 922 in [RFC8955] in section 4.2.1.1. Type 11 component values MUST be 923 encoded as single octet (numeric_op len=00). 925 The six least significant bits contain the DSCP value. All other 926 bits SHOULD be treated as 0. 928 4.1.12. Fragment (type = 12) 930 IPv4/IPv6: Fragment (reference: [RFC8955], [RFC8956]) 932 Filter defines: a list of match criteria for specific IP fragments. 934 Length: variable 936 Component Value format: [bitmask_op, value]+ 938 Bitmask values are: 940 0 1 2 3 4 5 6 7 941 +---+---+---+---+---+---+---+---+ 942 | 0 | 0 | 0 | 0 |lf |FF |IsF| DF| 943 +---+---+---+---+---+---+---+---+ 944 Figure 6 946 Where: 948 DF (don't fragment): match If IP header flags bit 1 (DF) is 1. 950 IsF(is a fragment other than first: match if IP header fragment 951 offset is not 0. 953 FF (First Fragment): Match if [RFC0791] IP Header Fragment offset 954 is zero and Flags Bit-2 (MF) is 1. 956 LF (last Fragment): Match if [RFC7091] IP header Fragment is not 0 957 And Flags bit-2 (MF) is 0 959 0: must be sent in NLRI encoding as 0, and must be ignored during 960 reception. 962 4.1.13. Flow Label(type = 13) 964 IPv4/IPv6: Fragment (reference: [RFC8956]) 966 Filter defines: a list of match criteria for 20-bit Flow Label in the 967 IPv6 header field. 969 Length: variable 971 Component Value format: [numeric_op, value]+ 973 4.1.14. Parts of SID (type = 14 975 IPv6: Service Identifier Matches (reference: 976 [I-D.ietf-idr-flowspec-srv6] 978 Filter defines: a list of match bit match criteria for some 979 combinations of the LOC, FUNCT and ARG in SID fields in the SID or or 980 whole SID. 982 Length: variable 984 Component Value format: [type, LOC-Len, FUNCT-Len, ARG-Len, [op, 985 value]+] 987 where: 989 * type (1 octet): This indicates the new component type (TBD1, which 990 is to be assigned by IANA). 992 * LOC-Len (1 octet): This indicates the length in bits of LOC in 993 SID. 995 * iFUNCT-Len (1 octet): This indicates the length in bits of FUNCT 996 in SID. 998 * ARG-Len (1 octet): This indicates the length in bits of ARG in 999 SID. 1001 * [op, value]+: This contains a list of {operator, value} pairs that 1002 are used to match some parts of SID. 1004 The total of three lengths (i.e., LOC length + FUNCT length + ARG 1005 length) MUST NOT be greater than 128. If it is greater than 128, an 1006 error occurs and it is treated as a withdrawl [RFC7606] and 1007 [RFC4760]. 1009 The operator (op) byte is encoded as: 1011 0 1 2 3 4 5 6 7 1012 +---+---+---+---+---+---+---+---+ 1013 | e | a | field type|lt |gt |eq | 1014 +---+---+---+---+---+---+---+---+ 1015 Figure 7 1017 where: 1019 where the behavior of each operator bit has clear similarity with 1020 that of [RFC8955]'s Numeric Operator field. 1022 e (end-of-list bit): Set in the last {op, value} pair in the 1023 sequence. 1025 a - AND bit: If unset, the previous term is logically ORed with 1026 the current one. If set, the operation is a logical AND. It 1027 should be unset in the first operator byte of a sequence. The AND 1028 operator has higher priority than OR for the purposes of 1029 evaluating logical expressions. 1031 field type: 1033 - 000: SID's LOC 1035 - 001: SID's FUNCT 1037 - 010: SID's ARG 1039 - 011: SID's LOC:FUNCT 1041 - 100: SID's FUNCT:ARG 1043 - 101: SID's LOC:FUNCT:ARG 1045 Note: For an unknown field type, Error Handling is to "treat as 1046 withdrawl" [RFC7606] and [RFC4760]. 1048 lt: less than comparison between data' and value'. 1050 gt: greater than comparison between data' and value'. 1052 eq: equality between data' and value'. 1054 The data' and value' used in lt, gt and eq are indicated by the field 1055 type in an operator and the value field following the operator. 1057 The value field depends on the field type and has the value of SID's 1058 some parts rounding up to bytes (refer to the table 3 in figure 8 1059 below ). 1061 Table 3 - SID Parts fields 1063 +-----------------------+------------------------------+ 1064 | Field Type | Value | 1065 +=======================+==============================+ 1066 | SID's LOC | value of LOC bits | 1067 +-----------------------+------------------------------+ 1068 | SID's FUNCT | value of FUNCT bits | 1069 +-----------------------+------------------------------+ 1070 | SID's ARG | value of ARG bits | 1071 +-----------------------+------------------------------+ 1072 | SID's LOC:FUNCT | value of LOC:FUNCT bits | 1073 +-----------------------+------------------------------+ 1074 | SID's FUNCT:ARG | value of FUNCT:ARG bits | 1075 +-----------------------+------------------------------+ 1076 | SID's LOC:FUNCT:ARG | value of LOC:FUNCT:ARG bits | 1077 +-----------------------+------------------------------+ 1078 Figure 8 1080 4.2. Encoding of Actions (type=2) 1082 The FSv2 actions may be sent in an Extended Community, a Wide 1083 Community or an NLRI. 1085 The Extended Community encodes the Flow Specification actions in the 1086 Extended Community format [RFC4360]. 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Type high | Type low(*) | | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (6 octets) | 1093 | | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 Figure 9 1098 The Wide Community definition for FSv2 actions is as follows: 1100 0 1 2 3 1101 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 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Type = 2 | Flags |C|T| Reserved | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Length |+ | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------- 1108 Figure 10 1110 where FSv2-Action-TLV is defined as: 1112 FSv2-Action-TLV 1113 0 1 2 3 1114 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 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | action order | Identifier | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 |+ | 1119 +-------------------------------- 1121 Figure 11 1123 Where FS-SubTLVs have the format: 1125 FS-SubTLVs 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | SubTLV type (2 octet) | length type (2 octet) | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | value (variable) | 1133 +-------------------------------+ 1135 Figure 12 1137 The FSv2 Action TLV may be included in the NLRI to be associated with 1138 a specific NLRI. (Note inclusion with the FSv2 NLRI does not have 1139 good scaling properties.) 1141 0 1 2 3 1142 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 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Type = 2 | length | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | action-order | chain-ID | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | length-TLV | value + | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 Figure 13 1153 where: 1155 action-order: is the user defined action within the list 1157 chain ID: is a 2-byte identifier for action chain 1159 length -TLV - is the length of the TLV 1161 value - contains a sequence of action SubTLVs. 1163 Each Action SubTLV has the format: 1165 +-------------------------------+ 1166 | SubTLV type (2 octet) | 1167 +-------------------------------+ 1168 | length (2 octet) | 1169 +-------------------------------+ 1170 | value (variable) | 1171 +-------------------------------+ 1173 Figure 14 1175 Where: 1177 * SubTLV type: values are action type values shown in Table 4 below. 1179 * length: is the length of the action subtlv 1181 * Value is specific to the SubTLV 1182 Table 4 – FSv2 Action types 1184 Action Description 1185 ====== =========== 1186 00 reserved 1187 01 Action Chain Operation 1188 02 traffic actions per interface group 1189 06 traffic rate limited by bytes 1190 07 traffic action (terminal/sample) 1191 08 redirect IPv4 1192 09 mark DSCP value 1193 10 associate L2 Information 1194 11 associate E-Tree Information 1195 12 traffic rate limited by packets 1196 13 redirect to IPv6 1197 14 SFC Classifier Info (moved from OD to OE) 1198 15 redirect to Indirection-id (move from 0x00) 1199 15-21 TBA (to be assigned) 1200 22 VLAN-Action (0x16)[draft-ietf-idr-flowspec-l2vpn-17] 1201 23 TPID-Action (0x17) [draft-ietf-idr-flowspec-l2vpn-17] 1202 24-254 TBA (to be assigned) 1203 255 reserved 1205 Figure 15 1207 Ordering of actions within a rule 1209 The actions are first stored in user-defined order. If multiple 1210 actions exist for a single action order value, then the actions will 1211 be ordered by action type followed by value. 1213 Action specifications must include descriptions of order comparison 1214 for the values within the action. 1216 4.2.1. Action 1 - Action Chain operation (ACO) (0x01) 1218 SubTLV: 0x01 1220 Length: variable 1222 Value: 1224 AC-failure-type - byte that determines the action on failure 1226 AC-failure-value - variable depending on AC-failure-type. 1228 Actions may succeed or fail and an Action chain must deal with it. 1229 The default value stored for an action chain that does not have this 1230 action chain is "stop on failure". 1232 where: 1234 AC-Failure types are: 1236 - 0x00 - default - stop on failure 1238 - 0x01 - continue on failure (best effort on actions) 1240 - 0x02 - conditional stop on failure - depending on AC-Failure- 1241 value 1243 - 0x03 - rollback - do all or nothing - depending in AC-Failure- 1244 value 1246 AC-Failure values: TBD 1248 Interactions with other actions: Interactions with all other Actions 1250 Ordering within Action type:By AC-Failure type 1252 4.2.2. Traffic Actions per interface set (TAIS) (0x02) 1254 SubTLV: 0x2 1256 Length: 8 octets (6 in extended community) 1258 Value field: [4-octet-AS] [GroupID 2-octet] [action 2-octet] 1260 where: 1262 Group-ID: identifier for group in 2 octets (14 lower bits) 1264 - Note: Extended Community format will have 2 bits for action. 1266 Action: determines inbound or outbound action where: 1268 - Outbound(0x1): FSv2 rule MUST be applied in outbound Direction 1269 to interface set identified by Group-id 1271 - Inbound (0x2): FSv2 rule MUST be applied in inbound Direction 1272 to interface set identified by Group-ID. 1274 Value ordering: AS, then Group ID, then Action bytes. 1276 Conflict: with any bi-direction action such as 1278 1. traffic rate limited by bytes, or 1280 2. traffic rate limited by packets. 1282 Reference: [I-D.ietf-idr-flowspec-interfaceset] 1284 4.2.3. Traffic rate limited by bytes (TRB) (0x6) 1286 SubTLV:0x6 1288 Length: 8 octets 1290 Value field:[4-octet-AS] [float (4 bytes)] 1292 where: 1294 [4-octet-AS]:4 byte AS number 1296 - If FSv1 passes the lower 2 bytes of 4 byte AS number, use 1297 [TBD5] as higher 2 bytes to identify. 1299 Float: maximum byte rate in IEEE floating point [IEEE.754.19895 1300 format] in units per second. 1302 - A value of 0 should result in all traffic for the particular 1303 flow to be discarded. 1305 Value ordering: AS then float value 1307 Action Conflict: traffic-rate-packets 1309 reference: [RFC8955] 1311 4.2.4. Traffic Action (TA)(0x7) 1313 SubTLV: 0x7 1315 Length: 1 1317 Value field: [1-octet action] 1319 where the traffic action values are: 1321 1 = Terminal flow specification action 1323 2 - Sample - enables sampling and logging 1324 3 - Terminal action + sample 1326 Value ordering: By traffic action values 1328 Conflicts/Interactions: duplication of packets also occurs in: 1330 Redirect to IPv4 (action 0x08), 1332 Redirect to IPv6 (action 0x0D (13)), 1334 Redirect to SFC (action 0xOE (14)) 1336 Redirect to Indirection-ID (action 0xF (15) 1338 4.2.5. Redirect to IPv4 (RDIPv4)[0x8) 1340 SubTLV: 0x08 1342 Length: 12 octets 1344 Value field: 1346 [4-byte-AS] [IPv4 address (4 octets] [ID (4 octets)] [Flag (1 octet)] 1348 where: 1350 4-octet-AS - is a 4-byte AS in a Route Target 1352 IPv4 address - is an IP Address in RT 1354 ID - the 4-octet value set by user 1356 Flag is 1 octet value with the following definitions: 1358 - 0 - reserved 1360 - 1 - copy and redirect copy 1362 Value ordering: 4-octet AS, then IP addres, then ID (lowest to 1363 highest) with: 1365 No AS specified uses AS value of zero. 1367 No IP specified uses IP value of zero. 1369 No ID specified uses ID value of zero. 1371 Conflicts/Interactions: Any redirection or traffic sampling found in: 1373 Traffic Action (action 0x07), 1375 Redirect to IPv6 (action 0x0D (13)), 1377 Redirect to SFC (action 0xOE (14)) 1379 Redirect to Indirection-ID (action 0xF (15) 1381 reference: [RFC8955], draft-ietf-idr-flowspec-ip-02.txt 1383 4.2.6. Traffic marking (TM) (0x9) 1385 SubTLV: 0x9 1387 Length: 1 octet 1389 Value: DSCP field with the 2 left most bits zero 1391 The DSCP field format is: 1393 0 1 2 3 4 5 6 7 1394 +---------------+ 1395 |R R DSCP bits | 1396 +---------------+ 1397 Figure 16 1399 where: 1401 RR - reserved bits (set to zero to send, ignored upon reception 1402 and set to zero. 1404 DSCP - 6 bits of DSCP values 1406 Ordering within Value: Based on DSCP value 1408 Conflicts: none 1410 reference: [RFC8955] 1412 4.2.7. Traffic rate limited by packets (TRP) (12/0xC) 1414 SubTLV= 12 (0xC) 1416 Length: 8 1417 Value field: [4-octet-AS] [float (4 octet)] 1419 Where: 1421 4-octet AS - is the AS setting this value 1423 Float - specifies maximum rate [IEEE.754.185] format in packets 1424 per second. 1426 - A traffic rate of zero should result in all packets being 1427 discard. The traffic rate should not be negative. 1429 Ordering within Value: Based on DSCP value 1431 Conflicts: Traffic rate limited by bytes (0x06) 1433 reference: [RFC8955] 1435 4.2.8. Traffic redirect to IPv6 (RDIPv6) (13, 0xD) 1437 SubTLV = 13 (0xD) 1439 Length = 24 octets 1441 Value field: [4-octet-as] [IPv6-address (16 octets)] [local 1442 administrator (2 octets] [Flag (1 octets)] 1444 where: 1446 4-octet-AS - is the AS requesting action in 4 byte AS format, 1448 IPv6-address - is the redirection IPv6 address 1450 Local administrator - 2 bytes assigned by network administrator. 1452 lag (1 octet) with the following definitions: 1454 - 0 - reserved 1456 - 1 - copy and redirect copy 1458 Ordering within Value: AS, then IPv6, the flag (low to high) 1460 Conflicts/Interactions: Any redirection or traffic sampling found in: 1462 Traffic Action (action 0x07) , 1463 Redirect to IPv4 (action 0x08 (8)), 1465 Redirect to SFC (action 0xOE (14)) 1467 Redirect to Indirection-ID (action 0xF (15) 1469 4.2.9. Traffic insertion in SFC (TISFC)(14, OXE) 1471 SubTLV = (14, 0xE) 1473 Note: replace IANA 0xD FSv1 with FSv2 OxE. 1475 Length = 6 octets 1477 Value field: [SPI (3 octets)][SI (1 octet)][SFT (2 octet)] 1479 where: 1481 SPI - is the service path identifier 1483 SI - is the service index 1485 SFT - is the service function type. 1487 Value ordering: SPI, then SI, then SFT (lowest to highest) 1489 Conflicts/Interactions: Any redirection or traffic sampling found in: 1491 Traffic Action (action 0x07) , 1493 Redirect to IPv4 (action 0x08 (8)), 1495 Redirect to IPv6 (action 0xOD (13)) 1497 Redirect to Indirection-ID (action 0xF (15) 1499 Reference: [RFC9015] 1501 4.2.10. Flow Specification Redirect to Indirection-ID (RDIID) (0x0F) 1503 SubTLV: 15, 0x0F 1505 note: current value is 0x00 for FSv1 1507 Length: 6 octets 1509 Value field: 1511 [Flags (1 octet)] [ID-Type (1 octet)][Generalized-ID (4 octets)] 1513 where: 1515 Flags: are defined as: 1517 - S-ID]: sequence number for indirection IDs (3 bits). 1519 o Value of zero means sequence is not set and all other S-ID 1520 values should be ignored 1522 - [C] - copy packets matching this ID 1524 ID-Type: type of indirection ID with following values: 1526 - 0 - localized ID 1528 - 1 - Node with SID/index in MPLS SR 1530 - 2 - Node with SID/label in MPLS SR 1532 - 3 - Node with Binding Segment ID with SID/Index 1534 - 4 - Node with Binding Segment ID with SID/Label 1536 - 5 - Tunnel ID 1538 Generalized-ID (G-ID): indirection value 1540 Value Ordering: first indirection ID, then Generalized ID 1542 Action Value ordering: ID-Type by value (lowest to highest) 1544 Conflicts/Interactions: Any redirection or traffic sampling found in: 1546 Traffic Action (action 0x07) , 1548 Redirect to IPv4 (action 0x08 (8)), 1550 Redirect to IPv6 (action 0x0D, (13) 1552 Redirect to SFC (action 0xOE (14)) 1554 reference: [I-D.ietf-idr-flowspec-path-redirect] 1556 4.2.11. VLAN action (VLAN) (action 0x16, 22) 1558 Function: Rewrite inner or outer VLAN header 1560 SubTLV: 22 (0x16) 1562 Length: 6 octets 1564 Value: 1566 [Rewrite-actions (2 octets)] 1568 [vlan-PCP-DE-1 (2 octets)] 1570 [vlan-PCP-DE-2 [2 octets)] 1572 where: 1574 Rewrite-actions - is as follows: 1576 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1577 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1578 |PO1|PU1|SW1|RI1|RO1| Resv |PO2|PU2|SW2|RI2|RO2| Resv | 1579 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1581 Figure 17 1583 PO1: Pop action. If the PO1 flag is one, it indicates the outmost 1584 VLAN should be removed. 1586 PU1: Push action. If PU1 is one, it indicates VLAN ID1 will be 1587 added, the associated Priority Code Point (PCP and Drop 1588 Eligibility Indicator (DEI) are PCP1 and DE1. 1590 SW1: Swap action. If the SW1 flag is one, it indicates the outer 1591 VLAN and inner VLAN should be swapped. 1593 PO2: Pop action. If the PO2 flag is one, it indicates the outmost 1594 VLAN should be removed. 1596 PU2: Push action. If PU2 is one, it indicates VLAN ID2 will be 1597 added, the associated PCP and DEI are PCP2 and DE2. 1599 SW2: Swap action. If the SW2 flag is one, it indicates the outer 1600 VLAN and inner VLAN should be swapped. 1602 RI1 and RI2: Rewrite inner VLAN action. If the RIx flag is one 1603 where "x" is "1" or "2"), it indicates the inner VLAN should be 1604 replaced by a new VLAN where the new VLAN is VLAN IDx and the 1605 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, 1606 the action is to only modify the PCP and DEI value of the inner 1607 VLAN. 1609 RO1 and RO2: Rewrite outer VLAN action. If the ROx flag is one 1610 (where "x" is "1" or "2"), it indicates the outer VLAN should be 1611 replaced by a new VLAN where the new VLAN is VLAN IDx and the 1612 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, 1613 the action is to only modify the PCP and DEI value of the outer 1614 VLAN. 1616 Resv: Reserved for future use. MUST be sent as zero and ignored 1617 on receipt. 1619 Value ordering: rewrite-actions, VLAN1, VLAN2, PCP-DE1, PCP-DE2 1621 Conflicts: TIPD Action 1623 reference: [I-D.ietf-idr-flowspec-l2vpn] 1625 4.2.12. TPID action (TPID) (action 0x17, 23) 1627 Function: Replace Inner or outer TP 1629 SubTLV: 23 (0x17) 1631 Length: 6 octets 1633 Value: 1635 [Rewrite-actions (2 octets)] 1637 [TP-ID-1 (2 octets)] 1639 [TP-ID-2 (2 octets)] 1641 Where: rewrite-actions are bitmask (2 octets) with 2 actions as 1642 follows: 1644 0 15 1645 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1646 |TI|TO| Resv | 1647 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1649 Figure 18 1651 TI: Mapping inner Tag Protocol (TP) ID (typically a VLAN) action. If 1652 the TI flag is one, it indicates the inner TP ID should be replaced 1653 by a new TP ID, the new TP ID is TP ID1. 1655 TO: Mapping outer TP ID action. If the TO flag is one, it indicates 1656 the outer TP ID should be replaced by a new TP ID, the new TP ID is 1657 TP ID2. 1659 Resv: Reserved for future use. MUST be sent as zero and ignored on 1660 receipt 1662 Value Ordering: rewrite-actions, TP-ID-1, TP-ID-2 1664 Conflicts: VLAN action 1666 reference:[I-D.ietf-idr-flowspec-l2vpn] 1668 4.2.13. Extended Community vs. Action SubTLV formats 1670 The SubTLV format is used for the Wide communities and for the action 1671 subTLVs in the NLRI. 1673 Sub-TLV Action Action SubTLV Extended Community 1674 type Name format format 1675 ======= ===== =============== ==================== 1676 1 ACO type: 1 not applicable (n/a) 1677 length:variable 1679 2 TAIS type: 2 type: 0x0702 or 0x4702 1680 length:8 length: 6 1681 [4-octet-as] [4-octet-AS] 1682 [group-3-octet] [flags-group] (2) 1683 [flags-1-octet] 1685 3-5 reserved 1687 Sub-TLV Action Action SubTLV Extended Community 1688 type Name format format 1689 ======= ===== =============== ==================== 1690 6 TRB type:6 type:8006 1691 length:8 length: 6 1692 [4-byte-AS] [2-byte-AS] 1693 [float (4 octets)] [float (4 octets)] 1695 7 TA type:7 type:8007 1696 length:1 length:6 octets 1697 flags: (1 octet) flags (6 octets) 1699 8 RDIPv4 type:8 type:8008 1700 length: 12 length: 6 octets 1701 [4-byte-AS] [AS-2-octets] 1702 [IPv4-address] [IPv4 address] 1703 type:8108 1704 length: 6 octets 1705 [IPv4 address] 1706 [ID-2 octets] 1707 type:8208 1708 length: 6 octets 1709 [AS-4-octets] 1710 [ID-2-octets] 1712 9 TM type:9 type:8009 1713 length:1 length:6 1714 DSCP: 1 octet DSCP: 1 octet 1716 10-11 reserved 1718 12 TRP type:12 (0xC) type: 0x800C 1719 length: 8 octets length: 6 octets 1720 [4-byte-AS] [2-byte-AS] 1721 [float-4-octet] [float-4-octet] 1723 13 RDIPv6 type:13 (0xD) type:0x000C 1724 length:22 length: 18 1725 [4-byte-AS] [IPv6-address (16)] 1726 [IPv6-address (16)] [local-admin (2)] 1727 [local-admin (2)] 1729 Sub-TLV Action Action SubTLV Extended Community 1730 type Name format format 1731 ======= ===== =============== ==================== 1733 14 TISFC type:14 (0xE) type: 0xD (FSv1) 1734 type: 0xE (FSv2) 1736 length:6 length:6 1737 SPI (3 octets) SPI (3 octets) 1738 SI (1 octet) SI (1 octet) 1739 SFT (2 octets) SFT (2 octets) 1741 15 RDIID type:15 (0xF) Type: 0900 (FSv1) 1742 length: 6 length 6 1743 flags (1) flags (1) 1744 ID-type (1) ID type (1) 1745 G-ID (4 octets) G-ID (4-octets) 1747 16-21 reserved 1749 22 VLAN type:22 (0x16) Type: (TBD) 1750 length:6 length:6 1751 [rewrite-action(2)] [rewrite-actions (2)] 1752 [vlan-pcp-de-1 (2)] [vlan-pcp-de-1 (2)] 1753 [vlan-pcp-de-2 (2)] [vlan-pcp-de-2 (2)] 1755 23 TPID type:23 (0x17) Type: (TBD) 1756 length:6 length:6 1757 [rewrite-action(2)] [rewrite-actions (2)] 1758 [TP-ID-1 (2)] [TP-ID-1 (2)] 1759 [TP-ID-2 (2)] [TP-ID-2 (2)] 1761 4.3. L2 and L2VPN FSv2 Filters 1763 field includes the AFI (2 octets), SAFI (1 octet) and will be 6/TBD1 1764 or, for the VPN case, 28/TBD2 1765 +-------------------------------+ 1766 | +--------------------------+ | 1767 | | L3 AFI-SAFI field (3) | | 1768 | | + | | 1769 | +==========================+ | 1770 +-------------------------------+ 1772 Each SubTLV has the format: 1774 +-------------------------------+ 1775 | SubTLV type (1 octet) | 1776 +-------------------------------+ 1777 | length (1 octet) | 1778 + ------------------------------+ 1779 | value (variable) | 1780 +-------------------------------+ 1781 Figure 19 1783 SubTLV type: A component type value defined in the "L2 Flow 1784 Specification Component Types" registry for L2 by [draft-ietf-idr- 1785 flowspec-l2vpn). 1787 Where the SubTLVs have the following component types: 1789 Component Types Table 1791 Component 1792 type Description 1793 ======= ================== 1794 1 EtherType 1795 2 Source MAC 1796 3 Destination MAC 1797 4 DSAP (destination service access point) 1798 5 SSAP (source service access point) 1799 6 control field in LLC 1800 7 SNAP 1801 8 VLAN ID 1802 9 VPAN PCP 1803 10 Inner VLAN ID 1804 11 Inner VLAN PCP 1805 12 VLAN DEI 1806 13 VLAN DEI 1807 14 Source MAC special bits 1808 15 Destination MAC special bits 1810 Table 4 – L2 VPN components 1812 See [I-D.ietf-idr-flowspec-l2vpn] for the details on the format and 1813 value fields for each component. 1815 Value ordering: Ordering of L2 FSv2 rules will be by user-defined 1816 order of the rule. For FSv2 filters within the same rule, the 1817 ordering will be by component number and then by value within the 1818 component. See [I-D.ietf-idr-flowspec-l2vpn] for the ordering of the 1819 values within the component. 1821 reference: [I-D.ietf-idr-flowspec-l2vpn] 1823 4.4. FSv2 SFC NLRI Traffic Filters 1825 The FSv2 filters allow for filtering of the SFC NLRI family of 1826 routes. The traffic NLRIs filtered are from SFC AFI/SAFI (AFI = 31, 1827 SAFI=9). 1829 The FSv2 filters provide this filtering with SFC AFI (AFI=31) and 1830 SAFI for FSv2 filters (SAFI = TB1). 1832 +--------------------------------------+ 1833 | +---------------------------------+ | 1834 | | Tunneled AFI/SAFI field | | 1835 | | + | | 1836 | +=================================+ | 1837 +--------------------------------------+ 1839 Figure 20 1841 Each SubTLV has the format: 1843 +-------------------------------+ 1844 | SubTLV type (1 octet) | 1845 +-------------------------------+ 1846 | length (1 octet) | 1847 + ------------------------------+ 1848 | value (variable) | 1849 +-------------------------------+ 1850 Figure 21 – Tunneled SubTLV format 1852 The components listed are: 1854 1 = SFIR RD Type (types 1, 2, 3) 1855 2 = SFIR RD Value 1856 3 = SFIR Pool ID 1857 4 = SFIR MPLS context/label 1858 5 = SFPR SPI 1859 6 = SPF attribute fields 1861 Table 6 – SFC Filter types 1863 Ordering is by: User-defined rule order, component number, and then 1864 value within component. 1866 reference: [RFC9015], [TBD] 1868 4.5. Encoding of Actions passed in Wide Communities 1870 The BGP Flow specification version 2 actions are passed in a Wide 1871 Community [I-D.ietf-idr-wide-bgp-communities] atom with the following 1872 format: 1874 +----------------------------+ 1875 | atom-id | 1876 +----------------------------+ 1877 | length (2 octets) | 1878 +----------------------------+ 1879 | + | 1880 +----------------------------+ 1882 Figure 22 - Flow Specification with 1883 IDs for Wide Community Actions 1885 where: 1887 Atom-id (TBD) - is id to be defined 1889 length: variable depending on SubTLVS 1891 Action Sub-TLVs as defined above 1893 The BGP Flow Specification (BGP-FS) atom can be part of the Wide 1894 Community container (type 1) or the BGP Flow Specification Atom can 1895 be part of the BGP Flow Specification container (type 2) which will 1896 have: 1898 +-----------------------------+ 1899 | Source AS Number (4 octets)| 1900 +-----------------------------+ 1901 | list of atoms (variable) | 1902 +-----------------------------+ 1903 Figure 23: Atom format 1905 5. Validation of FSv2 NLRI 1907 The validation of FSv2 NLRI adheres to the combination of rules for 1908 general BGP FSv1 NLRI found in [RFC8955], [RFC8956], [RFC9117], and 1909 the specific additions made for SFC NLRI [RFC9015], L2VPN NLRI 1910 [I-D.ietf-idr-flowspec-l2vpn]. 1912 To provide clarity, the full validation process for flow 1913 specification routes (FSv1 or FSv2) is described in this section 1914 rather than simply refer to the portions of these RFCs. Validation 1915 only occurs after BGP UPDATE packet, the FSv2 NLRI and the path 1916 attributes relating to FSv2 (Extended community and Wide Community) 1917 have been determined to be well-formed. Any MALFORMED FSv2 NRLI is 1918 handled as a "TREAT as WITHDRAW". 1920 5.1. Validation of FS NLRI (FSv1 or FSv2) 1922 Flow specification received from a BGP peer that are accepted in the 1923 respective Adj-RIB-In are used as input to the route selection 1924 process. Although the forwarding attributes of the two routes for 1925 same prefix may be the same, BGP is still required to perform its 1926 path selection algorithm in order to select the correct set of 1927 attributes to advertise. 1929 The first step of the BGP Route selection procedure (section 9.1.2 of 1930 [RFC4271] is to exclude from the selection procedure routes that are 1931 considered unfeasible. In the context of IP routing information, 1932 this is used to validate that the NEXT_HOP Attribute of a given route 1933 is resolvable. 1935 The concept can be extended in the case of the Flow Specification 1936 NLRI to allow other validation procedures. 1938 The FSv2 validation process validates the FSv2 NLRI with following 1939 unicast routes received over the same AFI (1 or 2) but different 1940 SAFIs: 1942 * Flow specification routes (FSv1 or FSv2) received over SAFI=133 1943 will be validated against SAFI=1, 1945 * Flow Specification routes (FSv1 or FSv2) received over SAFI=134 1946 will be validated against SAFI=128, and 1948 * Flow Specification routes (FSv1 or FSv2) [AFI =1, 2] received over 1949 SAFI=77 will be validated will be validated using only the Outer 1950 Flow Spec against SAFI = 133. 1952 The FSv2 validates L2 FSv2 NLRI with the following L2 routes received 1953 over the same AFI (25), but a different SAFI: 1955 * Flow specification routes (FSv1 or FSv2)received over SAFI=135 are 1956 validated against SAFI=128. 1958 In the absence of explicit configuration, a Flow specification NLRI 1959 (FSv1 or FSv2) MUST be validated such that it is considered feasible 1960 if and only if all of the conditions are true: 1962 a) A destination prefix component is embedded in the Flow 1963 Specification, 1965 b) One of the following conditions must hold true: 1967 - 1. The originator of the Flow Specification matches the 1968 originator of the best-math unicast route for the destination 1969 prefix embedded in the flow specification (this is the unicast 1970 route with the longest possible prefix length covering the 1971 destination prefix embedded in the flow specification). 1973 - 2. The AS_PATH attribute of the flow specification is empty or 1974 contains only an AS_CONFED_SEQUENCE segment [RFC5065]. 1976 o 1.This condition should be enabled by default. 1978 o 2.This condition may be disabled by explicit configuration 1979 on a BGP Speaker, 1981 o 3.As an extension to this rule, a given non-empty AS_PATH 1982 (besides AS_CONFED_SEQUENCE segments) MAY be permitted by 1983 policy]. 1985 c) There are no "more-specific" unicast routes when compared with 1986 the flow destination prefix that have been received from a 1987 different neighbor AS than the best-match unicast route, which has 1988 been determined in rule b. 1990 However, rule a may be relaxed by explicit configuration, permitting 1991 Flow Specifications that include no destination prefix component. If 1992 such is the case, rules b and c are moot and MUST be disregarded. 1994 By "originator" of a BGP route, we mean either the address of the 1995 originator in the ORIGINATOR_ID Attribute [RFC4456] or the source 1996 address of the BGP peer, if this path attribute is not present. 1998 BGP implementation MUST enforce that the AS in the left-most position 1999 of the AS_PATH attribute of a Flow Specification Route (FSv1 or FSv2) 2000 received via the Exterior Border Gateway Protocol (eBGP) matches the 2001 AS in the left-most position of the AS_PATH attribute of the best- 2002 match unicast route for the destination prefix embedded in the Flow 2003 Specification (FSv1 or FSv2) NLRI. 2005 The best-match unicast route may change over time independently of 2006 the Flow Specification NLRI (FSv1 or FSv2). Therefore, a 2007 revalidation of the Flow Specification MUST be performed whenever 2008 unicast routes change. Revalidation is defined as retesting rules a 2009 to c as described above. 2011 5.2. Validation of Flow Specification Actions 2013 Flow Specification may be mapped using Extended Communities, Wide 2014 Communities or a FSv2 NLRI TLV. The scaling of FSv2 actions implies 2015 that Extended Communities and wide communities which can associate an 2016 action to a large number of NLRIs will be most often used. 2017 Therefore, it is likely the FSv2 NLRI TLV for actions will be very 2018 few actions (such as the "die-die-die Internet worm" use case). 2020 The ordering of precedence for these actions in the absence of user- 2021 defined ordering, is to follow the precedence of the FSv2 NLRI action 2022 TLV values (lowest to highest). If multiple items exist for the same 2023 action type, then ordering is described within each Action SubTLV. 2024 Extended Community actions should be translated to the Action SubTLV 2025 format for internal comparison. 2027 Actions may conflict, duplicate, or complementation other actions. 2028 An example of conflict is the packet rate limiting by byte and by 2029 packet. An example of a duplicate is the request to copy or sample a 2030 packet under one of hte redirect functions (RDIPv4, RDIPv6, RDIID, ) 2031 Each FSv2 actions in this document defines the potential conflicts or 2032 duplications. Specifications for new FSv2 actions outside of this 2033 specification MUST specify interactions or conflicts with any FSv2 2034 actions (in this specification or subsequent specification). 2036 Well-formed syntactically correct actions should be linked to a 2037 filtering rule in order the actions should be enacted. If one action 2038 in the ordered list fails, the default procedure is for the action 2039 process for this rule to stop and flag the error via system 2040 management. By explicit configuration, the action processing may 2041 continue after errors.. 2043 Implementations MAY wish to log the actions taken by FS actions (FSv1 2044 or FSv2). 2046 5.3. Error handling and Validation 2048 The following two error handling rules must be followed by all BGP 2049 speakers which support FSv2: 2051 * FSv2 NLRI having TLVs which do not have the correct lengths or 2052 syntax must be considered MALFORMED. 2054 * FSv2 NLRIs having TLVs which do not follow the above ordering 2055 rules described in section 4.1 MUST be considered as malformed by 2056 a BGP FSv2 propagator. 2058 The above two rules prevent any ambiguity that arises from the 2059 multiple copies of the same NLRI from multiple BGP FSv2 propagators. 2061 A BGP implementation SHOULD treat such malformed NLRIs as 'Treat-as- 2062 withdraw'. 2064 An implementation for a BGP speaker supporting both FSv1 and FSv2 2065 must support the error handling for both FSv1 and FSv2. The storage 2066 of the BGP FSv1 and FSv2 must support both the AFI/SAFI and the 2067 configuration which translates FSv1 NLRI into FSv2 NLRI for order 2068 storage. 2070 6. Ordering for Flow Specification v2 (FS-v2) 2072 Flow Specification v2 allows the user to order flow specification 2073 rules and the actions associated with a rule. Each FSv2 rule has one 2074 or more match conditions and one or more actions associated with each 2075 rule. 2077 This section describes how to order FSv2 filters received from a peer 2078 prior to transmission to another peer. The same ordering should be 2079 used for the ordering of forwarding filtering installed based on only 2080 FSv2 filters. 2082 Section 7.0 describes how a BGP peer that supports FSv1 and FSv2 2083 should order order the flow specification filters during the 2084 installation of these flow specification filters into FIBs or 2085 firewall engines in routers. 2087 The BGP distribution of FSv1 NLRI and FSv2 NLRI and their associated 2088 path attributes for actions (Wide Communities and Extended 2089 Communities) is "ships-in-the-night" forwarding of different AFI/SAFI 2090 information. This recommended ordering provides for deterministic 2091 ordering of filters sent by the BGP distribution. 2093 6.1. Ordering of FSv2 NLRI Filters 2095 The basic principles regarding ordering of rules are simple: 2097 1) Rule-0 (zero) is defined to be 0/0 with the "permit-all" action 2099 - BGP peers which do not support flow specification permit 2100 traffic for routes received. Rule-0 is defined to be "permit- 2101 all" for 0/0 which is the normal case for filtering for routes 2102 received by BGP. 2104 - By configuration option, the "permit-all" may be set to "deny- 2105 all" if traffic rules on routers used as BGP must have a 2106 "route" AND a firewall filter to allow traffic flow. 2108 2)FSv2 rules are ordered based on the user-defined order numbers 2109 specified in the FSv2 NLRI (rules 1-n). 2111 3) If multiple FSv2 NLRI have the same user-defined order, then 2112 the filters are ordered by type of FSv2 NRLI filters (see Table 1, 2113 section 4) with lowest numerical number have the best precedence. 2115 - For the same user-defined order and the same value for the FSv2 2116 filters type, then the filters are ordered by FSv2 the 2117 component type for that FSv2 filter type (see Tables 3-6) with 2118 the lowest number having the best precedence. 2120 - For the same user-defined order, the same value of FSv2 Filter 2121 Type, and the same value for the component type, then the 2122 filters are ordered by value within the component type. Each 2123 component type defines value ordering. 2125 - For component types inherited from the FSv1 component types, 2126 there are the following two types of comparisons: 2128 o FSv1 component value comparison for the IP prefix values, 2129 compares the length of the two prefixes. If the length is 2130 different, the longer prefix has precedence. If the length 2131 is the same, the lower IP number has precedence. 2133 o For all other FSv1 component types, unless specified, the 2134 component data is compared using the memcmp() function 2135 defined by [ISO_IEC_9899]. For strings with the same 2136 length, the lowest string memcmp() value has precedence. 2137 For strings of different lengths, the common prefix is 2138 compared. If the common string prefix is not equal, then 2139 the string with the lowest string prefix has higher 2140 precedence. If the common prefix is equal, the longest 2141 string is considered to have higher precedence 2143 Notes: 2145 * Since the user can define rules that re-order these value 2146 comparisons, this order is arbitrary and set to provide a 2147 deterministic default. 2149 6.2. Ordering of the Actions 2151 The FSv2 specification allows for actions to be associated by: 2153 a) a Wide Community path attribute, 2155 b) an Extended Community path attribute, and 2157 c) a FSv2 Action TLV in an FSv2 NLRI (poor scaling) 2159 Actions may be ordered by user-defined action order number from 1-n 2160 (where n is 2**16-2 and value of 2**16-1 is reserved. 2162 Extended community actions are associated with order number 32768 2163 [0x8000] or a specific configured value for the FSv2 domain. 2165 Action user-order number zero is defined to have an Action type of 2166 "Set Action Chain operation" (ACO) (value 0x01) that defines the 2167 default action chain process. For details on "set action chain 2168 operation" see section 4.2.0 and section 6.2.1 below. 2170 If the user-defined action number for an action is the same, then the 2171 actions are ordered by FSv2 action types (see Table 3 for a list of 2172 action types). If the user-defined action number and the FSv2 action 2173 types are the same, then the order must be defined by the FSv2 2174 action. 2176 6.2.1. Action Chain Operation 2178 The "Action Chain Operation" (ACO) changes the way the actions after 2179 this action in an action chain handles a failure. If no action chain 2180 operations are set, then the default action of "stop upon failure" 2181 (value 0x00) will be used for the chain. 2183 An example may help illustrate how failure impacts an action chain. 2184 Suppose we have the following 4 actions defined for a match: 2186 * Sent Redirect to indirection ID (0x01) with user-defined match 2 2187 attached in wide community, 2189 * Traffic rate limit by bytes (0x07) with user-defined match 1 2190 attached in wide community, 2192 * Traffic sample (0x07) sent in extended community, and 2194 * SF classifier Info (0x0E) sent in extended community. 2196 These 4 filters rate limit a potential DDoS attack by: a) redirect 2197 the packet to indirection ID (for slower speed processing), sample to 2198 local hardware, and forward the attack traffic via a SFC to a data 2199 collection box. 2201 The FSv2 action list for the match would look like this 2203 Action 0: Operation of action chain (0x01) (stop upon failure) 2205 Action 1: Traffic Rate limit by byte (0x07) 2207 Action 2: Redirect to Redirection ID (0x0F) 2209 Action 32768 (0x8000) Traffic Action (0x07) Sample 2211 Action 32768 (0x8000) SFC Classifier: (0xE) 2213 If the redirect to a redirection ID fails, then Traffic Sample and 2214 sending the data to an SFC classifier for forwarding via SFC will not 2215 happen. The traffic is limited, but not redirect away from the 2216 network and a sample sent to DDOS processing via a SFC classifier. 2218 Suppose the following 5 actions were defined for a FSV2 filter: 2220 * Set Action Chain Operation (ACO) (0x01) to continue on failure 2221 (ox01) at user-order 2 attached in wide community, 2223 * redirect to indirection ID (0x0F) at user-order 2 attached in wide 2224 community, 2226 * traffic rate limit by bytes (0x07)with user-order 1 attached in 2227 wide community, 2229 * Traffic sample (0x07) attached via extended community, and 2231 * SFC classifier Info (0x0E) attached in extended community. 2233 The FSv2 action list for the match would look like this: 2235 Action 0: Operation of action chain (0x01) (stop upon failure) 2237 Action 01:Traffic Rate limit by byte (0x07) 2239 Action 02:Set Action Chain Operation (ACO) (0x01) (continue on 2240 failure) 2242 Action 02: Redirect to Redirection ID (0F) 2244 Action 32768 (0x8000): Traffic Action (0x07) Sample 2246 Action 32768 (0x8000): SFC classifier (0x0E) forward via SFC [to 2247 DDoS classifier] 2249 If the redirect to a redirection ID fails, the action chain will 2250 continue on to sample the data and enact SFC classifier actions. 2252 Note:The scaling for associating actions is better with Wide or 2253 Extended Communities which can be associated with many FSv2 filters. 2254 The FSv2 action with FSv2 NLRI should be used in rare cases such the 2255 use case of an pernicious Internet worm. In this case, Suppose we 2256 call the filter "Internet worm" particular filter match identifies 2257 the pernicious Internet worm that must be die off and not be 2258 forwarded. Let us call the actions in the action chain "Die-Die- 2259 Internet-worm". For such a use case, the the FSV2 actions to stop 2260 the packets are tied to the filter even though it may not scale or 2261 have issues in some deployments. 2263 6.2.2. Summary of FSv2 ordering 2265 Operators should use user-defined ordering to clearly specify the 2266 actions desired upon a match. The FSv2 actions default ordering is 2267 specified to provide deterministic order for actions which have the 2268 same user-defined order and same type. 2270 FS Action Value Order 2271 (lowest value to highest) (lowest to highest) 2272 ============================= ================================= 2273 0x01: Action chain operation Failure flag 2274 0x02: traffic actions per AS, then Group-ID, then Action ID 2275 Interface group 2277 0x03-0x05 to be assigned TBD 2279 0x06: Traffic rate limit AS, then float value 2280 0x07 – Traffic Action traffic Action value 2281 0x08 – Redirect to IP AS, then IP Address, then ID 2282 0x09 – Traffic Marking DSCP value (lowest to highest) 2283 0x0C – Redirect to Indirect ID AS, then Float value 2284 0x0D – Traffic Redirect to IPv6 AS, IPv6 value, then local Admin 2285 0x0E – Traffic insertion to SFC SPI, then SI, the SFT 2286 0xOF – Redirect to 2287 Indirection-ID ID-type, then Generalized-ID 2289 0x10-0x15 – to be assigned TBD 2291 0x16 – VLAN action rewrite-actions, VALN1, VLAN2, 2292 PCP-DE1, PCP-DE2 2293 0x17 – TPID action rewrite actions, TP-ID-1, TP-ID-2 2295 Figure 24 2297 7. Ordering of FS filters for BGP Peers support FSv1 and FSv2 2299 FSv2 allows the user to order flow specification rules and the 2300 actions associated with a rule. Each FSv2 rule has one or more match 2301 conditions and one or more actions associated with each rule. 2303 Some BGP peers will support FSv1 and FSv2. This section describes 2304 the best practice for ordering the FSv1 and FSv2 filter rules. 2306 One simple rule captures the best practice: Order the FSv1 filters 2307 after the FSv2 filter by placing the FSv1 filters after the FSv2 2308 filters. 2310 To operationally make this work, all flow specification filters 2311 should be included the same data base with the FSv1 filters being 2312 assigned a user- defined order beyond the normal size of FSv2 user- 2313 ordered values. 2315 Suppose you might have 10,000 rules for the FSv2 filters. Assign all 2316 the FSv1 user defined rules to 10,001 (or better yet 20,000). The 2317 FSv1 rules will be ordered by the components and component values. 2319 All FSv1 actions are defined ordered actions in FSv2. Translate your 2320 FSv1 actions into FSv2 ordered actions for storing in a common 2321 FSv1-FSv2 flow specification data base. 2323 8. Scalability and Aspirations for FSv2 2325 Operational issues drive the deployment of BGP flow specification as 2326 a quick and scalable way to distribute filters. The early operations 2327 accepted the fact validation of the distribution of filter needed to 2328 be done outside of the BGP distribution mechanism. Other mechanisms 2329 (NETCONF/RESTCONF or PCEP) have reply-request protocols. 2331 These features within BGP have not changed. BGP still does not have 2332 an action-reply feature. 2334 NETCONF/RESTCONF latest enhancements provide action/response features 2335 which scale. The combination of a quick distribution of filters via 2336 BGP and a long-term action in NETCONF/RESTCONF that ask for reporting 2337 of the installation of FSv2 filters may provide the best scalability. 2339 The combination of NETCONF/RESTCONF NM protocols and BGP focuses each 2340 protocol on the strengths of scalability. 2342 FSv2 will be deployed in webs of BGP peers which have some BGP peers 2343 passing FSv1, some BGP peers passing FSv2, some BGP peers passing 2344 FSv1 and FSv2, and some BGP peers not passing any routes. 2346 The TLV encoding and deterministic behaviors of FSv2 will not 2347 deprecate the need for careful design of the distribution of flow 2348 specification filters in this mixed environment. The needs of 2349 networks for flow specification are different depending on the 2350 network topology and the deployment technology for BGP peers sending 2351 flow specification. 2353 Suppose we have a centralized RR connected to DDoS processing sending 2354 out flow specification to a second tier of RR who distribute the 2355 information to targeted nodes. This type of distribution has one set 2356 of needs for FSv2 and the transition from FSv1 to FSv2 2358 Suppose we have Data Center with a 3-tier backbone trying to 2359 distribute DDoS or other filters from the spine to combinational 2360 nodes, to the leaf BGP nodes. The BGP peers may use RR or normal BGP 2361 distribution. This deployment has another set of needs for FSv2 and 2362 the transition from FSv1 to FSV2. 2364 Suppose we have a corporate network with a few AS sending DDoS 2365 filters using basic BGP from a variety of sites. Perhaps the 2366 corporate network will be satisfied with FSv1 for a long time. 2368 These examples are given to indicate that BGP FSv2 like so many BGP 2369 protocols needs to be carefully tuned to aid the mitigation services 2370 within the network. This protocol suite starts the migration toward 2371 better tools using FSv2, but it does not end it. With FSv2 TLVs and 2372 deterministic actions, new operational mechanisms can start to be 2373 understood and utilized. 2375 This FSv2 specification is merely the start of a revolution of work - 2376 not the end. 2378 9. Optional Security Additions 2380 This section discusses the optional BGP Security additions for BGP-FS 2381 v2 relating to BGPSEC [RFC8205] and ROA. 2383 9.1. BGP FS v2 and BGPSEC 2385 Flow specification v1 ([RFC8955] and [RFC8956]) do not comment on how 2386 BGP Flow specifications to be passed BGPSEC [RFC8205] BGP Flow 2387 Specification v2 can be passed in BGPSEC, but it is not required. 2389 FSv1 and FSv2 may be sent via BGPSEC. 2391 9.2. BGP FS v2 with with ROA 2393 BGP Flow Specification v2 can utilize ROAs in the validation. If 2394 BGP-FS v2 is used with BGPSEC and ROA, the first thing is to validate 2395 the route within BGPSEC and second to utilize BGP ROA to validate the 2396 route origin. 2398 The BGP-FS peers using both ROA and BGP-FS validation determine that 2399 a BGP Flow specification is valid if and only if one of the following 2400 cases: 2402 * If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in 2403 destination address match filter and the following is true: 2405 - A BGP ROA has been received to validate the originator, and 2407 - the route is the best-match unicast route for the destination 2408 prefix embedded in the match filter; or 2410 * If a BGP ROA has not been received that matches the IPv4 or IPv6 2411 destination address in the destination filter, the match filter 2412 must abide by the [RFC8955] and [RFC8956] validation rules of: 2414 - The originator match of the flow specification matches the 2415 originator of the best-match unicast route for the destination 2416 prefix filter embedded in the flow specification", and 2418 - No more specific unicast routes exist when compared with the 2419 flow destination prefix that have been received from a 2420 different neighboring AS than the best-match unicast route, 2421 which has been determined in step A. 2423 The best match is defined to be the longest-match NLRI with the 2424 highest preference. 2426 10. IANA Considerations 2428 This section complies with [RFC7153] 2430 10.1. Flow Specification V2 SAFIs 2432 IANA is required to assign two SAFI Values from the registry at 2433 https://www.iana.org/assignments/safi-namespace from the Standard 2434 Action Range as follows: 2436 Value Description Reference 2437 ----- ------------- --------------- 2438 TBD1 BGP-FS V2 [This document] 2439 TBD2 BGP-FS V2 VPN [this document] 2441 10.2. BGP Capability Code 2443 IANA is requested to assign a Capability Code from the registry at 2444 https://www.iana.org/assignments/capability-codes/ from the IETF 2445 Review range as follows: 2447 Value Description Reference Controller 2448 ----- --------------------- --------------- ---------- 2449 TBD3 Flow Specification V2 [this document] IETF 2451 10.3. Filter IP Component types 2453 IANA is requested to indicate [this draft] as a reference on the 2454 following assignments in the Flow Specification Component Types 2455 Registry: 2457 Value Description Reference 2458 ----- -------------------- ------------------------ 2459 1 Destination filter [RFC8955][RFC8956][this draft] 2460 2 Source Prefix [RFC8955][RFC8956][this draft] 2461 3 IP Protocol [RFC8955][RFC8956][this draft] 2462 4 Port [RFC8955][RFC8956][this draft] 2463 5 Destination Port [RFC8955][RFC8956][this draft] 2464 6 Source Port [RFC8955][RFC8956][this draft] 2465 7 ICMP Type [v4 or v6] [RFC8955][RFC8956][this draft] 2466 8 ICMP Code [v4 or v6] [RFC8955][RFC8956][this draft] 2467 9 TCP Flags [v4] [RFC8955][RFC8956][this draft] 2468 10 Packet Length [RFC8955][RFC8956][this draft] 2469 11 DSCP marking [RFC8955][RFC8956][this draft] 2470 12 Fragment [RFC8955][RFC8956][This draft] 2471 13 Flow Label [RFC8956] [This draft] 2472 14 Partial SID {draft-ietf-idr-flowspec-srv6] 2473 [This draft] 2475 10.4. Filter IP component types 2477 IANA is requested to create the following two new registries on a new 2478 "Flow Specification v2 TLV types". 2480 Name: BGP FSv2 TLV types 2481 Reference: [this document] 2482 Registration Procedures: 0x01-0x3FFF Standards Action. 2484 Type Use Reference 2485 ----- --------------- --------------- 2486 0x00 Reserved [this document] 2487 0x01 IP traffic rules [this document] 2488 0x02 FSv2 Actions [this document] 2489 0x03 L2 traffic rules [this document] 2490 0x04 tunnel traffic rules [this document] 2491 0x05 SFC AFI filter rules [this document] 2492 0x06-0x3FFF Unassigned [this document] 2493 0x4000-0x7FFF Vendor specific [this document] 2494 0x8000- 2495 0xFFFFFFFF Reserved [this document] 2497 Name: BGP FSv2 Action types 2498 Reference: [this document] 2499 Registration Procedure: 0x01-0x3FFF Standards Action. 2501 Type Use Reference 2502 ----- --------------- --------------- 2503 0x00 Reserved [this document] 2504 0x01 Action Chain Operation (ACO) [this document] 2505 0x02 Traffic actions per 2506 interface group [this document] 2507 0x03 Unassigned [this document] 2508 0x04 Unassigned [this document] 2509 0x05 Unassigned [this document] 2510 0x06 traffic rate limited by bytes [this document] 2511 0x07 traffic action (terminal/sample)[this document] 2512 0x08 redirect IPv4 [this document] 2513 0x09 mark DSCP value [this document] 2514 0x0a associate L2 Information [this document] 2515 0x0b associate E-Tree Information [this document] 2516 0xoc traffic rate limited by packets [this document] 2517 0x0D Redirect to IPv6 [this document] 2518 0x0E Traffic insertion to SFC [this document] 2519 0x0F Redirect to indirection-iD [this document] 2520 0x10 unassigned [this document] 2521 0x11 unassigned [this document] 2522 0x12 unassigned [this document] 2523 0x13 unassigned [this document] 2524 0x14 unassigned [this document] 2525 0x15 unassigned [this document] 2526 0x16 VLAN action [this document] 2527 0x17 TIPD action [this document] 2528 0x18- 2529 0x3ff Unassigned [this document] 2530 0x4000- 2531 0x7fff Vendor assigned [this document] 2532 0xc800- 2533 0xFFFFFFFFF [this document] 2535 11. Security Considerations 2537 The use of ROA improves on [RFC8955] by checking to see of the route 2538 origination. This check can improve the validation sequence for a 2539 multiple-AS environment. 2541 >The use of BGPSEC [RFC8205] to secure the packet can increase 2542 security of BGP flow specification information sent in the packet. 2544 The use of the reduced validation within an AS [RFC9117] can provide 2545 adequate validation for distribution of flow specification within an 2546 single autonomous system for prevention of DDOS. 2548 Distribution of flow filters may provide insight into traffic being 2549 sent within an AS, but this information should be composite 2550 information that does not reveal the traffic patterns of individuals. 2552 12. References 2554 12.1. Normative References 2556 [I-D.ietf-idr-flowspec-interfaceset] 2557 Litkowski, S., Simpson, A., Patel, K., Haas, J., and L. 2558 Yong, "Applying BGP flowspec rules on a specific interface 2559 set", Work in Progress, Internet-Draft, draft-ietf-idr- 2560 flowspec-interfaceset-05, 18 November 2019, 2561 . 2564 [I-D.ietf-idr-flowspec-l2vpn] 2565 Hao, W., Eastlake, D. E., Litkowski, S., and S. Zhuang, 2566 "BGP Dissemination of L2 Flow Specification Rules", Work 2567 in Progress, Internet-Draft, draft-ietf-idr-flowspec- 2568 l2vpn-17, 12 May 2021, . 2571 [I-D.ietf-idr-flowspec-nvo3] 2572 Eastlake, D., Weiguo, H., Zhuang, S., Li, Z., and R. Gu, 2573 "BGP Dissemination of Flow Specification Rules for 2574 Tunneled Traffic", Work in Progress, Internet-Draft, 2575 draft-ietf-idr-flowspec-nvo3-14, 15 August 2021, 2576 . 2579 [I-D.ietf-idr-flowspec-path-redirect] 2580 Velde, G. V. D., Patel, K., and Z. Li, "Flowspec 2581 Indirection-id Redirect", Work in Progress, Internet- 2582 Draft, draft-ietf-idr-flowspec-path-redirect-11, 26 May 2583 2020, . 2586 [I-D.ietf-idr-flowspec-srv6] 2587 Li, Z., Li, L., Chen, H., Loibl, C., Mishra, G. S., Fan, 2588 Y., Zhu, Y., Liu, L., and X. Liu, "BGP Flow Specification 2589 for SRv6", Work in Progress, Internet-Draft, draft-ietf- 2590 idr-flowspec-srv6-00, 8 October 2021, 2591 . 2594 [I-D.ietf-idr-wide-bgp-communities] 2595 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 2596 and P. Jakma, "BGP Community Container Attribute", Work in 2597 Progress, Internet-Draft, draft-ietf-idr-wide-bgp- 2598 communities-05, 2 July 2018, 2599 . 2602 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2603 DOI 10.17487/RFC0791, September 1981, 2604 . 2606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2607 Requirement Levels", BCP 14, RFC 2119, 2608 DOI 10.17487/RFC2119, March 1997, 2609 . 2611 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2612 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2613 DOI 10.17487/RFC4271, January 2006, 2614 . 2616 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 2617 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 2618 February 2006, . 2620 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2621 "Multiprotocol Extensions for BGP-4", RFC 4760, 2622 DOI 10.17487/RFC4760, January 2007, 2623 . 2625 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 2626 System Confederations for BGP", RFC 5065, 2627 DOI 10.17487/RFC5065, August 2007, 2628 . 2630 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 2631 Origin Authorizations (ROAs)", RFC 6482, 2632 DOI 10.17487/RFC6482, February 2012, 2633 . 2635 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 2636 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 2637 March 2014, . 2639 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2640 Patel, "Revised Error Handling for BGP UPDATE Messages", 2641 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2642 . 2644 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2645 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2646 May 2017, . 2648 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 2649 Bacher, "Dissemination of Flow Specification Rules", 2650 RFC 8955, DOI 10.17487/RFC8955, December 2020, 2651 . 2653 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 2654 "Dissemination of Flow Specification Rules for IPv6", 2655 RFC 8956, DOI 10.17487/RFC8956, December 2020, 2656 . 2658 [RFC9015] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 2659 Jalil, "BGP Control Plane for the Network Service Header 2660 in Service Function Chaining", RFC 9015, 2661 DOI 10.17487/RFC9015, June 2021, 2662 . 2664 [RFC9117] Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. 2665 Mohapatra, "Revised Validation Procedure for BGP Flow 2666 Specifications", RFC 9117, DOI 10.17487/RFC9117, August 2667 2021, . 2669 12.2. Informative References 2671 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2672 and A. Bierman, Ed., "Network Configuration Protocol 2673 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2674 . 2676 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2677 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2678 . 2680 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 2681 Specification", RFC 8205, DOI 10.17487/RFC8205, September 2682 2017, . 2684 [RFC8206] George, W. and S. Murphy, "BGPsec Considerations for 2685 Autonomous System (AS) Migration", RFC 8206, 2686 DOI 10.17487/RFC8206, September 2017, 2687 . 2689 Authors' Addresses 2691 Susan Hares 2692 Hickory Hill Consulting 2693 7453 Hickory Hill 2694 Saline, MI 48176 2695 United States of America 2697 Email: shares@ndzh.com 2699 Donald Eastlake 2700 Futurewei Technologies 2701 2396 Panoramic Circle 2702 Apopka, FL 32703 2703 United States of America 2705 Phone: +1-508-333-2270 2706 Email: d3e3e3@gmail.com 2708 Chaitanya Yadlapalli 2709 ATT 2710 United States of America 2712 Email: cy098d@att.com 2714 Sven Maduschke 2715 Verizon 2716 Germany 2718 Email: sven.maduschke@de.verizon.com