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