idnits 2.17.1 draft-ietf-idr-rfc5575bis-19.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC7674, but the abstract doesn't seem to directly say this. It does mention RFC7674 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC5575, but the abstract doesn't seem to directly say this. It does mention RFC5575 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2020) is 1561 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) -- Looks like a reference, but probably isn't: '137' on line 654 -- Looks like a reference, but probably isn't: '139' on line 654 -- Looks like a reference, but probably isn't: '1' on line 1592 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-10 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 7674 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group C. Loibl 3 Internet-Draft Next Layer Communications 4 Obsoletes: 5575,7674 (if approved) S. Hares 5 Intended status: Standards Track Huawei 6 Expires: July 20, 2020 R. Raszuk 7 Bloomberg LP 8 D. McPherson 9 Verisign 10 M. Bacher 11 T-Mobile Austria 12 January 17, 2020 14 Dissemination of Flow Specification Rules 15 draft-ietf-idr-rfc5575bis-19 17 Abstract 19 This document defines a Border Gateway Protocol Network Layer 20 Reachability Information (BGP NLRI) encoding format that can be used 21 to distribute traffic Flow Specifications. This allows the routing 22 system to propagate information regarding more specific components of 23 the traffic aggregate defined by an IP destination prefix. 25 It also specifies BGP Extended Community encoding formats, that can 26 be used to propagate Traffic Filtering Actions along with the Flow 27 Specification NLRI. Those Traffic Filtering Actions encode actions a 28 routing system can take if the packet matches the Flow Specification. 30 Additionally, it defines two applications of that encoding format: 31 one that can be used to automate inter-domain coordination of traffic 32 filtering, such as what is required in order to mitigate 33 (distributed) denial-of-service attacks, and a second application to 34 provide traffic filtering in the context of a BGP/MPLS VPN service. 35 Other applications (ie. centralized control of traffic in a SDN or 36 NFV context) are also possible. Other documents may specify Flow 37 Specification extensions. 39 The information is carried via BGP, thereby reusing protocol 40 algorithms, operational experience, and administrative processes such 41 as inter-provider peering agreements. 43 This document obsoletes both RFC5575 and RFC7674. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on July 20, 2020. 62 Copyright Notice 64 Copyright (c) 2020 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Definitions of Terms Used in This Memo . . . . . . . . . . . 5 81 3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 5 82 4. Dissemination of IPv4 Flow Specification Information . . . . 6 83 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7 84 4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7 85 4.2.1. Operators . . . . . . . . . . . . . . . . . . . . . . 8 86 4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 9 87 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 14 88 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 16 89 5.1. Ordering of Flow Specifications . . . . . . . . . . . . . 17 90 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 18 91 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 19 92 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 20 93 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type 94 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 21 96 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 22 97 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 22 98 7.6. Interaction with other Filtering Mechanisms in Routers . 23 99 7.7. Considerations on Traffic Filtering Action Interference . 23 100 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 24 101 9. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25 102 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25 103 11. Future NLRI Extensions . . . . . . . . . . . . . . . . . . . 25 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 105 12.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 26 106 12.2. Flow Component Definitions . . . . . . . . . . . . . . . 26 107 12.3. Extended Community Flow Specification Actions . . . . . 27 108 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 109 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 110 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 111 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 16.1. Normative References . . . . . . . . . . . . . . . . . . 32 113 16.2. Informative References . . . . . . . . . . . . . . . . . 34 114 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 115 Appendix A. Python code: flow_rule_cmp . . . . . . . . . . . . . 35 116 Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 36 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 119 1. Introduction 121 This document obsoletes both 122 "Dissemination of Flow Specification Rules" [RFC5575] and 123 "Clarification of the Flowspec Redirect Extended Community"[RFC7674]. 125 Modern IP routers contain both the capability to forward traffic 126 according to IP prefixes as well as to classify, shape, rate limit, 127 filter, or redirect packets based on administratively defined 128 policies. These traffic policy mechanisms allow the operator to 129 define match rules that operate on multiple fields of the packet 130 header. Actions such as the ones described above can be associated 131 with each rule. 133 The n-tuple consisting of the matching criteria defines an aggregate 134 traffic Flow Specification. The matching criteria can include 135 elements such as source and destination address prefixes, IP 136 protocol, and transport protocol port numbers. 138 Section 4 of this document defines a general procedure to encode Flow 139 Specification for aggregated traffic flows so that they can be 140 distributed as a BGP [RFC4271] NLRI. Additionally, Section 7 of this 141 document defines the required Traffic Filtering Actions BGP Extended 142 Communities and mechanisms to use BGP for intra- and inter-provider 143 distribution of traffic filtering rules to filter (distributed) 144 denial-of-service (DoS) attacks. 146 By expanding routing information with Flow Specifications, the 147 routing system can take advantage of the ACL (Access Control List) or 148 firewall capabilities in the router's forwarding path. Flow 149 Specifications can be seen as more specific routing entries to a 150 unicast prefix and are expected to depend upon the existing unicast 151 data information. 153 A Flow Specification received from an external autonomous system will 154 need to be validated against unicast routing before being accepted 155 (Section 6). The Flow Specification received from an internal BGP 156 peer within the same autonomous system [RFC4271] is assumed to have 157 been validated prior to transmission within the iBGP mesh of an 158 autonomous system. If the aggregate traffic flow defined by the 159 unicast destination prefix is forwarded to a given BGP peer, then the 160 local system can install more specific Flow Specifications that may 161 result in different forwarding behavior, as requested by this system. 163 From an operational perspective, the utilization of BGP as the 164 carrier for this information allows a network service provider to 165 reuse both internal route distribution infrastructure (e.g., route 166 reflector or confederation design) and existing external 167 relationships (e.g., inter-domain BGP sessions to a customer 168 network). 170 While it is certainly possible to address this problem using other 171 mechanisms, this solution has been utilized in deployments because of 172 the substantial advantage of being an incremental addition to already 173 deployed mechanisms. 175 In current deployments, the information distributed by this extension 176 is originated both manually as well as automatically. The latter by 177 systems that are able to detect malicious traffic flows. When 178 automated systems are used, care should be taken to ensure their 179 correctness as well as the limitations of the systems that receive 180 and process the advertised Flow Specifications (see also Section 13). 182 This specification defines required protocol extensions to address 183 most common applications of IPv4 unicast and VPNv4 unicast filtering. 184 The same mechanism can be reused and new match criteria added to 185 address similar filtering needs for other BGP address families such 186 as IPv6 families [I-D.ietf-idr-flow-spec-v6]. 188 2. Definitions of Terms Used in This Memo 190 AFI - Address Family Identifier. 192 AS - Autonomous System. 194 Loc-RIB - The Loc-RIB contains the routes that have been selected 195 by the local BGP speaker's Decision Process [RFC4271]. 197 NLRI - Network Layer Reachability Information. 199 PE - Provider Edge router. 201 RIB - Routing Information Base. 203 SAFI - Subsequent Address Family Identifier. 205 VRF - Virtual Routing and Forwarding instance. 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 209 "OPTIONAL" in this document are to be interpreted as described in BCP 210 14 [RFC2119] [RFC8174] when, and only when, they appear in all 211 capitals, as shown here. 213 3. Flow Specifications 215 A Flow Specification is an n-tuple consisting of several matching 216 criteria that can be applied to IP traffic. A given IP packet is 217 said to match the defined Flow Specification if it matches all the 218 specified criteria. This n-tuple is encoded into a BGP NLRI defined 219 below. 221 A given Flow Specification may be associated with a set of 222 attributes, depending on the particular application; such attributes 223 may or may not include reachability information (i.e., NEXT_HOP). 224 Well-known or AS-specific community attributes can be used to encode 225 a set of predetermined actions. 227 A particular application is identified by a specific (Address Family 228 Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair 229 [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs 230 should be treated independently from each other in order to assure 231 non-interference between distinct applications. 233 BGP itself treats the NLRI as a key to an entry in its databases. 234 Entries that are placed in the Loc-RIB are then associated with a 235 given set of semantics, which is application dependent. This is 236 consistent with existing BGP applications. For instance, IP unicast 237 routing (AFI=1, SAFI=1) and IP multicast reverse-path information 238 (AFI=1, SAFI=2) are handled by BGP without any particular semantics 239 being associated with them until installed in the Loc-RIB. 241 Standard BGP policy mechanisms, such as UPDATE filtering by NLRI 242 prefix as well as community matching and manipulation, must apply to 243 the Flow Specification defined NLRI-type, especially in an inter- 244 domain environment. Network operators can also control propagation 245 of such routing updates by enabling or disabling the exchange of a 246 particular (AFI, SAFI) pair on a given BGP peering session. 248 4. Dissemination of IPv4 Flow Specification Information 250 This document defines a Flow Specification NLRI type (Figure 1) that 251 may include several components such as destination prefix, source 252 prefix, protocol, ports, and others (see Section 4.2 below). 254 This NLRI information is encoded using MP_REACH_NLRI and 255 MP_UNREACH_NLRI attributes as defined in [RFC4760]. When advertising 256 Flow Specifications, the Length of Next Hop Network Address SHOULD be 257 set to 0. The Network Address of Next Hop field MUST be ignored. 259 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 260 one or more 2-tuples of the form . It consists 261 of a 1- or 2-octet length field followed by a variable-length NLRI 262 value. The length is expressed in octets. 264 +-------------------------------+ 265 | length (0xnn or 0xfnnn) | 266 +-------------------------------+ 267 | NLRI value (variable) | 268 +-------------------------------+ 270 Figure 1: Flow Specification NLRI for IPv4 272 Implementations wishing to exchange Flow Specification MUST use BGP's 273 Capability Advertisement facility to exchange the Multiprotocol 274 Extension Capability Code (Code 1) as defined in [RFC4760]. The 275 (AFI, SAFI) pair carried in the Multiprotocol Extension Capability 276 MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification, and (AFI=1, 277 SAFI=134) for VPNv4 Flow Specification. 279 The Flow Specification NLRI is considered a Typed NLRI in the sense 280 of Section 5.4 of [RFC7606]. See also Section 4.2 on unknown 281 component type handling. 283 4.1. Length Encoding 285 o If the NLRI length is smaller than 240 (0xf0 hex) octets, the 286 length field can be encoded as a single octet. 288 o Otherwise, it is encoded as an extended-length 2-octet value in 289 which the most significant nibble of the first byte is all ones. 291 In Figure 1 above, values less-than 240 are encoded using two hex 292 digits (0xnn). Values above 239 are encoded using 3 hex digits 293 (0xfnnn). The highest value that can be represented with this 294 encoding is 4095. For example the length value of 239 is encoded as 295 0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet). 297 4.2. NLRI Value Encoding 299 The Flow Specification NLRI value consists of a list of optional 300 components and is encoded as follows: 302 Encoding: <[component]+> 304 A specific packet is considered to match the Flow Specification when 305 it matches the intersection (AND) of all the components present in 306 the Flow Specification. 308 Components MUST follow strict type ordering by increasing numerical 309 order. A given component type may (exactly once) or may not be 310 present in the Flow Specification. If present, it MUST precede any 311 component of higher numeric type value. 313 All combinations of components within a single Flow Specification are 314 allowed. However, some combinations cannot match any packets (e.g. 315 "ICMP Type AND Port" will never match any packets), and thus SHOULD 316 NOT be propagated by BGP. 318 An advertisement containing an unknown Flow Specification component 319 type should be discarded as specified in Section 5.4 of [RFC7606]. 320 It needs to be pointed out that the encoding of the NLRI as a 2-tuple 321 allows to skip over a NLRI value (the NLRI that 322 value should be discarded). 324 Except for an unknown component type (see above), a NLRI value not 325 encoded as specified in Section 4.2 is considered malformed and error 326 handling according to Section 10 is performed. 328 4.2.1. Operators 330 Most of the components described below make use of comparison 331 operators. Which of the two operators is used is defined by the 332 components in Section 4.2.2. The operators are encoded as a single 333 octet. 335 4.2.1.1. Numeric Operator (numeric_op) 337 This operator is encoded as shown in Figure 2. 339 0 1 2 3 4 5 6 7 340 +---+---+---+---+---+---+---+---+ 341 | e | a | len | 0 |lt |gt |eq | 342 +---+---+---+---+---+---+---+---+ 344 Figure 2: Numeric Operator (numeric_op) 346 e - end-of-list bit: Set in the last {op, value} pair in the list. 348 a - AND bit: If unset, the previous term is logically ORed with the 349 current one. If set, the operation is a logical AND. In the 350 first operator byte of a sequence it SHOULD be encoded as unset 351 and and MUST be treated as always unset on decoding. The AND 352 operator has higher priority than OR for the purposes of 353 evaluating logical expressions. 355 len - length: The length of the value field for this operator given 356 as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), 8 357 (len=11) bytes. 359 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during 360 decoding 362 lt - less than comparison between data and value. 364 gt - greater than comparison between data and value. 366 eq - equality between data and value. 368 The bits lt, gt, and eq can be combined to produce common relational 369 operators such as "less or equal", "greater or equal", and "not equal 370 to" as shown in Table 1. 372 +----+----+----+-----------------------------------+ 373 | lt | gt | eq | Resulting operation | 374 +----+----+----+-----------------------------------+ 375 | 0 | 0 | 0 | false (independent of the value) | 376 | 0 | 0 | 1 | == (equal) | 377 | 0 | 1 | 0 | > (greater than) | 378 | 0 | 1 | 1 | >= (greater than or equal) | 379 | 1 | 0 | 0 | < (less than) | 380 | 1 | 0 | 1 | <= (less than or equal) | 381 | 1 | 1 | 0 | != (not equal value) | 382 | 1 | 1 | 1 | true (independent of the value) | 383 +----+----+----+-----------------------------------+ 385 Table 1: Comparison operation combinations 387 4.2.1.2. Bitmask Operator (bitmask_op) 389 This operator is encoded as shown in Figure 3. 391 0 1 2 3 4 5 6 7 392 +---+---+---+---+---+---+---+---+ 393 | e | a | len | 0 | 0 |not| m | 394 +---+---+---+---+---+---+---+---+ 396 Figure 3: Bitmask Operator (bitmask_op) 398 e, a, len - Most significant nibble: (end-of-list bit, AND bit, and 399 length field), as defined in the Numeric Operator format in 400 Section 4.2.1.1. 402 not - NOT bit: If set, logical negation of operation. 404 m - Match bit: If set, this is a bitwise match operation defined as 405 "(data AND value) == value"; if unset, (data AND value) evaluates 406 to TRUE if any of the bits in the value mask are set in the data 408 0 - all 0 bits: SHOULD be set to 0 on NLRI encoding, and MUST be 409 ignored during decoding 411 4.2.2. Components 413 The encoding of each of the components begins with a type field (1 414 octet) followed by a variable length parameter. The following 415 sections define component types and parameter encodings for the IPv4 416 IP layer and transport layer headers. IPv6 NLRI component types are 417 described in [I-D.ietf-idr-flow-spec-v6]. 419 4.2.2.1. Type 1 - Destination Prefix 421 Encoding: 423 Defines the destination prefix to match. The length and prefix 424 fields are encoded as in BGP UPDATE messages [RFC4271] 426 4.2.2.2. Type 2 - Source Prefix 428 Encoding: 430 Defines the source prefix to match. The length and prefix fields are 431 encoded as in BGP UPDATE messages [RFC4271] 433 4.2.2.3. Type 3 - IP Protocol 435 Encoding: 437 Contains a list of {numeric_op, value} pairs that are used to match 438 the IP protocol value byte in IP packet header (see [RFC0791] 439 Section 3.1). 441 This component uses the Numeric Operator (numeric_op) described in 442 Section 4.2.1.1. Type 3 component values SHOULD be encoded as single 443 byte (numeric_op len=00). 445 4.2.2.4. Type 4 - Port 447 Encoding: 449 Defines a list of {numeric_op, value} pairs that matches source OR 450 destination TCP/UDP ports (see [RFC0793] Section 3.1 and [RFC0768] 451 Section "Format"). This component matches if either the destination 452 port OR the source port of a IP packet matches the value. 454 This component uses the Numeric Operator (numeric_op) described in 455 Section 4.2.1.1. Type 4 component values SHOULD be encoded as 1- or 456 2-byte quantities (numeric_op len=00 or len=01). 458 In case of the presence of the port (destination-port, source-port) 459 component only TCP or UDP packets can match the entire Flow 460 Specification. The port component, if present, never matches when 461 the packet's IP protocol value is not 6 (TCP) or 17 (UDP), if the 462 packet is fragmented and this is not the first fragment, or if the 463 system is unable to locate the transport header. Different 464 implementations may or may not be able to decode the transport header 465 in the presence of IP options or Encapsulating Security Payload (ESP) 466 NULL [RFC4303] encryption. 468 4.2.2.5. Type 5 - Destination Port 470 Encoding: 472 Defines a list of {numeric_op, value} pairs used to match the 473 destination port of a TCP or UDP packet (see also [RFC0793] 474 Section 3.1 and [RFC0768] Section "Format"). 476 This component uses the Numeric Operator (numeric_op) described in 477 Section 4.2.1.1. Type 5 component values SHOULD be encoded as 1- or 478 2-byte quantities (numeric_op len=00 or len=01). 480 The last paragraph of Section 4.2.2.4 also applies to this component. 482 4.2.2.6. Type 6 - Source Port 484 Encoding: 486 Defines a list of {numeric_op, value} pairs used to match the source 487 port of a TCP or UDP packet (see also [RFC0793] Section 3.1 and 488 [RFC0768] Section "Format"). 490 This component uses the Numeric Operator (numeric_op) described in 491 Section 4.2.1.1. Type 6 component values SHOULD be encoded as 1- or 492 2-byte quantities (numeric_op len=00 or len=01). 494 The last paragraph of Section 4.2.2.4 also applies to this component. 496 4.2.2.7. Type 7 - ICMP type 498 Encoding: 500 Defines a list of {numeric_op, value} pairs used to match the type 501 field of an ICMP packet (see also [RFC0792] Section "Message 502 Formats"). 504 This component uses the Numeric Operator (numeric_op) described in 505 Section 4.2.1.1. Type 7 component values SHOULD be encoded as single 506 byte (numeric_op len=00). 508 In case of the presence of the ICMP type (code) component only ICMP 509 packets can match the entire Flow Specification. The ICMP type 510 (code) component, if present, never matches when the packet's IP 511 protocol value is not 1 (ICMP), if the packet is fragmented and this 512 is not the first fragment, or if the system is unable to locate the 513 transport header. Different implementations may or may not be able 514 to decode the transport header in the presence of IP options or 515 Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. 517 4.2.2.8. Type 8 - ICMP code 519 Encoding: 521 Defines a list of {numeric_op, value} pairs used to match the code 522 field of an ICMP packet (see also [RFC0792] Section "Message 523 Formats"). 525 This component uses the Numeric Operator (numeric_op) described in 526 Section 4.2.1.1. Type 8 component values SHOULD be encoded as single 527 byte (numeric_op len=00). 529 The last paragraph of Section 4.2.2.7 also applies to this component. 531 4.2.2.9. Type 9 - TCP flags 533 Encoding: 535 Defines a list of {bitmask_op, bitmask} pairs used to match TCP 536 Control Bits (see also [RFC0793] Section 3.1). 538 This component uses the Bitmask Operator (bitmask_op) described in 539 Section 4.2.1.2. Type 9 component bitmasks MUST be encoded as 1- or 540 2-byte bitmask (bitmask_op len=00 or len=01). 542 When a single byte (bitmask_op len=00) is specified, it matches byte 543 14 of the TCP header (see also [RFC0793] Section 3.1), which contains 544 the TCP Control Bits. When a 2-byte (bitmask_op len=01) encoding is 545 used, it matches bytes 13 and 14 of the TCP header with the data 546 offset (leftmost 4 bits) always treated as 0. 548 In case of the presence of the TCP flags component only TCP packets 549 can match the entire Flow Specification. The TCP flags component, if 550 present, never matches when the packet's IP protocol value is not 6 551 (TCP), if the packet is fragmented and this is not the first 552 fragment, or if the system is unable to locate the transport header. 553 Different implementations may or may not be able to decode the 554 transport header in the presence of IP options or Encapsulating 555 Security Payload (ESP) NULL [RFC4303] encryption. 557 4.2.2.10. Type 10 - Packet length 559 Encoding: 561 Defines a list of {numeric_op, value} pairs used to match on the 562 total IP packet length (excluding Layer 2 but including IP header). 564 This component uses the Numeric Operator (numeric_op) described in 565 Section 4.2.1.1. Type 10 component values SHOULD be encoded as 1- or 566 2-byte quantities (numeric_op len=00 or len=01). 568 4.2.2.11. Type 11 - DSCP (Diffserv Code Point) 570 Encoding: 572 Defines a list of {numeric_op, value} pairs used to match the 6-bit 573 DSCP field (see also [RFC2474]). 575 This component uses the Numeric Operator (numeric_op) described in 576 Section 4.2.1.1. Type 11 component values MUST be encoded as single 577 byte (numeric_op len=00). 579 The six least significant bits contain the DSCP value. All other 580 bits SHOULD be treated as 0. 582 4.2.2.12. Type 12 - Fragment 584 Encoding: 586 Defines a list of {bitmask_op, bitmask} pairs used to match specific 587 IP fragments. 589 This component uses the Bitmask Operator (bitmask_op) described in 590 Section 4.2.1.2. The Type 12 component bitmask MUST be encoded as 591 single byte bitmask (bitmask_op len=00). 593 0 1 2 3 4 5 6 7 594 +---+---+---+---+---+---+---+---+ 595 | 0 | 0 | 0 | 0 |LF |FF |IsF|DF | 596 +---+---+---+---+---+---+---+---+ 598 Figure 4: Fragment Bitmask Operand 600 Bitmask values: 602 DF - Don't fragment - match if [RFC0791] IP Header Flags Bit-1 (DF) 603 is 1 605 IsF - Is a fragment - match if [RFC0791] IP Header Fragment Offset 606 is not 0 608 FF - First fragment - match if [RFC0791] IP Header Fragment Offset 609 is 0 AND Flags Bit-2 (MF) is 1 611 LF - Last fragment - match if [RFC0791] IP Header Fragment Offset is 612 not 0 AND Flags Bit-2 (MF) is 0 614 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during 615 decoding 617 4.3. Examples of Encodings 619 4.3.1. Example 1 621 An example of a Flow Specification NLRI encoding for: "all packets to 622 192.0.2.0/24 and TCP port 25". 624 +--------+----------------+----------+----------+ 625 | length | destination | protocol | port | 626 +--------+----------------+----------+----------+ 627 | 0x0b | 01 18 c0 00 02 | 03 81 06 | 04 81 19 | 628 +--------+----------------+----------+----------+ 630 Decoded: 632 +-------+------------+-------------------------------+ 633 | Value | | | 634 +-------+------------+-------------------------------+ 635 | 0x0b | length | 11 octets (len<240 1-octet) | 636 | 0x01 | type | Type 1 - Destination Prefix | 637 | 0x18 | length | 24 bit | 638 | 0xc0 | prefix | 192 | 639 | 0x00 | prefix | 0 | 640 | 0x02 | prefix | 2 | 641 | 0x03 | type | Type 3 - IP Protocol | 642 | 0x81 | numeric_op | end-of-list, value size=1, == | 643 | 0x06 | value | 6 (TCP) | 644 | 0x04 | type | Type 4 - Port | 645 | 0x81 | numeric_op | end-of-list, value size=1, == | 646 | 0x19 | value | 25 | 647 +-------+------------+-------------------------------+ 649 This constitutes a NLRI with a NLRI length of 11 octets. 651 4.3.2. Example 2 653 An example of a Flow Specification NLRI encoding for: "all packets to 654 192.0.2.0/24 from 203.0.113.0/24 and port {range [137, 139] or 655 8080}". 657 +--------+----------------+----------------+-------------------------+ 658 | length | destination | source | port | 659 +--------+----------------+----------------+-------------------------+ 660 | 0x12 | 01 18 c0 00 02 | 02 18 cb 00 71 | 04 03 89 45 8b 91 1f 90 | 661 +--------+----------------+----------------+-------------------------+ 663 Decoded: 665 +--------+------------+-------------------------------+ 666 | Value | | | 667 +--------+------------+-------------------------------+ 668 | 0x12 | length | 18 octets (len<240 1-octet) | 669 | 0x01 | type | Type 1 - Destination Prefix | 670 | 0x18 | length | 24 bit | 671 | 0xc0 | prefix | 192 | 672 | 0x00 | prefix | 0 | 673 | 0x02 | prefix | 2 | 674 | 0x02 | type | Type 2 - Source Prefix | 675 | 0x18 | length | 24 bit | 676 | 0xcb | prefix | 203 | 677 | 0x00 | prefix | 0 | 678 | 0x71 | prefix | 113 | 679 | 0x04 | type | Type 4 - Port | 680 | 0x03 | numeric_op | value size=1, >= | 681 | 0x89 | value | 137 | 682 | 0x45 | numeric_op | "AND", value size=1, <= | 683 | 0x8b | value | 139 | 684 | 0x91 | numeric_op | end-of-list, value size=2, == | 685 | 0x1f90 | value | 8080 | 686 +--------+------------+-------------------------------+ 688 This constitutes a NLRI with a NLRI length of 18 octets. 690 4.3.3. Example 3 692 An example of a Flow Specification NLRI encoding for: "all packets to 693 192.0.2.1/32 and fragment { DF or FF } (matching packet with DF bit 694 set or First Fragments) 696 +--------+-------------------+----------+ 697 | length | destination | fragment | 698 +--------+-------------------+----------+ 699 | 0x09 | 01 20 c0 00 02 01 | 0c 80 05 | 700 +--------+-------------------+----------+ 702 Decoded: 704 +-------+------------+------------------------------+ 705 | Value | | | 706 +-------+------------+------------------------------+ 707 | 0x09 | length | 9 octets (len<240 1-octet) | 708 | 0x01 | type | Type 1 - Destination Prefix | 709 | 0x20 | length | 32 bit | 710 | 0xc0 | prefix | 192 | 711 | 0x00 | prefix | 0 | 712 | 0x02 | prefix | 2 | 713 | 0x01 | prefix | 1 | 714 | 0x0c | type | Type 12 - Fragment | 715 | 0x80 | bitmask_op | end-of-list, value size=1 | 716 | 0x05 | bitmask | DF=1, FF=1 | 717 +-------+------------+------------------------------+ 719 This constitutes a NLRI with a NLRI length of 9 octets. 721 5. Traffic Filtering 723 Traffic filtering policies have been traditionally considered to be 724 relatively static. Limitations of these static mechanisms caused 725 this new dynamic mechanism to be designed for the three new 726 applications of traffic filtering: 728 o Prevention of traffic-based, denial-of-service (DOS) attacks. 730 o Traffic filtering in the context of BGP/MPLS VPN service. 732 o Centralized traffic control for SDN/NFV networks. 734 These applications require coordination among service providers and/ 735 or coordination among the AS within a service provider. 737 The Flow Specification NLRI defined in Section 4 conveys information 738 about traffic filtering rules for traffic that should be discarded or 739 handled in a manner specified by a set of pre-defined actions (which 740 are defined in BGP Extended Communities). This mechanism is 741 primarily designed to allow an upstream autonomous system to perform 742 inbound filtering in their ingress routers of traffic that a given 743 downstream AS wishes to drop. 745 In order to achieve this goal, this draft specifies two application 746 specific NLRI identifiers that provide traffic filters, and a set of 747 actions encoding in BGP Extended Communities. The two application 748 specific NLRI identifiers are: 750 o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with 751 specific semantic rules for IPv4 routes, and 753 o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which 754 can be used to propagate traffic filtering information in a BGP/ 755 MPLS VPN environment. 757 Encoding of the NLRI is described in Section 4 for IPv4 Flow 758 Specification and in Section 8 for VPNv4 Flow Specification. The 759 filtering actions are described in Section 7. 761 5.1. Ordering of Flow Specifications 763 More than one Flow Specification may match a particular traffic flow. 764 Thus, it is necessary to define the order in which Flow 765 Specifications get matched and actions being applied to a particular 766 traffic flow. This ordering function is such that it does not depend 767 on the arrival order of the Flow Specification via BGP and thus is 768 consistent in the network. 770 The relative order of two Flow Specifications is determined by 771 comparing their respective components. The algorithm starts by 772 comparing the left-most components (lowest component type value) of 773 the Flow Specifications. If the types differ, the Flow Specification 774 with lowest numeric type value has higher precedence (and thus will 775 match before) than the Flow Specification that doesn't contain that 776 component type. If the component types are the same, then a type- 777 specific comparison is performed (see below) if the types are equal 778 the algorithm continues with the next component. 780 For IP prefix values (IP destination or source prefix): If one of the 781 two prefixes to compare is a more specific prefix of the other, the 782 more specific prefix has higher precedence. Otherwise the one with 783 the lowest IP value has higher precedence. 785 For all other component types, unless otherwise specified, the 786 comparison is performed by comparing the component data as a binary 787 string using the memcmp() function as defined by [ISO_IEC_9899]. For 788 strings with equal lengths the lowest string (memcmp) has higher 789 precedence. For strings of different lengths, the common prefix is 790 compared. If the common prefix is not equal the string with the 791 lowest prefix has higher precedence. If the common prefix is equal, 792 the longest string is considered to have higher precedence than the 793 shorter one. 795 The code in Appendix A shows a Python3 implementation of the 796 comparison algorithm. The full code was tested with Python 3.6.3 and 797 can be obtained at https://github.com/stoffi92/flowspec-cmp [1]. 799 6. Validation Procedure 801 Flow Specifications received from a BGP peer that are accepted in the 802 respective Adj-RIB-In are used as input to the route selection 803 process. Although the forwarding attributes of two routes for the 804 same Flow Specification prefix may be the same, BGP is still required 805 to perform its path selection algorithm in order to select the 806 correct set of attributes to advertise. 808 The first step of the BGP Route Selection procedure (Section 9.1.2 of 809 [RFC4271] is to exclude from the selection procedure routes that are 810 considered non-feasible. In the context of IP routing information, 811 this step is used to validate that the NEXT_HOP attribute of a given 812 route is resolvable. 814 The concept can be extended, in the case of the Flow Specification 815 NLRI, to allow other validation procedures. 817 The validation process described below validates Flow Specifications 818 against unicast routes received over the same AFI but the associated 819 unicast routing information SAFI: 821 Flow Specification received over SAFI=133 will be validated 822 against routes received over SAFI=1 824 Flow Specification received over SAFI=134 will be validated 825 against routes received over SAFI=128 827 By default a Flow Specification NLRI MUST be validated such that it 828 is considered feasible if and only if all of the below is true: 830 a) A destination prefix component is embedded in the Flow 831 Specification. 833 b) The originator of the Flow Specification matches the originator 834 of the best-match unicast route for the destination prefix 835 embedded in the Flow Specification (this is the unicast route with 836 the longest possible prefix length covering the destination prefix 837 embedded in the Flow Specification). 839 c) There are no more specific unicast routes, when compared with 840 the flow destination prefix, that have been received from a 841 different neighboring AS than the best-match unicast route, which 842 has been determined in rule b). 844 However, rule a) MAY be relaxed by explicit configuration, permitting 845 Flow Specifications that include no destination prefix component. If 846 such is the case, rules b) and c) are moot and MUST be disregarded. 848 By originator of a BGP route, we mean either the address of the 849 originator in the ORIGINATOR_ID Attribute [RFC4456], or the source IP 850 address of the BGP peer, if this path attribute is not present. 852 BGP implementations MUST also enforce that the AS_PATH attribute of a 853 route received via the External Border Gateway Protocol (eBGP) 854 contains the neighboring AS in the left-most position of the AS_PATH 855 attribute. While this rule is optional in the BGP specification, it 856 becomes necessary to enforce it for security reasons. 858 The best-match unicast route may change over the time independently 859 of the Flow Specification NLRI. Therefore, a revalidation of the 860 Flow Specification NLRI MUST be performed whenever unicast routes 861 change. Revalidation is defined as retesting that clause a and 862 clause b above are true. 864 Explanation: 866 The underlying concept is that the neighboring AS that advertises the 867 best unicast route for a destination is allowed to advertise Flow 868 Specification information that conveys a more or equally specific 869 destination prefix. Thus, as long as there are no more specific 870 unicast routes, received from a different neighboring AS, which would 871 be affected by that Flow Specification. 873 The neighboring AS is the immediate destination of the traffic 874 described by the Flow Specification. If it requests these flows to 875 be dropped, that request can be honored without concern that it 876 represents a denial of service in itself. Supposedly, the traffic is 877 being dropped by the downstream autonomous system, and there is no 878 added value in carrying the traffic to it. 880 7. Traffic Filtering Actions 882 This document defines a minimum set of Traffic Filtering Actions that 883 it standardizes as BGP extended community values [RFC4360]. This is 884 not meant to be an inclusive list of all the possible actions, but 885 only a subset that can be interpreted consistently across the 886 network. Additional actions can be defined as either requiring 887 standards or as vendor specific. 889 The default action for a matching Flow Specification is to accept the 890 packet (treat the packet according to the normal forwarding behaviour 891 of the system). 893 This document defines the following extended communities values shown 894 in Table 2 in the form 0xttss where tt indicates the type and ss 895 indicates the sub-type of the extended community. Encodings for 896 these extended communities are described below. 898 +--------------+--------------------------+-------------------------+ 899 | community | action | encoding | 900 | 0xttss | | | 901 +--------------+--------------------------+-------------------------+ 902 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte | 903 | | (Section 7.1) | float | 904 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte | 905 | | (Section 7.1) | float | 906 | 0x8007 | traffic-action (Section | bitmask | 907 | | 7.3) | | 908 | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet | 909 | | (Section 7.4) | value | 910 | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 address, | 911 | | (Section 7.4) | 2-octet value | 912 | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet | 913 | | (Section 7.4) | value | 914 | 0x8009 | traffic-marking (Section | DSCP value | 915 | | 7.5) | | 916 +--------------+--------------------------+-------------------------+ 918 Table 2: Traffic Filtering Action Extended Communities 920 Multiple Traffic Filtering Actions defined in this document may be 921 present for a single Flow Specification and SHOULD be applied to the 922 traffic flow (for example traffic-rate-bytes and rt-redirect can be 923 applied to packets at the same time). If not all of the Traffic 924 Filtering Actions can be applied to a traffic flow they should be 925 treated as interfering Traffic filtering actions (see below). 927 Some Traffic Filtering Actions may interfere with each other even 928 contradict. Section 7.7 of this document provides general 929 considerations on such Traffic Filtering Action interference. Any 930 additional definition of Traffic Filtering Actions SHOULD specify the 931 action to take if those Traffic Filtering Actions interfere (also 932 with existing Traffic Filtering Actions). 934 All Traffic Filtering Actions are specified as transitive BGP 935 Extended Communities. 937 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 939 The traffic-rate-bytes extended community uses the following extended 940 community encoding: 942 The first two octets carry the 2-octet id, which can be assigned from 943 a 2-byte AS number. When a 4-byte AS number is locally present, the 944 2 least significant bytes of such an AS number can be used. This 945 value is purely informational and SHOULD NOT be interpreted by the 946 implementation. 948 The remaining 4 octets carry the maximum rate information in IEEE 949 floating point [IEEE.754.1985] format, units being bytes per second. 950 A traffic-rate of 0 should result on all traffic for the particular 951 flow to be discarded. On encoding the traffic-rate MUST NOT be 952 negative. On decoding negative values MUST be treated as zero 953 (discard all traffic). 955 Interferes with: No other BGP Flow Specification Traffic Filtering 956 Action in this document. 958 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD 960 The traffic-rate-packets extended community uses the same encoding as 961 the traffic-rate-bytes extended community. The floating point value 962 carries the maximum packet rate in packets per second. A traffic- 963 rate-packets of 0 should result in all traffic for the particular 964 flow to be discarded. On encoding the traffic-rate-packets MUST NOT 965 be negative. On decoding negative values MUST be treated as zero 966 (discard all traffic). 968 Interferes with: No other BGP Flow Specification Traffic Filtering 969 Action in this document. 971 7.3. Traffic-action (traffic-action) sub-type 0x07 973 The traffic-action extended community consists of 6 bytes of which 974 only the 2 least significant bits of the 6th byte (from left to 975 right) are defined by this document as shown in Figure 5. 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Traffic Action Field | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Tr. Action Field (cont.) |S|T| 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 Figure 5: Traffic-action Extended Community Encoding 987 where S and T are defined as: 989 o T: Terminal Action (bit 47): When this bit is set, the traffic 990 filtering engine will evaluate any subsequent Flow Specifications 991 (as defined by the ordering procedure Section 5.1). If not set, 992 the evaluation of the traffic filters stops when this Flow 993 Specification is evaluated. 995 o S: Sample (bit 46): Enables traffic sampling and logging for this 996 Flow Specification (only effective when set). 998 o Traffic Action Field: Other Traffic Action Field (see Section 12) 999 bits unused in this specification. These bits SHOULD be set to 0 1000 on encoding, and MUST be ignored during decoding. 1002 The use of the Terminal Action (bit 47) may result in more than one 1003 Flow Specification matching a particular traffic flow. All the 1004 Traffic Filtering Actions from these Flow Specifications shall be 1005 collected and applied. In case of interfering Traffic Filtering 1006 Actions it is an implementation decision which Traffic Filtering 1007 Actions are selected. See also Section 7.7. 1009 Interferes with: No other BGP Flow Specification Traffic Filtering 1010 Action in this document. 1012 7.4. RT Redirect (rt-redirect) sub-type 0x08 1014 The redirect extended community allows the traffic to be redirected 1015 to a VRF routing instance that lists the specified route-target in 1016 its import policy. If several local instances match this criteria, 1017 the choice between them is a local matter (for example, the instance 1018 with the lowest Route Distinguisher value can be elected). 1020 This Extended Community allows 3 different encodings formats for the 1021 route-target (type 0x80, 0x81, 0x82). It uses the same encoding as 1022 the Route Target Extended Community in Sections 3.1 (type 0x80: 1023 2-octet AS, 4-octet value), 3.2 (type 0x81: 4-octet IPv4 address, 1024 2-octet value) and 4 of [RFC4360] and Section 2 (type 0x82: 4-octet 1025 AS, 2-octet value) of [RFC5668] with the high-order octet of the Type 1026 field 0x80, 0x81, 0x82 respectively and the low-order of the Type 1027 field (Sub-Type) always 0x08. 1029 Interferes with: No other BGP Flow Specification Traffic Filtering 1030 Action in this document. 1032 7.5. Traffic Marking (traffic-marking) sub-type 0x09 1034 The traffic marking extended community instructs a system to modify 1035 the DSCP bits in the IP header ([RFC2474] Section 3) of a transiting 1036 IP packet to the corresponding value encoded in the 6 least 1037 significant bits of the extended community value as shown in 1038 Figure 6. 1040 The extended is encoded as follows: 1042 0 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | reserved | reserved | reserved | reserved | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | reserved | r.| DSCP | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 Figure 6: Traffic Marking Extended Community Encoding 1052 o DSCP: new DSCP value for the transiting IP packet. 1054 o reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored 1055 during decoding. 1057 Interferes with: No other BGP Flow Specification Traffic Filtering 1058 Action in this document. 1060 7.6. Interaction with other Filtering Mechanisms in Routers 1062 Implementations should provide mechanisms that map an arbitrary BGP 1063 community value (normal or extended) to Traffic Filtering Actions 1064 that require different mappings in different systems in the network. 1065 For instance, providing packets with a worse-than-best-effort, per- 1066 hop behavior is a functionality that is likely to be implemented 1067 differently in different systems and for which no standard behavior 1068 is currently known. Rather than attempting to define it here, this 1069 can be accomplished by mapping a user-defined community value to 1070 platform-/network-specific behavior via user configuration. 1072 7.7. Considerations on Traffic Filtering Action Interference 1074 Since Traffic Filtering Actions are represented as BGP extended 1075 community values, Traffic Filtering Actions may interfere with each 1076 other (e.g. there may be more than one conflicting traffic-rate-bytes 1077 Traffic Filtering Action associated with a single Flow 1078 Specification). Traffic Filtering Action interference has no impact 1079 on BGP propagation of Flow Specifications (all communities are 1080 propagated according to policies). 1082 If a Flow Specification associated with interfering Traffic Filtering 1083 Actions is selected for packet forwarding, it is an implementation 1084 decision which of the interfering Traffic Filtering Actions are 1085 selected. Implementors of this specification SHOULD document the 1086 behaviour of their implementation in such cases. 1088 Operators are encouraged to make use of the BGP policy framework 1089 supported by their implementation in order to achieve a predictable 1090 behaviour (ie. match - replace - delete communities on administrative 1091 boundaries). See also Section 13. 1093 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 1095 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1096 MPLS IP VPN [RFC4364] control plane, may have different traffic 1097 filtering requirements than Internet service providers. But also 1098 Internet service providers may use those VPNs for scenarios like 1099 having the Internet routing table in a VRF, resulting in the same 1100 traffic filtering requirements as defined for the global routing 1101 table environment within this document. This document defines an 1102 additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used 1103 to propagate Flow Specification in a BGP/MPLS VPN environment. 1105 The NLRI format for this address family consists of a fixed-length 1106 Route Distinguisher field (8 bytes) followed by the Flow 1107 Specification NLRI value (Section 4.2). The NLRI length field shall 1108 include both the 8 bytes of the Route Distinguisher as well as the 1109 subsequent Flow Specification NLRI value. The resulting encoding is 1110 shown in Figure 7. 1112 +------------------------------+ 1113 | length (0xnn or 0xfn nn) | 1114 +------------------------------+ 1115 | Route Distinguisher (8 bytes)| 1116 +------------------------------+ 1117 | NLRI value (variable) | 1118 +------------------------------+ 1120 Figure 7: Flow Specification NLRI for MPLS 1122 Propagation of this NLRI is controlled by matching Route Target 1123 extended communities associated with the BGP path advertisement with 1124 the VRF import policy, using the same mechanism as described in BGP/ 1125 MPLS IP VPNs [RFC4364]. 1127 Flow Specifications received via this NLRI apply only to traffic that 1128 belongs to the VRF(s) in which it is imported. By default, traffic 1129 received from a remote PE is switched via an MPLS forwarding decision 1130 and is not subject to filtering. 1132 Contrary to the behavior specified for the non-VPN NLRI, Flow 1133 Specifications are accepted by default, when received from remote PE 1134 routers. 1136 The validation procedure (Section 6) and Traffic Filtering Actions 1137 (Section 7) are the same as for IPv4. 1139 9. Traffic Monitoring 1141 Traffic filtering applications require monitoring and traffic 1142 statistics facilities. While this is an implementation specific 1143 choice, implementations SHOULD provide: 1145 o A mechanism to log the packet header of filtered traffic. 1147 o A mechanism to count the number of matches for a given Flow 1148 Specification. 1150 10. Error Handling 1152 Error handling according to [RFC7606] and [RFC4760] applies to this 1153 specification. 1155 This document introduces Traffic Filtering Action Extended 1156 Communities. Malformed Traffic Filtering Action Extended Communities 1157 in the sense of [RFC7606] Section 7.14. are Extended Community values 1158 that cannot be decoded according to Section 7 of this document. 1160 11. Future NLRI Extensions 1162 Future Flow Specification extensions may introduce new Flow 1163 Specification components. If a receiving BGP speaker decodes an 1164 unknown Flow Specification component type it is unable to continue 1165 decoding the following Flow Specification components in the same NLRI 1166 value and MUST discard this NLRI value and all its components as 1167 described in Section 4.2 for further processing. Since the NLRI 1168 field encoding (Section 4) is defined in the form of a 2-tuple 1169 message decoding can skip over the NLRI value 1170 and continue with subsequent NLRI and message decoding. 1172 The specification of a new Flow Specification Component Type MUST 1173 clearly identify what the criteria used to match packets forwarded by 1174 the router is. This criteria should be meaningful across router hops 1175 and not depend on values that change hop-by-hop such as TTL or Layer 1176 2 encapsulation. 1178 Such extensions SHOULD also specify a way to encode an "always-match" 1179 match condition within the newly introduced components (this is a 1180 match condition, encoded with the newly introduced components: If 1181 present on its own, matches all flows). This match condition can be 1182 used to propagate (and apply) certain Flow Specifications only if a 1183 specific extension is known to the implementation. 1185 12. IANA Considerations 1187 This section complies with [RFC7153]. 1189 12.1. AFI/SAFI Definitions 1191 IANA maintains a registry entitled "SAFI Values". For the purpose of 1192 this work, IANA is requested to update the following SAFIs to read 1193 according to the table below (Note: This document obsoletes both 1194 RFC7674 and RFC5575 and all references to those documents should be 1195 deleted from the registry below): 1197 +-------+------------------------------------------+----------------+ 1198 | Value | Name | Reference | 1199 +-------+------------------------------------------+----------------+ 1200 | 133 | Dissemination of Flow Specification | [this | 1201 | | rules | document] | 1202 | 134 | L3VPN Dissemination of Flow | [this | 1203 | | Specification rules | document] | 1204 +-------+------------------------------------------+----------------+ 1206 Table 3: Registry: SAFI Values 1208 12.2. Flow Component Definitions 1210 A Flow Specification consists of a sequence of flow components, which 1211 are identified by a an 8-bit component type. IANA has created and 1212 maintains a registry entitled "Flow Spec Component Types". IANA is 1213 requested to update the reference for this registry to [this 1214 document]. Furthermore the references to the values should be 1215 updated according to the table below (Note: This document obsoletes 1216 both RFC7674 and RFC5575 and all references to those documents should 1217 be deleted from the registry below). 1219 +-------+--------------------+-----------------+ 1220 | Value | Name | Reference | 1221 +-------+--------------------+-----------------+ 1222 | 1 | Destination Prefix | [this document] | 1223 | 2 | Source Prefix | [this document] | 1224 | 3 | IP Protocol | [this document] | 1225 | 4 | Port | [this document] | 1226 | 5 | Destination port | [this document] | 1227 | 6 | Source port | [this document] | 1228 | 7 | ICMP type | [this document] | 1229 | 8 | ICMP code | [this document] | 1230 | 9 | TCP flags | [this document] | 1231 | 10 | Packet length | [this document] | 1232 | 11 | DSCP | [this document] | 1233 | 12 | Fragment | [this document] | 1234 +-------+--------------------+-----------------+ 1236 Table 4: Registry: Flow Spec Component Types 1238 In order to manage the limited number space and accommodate several 1239 usages, the following policies defined by [RFC8126] are used: 1241 +--------------+-------------------------------+ 1242 | Type Values | Policy | 1243 +--------------+-------------------------------+ 1244 | 0 | Reserved | 1245 | [1 .. 12] | Defined by this specification | 1246 | [13 .. 127] | Specification required | 1247 | [128 .. 255] | First Come First Served | 1248 +--------------+-------------------------------+ 1250 Table 5: Flow Spec Component Types Policies 1252 12.3. Extended Community Flow Specification Actions 1254 The Extended Community Flow Specification Action types defined in 1255 this document consist of two parts: 1257 Type (BGP Transitive Extended Community Type) 1259 Sub-Type 1261 For the type-part, IANA maintains a registry entitled "BGP Transitive 1262 Extended Community Types". For the purpose of this work (Section 7), 1263 IANA is requested to update the references to the following entries 1264 according to the table below (Note: This document obsoletes both 1265 RFC7674 and RFC5575 and all references to those documents should be 1266 deleted in the registry below): 1268 +-------+-----------------------------------------------+-----------+ 1269 | Type | Name | Reference | 1270 | Value | | | 1271 +-------+-----------------------------------------------+-----------+ 1272 | 0x81 | Generic Transitive Experimental | [this | 1273 | | Use Extended Community Part 2 (Sub-Types are | document] | 1274 | | defined in the "Generic Transitive | | 1275 | | Experimental Use Extended Community Part 2 | | 1276 | | Sub-Types" Registry) | | 1277 | 0x82 | Generic Transitive Experimental | [this | 1278 | | Use Extended Community Part 3 | document] | 1279 | | (Sub-Types are defined in the "Generic | | 1280 | | Transitive Experimental Use | | 1281 | | Extended Community Part 3 Sub-Types" | | 1282 | | Registry) | | 1283 +-------+-----------------------------------------------+-----------+ 1285 Table 6: Registry: BGP Transitive Extended Community Types 1287 For the sub-type part of the extended community Traffic Filtering 1288 Actions IANA maintains the following registries. IANA is requested 1289 to update all names and references according to the tables below and 1290 assign a new value for the "Flow spec traffic-rate-packets" Sub-Type 1291 (Note: This document obsoletes both RFC7674 and RFC5575 and all 1292 references to those documents should be deleted from the registries 1293 below). 1295 +----------+--------------------------------------------+-----------+ 1296 | Sub-Type | Name | Reference | 1297 | Value | | | 1298 +----------+--------------------------------------------+-----------+ 1299 | 0x06 | Flow spec traffic-rate-bytes | [this | 1300 | | | document] | 1301 | TBD | Flow spec traffic-rate-packets | [this | 1302 | | | document] | 1303 | 0x07 | Flow spec traffic-action (Use | [this | 1304 | | of the "Value" field is defined in the | document] | 1305 | | "Traffic Action Fields" registry) | | 1306 | 0x08 | Flow spec rt-redirect AS-2byte | [this | 1307 | | format | document] | 1308 | 0x09 | Flow spec traffic-remarking | [this | 1309 | | | document] | 1310 +----------+--------------------------------------------+-----------+ 1312 Table 7: Registry: Generic Transitive Experimental Use Extended 1313 Community Sub-Types 1315 +------------+----------------------------------------+-------------+ 1316 | Sub-Type | Name | Reference | 1317 | Value | | | 1318 +------------+----------------------------------------+-------------+ 1319 | 0x08 | Flow spec rt-redirect IPv4 | [this | 1320 | | format | document] | 1321 +------------+----------------------------------------+-------------+ 1323 Table 8: Registry: Generic Transitive Experimental Use Extended 1324 Community Part 2 Sub-Types 1326 +------------+----------------------------------------+-------------+ 1327 | Sub-Type | Name | Reference | 1328 | Value | | | 1329 +------------+----------------------------------------+-------------+ 1330 | 0x08 | Flow spec rt-redirect AS- | [this | 1331 | | 4byte format | document] | 1332 +------------+----------------------------------------+-------------+ 1334 Table 9: Registry: Generic Transitive Experimental Use Extended 1335 Community Part 3 Sub-Types 1337 Furthermore IANA is requested to update the reference for the 1338 registries "Generic Transitive Experimental Use Extended Community 1339 Part 2 Sub-Types" and "Generic Transitive Experimental Use Extended 1340 Community Part 3 Sub-Types" to [this document]. 1342 The "traffic-action" extended community (Section 7.3) defined in this 1343 document has 46 unused bits, which can be used to convey additional 1344 meaning. IANA created and maintains a registry entitled: "Traffic 1345 Action Fields". IANA is requested to update the reference for this 1346 registry to [this document]. Furthermore IANA is requested to update 1347 the references according to the table below. These values should be 1348 assigned via IETF Review rules only (Note: This document obsoletes 1349 both RFC7674 and RFC5575 and all references to those documents should 1350 be deleted from the registry below). 1352 +-----+-----------------+-----------------+ 1353 | Bit | Name | Reference | 1354 +-----+-----------------+-----------------+ 1355 | 47 | Terminal Action | [this document] | 1356 | 46 | Sample | [this document] | 1357 +-----+-----------------+-----------------+ 1359 Table 10: Registry: Traffic Action Fields 1361 13. Security Considerations 1363 As long as Flow Specifications are restricted to match the 1364 corresponding unicast routing paths for the relevant prefixes 1365 (Section 6), the security characteristics of this proposal are 1366 equivalent to the existing security properties of BGP unicast 1367 routing. Any relaxation of the validation procedure described in 1368 Section 6 may allow unwanted Flow Specifications to be propagated and 1369 thus unwanted Traffic Filtering Actions may be applied to flows. 1371 Where the above mechanisms are not in place, this could open the door 1372 to further denial-of-service attacks such as unwanted traffic 1373 filtering, remarking or redirection. 1375 Deployment of specific relaxations of the validation within an 1376 administrative boundary of a network, defined by an AS or an AS- 1377 Confederation boundary, may be useful in some networks for quickly 1378 distributing filters to prevent denial-of-service attacks. For a 1379 network to utilize this relaxation, the BGP policies must support 1380 additional filtering since the origin AS field is empty. 1381 Specifications relaxing the validation restrictions MUST contain 1382 security considerations that provide details on the required 1383 additional filtering. For example, the use of [RFC6811] to enhance 1384 filtering within an AS confederation. 1386 Inter-provider routing is based on a web of trust. Neighboring 1387 autonomous systems are trusted to advertise valid reachability 1388 information. If this trust model is violated, a neighboring 1389 autonomous system may cause a denial-of-service attack by advertising 1390 reachability information for a given prefix for which it does not 1391 provide service (unfiltered address space hijack). Since validation 1392 of the Flow Specification is tied to the announcement of the best 1393 unicast route, this may also cause this validation to fail and 1394 consequently prevent Flow Specifications from being accepted by a 1395 peer. Possible mitigations are [RFC6811] and [RFC8205]. 1397 On IXPs routes are often exchanged via route servers which do not 1398 extend the AS_PATH. In such cases it is not possible to enforce the 1399 left-most AS in the AS_PATH to be the neighbor AS (the AS of the 1400 route server). Since the validation of Flow Specification 1401 (Section 6) depends on this, additional care must be taken. It is 1402 advised to use a strict inbound route policy in such scenarios. 1404 Enabling firewall-like capabilities in routers without centralized 1405 management could make certain failures harder to diagnose. For 1406 example, it is possible to allow TCP packets to pass between a pair 1407 of addresses but not ICMP packets. It is also possible to permit 1408 packets smaller than 900 or greater than 1000 bytes to pass between a 1409 pair of addresses, but not packets whose length is in the range 900- 1410 1000. Such behavior may be confusing and these capabilities should 1411 be used with care whether manually configured or coordinated through 1412 the protocol extensions described in this document. 1414 Flow Specification BGP speakers (e.g. automated DDoS controllers) not 1415 properly programmed, algorithms that are not performing as expected, 1416 or simply rogue systems may announce unintended Flow Specifications, 1417 send updates at a high rate or generate a high number of Flow 1418 Specifications. This may stress the receiving systems, exceed their 1419 maximum capacity or may lead to unwanted Traffic Filtering Actions 1420 being applied to flows. 1422 When BGP decodes an unknown Flow Specification component type, as of 1423 Section 4.2 it needs to discard the NLRI and skip over the remaining 1424 undecoded octets to the following NLRI or to the end of the list. 1425 Skipping over unknown octets of the to be discarded NLRI is the 1426 specified behaviour for a Type NLRI in Section 5.4 [RFC7606]. While 1427 this is not intrinsic to the Flow Specification NLRI in particular, 1428 it needs to be pointed out that, carefully crafted wrong NLRI length 1429 fields may lead to synchronisation issues between BGP senders and 1430 receivers. 1432 While the general verification of the Flow Specification NLRI is 1433 specified in this document (Section 6) the Traffic Filtering Actions 1434 received by a third party may need custom verification or filtering. 1435 In particular all non traffic-rate actions may allow a third party to 1436 modify packet forwarding properties and potentially gain access to 1437 other routing-tables/VPNs or undesired queues. This can be avoided 1438 by proper filtering/screening of the Traffic Filtering Action 1439 communities at network borders and only exposing a predefined subset 1440 of Traffic Filtering Actions (see Section 7) to third parties. One 1441 way to achieve this is by mapping user-defined communities, that can 1442 be set by the third party, to Traffic Filtering Actions and not 1443 accepting Traffic Filtering Action extended communities from third 1444 parties. 1446 This extension adds additional information to Internet routers. 1447 These are limited in terms of the maximum number of data elements 1448 they can hold as well as the number of events they are able to 1449 process in a given unit of time. Service providers need to consider 1450 the maximum capacity of their devices and may need to limit the 1451 number of Flow Specifications accepted and processed. 1453 14. Contributors 1455 Barry Greene, Pedro Marques, Jared Mauch and Nischal Sheth were 1456 authors on [RFC5575], and therefore are contributing authors on this 1457 document. 1459 15. Acknowledgements 1461 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 1462 Morrow, Charlie Kaufman, and David Smith for their comments for the 1463 comments on the original [RFC5575]. Chaitanya Kodeboyina helped 1464 design the flow validation procedure; and Steven Lin and Jim Washburn 1465 ironed out all the details necessary to produce a working 1466 implementation in the original [RFC5575]. 1468 A packet rate Traffic Filtering Action was also described in a Flow 1469 Specification extension draft and the authors like to thank Wesley 1470 Eddy, Justin Dailey and Gilbert Clark for their work. 1472 Additionally, the authors would like to thank Alexander Mayrhofer, 1473 Nicolas Fevrier, Job Snijders, Jeffrey Haas and Adam Chappell for 1474 their comments and review. 1476 16. References 1478 16.1. Normative References 1480 [IEEE.754.1985] 1481 IEEE, "Standard for Binary Floating-Point Arithmetic", 1482 IEEE 754-1985, August 1985. 1484 [ISO_IEC_9899] 1485 ISO, "Information technology -- Programming languages -- 1486 C", ISO/IEC 9899:2018, June 2018. 1488 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1489 DOI 10.17487/RFC0768, August 1980, 1490 . 1492 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1493 DOI 10.17487/RFC0791, September 1981, 1494 . 1496 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1497 RFC 792, DOI 10.17487/RFC0792, September 1981, 1498 . 1500 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1501 RFC 793, DOI 10.17487/RFC0793, September 1981, 1502 . 1504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1505 Requirement Levels", BCP 14, RFC 2119, 1506 DOI 10.17487/RFC2119, March 1997, 1507 . 1509 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1510 "Definition of the Differentiated Services Field (DS 1511 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1512 DOI 10.17487/RFC2474, December 1998, 1513 . 1515 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1516 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1517 DOI 10.17487/RFC4271, January 2006, 1518 . 1520 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1521 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1522 February 2006, . 1524 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1525 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1526 2006, . 1528 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1529 Reflection: An Alternative to Full Mesh Internal BGP 1530 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1531 . 1533 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1534 "Multiprotocol Extensions for BGP-4", RFC 4760, 1535 DOI 10.17487/RFC4760, January 2007, 1536 . 1538 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 1539 Specific BGP Extended Community", RFC 5668, 1540 DOI 10.17487/RFC5668, October 2009, 1541 . 1543 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1544 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1545 March 2014, . 1547 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1548 Patel, "Revised Error Handling for BGP UPDATE Messages", 1549 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1550 . 1552 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1553 Writing an IANA Considerations Section in RFCs", BCP 26, 1554 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1555 . 1557 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1558 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1559 May 2017, . 1561 16.2. Informative References 1563 [I-D.ietf-idr-flow-spec-v6] 1564 Loibl, C., Raszuk, R., and S. Hares, "Dissemination of 1565 Flow Specification Rules for IPv6", draft-ietf-idr-flow- 1566 spec-v6-10 (work in progress), November 2019. 1568 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1569 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1570 . 1572 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1573 and D. McPherson, "Dissemination of Flow Specification 1574 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1575 . 1577 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1578 Austein, "BGP Prefix Origin Validation", RFC 6811, 1579 DOI 10.17487/RFC6811, January 2013, 1580 . 1582 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1583 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1584 October 2015, . 1586 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 1587 Specification", RFC 8205, DOI 10.17487/RFC8205, September 1588 2017, . 1590 16.3. URIs 1592 [1] https://github.com/stoffi92/flowspec-cmp 1594 Appendix A. Python code: flow_rule_cmp 1596 1597 """ 1598 Copyright (c) 2019 IETF Trust and the persons identified as authors of 1599 the code. All rights reserved. 1601 Redistribution and use in source and binary forms, with or without 1602 modification, is permitted pursuant to, and subject to the license 1603 terms contained in, the Simplified BSD License set forth in Section 1604 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1605 (http://trustee.ietf.org/license-info). 1606 """ 1608 import itertools 1609 import ipaddress 1611 def flow_rule_cmp(a, b): 1612 for comp_a, comp_b in itertools.zip_longest(a.components, 1613 b.components): 1614 # If a component type does not exist in one rule 1615 # this rule has lower precedence 1616 if not comp_a: 1617 return B_HAS_PRECEDENCE 1618 if not comp_b: 1619 return A_HAS_PRECEDENCE 1620 # higher precedence for lower component type 1621 if comp_a.component_type < comp_b.component_type: 1622 return A_HAS_PRECEDENCE 1623 if comp_a.component_type > comp_b.component_type: 1624 return B_HAS_PRECEDENCE 1625 # component types are equal -> type specific comparison 1626 if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): 1627 # assuming comp_a.value, comp_b.value of type 1628 # ipaddress.IPv4Network 1629 if comp_a.value.overlaps(comp_b.value): 1630 # longest prefixlen has precedence 1631 if comp_a.value.prefixlen > comp_b.value.prefixlen: 1632 return A_HAS_PRECEDENCE 1633 if comp_a.value.prefixlen < comp_b.value.prefixlen: 1634 return B_HAS_PRECEDENCE 1635 # components equal -> continue with next component 1636 elif comp_a.value > comp_b.value: 1637 return B_HAS_PRECEDENCE 1638 elif comp_a.value < comp_b.value: 1639 return A_HAS_PRECEDENCE 1640 else: 1641 # assuming comp_a.value, comp_b.value of type bytearray 1642 if len(comp_a.value) == len(comp_b.value): 1643 if comp_a.value > comp_b.value: 1644 return B_HAS_PRECEDENCE 1645 if comp_a.value < comp_b.value: 1646 return A_HAS_PRECEDENCE 1647 # components equal -> continue with next component 1648 else: 1649 common = min(len(comp_a.value), len(comp_b.value)) 1650 if comp_a.value[:common] > comp_b.value[:common]: 1651 return B_HAS_PRECEDENCE 1652 elif comp_a.value[:common] < comp_b.value[:common]: 1653 return A_HAS_PRECEDENCE 1654 # the first common bytes match 1655 elif len(comp_a.value) > len(comp_b.value): 1656 return A_HAS_PRECEDENCE 1657 else: 1658 return B_HAS_PRECEDENCE 1659 return EQUAL 1660 1662 Appendix B. Comparison with RFC 5575 1664 This document includes numerous editorial changes to [RFC5575]. It 1665 also completely incorporates the redirect action clarification 1666 document [RFC7674]. It is recommended to read the entire document. 1667 The authors, however want to point out the following technical 1668 changes to [RFC5575]: 1670 Section 1 introduces the Flow Specification NLRI. In [RFC5575] 1671 this NLRI was defined as an opaque-key in BGPs database. This 1672 specification has removed all references to a opaque-key property. 1673 BGP is able to understand the NLRI encoding. This change also 1674 resulted in a new section regarding error handling and 1675 extensibility (Section 10 and Section 11). 1677 Section 4.2.2.3 defines a numeric operator and comparison bit 1678 combinations. In [RFC5575] the meaning of those bit combination 1679 was not explicitly defined and left open to the reader. 1681 Section 4.2.2.3 - Section 4.2.2.8, Section 4.2.2.10, 1682 Section 4.2.2.11 make use of the above numeric operator. The 1683 allowed length of the comparison value was not consistently 1684 defined in [RFC5575]. 1686 Section 7 defines all Traffic Filtering Action Extended 1687 communities as transitive extended communities. [RFC5575] defined 1688 the traffic-rate action to be non-transitive and did not define 1689 the transitivity of the other Traffic Filtering Action communities 1690 at all. 1692 Section 7.2 introduces a new Traffic Filtering Action (traffic- 1693 rate-packets). This action did not exist in [RFC5575]. 1695 Section 7.4 contains the same redirect actions already defined in 1696 [RFC5575] however, these actions have been renamed to "rt- 1697 redirect" to make it clearer that the redirection is based on 1698 route-target. This section also completely incorporates the 1699 [RFC7674] clarifications of the Flowspec Redirect Extended 1700 Community. 1702 Section 7.7 contains general considerations on interfering traffic 1703 actions. Section 7.3 also cross-references this section. 1704 [RFC5575] did not mention this. 1706 Section 10 contains new error handling. 1708 Section 11 describes graceful handling of unknown Flow 1709 Specification components to allow future extensions. 1711 Authors' Addresses 1713 Christoph Loibl 1714 Next Layer Communications 1715 Mariahilfer Guertel 37/7 1716 Vienna 1150 1717 AT 1719 Phone: +43 664 1176414 1720 Email: cl@tix.at 1722 Susan Hares 1723 Huawei 1724 7453 Hickory Hill 1725 Saline, MI 48176 1726 USA 1728 Email: shares@ndzh.com 1729 Robert Raszuk 1730 Bloomberg LP 1731 731 Lexington Ave 1732 New York City, NY 10022 1733 USA 1735 Email: robert@raszuk.net 1737 Danny McPherson 1738 Verisign 1739 USA 1741 Email: dmcpherson@verisign.com 1743 Martin Bacher 1744 T-Mobile Austria 1745 Rennweg 97-99 1746 Vienna 1030 1747 AT 1749 Email: mb.ietf@gmail.com