idnits 2.17.1 draft-ietf-idr-rfc5575bis-07.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 abstract seems to contain references ([RFC5575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC7674, but the abstract doesn't seem to mention this, which it should. -- 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. -- The abstract seems to indicate that this document updates RFC5575, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (April 20, 2018) is 2198 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 584 -- Looks like a reference, but probably isn't: '139' on line 584 -- Looks like a reference, but probably isn't: '1' on line 1446 == Missing Reference: 'IEEE.754.1985' is mentioned on line 872, but not defined == Unused Reference: 'RFC4761' is defined on line 1384, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 1389, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1409, but no explicit reference was found in the text == Unused Reference: 'RFC6482' is defined on line 1414, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Obsolete normative reference: RFC 7674 (Obsoleted by RFC 8955) == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-09 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group S. Hares 3 Internet-Draft Huawei 4 Obsoletes: 5575,7674 (if approved) C. Loibl 5 Intended status: Standards Track Next Layer Communications 6 Expires: October 22, 2018 R. Raszuk 7 Bloomberg LP 8 D. McPherson 9 Verisign 10 M. Bacher 11 T-Mobile Austria 12 April 20, 2018 14 Dissemination of Flow Specification Rules 15 draft-ietf-idr-rfc5575bis-07 17 Abstract 19 This document updates [RFC5575] which defines a Border Gateway 20 Protocol Network Layer Reachability Information (BGP NLRI) encoding 21 format that can be used to distribute traffic Flow Specifications. 22 This allows the routing system to propagate information regarding 23 more specific components of the traffic aggregate defined by an IP 24 destination prefix. 26 It specifies IPv4 traffic Flow Specifications via a BGP NLRI which 27 carries traffic Flow Specification filter, and an Extended community 28 value which encodes actions a routing system can take if the packet 29 matches the traffic flow filters. The flow filters and the actions 30 are processed in a fixed order. Other drafts specify IPv6, MPLS 31 addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. 33 This document updates [RFC5575] to correct unclear specifications in 34 the flow filters and to provide rules for actions which interfere 35 (e.g. redirection of traffic and flow filtering). 37 Applications which use the bgp Flow Specification are: 1) application 38 which automate inter-domain coordination of traffic filtering, such 39 as what is required in order to mitigate (distributed) denial-of- 40 service attacks; 2) applications which control traffic filtering in 41 the context of a BGP/MPLS VPN service, and 3) applications with 42 centralized control of traffic in a SDN or NFV context. Some 43 deployments of these three applications can be handled by the strict 44 ordering of the BGP NLRI traffic flow filters, and the strict actions 45 encoded in the extended community Flow Specification actions. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on October 22, 2018. 64 Copyright Notice 66 Copyright (c) 2018 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (https://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. Definitions of Terms Used in This Memo . . . . . . . . . . . 5 83 3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 6 84 4. Dissemination of IPv4 FLow Specification Information . . . . 6 85 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7 86 4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7 87 4.2.1. Type 1 - Destination Prefix . . . . . . . . . . . . . 8 88 4.2.2. Type 2 - Source Prefix . . . . . . . . . . . . . . . 8 89 4.2.3. Type 3 - IP Protocol . . . . . . . . . . . . . . . . 8 90 4.2.4. Type 4 - Port . . . . . . . . . . . . . . . . . . . . 10 91 4.2.5. Type 5 - Destination Port . . . . . . . . . . . . . . 10 92 4.2.6. Type 6 - Source Port . . . . . . . . . . . . . . . . 10 93 4.2.7. Type 7 - ICMP type . . . . . . . . . . . . . . . . . 10 94 4.2.8. Type 8 - ICMP code . . . . . . . . . . . . . . . . . 11 95 4.2.9. Type 9 - TCP flags . . . . . . . . . . . . . . . . . 11 96 4.2.10. Type 10 - Packet length . . . . . . . . . . . . . . . 12 97 4.2.11. Type 11 - DSCP (Diffserv Code Point) . . . . . . . . 12 98 4.2.12. Type 12 - Fragment . . . . . . . . . . . . . . . . . 12 99 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 12 100 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 13 101 5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 14 102 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 16 103 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17 104 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 19 105 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type 106 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 19 108 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 20 109 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 20 110 7.6. Rules on Traffic Action Interference . . . . . . . . . . 21 111 7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 112 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 22 113 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 23 114 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 23 115 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 23 116 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 23 117 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 24 118 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24 119 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 120 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 121 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 25 122 11.3. Extended Community Flow Specification Actions . . . . . 26 123 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 124 13. Original authors . . . . . . . . . . . . . . . . . . . . . . 29 125 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 126 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 127 15.1. Normative References . . . . . . . . . . . . . . . . . . 29 128 15.2. Informative References . . . . . . . . . . . . . . . . . 31 129 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 130 Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 32 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 133 1. Introduction 135 Modern IP routers contain both the capability to forward traffic 136 according to IP prefixes as well as to classify, shape, rate limit, 137 filter, or redirect packets based on administratively defined 138 policies. 140 These traffic policy mechanisms allow the router to define match 141 rules that operate on multiple fields of the packet header. Actions 142 such as the ones described above can be associated with each rule. 144 The n-tuple consisting of the matching criteria defines an aggregate 145 traffic Flow Specification. The matching criteria can include 146 elements such as source and destination address prefixes, IP 147 protocol, and transport protocol port numbers. 149 This document defines a general procedure to encode flow 150 specification rules for aggregated traffic flows so that they can be 151 distributed as a BGP [RFC4271] NLRI. Additionally, we define the 152 required mechanisms to utilize this definition to the problem of 153 immediate concern to the authors: intra- and inter-provider 154 distribution of traffic filtering rules to filter (distributed) 155 denial-of-service (DoS) attacks. 157 By expanding routing information with Flow Specifications, the 158 routing system can take advantage of the ACL (Access Control List) or 159 firewall capabilities in the router's forwarding path. Flow 160 specifications can be seen as more specific routing entries to a 161 unicast prefix and are expected to depend upon the existing unicast 162 data information. 164 A Flow Specification received from an external autonomous system will 165 need to be validated against unicast routing before being accepted. 166 If the aggregate traffic flow defined by the unicast destination 167 prefix is forwarded to a given BGP peer, then the local system can 168 safely install more specific flow rules that may result in different 169 forwarding behavior, as requested by this system. 171 The key technology components required to address the class of 172 problems targeted by this document are: 174 1. Efficient point-to-multipoint distribution of control plane 175 information. 177 2. Inter-domain capabilities and routing policy support. 179 3. Tight integration with unicast routing, for verification 180 purposes. 182 Items 1 and 2 have already been addressed using BGP for other types 183 of control plane information. Close integration with BGP also makes 184 it feasible to specify a mechanism to automatically verify flow 185 information against unicast routing. These factors are behind the 186 choice of BGP as the carrier of Flow Specification information. 188 As with previous extensions to BGP, this specification makes it 189 possible to add additional information to Internet routers. These 190 are limited in terms of the maximum number of data elements they can 191 hold as well as the number of events they are able to process in a 192 given unit of time. The authors believe that, as with previous 193 extensions, service providers will be careful to keep information 194 levels below the maximum capacity of their devices. 196 In many deployments of BGP Flow Specification, the Flow Specification 197 information has replace existing host length route advertisements. 199 Experience with previous BGP extensions has also shown that the 200 maximum capacity of BGP speakers has been gradually increased 201 according to expected loads. Taking into account Internet unicast 202 routing as well as additional applications as they gain popularity. 204 From an operational perspective, the utilization of BGP as the 205 carrier for this information allows a network service provider to 206 reuse both internal route distribution infrastructure (e.g., route 207 reflector or confederation design) and existing external 208 relationships (e.g., inter-domain BGP sessions to a customer 209 network). 211 While it is certainly possible to address this problem using other 212 mechanisms, this solution has been utilized in deployments because of 213 the substantial advantage of being an incremental addition to already 214 deployed mechanisms. 216 In current deployments, the information distributed by the flow-spec 217 extension is originated both manually as well as automatically. The 218 latter by systems that are able to detect malicious flows. When 219 automated systems are used, care should be taken to ensure their 220 correctness as well as to limit the number and advertisement rate of 221 flow routes. 223 This specification defines required protocol extensions to address 224 most common applications of IPv4 unicast and VPNv4 unicast filtering. 225 The same mechanism can be reused and new match criteria added to 226 address similar filtering needs for other BGP address families such 227 as IPv6 families [I-D.ietf-idr-flow-spec-v6], 229 2. Definitions of Terms Used in This Memo 231 NLRI - Network Layer Reachability Information. 233 RIB - Routing Information Base. 235 Loc-RIB - Local RIB. 237 AS - Autonomous System. 239 VRF - Virtual Routing and Forwarding instance. 241 PE - Provider Edge router 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [RFC2119] 247 3. Flow Specifications 249 A Flow Specification is an n-tuple consisting of several matching 250 criteria that can be applied to IP traffic. A given IP packet is 251 said to match the defined flow if it matches all the specified 252 criteria. 254 A given flow may be associated with a set of attributes, depending on 255 the particular application; such attributes may or may not include 256 reachability information (i.e., NEXT_HOP). Well-known or AS-specific 257 community attributes can be used to encode a set of predetermined 258 actions. 260 A particular application is identified by a specific (Address Family 261 Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair 262 [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs 263 should be treated independently from each other in order to assure 264 non-interference between distinct applications. 266 BGP itself treats the NLRI as an opaque key to an entry in its 267 databases. Entries that are placed in the Loc-RIB are then 268 associated with a given set of semantics, which is application 269 dependent. This is consistent with existing BGP applications. For 270 instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast 271 reverse-path information (AFI=1, SAFI=2) are handled by BGP without 272 any particular semantics being associated with them until installed 273 in the Loc-RIB. 275 Standard BGP policy mechanisms, such as UPDATE filtering by NLRI 276 prefix as well as community matching and manipulation, MUST apply to 277 the Flow Specification defined NLRI-type, especially in an inter- 278 domain environment. Network operators can also control propagation 279 of such routing updates by enabling or disabling the exchange of a 280 particular (AFI, SAFI) pair on a given BGP peering session. 282 4. Dissemination of IPv4 FLow Specification Information 284 We define a "Flow Specification" NLRI type (Figure 1) that may 285 include several components such as destination prefix, source prefix, 286 protocol, ports, and others (see Section 4.2 below). This NLRI is 287 treated as an opaque bit string prefix by BGP. Each bit string 288 identifies a key to a database entry with which a set of attributes 289 can be associated. 291 This NLRI information is encoded using MP_REACH_NLRI and 292 MP_UNREACH_NLRI attributes as defined in [RFC4760]. Whenever the 293 corresponding application does not require Next-Hop information, this 294 shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI 295 attribute and ignored on receipt. 297 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 298 a 1- or 2-octet NLRI length field followed by a variable-length NLRI 299 value. The NLRI length is expressed in octets. 301 +------------------------------+ 302 | length (0xnn or 0xfn nn) | 303 +------------------------------+ 304 | NLRI value (variable) | 305 +------------------------------+ 307 Figure 1: Flow-spec NLRI for IPv4 309 Implementations wishing to exchange Flow Specification rules MUST use 310 BGP's Capability Advertisement facility to exchange the Multiprotocol 311 Extension Capability Code (Code 1) as defined in [RFC4760]. The 312 (AFI, SAFI) pair carried in the Multiprotocol Extension Capability 313 MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification, and (AFI=1, 314 SAFI=134) for VPNv4 Flow Specification. 316 4.1. Length Encoding 318 o If the NLRI length value is smaller than 240 (0xf0 hex), the 319 length field can be encoded as a single octet. 321 o Otherwise, it is encoded as an extended-length 2-octet value in 322 which the most significant nibble of the first byte is all ones. 324 In figure 1 above, values less-than 240 are encoded using two hex 325 digits (0xnn). Values above 239 are encoded using 3 hex digits 326 (0xfnnn). The highest value that can be represented with this 327 encoding is 4095. The value 241 is encoded as 0xf0f1. 329 4.2. NLRI Value Encoding 331 The Flow Specification NLRI-type consists of several optional 332 subcomponents. A specific packet is considered to match the flow 333 specification when it matches the intersection (AND) of all the 334 components present in the specification. 336 The encoding of each of the NLRI components begins with a type field 337 (1 octet) followed by a variable length parameter. Section 4.2.1 to 338 Section 4.2.12 define component types and parameter encodings for the 339 IPv4 IP layer and transport layer headers. IPv6 NLRI component types 340 are described in [I-D.ietf-idr-flow-spec-v6]. 342 Flow Specification components must follow strict type ordering by 343 increasing numerical order. A given component type may or may not be 344 present in the specification, but if present, it MUST precede any 345 component of higher numeric type value. 347 All combinations of component types within a single NLRI are allowed, 348 even if the combination makes no sense from a semantical perspective. 349 If a given component type within a prefix in unknown, the prefix in 350 question cannot be used for traffic filtering purposes by the 351 receiver. Since a Flow Specification has the semantics of a logical 352 AND of all components, if a component is FALSE, by definition it 353 cannot be applied. However, for the purposes of BGP route 354 propagation, this prefix should still be transmitted since BGP route 355 distribution is independent on NLRI semantics. 357 The encoding is chosen in order to allow for future 358 extensibility. 360 4.2.1. Type 1 - Destination Prefix 362 Encoding: 364 Defines: the destination prefix to match. Prefixes are encoded as 365 in BGP UPDATE messages, a length in bits is followed by enough 366 octets to contain the prefix information. 368 4.2.2. Type 2 - Source Prefix 370 Encoding: 372 Defines the source prefix to match. 374 4.2.3. Type 3 - IP Protocol 376 Encoding: 378 Contains a set of {operator, value} pairs that are used to match 379 the IP protocol value byte in IP packets. 381 The operator byte is encoded as: 383 0 1 2 3 4 5 6 7 384 +---+---+---+---+---+---+---+---+ 385 | e | a | len | 0 |lt |gt |eq | 386 +---+---+---+---+---+---+---+---+ 388 Numeric operator 390 e - end-of-list bit. Set in the last {op, value} pair in the 391 list. 393 a - AND bit. If unset, the previous term is logically ORed with 394 the current one. If set, the operation is a logical AND. It 395 should be unset in the first operator byte of a sequence. The AND 396 operator has higher priority than OR for the purposes of 397 evaluating logical expressions. 399 len - length of the value field for this operand encodes 1 (00) - 400 4 (11) bytes. Type 3 flow component values are always encoded as 401 single byte (len = 00). 403 lt - less than comparison between data and value. 405 gt - greater than comparison between data and value. 407 eq - equality between data and value. 409 The bits lt, gt, and eq can be combined to produce common relational 410 operators such as "less or equal", "greater or equal", and "not equal 411 to". 413 +----+----+----+----------------------------------+ 414 | lt | gt | eq | Resulting operation | 415 +----+----+----+----------------------------------+ 416 | 0 | 0 | 0 | true (independent of the value) | 417 | 0 | 0 | 1 | == (equal) | 418 | 0 | 1 | 0 | > (greater than) | 419 | 0 | 1 | 1 | >= (greater than or equal) | 420 | 1 | 0 | 0 | < (less than) | 421 | 1 | 0 | 1 | <= (less than or equal) | 422 | 1 | 1 | 0 | != (not equal value) | 423 | 1 | 1 | 1 | false (independent of the value) | 424 +----+----+----+----------------------------------+ 426 Table 1: Comparison operation combinations 428 4.2.4. Type 4 - Port 430 Encoding: 432 Defines a list of {operator, value} pairs that matches source OR 433 destination TCP/UDP ports. This list is encoded using the numeric 434 operator format defined in Section 4.2.3. Values are encoded as 435 1- or 2-byte quantities. 437 Port, source port, and destination port components evaluate to 438 FALSE if the IP protocol field of the packet has a value other 439 than TCP or UDP, if the packet is fragmented and this is not the 440 first fragment, or if the system in unable to locate the transport 441 header. Different implementations may or may not be able to 442 decode the transport header in the presence of IP options or 443 Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. 445 4.2.5. Type 5 - Destination Port 447 Encoding: 449 Defines a list of {operator, value} pairs used to match the 450 destination port of a TCP or UDP packet. This list is encoded 451 using the numeric operator format defined in Section 4.2.3. 452 Values are encoded as 1- or 2-byte quantities. 454 4.2.6. Type 6 - Source Port 456 Encoding: 458 Defines a list of {operator, value} pairs used to match the source 459 port of a TCP or UDP packet. This list is encoded using the 460 numeric operator format defined in Section 4.2.3. Values are 461 encoded as 1- or 2-byte quantities. 463 4.2.7. Type 7 - ICMP type 465 Encoding: 467 Defines a list of {operator, value} pairs used to match the type 468 field of an ICMP packet. This list is encoded using the numeric 469 operator format defined in Section 4.2.3. Values are encoded 470 using a single byte. 472 The ICMP type specifiers evaluate to FALSE whenever the protocol 473 value is not ICMP. 475 4.2.8. Type 8 - ICMP code 477 Encoding: 479 Defines a list of {operator, value} pairs used to match the code 480 field of an ICMP packet. This list is encoded using the numeric 481 operator format defined in Section 4.2.3. Values are encoded 482 using a single byte. 484 The ICMP code specifiers evaluate to FALSE whenever the protocol 485 value is not ICMP. 487 4.2.9. Type 9 - TCP flags 489 Encoding: 491 Bitmask values can be encoded as a 1- or 2-byte bitmask. When a 492 single byte is specified, it matches byte 13 of the TCP header 493 [RFC0793], which contains bits 8 though 15 of the 4th 32-bit word. 494 When a 2-byte encoding is used, it matches bytes 12 and 13 of the 495 TCP header with the data offset field having a "don't care" value. 497 This component evaluates to FALSE for packets that are not TCP 498 packets. 500 This type uses the bitmask operand format, which differs from the 501 numeric operator format in the lower nibble. 503 0 1 2 3 4 5 6 7 504 +---+---+---+---+---+---+---+---+ 505 | e | a | len | 0 | 0 |not| m | 506 +---+---+---+---+---+---+---+---+ 508 Bitmask format 510 e, a, len - Most significant nibble: (end-of-list bit, AND bit, and 511 length field), as defined for in the numeric operator format in 512 Section 4.2.3. 514 not - NOT bit. If set, logical negation of operation. 516 m - Match bit. If set, this is a bitwise match operation defined 517 as "(data AND value) == value"; if unset, (data AND value) 518 evaluates to TRUE if any of the bits in the value mask are set in 519 the data 521 4.2.10. Type 10 - Packet length 523 Encoding: 525 Defines a list of {operator, value} pairs used to match on the 526 total IP packet length (excluding Layer 2 but including IP 527 header). This list is encoded using the numeric operator format 528 defined in Section 4.2.3. Values are encoded using 1- or 2-byte 529 quantities. 531 4.2.11. Type 11 - DSCP (Diffserv Code Point) 533 Encoding: 535 Defines a list of {operator, value} pairs used to match the 6-bit 536 DSCP field [RFC2474]. This list is encoded using the numeric 537 operator format defined in Section 4.2.3. Values are encoded 538 using a single byte. The two most significant bits are zero and 539 the six least significant bits contain the DSCP value. 541 4.2.12. Type 12 - Fragment 543 Encoding: 545 Uses bitmask operand format defined in Section 4.2.9. 547 0 1 2 3 4 5 6 7 548 +---+---+---+---+---+---+---+---+ 549 | Reserved |LF |FF |IsF|DF | 550 +---+---+---+---+---+---+---+---+ 552 Bitmask values: 554 Bit 7 - Don't fragment (DF) 556 Bit 6 - Is a fragment (IsF) 558 Bit 5 - First fragment (FF) 560 Bit 4 - Last fragment (LF) 562 4.3. Examples of Encodings 564 An example of a Flow Specification encoding for: "all packets to 565 10.0.1/24 and TCP port 25". 567 +------------------+----------+----------+ 568 | destination | proto | port | 569 +------------------+----------+----------+ 570 | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | 571 +------------------+----------+----------+ 573 Decode for protocol: 575 +-------+----------+------------------------------+ 576 | Value | | | 577 +-------+----------+------------------------------+ 578 | 0x03 | type | | 579 | 0x81 | operator | end-of-list, value size=1, = | 580 | 0x06 | value | | 581 +-------+----------+------------------------------+ 583 An example of a Flow Specification encoding for: "all packets to 584 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". 586 +------------------+----------+-------------------------+ 587 | destination | source | port | 588 +------------------+----------+-------------------------+ 589 | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | 590 +------------------+----------+-------------------------+ 592 Decode for port: 594 +--------+----------+------------------------------+ 595 | Value | | | 596 +--------+----------+------------------------------+ 597 | 0x04 | type | | 598 | 0x03 | operator | size=1, >= | 599 | 0x89 | value | 137 | 600 | 0x45 | operator | "AND", value size=1, <= | 601 | 0x8b | value | 139 | 602 | 0x91 | operator | end-of-list, value-size=2, = | 603 | 0x1f90 | value | 8080 | 604 +--------+----------+------------------------------+ 606 This constitutes an NLRI with an NLRI length of 16 octets. 608 5. Traffic Filtering 610 Traffic filtering policies have been traditionally considered to be 611 relatively static. Limitations of the static mechanisms caused this 612 mechanism to be designed for the three new applications of traffic 613 filtering (prevention of traffic-based, denial-of-service (DOS) 614 attacks, traffic filtering in the context of BGP/MPLS VPN service, 615 and centralized traffic control for SDN/NFV networks) requires 616 coordination among service providers and/or coordination among the AS 617 within a service provider. Section 8 has details on the limitation 618 of previous mechanisms and why BGP Flow Specification version 1 619 provides a solution for to prevent DOS and aid BGP/MPLS VPN filtering 620 rules. 622 This Flow Specification NLRI defined above to convey information 623 about traffic filtering rules for traffic that should be discarded or 624 handled in manner specified by a set of pre-defined actions (which 625 are defined in BGP Extended Communities). This mechanism is 626 primarily designed to allow an upstream autonomous system to perform 627 inbound filtering in their ingress routers of traffic that a given 628 downstream AS wishes to drop. 630 In order to achieve this goal, this draft specifies two application 631 specific NLRI identifiers that provide traffic filters, and a set of 632 actions encoding in BGP Extended Communities. The two application 633 specific NLRI identifiers are: 635 o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with 636 specific semantic rules for IPv4 routes, and 638 o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which 639 can be used to propagate traffic filtering information in a BGP/ 640 MPLS VPN environment. 642 Distribution of the IPv4 Flow Specification is described in section 643 6, and distibution of BGP/MPLS traffic Flow Specification is 644 described in section 8. The traffic filtering actions are described 645 in section 7. 647 5.1. Ordering of Traffic Filtering Rules 649 With traffic filtering rules, more than one rule may match a 650 particular traffic flow. Thus, it is necessary to define the order 651 at which rules get matched and applied to a particular traffic flow. 652 This ordering function must be such that it must not depend on the 653 arrival order of the Flow Specification's rules and must be 654 consistent in the network. 656 The relative order of two Flow Specification rules is determined by 657 comparing their respective components. The algorithm starts by 658 comparing the left-most components of the rules. If the types 659 differ, the rule with lowest numeric type value has higher precedence 660 (and thus will match before) than the rule that doesn't contain that 661 component type. If the component types are the same, then a type- 662 specific comparison is performed (see below) if the types are equal 663 the algorithm continues with the next component. 665 For IP prefix values (IP destination or source prefix): If the 666 prefixes overlap, the one with the longer prefix-length has higher 667 precedence. If they do not overlap the one with the lowest IP value 668 has higher precedence. 670 For all other component types, unless otherwise specified, the 671 comparison is performed by comparing the component data as a binary 672 string using the memcmp() function as defined by the ISO C standard. 673 For strings with equal lengths the lowest string (memcmp) has higher 674 precedence. For strings of different lengths, the common prefix is 675 compared. If the common prefix is not equal the string with the 676 lowest prefix has higher precedence. If the common prefix is equal, 677 the longest string is considered to have higher precedence than the 678 shorter one. 680 The code below shows a Python3 implementation of the comparison 681 algorithm. The full code was tested with Python 3.6.3 and can be 682 obtained at https://github.com/stoffi92/flowspec-cmp [1]. 684 import itertools 685 import ipaddress 687 def flow_rule_cmp(a, b): 688 for comp_a, comp_b in itertools.zip_longest(a.components, 689 b.components): 690 # If a component type does not exist in one rule 691 # this rule has lower precedence 692 if not comp_a: 693 return B_HAS_PRECEDENCE 694 if not comp_b: 695 return A_HAS_PRECEDENCE 696 # higher precedence for lower component type 697 if comp_a.component_type < comp_b.component_type: 698 return A_HAS_PRECEDENCE 699 if comp_a.component_type > comp_b.component_type: 700 return B_HAS_PRECEDENCE 701 # component types are equal -> type specific comparison 702 if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): 703 # assuming comp_a.value, comp_b.value of type ipaddress 704 if comp_a.value.overlaps(comp_b.value): 705 # longest prefixlen has precedence 706 if comp_a.value.prefixlen > comp_b.value.prefixlen: 707 return A_HAS_PRECEDENCE 708 if comp_a.value.prefixlen < comp_b.value.prefixlen: 709 return B_HAS_PRECEDENCE 711 # components equal -> continue with next component 712 elif comp_a.value > comp_b.value: 713 return B_HAS_PRECEDENCE 714 elif comp_a.value < comp_b.value: 715 return A_HAS_PRECEDENCE 716 else: 717 # assuming comp_a.value, comp_b.value of type bytearray 718 if len(comp_a.value) == len(comp_b.value): 719 if comp_a.value > comp_b.value: 720 return B_HAS_PRECEDENCE 721 if comp_a.value < comp_b.value: 722 return A_HAS_PRECEDENCE 723 # components equal -> continue with next component 724 else: 725 common = min(len(comp_a.value), len(comp_b.value)) 726 if comp_a.value[:common] > comp_b.value[:common]: 727 return B_HAS_PRECEDENCE 728 elif comp_a.value[:common] < comp_b.value[:common]: 729 return A_HAS_PRECEDENCE 730 # the first common bytes match 731 elif len(comp_a.value) > len(comp_b.value): 732 return A_HAS_PRECEDENCE 733 else: 734 return B_HAS_PRECEDENCE 735 return EQUAL 737 6. Validation Procedure 739 Flow Specifications received from a BGP peer that are accepted in the 740 respective Adj-RIB-In are used as input to the route selection 741 process. Although the forwarding attributes of two routes for the 742 same Flow Specification prefix may be the same, BGP is still required 743 to perform its path selection algorithm in order to select the 744 correct set of attributes to advertise. 746 The first step of the BGP Route Selection procedure (Section 9.1.2 of 747 [RFC4271] is to exclude from the selection procedure routes that are 748 considered non-feasible. In the context of IP routing information, 749 this step is used to validate that the NEXT_HOP attribute of a given 750 route is resolvable. 752 The concept can be extended, in the case of Flow Specification NLRI, 753 to allow other validation procedures. 755 A Flow Specification NLRI must be validated such that it is 756 considered feasible if and only if: 758 a) The originator of the Flow Specification matches the originator 759 of the best-match unicast route for the destination prefix 760 embedded in the Flow Specification. 762 b) There are no more specific unicast routes, when compared with 763 the flow destination prefix, that has been received from a 764 different neighboring AS than the best-match unicast route, which 765 has been determined in step a). 767 By originator of a BGP route, we mean either the BGP originator path 768 attribute, as used by route reflection, or the transport address of 769 the BGP peer, if this path attribute is not present. 771 BGP implementations MUST also enforce that the AS_PATH attribute of a 772 route received via the External Border Gateway Protocol (eBGP) 773 contains the neighboring AS in the left-most position of the AS_PATH 774 attribute. While this rule is optional in the BGP specification, it 775 becomes necessary to enforce it for security reasons. 777 The best-match unicast route may change over the time independently 778 of the Flow Specification NLRI. Therefore, a revalidation of the 779 Flow Specification NLRI MUST be performed whenever unicast routes 780 change. Revalidation is defined as retesting that clause a and 781 clause b above are true. 783 Explanation: 785 The underlying concept is that the neighboring AS that advertises the 786 best unicast route for a destination is allowed to advertise flow- 787 spec information that conveys a more or equally specific destination 788 prefix. Thus, as long as there are no more specific unicast routes, 789 received from a different neighboring AS, which would be affected by 790 that filtering rule. 792 The neighboring AS is the immediate destination of the traffic 793 described by the Flow Specification. If it requests these flows to 794 be dropped, that request can be honored without concern that it 795 represents a denial of service in itself. Supposedly, the traffic is 796 being dropped by the downstream autonomous system, and there is no 797 added value in carrying the traffic to it. 799 7. Traffic Filtering Actions 801 This specification defines a minimum set of filtering actions that it 802 standardizes as BGP extended community values [RFC4360]. This is not 803 meant to be an inclusive list of all the possible actions, but only a 804 subset that can be interpreted consistently across the network. 806 Additional actions can be defined as either requiring standards or as 807 vendor specific. 809 Implementations SHOULD provide mechanisms that map an arbitrary BGP 810 community value (normal or extended) to filtering actions that 811 require different mappings in different systems in the network. For 812 instance, providing packets with a worse-than-best-effort, per-hop 813 behavior is a functionality that is likely to be implemented 814 differently in different systems and for which no standard behavior 815 is currently known. Rather than attempting to define it here, this 816 can be accomplished by mapping a user-defined community value to 817 platform-/network-specific behavior via user configuration. 819 The default action for a traffic filtering Flow Specification is to 820 accept IP traffic that matches that particular rule. 822 This document defines the following extended communities values shown 823 in Table 2 in the form 0x8xnn where nn indicates the sub-type. 824 Encodings for these extended communities are described below. 826 +-----------+----------------------+--------------------------------+ 827 | community | action | encoding | 828 +-----------+----------------------+--------------------------------+ 829 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | 830 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | 831 | 0x8007 | traffic-action | bitmask | 832 | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value | 833 | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet | 834 | | | value | 835 | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value | 836 | 0x8009 | traffic-marking | DSCP value | 837 +-----------+----------------------+--------------------------------+ 839 Table 2: Traffic Action Extended Communities 841 Some traffic action communities may interfere with each other. 842 Section 7.6 of this specification provides rules for handling 843 interference between specific types of traffic actions, and error 844 handling based on [RFC7606]. Any additional definition of a traffic 845 actions specified by additional standards documents or vendor 846 documents MUST specify if the traffic action interacts with an 847 existing traffic actions, and provide error handling per [RFC7606]. 849 Multiple traffic actions may be present for a single NLRI. The 850 traffic actions are processed in ascending order of the sub-type 851 found in the BGP Extended Communities. If not all of them can be 852 processed the filter SHALL NOT be applied at all (for example: if for 853 a given flow there are the action communities rate-limit-bytes and 854 traffic-marking attached, and the plattform does not support one of 855 them also the other shall not be applied for that flow). 857 All traffic actions are specified as transitive BGP Extended 858 Communities. 860 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 862 The traffic-rate-bytes extended community uses the following extended 863 community encoding: 865 The first two octets carry the 2-octet id, which can be assigned from 866 a 2-byte AS number. When a 4-byte AS number is locally present, the 867 2 least significant bytes of such an AS number can be used. This 868 value is purely informational and should not be interpreted by the 869 implementation. 871 The remaining 4 octets carry the maximum rate information in IEEE 872 floating point [IEEE.754.1985] format, units being bytes per second. 873 A traffic-rate of 0 should result on all traffic for the particular 874 flow to be discarded. 876 Interferes with: No other BGP Flow Specification traffic action in 877 this document. 879 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD 881 The traffic-rate-packets extended community uses the same encoding as 882 the traffic-rate-bytes extended community. The floating point value 883 carries the maximum packet rate in packets per second. A traffic- 884 rate-packets of 0 should result in all traffic for the particular 885 flow to be discarded. 887 Interferes with: No other BGP Flow Specification traffic action in 888 this document. 890 7.3. Traffic-action (traffic-action) sub-type 0x07 892 The traffic-action extended community consists of 6 bytes of which 893 only the 2 least significant bits of the 6th byte (from left to 894 right) are currently defined. 896 40 41 42 43 44 45 46 47 897 +---+---+---+---+---+---+---+---+ 898 | reserved | S | T | 899 +---+---+---+---+---+---+---+---+ 901 where S and T are defined as: 903 o T: Terminal Action (bit 47): When this bit is set, the traffic 904 filtering engine will apply any subsequent filtering rules (as 905 defined by the ordering procedure). If not set, the evaluation of 906 the traffic filter stops when this rule is applied. 908 o S: Sample (bit 46): Enables traffic sampling and logging for this 909 Flow Specification. 911 o reserved: should always be set to 0 by the originator and not be 912 evaluated by the receiving BGP speaker. 914 The use of the Terminal Action (bit 47) may result in more than one 915 filter-rule matching a particular flow. All the flow actions from 916 these rules shall be collected and applied. If interfering actions 917 have been collected only the first occurence SHALL be applied. 918 However, if a single rule contains interfering actions this rule 919 SHALL still be handled as described in Section 7.6. 921 Interferes with: No other BGP Flow Specification traffic action in 922 this document. 924 7.4. RT Redirect (rt-redirect) sub-type 0x08 926 The redirect extended community allows the traffic to be redirected 927 to a VRF routing instance that lists the specified route-target in 928 its import policy. If several local instances match this criteria, 929 the choice between them is a local matter (for example, the instance 930 with the lowest Route Distinguisher value can be elected). This 931 extended community allows 3 different encodings formats for the 932 route-target (type 0x80, 0x81, 0x82). Is uses the same encoding as 933 the Route Target extended community [RFC4360]. 935 It should be noted that the low-order nibble of the Redirect's Type 936 field corresponds to the Route Target Extended Community format field 937 (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of 938 [RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended 939 Community remains 0x08 for all three encodings of the BGP Extended 940 Communities (AS 2-byte, AS 4-byte, and IPv4 address). 942 Interferes with: All other redirect functions. All redirect 943 functions are mutually exclusive. If this redirect function exists, 944 then no other redirect functions can be processed. 946 7.5. Traffic Marking (traffic-marking) sub-type 0x09 948 The traffic marking extended community instructs a system to modify 949 the DSCP bits of a transiting IP packet to the corresponding value. 950 This extended community is encoded as a sequence of 5 zero bytes 951 followed by the DSCP value encoded in the 6 least significant bits of 952 6th byte. 954 Interferes with: No other BGP Flow Specification traffic action in 955 this document. 957 7.6. Rules on Traffic Action Interference 959 Traffic actions may interfere with each other. If interfering 960 traffic actions are present for a single Flow Specification NLRI the 961 entire Flow Specification (irrespective if there are any other non 962 conflicting actions associated with the same Flow Specification) 963 SHALL be treated as BGP WITHDRAW. 965 This document defines 7 traffic actions which are interfering in the 966 following way: 968 1. Redirect-action-communities (0x8008, 0x8108, 0x8208): 970 The three redirect-communities are mutually exclusive. Only a 971 single redirect community may be associated with a Flow 972 Specification otherwise they are interfering. 974 2. All traffic-action communities (including redirect-actions): 976 Multiple occurences of the same (sub-type and type) traffic- 977 action associated with a Flow Specification are always 978 interfering. 980 When a traffic action is defined in a standards document the handling 981 of interaction with other/same traffic actions MUST be defined as 982 well. Invalid interactions between actions SHOULD NOT trigger a BGP 983 NOTIFICATION. All error handling for error conditions based on 984 [RFC7606]. 986 7.6.1. Examples 988 (rt-redirect vrf-a, rt-redirect vrf-b, traffic-rate-bytes 1Mbit/s) 990 RT-redirect vrf-a and rt-redirect vrf-b are interfering: The BGP 991 UPDATE is treated as WITHDRAW. 993 (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate-bytes 994 2Mbit/s) 996 Duplicate traffic-rate-bytes are interfering: The BGP UPDATE is 997 treated as WITHDRAW. 999 (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate- 1000 packets 1000) 1002 No interfering action communities: The BGP UPDATE is subject to 1003 further processing. 1005 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 1007 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1008 MPLS IP VPN [RFC4364] control plane, may have different traffic 1009 filtering requirements than Internet service providers. But also 1010 Internet service providers may use those VPNs for scenarios like 1011 having the Internet routing table in a VRF, resulting in the same 1012 traffic filtering requirements as defined for the global routing 1013 table environment within this document. This document proposes an 1014 additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used 1015 to propagate traffic filtering information in a BGP/MPLS VPN 1016 environment. 1018 The NLRI format for this address family consists of a fixed-length 1019 Route Distinguisher field (8 bytes) followed by a Flow Specification, 1020 following the encoding defined above in Section 4.2 of this document. 1021 The NLRI length field shall include both the 8 bytes of the Route 1022 Distinguisher as well as the subsequent Flow Specification. 1024 +------------------------------+ 1025 | length (0xnn or 0xfn nn) | 1026 +------------------------------+ 1027 | Route Distinguisher (8 bytes)| 1028 +------------------------------+ 1029 | NLRI value (variable) | 1030 +------------------------------+ 1032 Flow-spec NLRI for MPLS 1034 Propagation of this NLRI is controlled by matching Route Target 1035 extended communities associated with the BGP path advertisement with 1036 the VRF import policy, using the same mechanism as described in "BGP/ 1037 MPLS IP VPNs" [RFC4364]. 1039 Flow Specification rules received via this NLRI apply only to traffic 1040 that belongs to the VRF(s) in which it is imported. By default, 1041 traffic received from a remote PE is switched via an MPLS forwarding 1042 decision and is not subject to filtering. 1044 Contrary to the behavior specified for the non-VPN NLRI, flow rules 1045 are accepted by default, when received from remote PE routers. 1047 8.1. Validation Procedures for BGP/MPLS VPNs 1049 The validation procedures are the same as for IPv4. 1051 8.2. Traffic Actions Rules 1053 The traffic action rules are the same as for IPv4. 1055 9. Limitations of Previous Traffic Filtering Efforts 1057 9.1. Limitations in Previous DDoS Traffic Filtering Efforts 1059 The popularity of traffic-based, denial-of-service (DoS) attacks, 1060 which often requires the network operator to be able to use traffic 1061 filters for detection and mitigation, brings with it requirements 1062 that are not fully satisfied by existing tools. 1064 Increasingly, DoS mitigation requires coordination among several 1065 service providers in order to be able to identify traffic source(s) 1066 and because the volumes of traffic may be such that they will 1067 otherwise significantly affect the performance of the network. 1069 Several techniques are currently used to control traffic filtering of 1070 DoS attacks. Among those, one of the most common is to inject 1071 unicast route advertisements corresponding to a destination prefix 1072 being attacked (commonly known as remote triggered blackhole RTBH). 1073 One variant of this technique marks such route advertisements with a 1074 community that gets translated into a discard Next-Hop by the 1075 receiving router. Other variants attract traffic to a particular 1076 node that serves as a deterministic drop point. 1078 Using unicast routing advertisements to distribute traffic filtering 1079 information has the advantage of using the existing infrastructure 1080 and inter-AS communication channels. This can allow, for instance, a 1081 service provider to accept filtering requests from customers for 1082 address space they own. 1084 There are several drawbacks, however. An issue that is immediately 1085 apparent is the granularity of filtering control: only destination 1086 prefixes may be specified. Another area of concern is the fact that 1087 filtering information is intermingled with routing information. 1089 The mechanism defined in this document is designed to address these 1090 limitations. We use the Flow Specification NLRI defined above to 1091 convey information about traffic filtering rules for traffic that is 1092 subject to modified forwarding behavior (actions). The actions are 1093 defined as extended communities and include (but are not limited to) 1094 rate-limiting (including discard), traffic redirection, packet 1095 rewriting. 1097 9.2. Limitations in Previous BGP/MPLS Traffic Filtering 1099 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1100 MPLS IP VPN [RFC4364] control plane, may have different traffic 1101 filtering requirements than Internet service providers. 1103 In these environments, the VPN customer network often has traffic 1104 filtering capabilities towards their external network connections 1105 (e.g., firewall facing public network connection). Less common is 1106 the presence of traffic filtering capabilities between different VPN 1107 attachment sites. In an any-to-any connectivity model, which is the 1108 default, this means that site-to-site traffic is unfiltered. 1110 In circumstances where a security threat does get propagated inside 1111 the VPN customer network, there may not be readily available 1112 mechanisms to provide mitigation via traffic filter. 1114 But also Internet service providers may use those VPNs for scenarios 1115 like having the Internet routing table in a VRF. Therefore, 1116 limitations described in Section 9.1 also apply to this section. 1118 The BGP Flow Specification version 1 addresses these limitations. 1120 10. Traffic Monitoring 1122 Traffic filtering applications require monitoring and traffic 1123 statistics facilities. While this is an implementation-specific 1124 choice, implementations SHOULD provide: 1126 o A mechanism to log the packet header of filtered traffic. 1128 o A mechanism to count the number of matches for a given flow 1129 specification rule. 1131 11. IANA Considerations 1133 This section complies with [RFC7153]. 1135 11.1. AFI/SAFI Definitions 1137 IANA maintains a registry entitled "SAFI Values". For the purpose of 1138 this work, IANA updated the registry and allocated two additional 1139 SAFIs: 1141 +-------+------------------------------------------+----------------+ 1142 | Value | Name | Reference | 1143 +-------+------------------------------------------+----------------+ 1144 | 133 | IPv4 dissemination of Flow Specification | [this | 1145 | | rules | document] | 1146 | 134 | VPNv4 dissemination of Flow | [this | 1147 | | Specification rules | document] | 1148 +-------+------------------------------------------+----------------+ 1150 Table 3: Registry: SAFI Values 1152 11.2. Flow Component Definitions 1154 A Flow Specification consists of a sequence of flow components, which 1155 are identified by a an 8-bit component type. IANA has created and 1156 maintains a registry entitled "Flow Spec Component Types". This 1157 document defines the following Component Type Codes: 1159 +-------+--------------------+-----------------+ 1160 | Value | Name | Reference | 1161 +-------+--------------------+-----------------+ 1162 | 1 | Destination Prefix | [this document] | 1163 | 2 | Source Prefix | [this document] | 1164 | 3 | IP Protocol | [this document] | 1165 | 4 | Port | [this document] | 1166 | 5 | Destination port | [this document] | 1167 | 6 | Source port | [this document] | 1168 | 7 | ICMP type | [this document] | 1169 | 8 | ICMP code | [this document] | 1170 | 9 | TCP flags | [this document] | 1171 | 10 | Packet length | [this document] | 1172 | 11 | DSCP | [this document] | 1173 | 12 | Fragment | [this document] | 1174 +-------+--------------------+-----------------+ 1176 Table 4: Registry: Flow Spec Component Types 1178 In order to manage the limited number space and accommodate several 1179 usages, the following policies defined by [RFC5226] used: 1181 +--------------+-------------------------------+ 1182 | Range | Policy | 1183 +--------------+-------------------------------+ 1184 | 0 | Invalid value | 1185 | [1 .. 12] | Defined by this specification | 1186 | [13 .. 127] | Specification required | 1187 | [128 .. 255] | First Come First Served | 1188 +--------------+-------------------------------+ 1190 Table 5: Flow Spec Component Types Policies 1192 The specification of a particular "Flow Spec Component Type" must 1193 clearly identify what the criteria used to match packets forwarded by 1194 the router is. This criteria should be meaningful across router hops 1195 and not depend on values that change hop-by-hop such as TTL or Layer 1196 2 encapsulation. 1198 11.3. Extended Community Flow Specification Actions 1200 The Extended Community Flow Specification Action types defined in 1201 this document consist of two parts: 1203 Type (BGP Transitive Extended Community Type) 1205 Sub-Type 1207 For the type-part, IANA maintains a registry entitled "BGP Transitive 1208 Extended Community Types". For the purpose of this work (Section 7), 1209 IANA updated the registry to contain the values listed below: 1211 +-------+-----------------------------------------------+-----------+ 1212 | Type | Name | Reference | 1213 | Value | | | 1214 +-------+-----------------------------------------------+-----------+ 1215 | 0x80 | Generic Transitive Experimental Use Extended | [RFC7153] | 1216 | | Community (Sub-Types are defined in the | | 1217 | | "Generic Transitive Experimental Use Extended | | 1218 | | Community Sub-Types" registry) | | 1219 | 0x81 | Generic Transitive Experimental Use Extended | [this | 1220 | | Community Part 2 (Sub-Types are defined in | document] | 1221 | | the "Generic Transitive Experimental Use | [See | 1222 | | Extended Community Part 2 Sub-Types" | Note-1] | 1223 | | Registry) | | 1224 | 0x82 | Generic Transitive Experimental Use Extended | [this | 1225 | | Community Part 3 (Sub-Types are defined in | document] | 1226 | | the "Generic Transitive Experimental Use | [See | 1227 | | Extended Community Part 3 Sub-Types" | Note-1] | 1228 | | Registry) | | 1229 +-------+-----------------------------------------------+-----------+ 1231 Table 6: Registry: Generic Transitive Experimental Use Extended 1232 Community Types 1234 Note-1: This document replaces [RFC7674]. 1236 For the sub-type part of the extended community actions IANA 1237 maintains and updated the following registries: 1239 +----------+-----------------------------------------+--------------+ 1240 | Sub-Type | Name | Reference | 1241 | Value | | | 1242 +----------+-----------------------------------------+--------------+ 1243 | 0x06 | Flow spec traffic-rate-bytes | [this | 1244 | | | document] | 1245 | TBD | Flow spec traffic-rate-packets | [this | 1246 | | | document] | 1247 | 0x07 | Flow spec traffic-action (Use of the | [this | 1248 | | "Value" field is defined in the | document] | 1249 | | "Traffic Action Fields" registry) | [See Note-2] | 1250 | 0x08 | Flow spec rt-redirect AS-2byte format | [this | 1251 | | | document] | 1252 | 0x09 | Flow spec traffic-remarking | [this | 1253 | | | document] | 1254 +----------+-----------------------------------------+--------------+ 1256 Table 7: Registry: Generic Transitive Experimental Use Extended 1257 Community Sub-Types 1259 Note-2: This document replaces both [RFC7674] and [RFC5575]. 1261 +-------------+---------------------------+-------------------------+ 1262 | Sub-Type | Name | Reference | 1263 | Value | | | 1264 +-------------+---------------------------+-------------------------+ 1265 | 0x08 | Flow spec rt-redirect | [this document] [See | 1266 | | IPv4 format | Note-3] | 1267 +-------------+---------------------------+-------------------------+ 1269 Table 8: Registry: Generic Transitive Experimental Use Extended 1270 Community Part 2 Sub-Types 1272 +-------------+----------------------------+------------------------+ 1273 | Sub-Type | Name | Reference | 1274 | Value | | | 1275 +-------------+----------------------------+------------------------+ 1276 | 0x08 | Flow spec rt-redirect AS- | [this document] [See | 1277 | | 4byte format | Note-3] | 1278 +-------------+----------------------------+------------------------+ 1280 Table 9: Registry: Generic Transitive Experimental Use Extended 1281 Community Part 3 Sub-Types 1283 Note-3: This document replaces [RFC7674], and becomes the only 1284 reference for this table. 1286 The "traffic-action" extended community (Section 7.3) defined in this 1287 document has 46 unused bits, which can be used to convey additional 1288 meaning. IANA created and maintains a new registry entitled: 1289 "Traffic Action Fields". These values should be assigned via IETF 1290 Review rules only. The following traffic-action fields have been 1291 allocated: 1293 +-----+-----------------+-----------------+ 1294 | Bit | Name | Reference | 1295 +-----+-----------------+-----------------+ 1296 | 47 | Terminal Action | [this document] | 1297 | 46 | Sample | [this document] | 1298 +-----+-----------------+-----------------+ 1300 Table 10: Registry: Traffic Action Fields 1302 12. Security Considerations 1304 Inter-provider routing is based on a web of trust. Neighboring 1305 autonomous systems are trusted to advertise valid reachability 1306 information. If this trust model is violated, a neighboring 1307 autonomous system may cause a denial-of-service attack by advertising 1308 reachability information for a given prefix for which it does not 1309 provide service. 1311 As long as traffic filtering rules are restricted to match the 1312 corresponding unicast routing paths for the relevant prefixes, the 1313 security characteristics of this proposal are equivalent to the 1314 existing security properties of BGP unicast routing. 1316 Where it is not the case, this would open the door to further denial- 1317 of-service attacks. 1319 Enabling firewall-like capabilities in routers without centralized 1320 management could make certain failures harder to diagnose. For 1321 example, it is possible to allow TCP packets to pass between a pair 1322 of addresses but not ICMP packets. It is also possible to permit 1323 packets smaller than 900 or greater than 1000 bytes to pass between a 1324 pair of addresses, but not packets whose length is in the range 900- 1325 1000. Such behavior may be confusing and these capabilities should 1326 be used with care whether manually configured or coordinated through 1327 the protocol extensions described in this document. 1329 13. Original authors 1331 Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and 1332 Nischal Sheth were authors on [RFC5575], and therefore are 1333 contributing authors on this document. 1335 14. Acknowledgements 1337 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 1338 Morrow, Charlie Kaufman, and David Smith for their comments for the 1339 comments on the original [RFC5575]. Chaitanya Kodeboyina helped 1340 design the flow validation procedure; and Steven Lin and Jim Washburn 1341 ironed out all the details necessary to produce a working 1342 implementation in the original [RFC5575]. 1344 Additional the authors would like to thank Alexander Mayrhofer, 1345 Nicolas Fevrier and Job Snijders for their comments and review. 1347 15. References 1349 15.1. Normative References 1351 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1352 RFC 793, DOI 10.17487/RFC0793, September 1981, 1353 . 1355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1356 Requirement Levels", BCP 14, RFC 2119, 1357 DOI 10.17487/RFC2119, March 1997, 1358 . 1360 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1361 "Definition of the Differentiated Services Field (DS 1362 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1363 DOI 10.17487/RFC2474, December 1998, 1364 . 1366 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1367 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1368 DOI 10.17487/RFC4271, January 2006, 1369 . 1371 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1372 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1373 February 2006, . 1375 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1376 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1377 2006, . 1379 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1380 "Multiprotocol Extensions for BGP-4", RFC 4760, 1381 DOI 10.17487/RFC4760, January 2007, 1382 . 1384 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1385 LAN Service (VPLS) Using BGP for Auto-Discovery and 1386 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1387 . 1389 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1390 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1391 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1392 . 1394 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1395 IANA Considerations Section in RFCs", RFC 5226, 1396 DOI 10.17487/RFC5226, May 2008, 1397 . 1399 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1400 and D. McPherson, "Dissemination of Flow Specification 1401 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1402 . 1404 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 1405 Specific BGP Extended Community", RFC 5668, 1406 DOI 10.17487/RFC5668, October 2009, 1407 . 1409 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1410 and A. Bierman, Ed., "Network Configuration Protocol 1411 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1412 . 1414 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1415 Origin Authorizations (ROAs)", RFC 6482, 1416 DOI 10.17487/RFC6482, February 2012, 1417 . 1419 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1420 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1421 March 2014, . 1423 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1424 Patel, "Revised Error Handling for BGP UPDATE Messages", 1425 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1426 . 1428 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1429 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1430 October 2015, . 1432 15.2. Informative References 1434 [I-D.ietf-idr-flow-spec-v6] 1435 McPherson, D., Raszuk, R., Pithawala, B., 1436 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 1437 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 1438 v6-09 (work in progress), November 2017. 1440 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1441 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1442 . 1444 15.3. URIs 1446 [1] https://github.com/stoffi92/flowspec-cmp 1448 Appendix A. Comparison with RFC 5575 1450 This document includes numerous editorial changes to [RFC5575]. It 1451 is recommended to read the entire document. The authors, however 1452 want to point out the following technical changes to [RFC5575]: 1454 Section 4.2.3 defines a numeric operator and comparison bit 1455 combinations. In [RFC5575] the meaning of those bit combination 1456 was not explicitly defined and left open to the reader. 1458 Section 4.2.3 - Section 4.2.8, Section 4.2.10, Section 4.2.11 make 1459 use of the above numeric operator. The allowed length of the 1460 comparison value was not consistently defined in [RFC5575]. 1462 Section 7 defines all traffic action extended communities as 1463 transitive extended communities. [RFC5575] defined the traffic- 1464 rate action to be non-transitive and did not define the 1465 transitivity of the other action communities at all. 1467 Section 7.2 introduces a new traffic filtering action (traffic- 1468 rate-packets). This action did not exist in [RFC5575]. 1470 Section 7.4 contains the same redirect actions already defined in 1471 [RFC5575] however, these actions have been renamed to "rt- 1472 redirect" to make it clearer that the redirection is based on 1473 route-target. 1475 Section 7.6 introduces rules how updates of Flow Specifications 1476 shall be handled in case they contain interfering actions. 1477 Section 7.3 also cross-references this section. [RFC5575] did not 1478 define this. 1480 Authors' Addresses 1482 Susan Hares 1483 Huawei 1484 7453 Hickory Hill 1485 Saline, MI 48176 1486 USA 1488 Email: shares@ndzh.com 1489 Christoph Loibl 1490 Next Layer Communications 1491 Mariahilfer Guertel 37/7 1492 Vienna 1150 1493 AT 1495 Phone: +43 664 1176414 1496 Email: cl@tix.at 1498 Robert Raszuk 1499 Bloomberg LP 1500 731 Lexington Ave 1501 New York City, NY 10022 1502 USA 1504 Email: robert@raszuk.net 1506 Danny McPherson 1507 Verisign 1508 USA 1510 Email: dmcpherson@verisign.com 1512 Martin Bacher 1513 T-Mobile Austria 1514 Rennweg 97-99 1515 Vienna 1030 1516 AT 1518 Email: mb.ietf@gmail.com