idnits 2.17.1 draft-ietf-idr-rfc5575bis-05.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 (October 19, 2017) is 2381 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 1448 == Missing Reference: 'IEEE.754.1985' is mentioned on line 873, but not defined == Unused Reference: 'RFC4761' is defined on line 1386, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1411, but no explicit reference was found in the text == Unused Reference: 'RFC6482' is defined on line 1416, 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-08 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: April 22, 2018 R. Raszuk 7 Bloomberg LP 8 D. McPherson 9 Verisign 10 M. Bacher 11 T-Mobile Austria 12 October 19, 2017 14 Dissemination of Flow Specification Rules 15 draft-ietf-idr-rfc5575bis-05 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 April 22, 2018. 64 Copyright Notice 66 Copyright (c) 2017 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 number. 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 the same as the one used to identify a particular application 314 that uses this NLRI-type. 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 BGP NLRI type (AFI=1, SAFI=134) value, which can be used to 639 propagate traffic filtering information in a BGP/MPLS VPN 640 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 described above. The full python3 implementation including 682 unittests can be optained at https://github.com/stoffi92/flowspec-cmp 683 [1]. 685 import itertools 686 import ipaddress 688 def flow_rule_cmp(a, b): 689 for comp_a, comp_b in itertools.zip_longest(a.components, 690 b.components): 691 # If a component type does not exist in one rule 692 # this rule has lower precedence 693 if not comp_a: 694 return B_HAS_PRECEDENCE 695 if not comp_b: 696 return A_HAS_PRECEDENCE 697 # higher precedence for lower component type 698 if comp_a.component_type < comp_b.component_type: 699 return A_HAS_PRECEDENCE 700 if comp_a.component_type > comp_b.component_type: 701 return B_HAS_PRECEDENCE 702 # component types are equal -> type specific comparison 703 if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): 704 # assuming comp_a.value, comp_b.value of type ipaddress 705 if comp_a.value.overlaps(comp_b.value): 706 # longest prefixlen has precedence 707 if comp_a.value.prefixlen > comp_b.value.prefixlen: 708 return A_HAS_PRECEDENCE 709 if comp_a.value.prefixlen < comp_b.value.prefixlen: 711 return B_HAS_PRECEDENCE 712 # components equal -> continue with next component 713 elif comp_a.value > comp_b.value: 714 return B_HAS_PRECEDENCE 715 elif comp_a.value < comp_b.value: 716 return A_HAS_PRECEDENCE 717 else: 718 # assuming comp_a.value, comp_b.value of type bytearray 719 if len(comp_a.value) == len(comp_b.value): 720 if comp_a.value > comp_b.value: 721 return B_HAS_PRECEDENCE 722 if comp_a.value < comp_b.value: 723 return A_HAS_PRECEDENCE 724 # components equal -> continue with next component 725 else: 726 common = min(len(comp_a.value), len(comp_b.value)) 727 if comp_a.value[:common] > comp_b.value[:common]: 728 return B_HAS_PRECEDENCE 729 elif comp_a.value[:common] < comp_b.value[:common]: 730 return A_HAS_PRECEDENCE 731 # the first common bytes match 732 elif len(comp_a.value) > len(comp_b.value): 733 return A_HAS_PRECEDENCE 734 else: 735 return B_HAS_PRECEDENCE 736 return EQUAL 738 6. Validation Procedure 740 Flow Specifications received from a BGP peer that are accepted in the 741 respective Adj-RIB-In are used as input to the route selection 742 process. Although the forwarding attributes of two routes for the 743 same Flow Specification prefix may be the same, BGP is still required 744 to perform its path selection algorithm in order to select the 745 correct set of attributes to advertise. 747 The first step of the BGP Route Selection procedure (Section 9.1.2 of 748 [RFC4271] is to exclude from the selection procedure routes that are 749 considered non-feasible. In the context of IP routing information, 750 this step is used to validate that the NEXT_HOP attribute of a given 751 route is resolvable. 753 The concept can be extended, in the case of Flow Specification NLRI, 754 to allow other validation procedures. 756 A Flow Specification NLRI must be validated such that it is 757 considered feasible if and only if: 759 a) The originator of the Flow Specification matches the originator 760 of the best-match unicast route for the destination prefix 761 embedded in the Flow Specification. 763 b) There are no more specific unicast routes, when compared with 764 the flow destination prefix, that has been received from a 765 different neighboring AS than the best-match unicast route, which 766 has been determined in step a). 768 By originator of a BGP route, we mean either the BGP originator path 769 attribute, as used by route reflection, or the transport address of 770 the BGP peer, if this path attribute is not present. 772 BGP implementations MUST also enforce that the AS_PATH attribute of a 773 route received via the External Border Gateway Protocol (eBGP) 774 contains the neighboring AS in the left-most position of the AS_PATH 775 attribute. While this rule is optional in the BGP specification, it 776 becomes necessary to enforce it for security reasons. 778 The best-match unicast route may change over the time independently 779 of the Flow Specification NLRI. Therefore, a revalidation of the 780 Flow Specification NLRI MUST be performed whenever unicast routes 781 change. Revalidation is defined as retesting that clause a and 782 clause b above are true. 784 Explanation: 786 The underlying concept is that the neighboring AS that advertises the 787 best unicast route for a destination is allowed to advertise flow- 788 spec information that conveys a more or equally specific destination 789 prefix. Thus, as long as there are no more specific unicast routes, 790 received from a different neighboring AS, which would be affected by 791 that filtering rule. 793 The neighboring AS is the immediate destination of the traffic 794 described by the Flow Specification. If it requests these flows to 795 be dropped, that request can be honored without concern that it 796 represents a denial of service in itself. Supposedly, the traffic is 797 being dropped by the downstream autonomous system, and there is no 798 added value in carrying the traffic to it. 800 7. Traffic Filtering Actions 802 This specification defines a minimum set of filtering actions that it 803 standardizes as BGP extended community values [RFC4360]. This is not 804 meant to be an inclusive list of all the possible actions, but only a 805 subset that can be interpreted consistently across the network. 807 Additional actions can be defined as either requiring standards or as 808 vendor specific. 810 Implementations SHOULD provide mechanisms that map an arbitrary BGP 811 community value (normal or extended) to filtering actions that 812 require different mappings in different systems in the network. For 813 instance, providing packets with a worse-than-best-effort, per-hop 814 behavior is a functionality that is likely to be implemented 815 differently in different systems and for which no standard behavior 816 is currently known. Rather than attempting to define it here, this 817 can be accomplished by mapping a user-defined community value to 818 platform-/network-specific behavior via user configuration. 820 The default action for a traffic filtering Flow Specification is to 821 accept IP traffic that matches that particular rule. 823 This document defines the following extended communities values shown 824 in Table 2 in the form 0x8xnn where nn indicates the sub-type. 825 Encodings for these extended communities are described below. 827 +-----------+----------------------+--------------------------------+ 828 | community | action | encoding | 829 +-----------+----------------------+--------------------------------+ 830 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | 831 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | 832 | 0x8007 | traffic-action | bitmask | 833 | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value | 834 | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet | 835 | | | value | 836 | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value | 837 | 0x8009 | traffic-marking | DSCP value | 838 +-----------+----------------------+--------------------------------+ 840 Table 2: Traffic Action Extended Communities 842 Some traffic action communities may interfere with each other. 843 Section 7.6 of this specification provides rules for handling 844 interference between specific types of traffic actions, and error 845 handling based on [RFC7606]. Any additional definition of a traffic 846 actions specified by additional standards documents or vendor 847 documents MUST specify if the traffic action interacts with an 848 existing traffic actions, and provide error handling per [RFC7606]. 850 Multiple traffic actions may be present for a single NLRI. The 851 traffic actions are processed in ascending order of the sub-type 852 found in the BGP Extended Communities. If not all of them can be 853 processed the filter SHALL NOT be applied at all (for example: if for 854 a given flow there are the action communities rate-limit-bytes and 855 traffic-marking attached, and the plattform does not support one of 856 them also the other shall not be applied for that flow). 858 All traffic actions are specified as transitive BGP Extended 859 Communities. 861 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 863 The traffic-rate-bytes extended community uses the following extended 864 community encoding: 866 The first two octets carry the 2-octet id, which can be assigned from 867 a 2-byte AS number. When a 4-byte AS number is locally present, the 868 2 least significant bytes of such an AS number can be used. This 869 value is purely informational and should not be interpreted by the 870 implementation. 872 The remaining 4 octets carry the maximum rate information in IEEE 873 floating point [IEEE.754.1985] format, units being bytes per second. 874 A traffic-rate of 0 should result on all traffic for the particular 875 flow to be discarded. 877 Interferes with: No other BGP Flow Specification traffic action in 878 this document. 880 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD 882 The traffic-rate-packets extended community uses the same encoding as 883 the traffic-rate-bytes extended community. The floating point value 884 carries the maximum packet rate in packets per second. A traffic- 885 rate-packets of 0 should result in all traffic for the particular 886 flow to be discarded. 888 Interferes with: No other BGP Flow Specification traffic action in 889 this document. 891 7.3. Traffic-action (traffic-action) sub-type 0x07 893 The traffic-action extended community consists of 6 bytes of which 894 only the 2 least significant bits of the 6th byte (from left to 895 right) are currently defined. 897 40 41 42 43 44 45 46 47 898 +---+---+---+---+---+---+---+---+ 899 | reserved | S | T | 900 +---+---+---+---+---+---+---+---+ 902 where S and T are defined as: 904 o T: Terminal Action (bit 47): When this bit is set, the traffic 905 filtering engine will apply any subsequent filtering rules (as 906 defined by the ordering procedure). If not set, the evaluation of 907 the traffic filter stops when this rule is applied. 909 o S: Sample (bit 46): Enables traffic sampling and logging for this 910 Flow Specification. 912 o reserved: should always be set to 0 by the originator and not be 913 evaluated by the receiving BGP speaker. 915 The use of the Terminal Action (bit 47) may result in more than one 916 filter-rule matching a particular flow. All the flow actions from 917 these rules shall be collected and applied. If interfering actions 918 have been collected only the first occurence SHALL be applied. 919 However, if a single rule contains interfering actions this rule 920 SHALL still be handled as described in Section 7.6. 922 Interferes with: No other BGP Flow Specification traffic action in 923 this document. 925 7.4. RT Redirect (rt-redirect) sub-type 0x08 927 The redirect extended community allows the traffic to be redirected 928 to a VRF routing instance that lists the specified route-target in 929 its import policy. If several local instances match this criteria, 930 the choice between them is a local matter (for example, the instance 931 with the lowest Route Distinguisher value can be elected). This 932 extended community allows 3 different encodings formats for the 933 route-target (type 0x80, 0x81, 0x82). Is uses the same encoding as 934 the Route Target extended community [RFC4360]. 936 It should be noted that the low-order nibble of the Redirect's Type 937 field corresponds to the Route Target Extended Community format field 938 (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of 939 [RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended 940 Community remains 0x08 for all three encodings of the BGP Extended 941 Communities (AS 2-byte, AS 4-byte, and IPv4 address). 943 Interferes with: All other redirect functions. All redirect 944 functions are mutually exclusive. If this redirect function exists, 945 then no other redirect functions can be processed. 947 7.5. Traffic Marking (traffic-marking) sub-type 0x09 949 The traffic marking extended community instructs a system to modify 950 the DSCP bits of a transiting IP packet to the corresponding value. 951 This extended community is encoded as a sequence of 5 zero bytes 952 followed by the DSCP value encoded in the 6 least significant bits of 953 6th byte. 955 Interferes with: No other BGP Flow Specification traffic action in 956 this document. 958 7.6. Rules on Traffic Action Interference 960 Traffic actions may interfere with each other. If interfering 961 traffic actions are present for a single Flow Specification NLRI the 962 entire Flow Specification (irrespective if there are any other non 963 conflicting actions associated with the same Flow Specification) 964 SHALL be treated as BGP WITHDRAW. 966 This document defines 7 traffic actions which are interfering in the 967 following way: 969 1. Redirect-action-communities (0x8008, 0x8108, 0x8208): 971 The three redirect-communities are mutually exclusive. Only a 972 single redirect community may be associated with a Flow 973 Specification otherwise they are interfering. 975 2. All traffic-action communities (including redirect-actions): 977 Multiple occurences of the same (sub-type and type) traffic- 978 action associated with a Flow Specification are always 979 interfering. 981 When a traffic action is defined in a standards document the handling 982 of interaction with other/same traffic actions MUST be defined as 983 well. Invalid interactions between actions SHOULD NOT trigger a BGP 984 NOTIFICATION. All error handling for error conditions based on 985 [RFC7606]. 987 7.6.1. Examples 989 (rt-redirect vrf-a, rt-redirect vrf-b, traffic-rate-bytes 1Mbit/s) 991 RT-redirect vrf-a and rt-redirect vrf-b are interfering: The BGP 992 UPDATE is treated as WITHDRAW. 994 (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate-bytes 995 2Mbit/s) 997 Duplicate traffic-rate-bytes are interfering: The BGP UPDATE is 998 treated as WITHDRAW. 1000 (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate- 1001 packets 1000) 1003 No interfering action communities: The BGP UPDATE is subject to 1004 further processing. 1006 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 1008 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1009 MPLS IP VPN [RFC4364] control plane, may have different traffic 1010 filtering requirements than Internet service providers. But also 1011 Internet service providers may use those VPNs for scenarios like 1012 having the Internet routing table in a VRF, resulting in the same 1013 traffic filtering requirements as defined for the global routing 1014 table environment within this document. This document proposes an 1015 additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used 1016 to propagate traffic filtering information in a BGP/MPLS VPN 1017 environment. 1019 The NLRI format for this address family consists of a fixed-length 1020 Route Distinguisher field (8 bytes) followed by a Flow Specification, 1021 following the encoding defined above in Section 4.2 of this document. 1022 The NLRI length field shall include both the 8 bytes of the Route 1023 Distinguisher as well as the subsequent Flow Specification. 1025 +------------------------------+ 1026 | length (0xnn or 0xfn nn) | 1027 +------------------------------+ 1028 | Route Distinguisher (8 bytes)| 1029 +------------------------------+ 1030 | NLRI value (variable) | 1031 +------------------------------+ 1033 Flow-spec NLRI for MPLS 1035 Propagation of this NLRI is controlled by matching Route Target 1036 extended communities associated with the BGP path advertisement with 1037 the VRF import policy, using the same mechanism as described in "BGP/ 1038 MPLS IP VPNs" [RFC4364]. 1040 Flow Specification rules received via this NLRI apply only to traffic 1041 that belongs to the VRF(s) in which it is imported. By default, 1042 traffic received from a remote PE is switched via an MPLS forwarding 1043 decision and is not subject to filtering. 1045 Contrary to the behavior specified for the non-VPN NLRI, flow rules 1046 are accepted by default, when received from remote PE routers. 1048 8.1. Validation Procedures for BGP/MPLS VPNs 1050 The validation procedures are the same as for IPv4. 1052 8.2. Traffic Actions Rules 1054 The traffic action rules are the same as for IPv4. 1056 9. Limitations of Previous Traffic Filtering Efforts 1058 9.1. Limitations in Previous DDoS Traffic Filtering Efforts 1060 The popularity of traffic-based, denial-of-service (DoS) attacks, 1061 which often requires the network operator to be able to use traffic 1062 filters for detection and mitigation, brings with it requirements 1063 that are not fully satisfied by existing tools. 1065 Increasingly, DoS mitigation requires coordination among several 1066 service providers in order to be able to identify traffic source(s) 1067 and because the volumes of traffic may be such that they will 1068 otherwise significantly affect the performance of the network. 1070 Several techniques are currently used to control traffic filtering of 1071 DoS attacks. Among those, one of the most common is to inject 1072 unicast route advertisements corresponding to a destination prefix 1073 being attacked (commonly known as remote triggered blackhole RTBH). 1074 One variant of this technique marks such route advertisements with a 1075 community that gets translated into a discard Next-Hop by the 1076 receiving router. Other variants attract traffic to a particular 1077 node that serves as a deterministic drop point. 1079 Using unicast routing advertisements to distribute traffic filtering 1080 information has the advantage of using the existing infrastructure 1081 and inter-AS communication channels. This can allow, for instance, a 1082 service provider to accept filtering requests from customers for 1083 address space they own. 1085 There are several drawbacks, however. An issue that is immediately 1086 apparent is the granularity of filtering control: only destination 1087 prefixes may be specified. Another area of concern is the fact that 1088 filtering information is intermingled with routing information. 1090 The mechanism defined in this document is designed to address these 1091 limitations. We use the Flow Specification NLRI defined above to 1092 convey information about traffic filtering rules for traffic that is 1093 subject to modified forwarding behavior (actions). The actions are 1094 defined as extended communities and include (but are not limited to) 1095 rate-limiting (including discard), traffic redirection, packet 1096 rewriting. 1098 9.2. Limitations in Previous BGP/MPLS Traffic Filtering 1100 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1101 MPLS IP VPN [RFC4364] control plane, may have different traffic 1102 filtering requirements than Internet service providers. 1104 In these environments, the VPN customer network often has traffic 1105 filtering capabilities towards their external network connections 1106 (e.g., firewall facing public network connection). Less common is 1107 the presence of traffic filtering capabilities between different VPN 1108 attachment sites. In an any-to-any connectivity model, which is the 1109 default, this means that site-to-site traffic is unfiltered. 1111 In circumstances where a security threat does get propagated inside 1112 the VPN customer network, there may not be readily available 1113 mechanisms to provide mitigation via traffic filter. 1115 But also Internet service providers may use those VPNs for scenarios 1116 like having the Internet routing table in a VRF. Therefore, 1117 limitations described in Section 9.1 also apply to this section. 1119 The BGP Flow Specification version 1 addresses these limitations. 1121 10. Traffic Monitoring 1123 Traffic filtering applications require monitoring and traffic 1124 statistics facilities. While this is an implementation-specific 1125 choice, implementations SHOULD provide: 1127 o A mechanism to log the packet header of filtered traffic. 1129 o A mechanism to count the number of matches for a given flow 1130 specification rule. 1132 11. IANA Considerations 1134 This section complies with [RFC7153]. 1136 11.1. AFI/SAFI Definitions 1138 IANA maintains a registry entitled "SAFI Values". For the purpose of 1139 this work, IANA updated the registry and allocated two additional 1140 SAFIs: 1142 +-------+------------------------------------------+----------------+ 1143 | Value | Name | Reference | 1144 +-------+------------------------------------------+----------------+ 1145 | 133 | IPv4 dissemination of Flow Specification | [this | 1146 | | rules | document] | 1147 | 134 | VPNv4 dissemination of Flow | [this | 1148 | | Specification rules | document] | 1149 +-------+------------------------------------------+----------------+ 1151 Table 3: Registry: SAFI Values 1153 11.2. Flow Component Definitions 1155 A Flow Specification consists of a sequence of flow components, which 1156 are identified by a an 8-bit component type. IANA has created and 1157 maintains a registry entitled "Flow Spec Component Types". This 1158 document defines the following Component Type Codes: 1160 +-------+--------------------+-----------------+ 1161 | Value | Name | Reference | 1162 +-------+--------------------+-----------------+ 1163 | 1 | Destination Prefix | [this document] | 1164 | 2 | Source Prefix | [this document] | 1165 | 3 | IP Protocol | [this document] | 1166 | 4 | Port | [this document] | 1167 | 5 | Destination port | [this document] | 1168 | 6 | Source port | [this document] | 1169 | 7 | ICMP type | [this document] | 1170 | 8 | ICMP code | [this document] | 1171 | 9 | TCP flags | [this document] | 1172 | 10 | Packet length | [this document] | 1173 | 11 | DSCP | [this document] | 1174 | 12 | Fragment | [this document] | 1175 +-------+--------------------+-----------------+ 1177 Table 4: Registry: Flow Spec Component Types 1179 In order to manage the limited number space and accommodate several 1180 usages, the following policies defined by [RFC5226] used: 1182 +--------------+-------------------------------+ 1183 | Range | Policy | 1184 +--------------+-------------------------------+ 1185 | 0 | Invalid value | 1186 | [1 .. 12] | Defined by this specification | 1187 | [13 .. 127] | Specification required | 1188 | [128 .. 255] | First Come First Served | 1189 +--------------+-------------------------------+ 1191 Table 5: Flow Spec Component Types Policies 1193 The specification of a particular "Flow Spec Component Type" must 1194 clearly identify what the criteria used to match packets forwarded by 1195 the router is. This criteria should be meaningful across router hops 1196 and not depend on values that change hop-by-hop such as TTL or Layer 1197 2 encapsulation. 1199 11.3. Extended Community Flow Specification Actions 1201 The Extended Community Flow Specification Action types defined in 1202 this document consist of two parts: 1204 Type (BGP Transitive Extended Community Type) 1206 Sub-Type 1208 For the type-part, IANA maintains a registry entitled "BGP Transitive 1209 Extended Community Types". For the purpose of this work (Section 7), 1210 IANA updated the registry to contain the values listed below: 1212 +----------+--------------------------------------------+-----------+ 1213 | Sub-Type | Name | Reference | 1214 | Value | | | 1215 +----------+--------------------------------------------+-----------+ 1216 | 0x80 | Generic Transitive Experimental Use | [RFC7153] | 1217 | | Extended Community (Sub-Types are defined | | 1218 | | in the "Generic Transitive Experimental | | 1219 | | Use Extended Community Sub-Types" | | 1220 | | registry) | | 1221 | 0x81 | Generic Transitive Experimental Use | [this | 1222 | | Extended Community Part 2 (Sub-Types are | document] | 1223 | | defined in the "Generic Transitive | [See | 1224 | | Experimental Use Extended Community Part 2 | Note-1] | 1225 | | Sub-Types" Registry) | | 1226 | 0x82 | Generic Transitive Experimental Use | [this | 1227 | | Extended Community Part 3 (Sub-Types are | document] | 1228 | | defined in the "Generic Transitive | [See | 1229 | | Experimental Use Extended Community Part 3 | Note-1] | 1230 | | Sub-Types" Registry) | | 1231 +----------+--------------------------------------------+-----------+ 1233 Table 6: Registry: Generic Transitive Experimental Use Extended 1234 Community Types 1236 Note-1: This document replaces [RFC7674]. 1238 For the sub-type part of the extended community actions IANA 1239 maintains and updated the following registries: 1241 +----------+-----------------------------------------+--------------+ 1242 | Sub-Type | Name | Reference | 1243 | Value | | | 1244 +----------+-----------------------------------------+--------------+ 1245 | 0x06 | Flow spec traffic-rate-bytes | [this | 1246 | | | document] | 1247 | TBD | Flow spec traffic-rate-packets | [this | 1248 | | | document] | 1249 | 0x07 | Flow spec traffic-action (Use of the | [this | 1250 | | "Value" field is defined in the | document] | 1251 | | "Traffic Action Fields" registry) | [See Note-2] | 1252 | 0x08 | Flow spec rt-redirect AS-2byte format | [this | 1253 | | | document] | 1254 | 0x09 | Flow spec traffic-remarking | [this | 1255 | | | document] | 1256 +----------+-----------------------------------------+--------------+ 1258 Table 7: Registry: Generic Transitive Experimental Use Extended 1259 Community Sub-Types 1261 Note-2: This document replaces both [RFC7674] and [RFC5575]. 1263 +-------------+---------------------------+-------------------------+ 1264 | Sub-Type | Name | Reference | 1265 | Value | | | 1266 +-------------+---------------------------+-------------------------+ 1267 | 0x08 | Flow spec rt-redirect | [this document] [See | 1268 | | IPv4 format | Note-3] | 1269 +-------------+---------------------------+-------------------------+ 1271 Table 8: Registry: Generic Transitive Experimental Use Extended 1272 Community Part 2 Sub-Types 1274 +-------------+----------------------------+------------------------+ 1275 | Sub-Type | Name | Reference | 1276 | Value | | | 1277 +-------------+----------------------------+------------------------+ 1278 | 0x08 | Flow spec rt-redirect AS- | [this document] [See | 1279 | | 4byte format | Note-3] | 1280 +-------------+----------------------------+------------------------+ 1282 Table 9: Registry: Generic Transitive Experimental Use Extended 1283 Community Part 3 Sub-Types 1285 Note-3: This document replaces [RFC7674], and becomes the only 1286 reference for this table. 1288 The "traffic-action" extended community (Section 7.3) defined in this 1289 document has 46 unused bits, which can be used to convey additional 1290 meaning. IANA created and maintains a new registry entitled: 1291 "Traffic Action Fields". These values should be assigned via IETF 1292 Review rules only. The following traffic-action fields have been 1293 allocated: 1295 +-----+-----------------+-----------------+ 1296 | Bit | Name | Reference | 1297 +-----+-----------------+-----------------+ 1298 | 47 | Terminal Action | [this document] | 1299 | 46 | Sample | [this document] | 1300 +-----+-----------------+-----------------+ 1302 Table 10: Registry: Traffic Action Fields 1304 12. Security Considerations 1306 Inter-provider routing is based on a web of trust. Neighboring 1307 autonomous systems are trusted to advertise valid reachability 1308 information. If this trust model is violated, a neighboring 1309 autonomous system may cause a denial-of-service attack by advertising 1310 reachability information for a given prefix for which it does not 1311 provide service. 1313 As long as traffic filtering rules are restricted to match the 1314 corresponding unicast routing paths for the relevant prefixes, the 1315 security characteristics of this proposal are equivalent to the 1316 existing security properties of BGP unicast routing. 1318 Where it is not the case, this would open the door to further denial- 1319 of-service attacks. 1321 Enabling firewall-like capabilities in routers without centralized 1322 management could make certain failures harder to diagnose. For 1323 example, it is possible to allow TCP packets to pass between a pair 1324 of addresses but not ICMP packets. It is also possible to permit 1325 packets smaller than 900 or greater than 1000 bytes to pass between a 1326 pair of addresses, but not packets whose length is in the range 900- 1327 1000. Such behavior may be confusing and these capabilities should 1328 be used with care whether manually configured or coordinated through 1329 the protocol extensions described in this document. 1331 13. Original authors 1333 Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and 1334 Nischal Sheth were authors on [RFC5575], and therefore are 1335 contributing authors on this document. 1337 14. Acknowledgements 1339 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 1340 Morrow, Charlie Kaufman, and David Smith for their comments for the 1341 comments on the original [RFC5575]. Chaitanya Kodeboyina helped 1342 design the flow validation procedure; and Steven Lin and Jim Washburn 1343 ironed out all the details necessary to produce a working 1344 implementation in the original [RFC5575]. 1346 Additional the authors would like to thank Alexander Mayrhofer, 1347 Nicolas Fevrier and Job Snijders for their comments and review. 1349 15. References 1351 15.1. Normative References 1353 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1354 RFC 793, DOI 10.17487/RFC0793, September 1981, 1355 . 1357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1358 Requirement Levels", BCP 14, RFC 2119, 1359 DOI 10.17487/RFC2119, March 1997, 1360 . 1362 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1363 "Definition of the Differentiated Services Field (DS 1364 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1365 DOI 10.17487/RFC2474, December 1998, 1366 . 1368 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1369 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1370 DOI 10.17487/RFC4271, January 2006, 1371 . 1373 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1374 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1375 February 2006, . 1377 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1378 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1379 2006, . 1381 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1382 "Multiprotocol Extensions for BGP-4", RFC 4760, 1383 DOI 10.17487/RFC4760, January 2007, 1384 . 1386 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1387 LAN Service (VPLS) Using BGP for Auto-Discovery and 1388 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1389 . 1391 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1392 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1393 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1394 . 1396 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1397 IANA Considerations Section in RFCs", RFC 5226, 1398 DOI 10.17487/RFC5226, May 2008, 1399 . 1401 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1402 and D. McPherson, "Dissemination of Flow Specification 1403 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1404 . 1406 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 1407 Specific BGP Extended Community", RFC 5668, 1408 DOI 10.17487/RFC5668, October 2009, 1409 . 1411 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1412 and A. Bierman, Ed., "Network Configuration Protocol 1413 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1414 . 1416 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1417 Origin Authorizations (ROAs)", RFC 6482, 1418 DOI 10.17487/RFC6482, February 2012, 1419 . 1421 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1422 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1423 March 2014, . 1425 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1426 Patel, "Revised Error Handling for BGP UPDATE Messages", 1427 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1428 . 1430 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1431 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1432 October 2015, . 1434 15.2. Informative References 1436 [I-D.ietf-idr-flow-spec-v6] 1437 McPherson, D., Raszuk, R., Pithawala, B., 1438 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 1439 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 1440 v6-08 (work in progress), March 2017. 1442 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1443 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1444 . 1446 15.3. URIs 1448 [1] https://github.com/stoffi92/flowspec-cmp 1450 Appendix A. Comparison with RFC 5575 1452 This document includes numerous editorial changes to [RFC5575]. It 1453 is recommended to read the entire document. The authors, however 1454 want to point out the following technical changes to [RFC5575]: 1456 Section 4.2.3 defines a numeric operator and comparison bit 1457 combinations. In [RFC5575] the meaning of those bit combination 1458 was not explicitly defined and left open to the reader. 1460 Section 4.2.3 - Section 4.2.8, Section 4.2.10, Section 4.2.11 make 1461 use of the above numeric operator. The allowed length of the 1462 comparison value was not consistently defined in [RFC5575]. 1464 Section 7 defines all traffic action extended communities as 1465 transitive extended communities. [RFC5575] defined the traffic- 1466 rate action to be non-transitive and did not define the 1467 transitivity of the other action communities at all. 1469 Section 7.2 introduces a new traffic filtering action (traffic- 1470 rate-packets). This action did not exist in [RFC5575]. 1472 Section 7.4 contains the same redirect actions already defined in 1473 [RFC5575] however, these actions have been renamed to "rt- 1474 redirect" to make it clearer that the redirection is based on 1475 route-target. 1477 Section 7.6 introduces rules how updates of Flow Specifications 1478 shall be handled in case they contain interfering actions. 1479 Section 7.3 also cross-references this section. [RFC5575] did not 1480 define this. 1482 Authors' Addresses 1484 Susan Hares 1485 Huawei 1486 7453 Hickory Hill 1487 Saline, MI 48176 1488 USA 1490 Email: shares@ndzh.com 1491 Christoph Loibl 1492 Next Layer Communications 1493 Mariahilfer Guertel 37/7 1494 Vienna 1150 1495 AT 1497 Phone: +43 664 1176414 1498 Email: cl@tix.at 1500 Robert Raszuk 1501 Bloomberg LP 1502 731 Lexington Ave 1503 New York City, NY 10022 1504 USA 1506 Email: robert@raszuk.net 1508 Danny McPherson 1509 Verisign 1510 USA 1512 Email: dmcpherson@verisign.com 1514 Martin Bacher 1515 T-Mobile Austria 1516 Rennweg 97-99 1517 Vienna 1030 1518 AT 1520 Email: mb.ietf@gmail.com