idnits 2.17.1 draft-ietf-idr-rfc5575bis-02.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 RFC5575, but the abstract doesn't seem to directly say this. It does mention RFC5575 though, so this could be OK. -- The draft header indicates that this document updates RFC7674, but the abstract doesn't seem to mention this, which it should. -- 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 (June 29, 2017) is 2492 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 580 -- Looks like a reference, but probably isn't: '139' on line 580 == Missing Reference: 'IEEE.754.1985' is mentioned on line 836, but not defined == Missing Reference: 'Note-2' is mentioned on line 1215, but not defined == Unused Reference: 'RFC4761' is defined on line 1354, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 1359, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1379, but no explicit reference was found in the text == Unused Reference: 'RFC6482' is defined on line 1384, 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 (~~), 9 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 (if approved) R. Raszuk 5 Updates: 7674 (if approved) Bloomberg LP 6 Intended status: Standards Track D. McPherson 7 Expires: December 31, 2017 Verisign 8 C. Loibl 9 Next Layer Communications 10 M. Bacher 11 T-Mobile Austria 12 June 29, 2017 14 Dissemination of Flow Specification Rules 15 draft-ietf-idr-rfc5575bis-02 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 December 31, 2017. 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 130 1. Introduction 132 Modern IP routers contain both the capability to forward traffic 133 according to IP prefixes as well as to classify, shape, rate limit, 134 filter, or redirect packets based on administratively defined 135 policies. 137 These traffic policy mechanisms allow the router to define match 138 rules that operate on multiple fields of the packet header. Actions 139 such as the ones described above can be associated with each rule. 141 The n-tuple consisting of the matching criteria defines an aggregate 142 traffic flow specification. The matching criteria can include 143 elements such as source and destination address prefixes, IP 144 protocol, and transport protocol port numbers. 146 This document defines a general procedure to encode flow 147 specification rules for aggregated traffic flows so that they can be 148 distributed as a BGP [RFC5575] NLRI. Additionally, we define the 149 required mechanisms to utilize this definition to the problem of 150 immediate concern to the authors: intra- and inter-provider 151 distribution of traffic filtering rules to filter (distributed) 152 denial-of-service (DoS) attacks. 154 By expanding routing information with flow specifications, the 155 routing system can take advantage of the ACL (Access Control List) or 156 firewall capabilities in the router's forwarding path. Flow 157 specifications can be seen as more specific routing entries to a 158 unicast prefix and are expected to depend upon the existing unicast 159 data information. 161 A flow specification received from an external autonomous system will 162 need to be validated against unicast routing before being accepted. 163 If the aggregate traffic flow defined by the unicast destination 164 prefix is forwarded to a given BGP peer, then the local system can 165 safely install more specific flow rules that may result in different 166 forwarding behavior, as requested by this system. 168 The key technology components required to address the class of 169 problems targeted by this document are: 171 1. Efficient point-to-multipoint distribution of control plane 172 information. 174 2. Inter-domain capabilities and routing policy support. 176 3. Tight integration with unicast routing, for verification 177 purposes. 179 Items 1 and 2 have already been addressed using BGP for other types 180 of control plane information. Close integration with BGP also makes 181 it feasible to specify a mechanism to automatically verify flow 182 information against unicast routing. These factors are behind the 183 choice of BGP as the carrier of flow specification information. 185 As with previous extensions to BGP, this specification makes it 186 possible to add additional information to Internet routers. These 187 are limited in terms of the maximum number of data elements they can 188 hold as well as the number of events they are able to process in a 189 given unit of time. The authors believe that, as with previous 190 extensions, service providers will be careful to keep information 191 levels below the maximum capacity of their devices. 193 In many deployments of BGP Flow Specification, the flow specification 194 information has replace existing host length route advertisements. 196 Experience with previous BGP extensions has also shown that the 197 maximum capacity of BGP speakers has been gradually increased 198 according to expected loads. Taking into account Internet unicast 199 routing as well as additional applications as they gain popularity. 201 From an operational perspective, the utilization of BGP as the 202 carrier for this information allows a network service provider to 203 reuse both internal route distribution infrastructure (e.g., route 204 reflector or confederation design) and existing external 205 relationships (e.g., inter-domain BGP sessions to a customer 206 network). 208 While it is certainly possible to address this problem using other 209 mechanisms, this solution has been utilized in deployments because of 210 the substantial advantage of being an incremental addition to already 211 deployed mechanisms. 213 In current deployments, the information distributed by the flow-spec 214 extension is originated both manually as well as automatically. The 215 latter by systems that are able to detect malicious flows. When 216 automated systems are used, care should be taken to ensure their 217 correctness as well as to limit the number and advertisement rate of 218 flow routes. 220 This specification defines required protocol extensions to address 221 most common applications of IPv4 unicast and VPNv4 unicast filtering. 222 The same mechanism can be reused and new match criteria added to 223 address similar filtering needs for other BGP address families such 224 as IPv6 families [I-D.ietf-idr-flow-spec-v6], 226 2. Definitions of Terms Used in This Memo 228 NLRI - Network Layer Reachability Information. 230 RIB - Routing Information Base. 232 Loc-RIB - Local RIB. 234 AS - Autonomous System number. 236 VRF - Virtual Routing and Forwarding instance. 238 PE - Provider Edge router 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in [RFC2119] 244 3. Flow Specifications 246 A flow specification is an n-tuple consisting of several matching 247 criteria that can be applied to IP traffic. A given IP packet is 248 said to match the defined flow if it matches all the specified 249 criteria. 251 A given flow may be associated with a set of attributes, depending on 252 the particular application; such attributes may or may not include 253 reachability information (i.e., NEXT_HOP). Well-known or AS-specific 254 community attributes can be used to encode a set of predetermined 255 actions. 257 A particular application is identified by a specific (Address Family 258 Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair 259 [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs 260 should be treated independently from each other in order to assure 261 non-interference between distinct applications. 263 BGP itself treats the NLRI as an opaque key to an entry in its 264 databases. Entries that are placed in the Loc-RIB are then 265 associated with a given set of semantics, which is application 266 dependent. This is consistent with existing BGP applications. For 267 instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast 268 reverse-path information (AFI=1, SAFI=2) are handled by BGP without 269 any particular semantics being associated with them until installed 270 in the Loc-RIB. 272 Standard BGP policy mechanisms, such as UPDATE filtering by NLRI 273 prefix as well as community matching and manipulation, MUST apply to 274 the Flow specification defined NLRI-type, especially in an inter- 275 domain environment. Network operators can also control propagation 276 of such routing updates by enabling or disabling the exchange of a 277 particular (AFI, SAFI) pair on a given BGP peering session. 279 4. Dissemination of IPv4 FLow Specification Information 281 We define a "Flow Specification" NLRI type (Figure 1) that may 282 include several components such as destination prefix, source prefix, 283 protocol, ports, and others (see Section 4.2 below). This NLRI is 284 treated as an opaque bit string prefix by BGP. Each bit string 285 identifies a key to a database entry with which a set of attributes 286 can be associated. 288 This NLRI information is encoded using MP_REACH_NLRI and 289 MP_UNREACH_NLRI attributes as defined in [RFC4760]. Whenever the 290 corresponding application does not require Next-Hop information, this 291 shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI 292 attribute and ignored on receipt. 294 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 295 a 1- or 2-octet NLRI length field followed by a variable-length NLRI 296 value. The NLRI length is expressed in octets. 298 +------------------------------+ 299 | length (0xnn or 0xfn nn) | 300 +------------------------------+ 301 | NLRI value (variable) | 302 +------------------------------+ 304 Figure 1: Flow-spec NLRI for IPv4 306 Implementations wishing to exchange flow specification rules MUST use 307 BGP's Capability Advertisement facility to exchange the Multiprotocol 308 Extension Capability Code (Code 1) as defined in [RFC4760]. The 309 (AFI, SAFI) pair carried in the Multiprotocol Extension Capability 310 MUST be the same as the one used to identify a particular application 311 that uses this NLRI-type. 313 4.1. Length Encoding 315 o If the NLRI length value is smaller than 240 (0xf0 hex), the 316 length field can be encoded as a single octet. 318 o Otherwise, it is encoded as an extended-length 2-octet value in 319 which the most significant nibble of the first byte is all ones. 321 In figure 1 above, values less-than 240 are encoded using two hex 322 digits (0xnn). Values above 239 are encoded using 3 hex digits 323 (0xfnnn). The highest value that can be represented with this 324 encoding is 4095. The value 241 is encoded as 0xf0f1. 326 4.2. NLRI Value Encoding 328 The Flow specification NLRI-type consists of several optional 329 subcomponents. A specific packet is considered to match the flow 330 specification when it matches the intersection (AND) of all the 331 components present in the specification. 333 The encoding of each of the NLRI components begins with a type field 334 (1 octet) followed by a variable length parameter. Section 4.2.1 to 335 Section 4.2.12 define component types and parameter encodings for the 336 IPv4 IP layer and transport layer headers. IPv6 NLRI component types 337 are described in [I-D.ietf-idr-flow-spec-v6]. 339 Flow specification components must follow strict type ordering by 340 increasing numerical order. A given component type may or may not be 341 present in the specification, but if present, it MUST precede any 342 component of higher numeric type value. 344 All combinations of component types within a single NLRI are allowed, 345 even if the combination makes no sense from a semantical perspective. 346 If a given component type within a prefix in unknown, the prefix in 347 question cannot be used for traffic filtering purposes by the 348 receiver. Since a flow specification has the semantics of a logical 349 AND of all components, if a component is FALSE, by definition it 350 cannot be applied. However, for the purposes of BGP route 351 propagation, this prefix should still be transmitted since BGP route 352 distribution is independent on NLRI semantics. 354 The encoding is chosen in order to allow for future 355 extensibility. 357 4.2.1. Type 1 - Destination Prefix 359 Encoding: 361 Defines: the destination prefix to match. Prefixes are encoded as 362 in BGP UPDATE messages, a length in bits is followed by enough 363 octets to contain the prefix information. 365 4.2.2. Type 2 - Source Prefix 367 Encoding: 369 Defines the source prefix to match. 371 4.2.3. Type 3 - IP Protocol 373 Encoding: 375 Contains a set of {operator, value} pairs that are used to match 376 the IP protocol value byte in IP packets. 378 The operator byte is encoded as: 380 0 1 2 3 4 5 6 7 381 +---+---+---+---+---+---+---+---+ 382 | e | a | len | 0 |lt |gt |eq | 383 +---+---+---+---+---+---+---+---+ 385 Numeric operator 387 e - end-of-list bit. Set in the last {op, value} pair in the 388 list. 390 a - AND bit. If unset, the previous term is logically ORed with 391 the current one. If set, the operation is a logical AND. It 392 should be unset in the first operator byte of a sequence. The AND 393 operator has higher priority than OR for the purposes of 394 evaluating logical expressions. 396 len - length of the value field for this operand encodes 1 (00) - 397 4 (11) bytes. Type 3 flow component values are always encoded as 398 single byte (len = 00). 400 lt - less than comparison between data and value. 402 gt - greater than comparison between data and value. 404 eq - equality between data and value. 406 The bits lt, gt, and eq can be combined to produce "less or equal", 407 "greater or equal", and inequality values. 409 +----+----+----+----------------------------------+ 410 | lt | gt | eq | Resulting operation | 411 +----+----+----+----------------------------------+ 412 | 0 | 0 | 0 | true (independent of the value) | 413 | 0 | 0 | 1 | == (equal) | 414 | 0 | 1 | 0 | > (greater than) | 415 | 0 | 1 | 1 | >= (greater than or equal) | 416 | 1 | 0 | 0 | < (less than) | 417 | 1 | 0 | 1 | <= (less than or equal) | 418 | 1 | 1 | 0 | != (not equal value) | 419 | 1 | 1 | 1 | false (independent of the value) | 420 +----+----+----+----------------------------------+ 422 Table 1: Comparison operation combinations 424 4.2.4. Type 4 - Port 426 Encoding: 428 Defines a list of {operator, value} pairs that matches source OR 429 destination TCP/UDP ports. This list is encoded using the numeric 430 operator format defined in Section 4.2.3. Values are encoded as 431 1- or 2-byte quantities. 433 Port, source port, and destination port components evaluate to 434 FALSE if the IP protocol field of the packet has a value other 435 than TCP or UDP, if the packet is fragmented and this is not the 436 first fragment, or if the system in unable to locate the transport 437 header. Different implementations may or may not be able to 438 decode the transport header in the presence of IP options or 439 Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. 441 4.2.5. Type 5 - Destination Port 443 Encoding: 445 Defines a list of {operator, value} pairs used to match the 446 destination port of a TCP or UDP packet. This list is encoded 447 using the numeric operator format defined in Section 4.2.3. 448 Values are encoded as 1- or 2-byte quantities. 450 4.2.6. Type 6 - Source Port 452 Encoding: 454 Defines a list of {operator, value} pairs used to match the source 455 port of a TCP or UDP packet. This list is encoded using the 456 numeric operator format defined in Section 4.2.3. Values are 457 encoded as 1- or 2-byte quantities. 459 4.2.7. Type 7 - ICMP type 461 Encoding: 463 Defines a list of {operator, value} pairs used to match the type 464 field of an ICMP packet. This list is encoded using the numeric 465 operator format defined in Section 4.2.3. Values are encoded 466 using a single byte. 468 The ICMP type specifiers evaluate to FALSE whenever the protocol 469 value is not ICMP. 471 4.2.8. Type 8 - ICMP code 473 Encoding: 475 Defines a list of {operator, value} pairs used to match the code 476 field of an ICMP packet. This list is encoded using the numeric 477 operator format defined in Section 4.2.3. Values are encoded 478 using a single byte. 480 The ICMP code specifiers evaluate to FALSE whenever the protocol 481 value is not ICMP. 483 4.2.9. Type 9 - TCP flags 485 Encoding: 487 Bitmask values can be encoded as a 1- or 2-byte bitmask. When a 488 single byte is specified, it matches byte 13 of the TCP header 489 [RFC0793], which contains bits 8 though 15 of the 4th 32-bit word. 490 When a 2-byte encoding is used, it matches bytes 12 and 13 of the 491 TCP header with the data offset field having a "don't care" value. 493 This component evaluates to FALSE for packets that are not TCP 494 packets. 496 This type uses the bitmask operand format, which differs from the 497 numeric operator format in the lower nibble. 499 0 1 2 3 4 5 6 7 500 +---+---+---+---+---+---+---+---+ 501 | e | a | len | 0 | 0 |not| m | 502 +---+---+---+---+---+---+---+---+ 504 Bitmask format 506 e, a, len - Most significant nibble: (end-of-list bit, AND bit, and 507 length field), as defined for in the numeric operator format in 508 Section 4.2.3. 510 not - NOT bit. If set, logical negation of operation. 512 m - Match bit. If set, this is a bitwise match operation defined 513 as "(data AND value) == value"; if unset, (data AND value) 514 evaluates to TRUE if any of the bits in the value mask are set in 515 the data 517 4.2.10. Type 10 - Packet length 519 Encoding: 521 Defines a list of {operator, value} pairs used to match on the 522 total IP packet length (excluding Layer 2 but including IP 523 header). This list is encoded using the numeric operator format 524 defined in Section 4.2.3. Values are encoded using 1- or 2-byte 525 quantities. 527 4.2.11. Type 11 - DSCP (Diffserv Code Point) 529 Encoding: 531 Defines a list of {operator, value} pairs used to match the 6-bit 532 DSCP field [RFC2474]. This list is encoded using the numeric 533 operator format defined in Section 4.2.3. Values are encoded 534 using a single byte. The two most significant bits are zero and 535 the six least significant bits contain the DSCP value. 537 4.2.12. Type 12 - Fragment 539 Encoding: 541 Uses bitmask operand format defined in Section 4.2.9. 543 0 1 2 3 4 5 6 7 544 +---+---+---+---+---+---+---+---+ 545 | Reserved |LF |FF |IsF|DF | 546 +---+---+---+---+---+---+---+---+ 548 Bitmask values: 550 Bit 7 - Don't fragment (DF) 552 Bit 6 - Is a fragment (IsF) 554 Bit 5 - First fragment (FF) 556 Bit 4 - Last fragment (LF) 558 4.3. Examples of Encodings 560 An example of a flow specification encoding for: "all packets to 561 10.0.1/24 and TCP port 25". 563 +------------------+----------+----------+ 564 | destination | proto | port | 565 +------------------+----------+----------+ 566 | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | 567 +------------------+----------+----------+ 569 Decode for protocol: 571 +-------+----------+------------------------------+ 572 | Value | | | 573 +-------+----------+------------------------------+ 574 | 0x03 | type | | 575 | 0x81 | operator | end-of-list, value size=1, = | 576 | 0x06 | value | | 577 +-------+----------+------------------------------+ 579 An example of a flow specification encoding for: "all packets to 580 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". 582 +------------------+----------+-------------------------+ 583 | destination | source | port | 584 +------------------+----------+-------------------------+ 585 | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | 586 +------------------+----------+-------------------------+ 588 Decode for port: 590 +--------+----------+------------------------------+ 591 | Value | | | 592 +--------+----------+------------------------------+ 593 | 0x04 | type | | 594 | 0x03 | operator | size=1, >= | 595 | 0x89 | value | 137 | 596 | 0x45 | operator | "AND", value size=1, <= | 597 | 0x8b | value | 139 | 598 | 0x91 | operator | end-of-list, value-size=2, = | 599 | 0x1f90 | value | 8080 | 600 +--------+----------+------------------------------+ 602 This constitutes an NLRI with an NLRI length of 16 octets. 604 5. Traffic Filtering 606 Traffic filtering policies have been traditionally considered to be 607 relatively static. Limitations of the static mechanisms caused this 608 mechanism to be designed for the three new applications of traffic 609 filtering (prevention of traffic-based, denial-of-service (DOS) 610 attacks, traffic filtering in the context of BGP/MPLS VPN service, 611 and centralized traffic control for SDN/NFV networks) requires 612 coordination among service providers and/or coordination among the AS 613 within a service provider. Section 8 has details on the limitation 614 of previous mechanisms and why BGP Flow Specification version 1 615 provides a solution for to prevent DOS and aid BGP/MPLS VPN filtering 616 rules. 618 This flow specification NLRI defined above to convey information 619 about traffic filtering rules for traffic that should be discarded or 620 handled in manner specified by a set of pre-defined actions (which 621 are defined in BGP Extended Communities). This mechanism is 622 primarily designed to allow an upstream autonomous system to perform 623 inbound filtering in their ingress routers of traffic that a given 624 downstream AS wishes to drop. 626 In order to achieve this goal, this draft specifies two application 627 specific NLRI identifiers that provide traffic filters, and a set of 628 actions encoding in BGP Extended Communities. The two application 629 specific NLRI identifiers are: 631 o IPv4 flow specification identifier (AFI=1, SAFI=133) along with 632 specific semantic rules for IPv4 routes, and 634 o BGP NLRI type (AFI=1, SAFI=134) value, which can be used to 635 propagate traffic filtering information in a BGP/MPLS VPN 636 environment. 638 Distribution of the IPv4 Flow specification is described in section 639 6, and distibution of BGP/MPLS traffic flow specification is 640 described in section 8. The traffic filtering actions are described 641 in section 7. 643 5.1. Ordering of Traffic Filtering Rules 645 With traffic filtering rules, more than one rule may match a 646 particular traffic flow. Thus, it is necessary to define the order 647 at which rules get matched and applied to a particular traffic flow. 648 This ordering function must be such that it must not depend on the 649 arrival order of the flow specification's rules and must be 650 consistent in the network. 652 The relative order of two flow specification rules is determined by 653 comparing their respective components. The algorithm starts by 654 comparing the left-most components of the rules. If the types 655 differ, the rule with lowest numeric type value has higher precedence 656 (and thus will match before) than the rule that doesn't contain that 657 component type. If the component types are the same, then a type- 658 specific comparison is performed. 660 For IP prefix values (IP destination and source prefix) precedence is 661 given to the lowest IP value of the common prefix length; if the 662 common prefix is equal, then the most specific prefix has precedence. 664 For all other component types, unless otherwise specified, the 665 comparison is performed by comparing the component data as a binary 666 string using the memcmp() function as defined by the ISO C standard. 667 For strings of different lengths, the common prefix is compared. If 668 equal, the longest string is considered to have higher precedence 669 than the shorter one. 671 Pseudocode: 673 flow_rule_cmp (a, b) 674 { 675 comp1 = next_component(a); 676 comp2 = next_component(b); 677 while (comp1 || comp2) { 678 // component_type returns infinity on end-of-list 679 if (component_type(comp1) < component_type(comp2)) { 680 return A_HAS_PRECEDENCE; 681 } 682 if (component_type(comp1) > component_type(comp2)) { 683 return B_HAS_PRECEDENCE; 684 } 686 if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) { 687 common = MIN(prefix_length(comp1), prefix_length(comp2)); 688 cmp = prefix_compare(comp1, comp2, common); 689 // not equal, lowest value has precedence 690 // equal, longest match has precedence 691 } else { 692 common = 693 MIN(component_length(comp1), component_length(comp2)); 694 cmp = memcmp(data(comp1), data(comp2), common); 695 // not equal, lowest value has precedence 696 // equal, longest string has precedence 697 } 698 } 699 return EQUAL; 700 } 702 6. Validation Procedure 704 Flow specifications received from a BGP peer that are accepted in the 705 respective Adj-RIB-In are used as input to the route selection 706 process. Although the forwarding attributes of two routes for the 707 same flow specification prefix may be the same, BGP is still required 708 to perform its path selection algorithm in order to select the 709 correct set of attributes to advertise. 711 The first step of the BGP Route Selection procedure (Section 9.1.2 of 712 [RFC4271] is to exclude from the selection procedure routes that are 713 considered non-feasible. In the context of IP routing information, 714 this step is used to validate that the NEXT_HOP attribute of a given 715 route is resolvable. 717 The concept can be extended, in the case of flow specification NLRI, 718 to allow other validation procedures. 720 A flow specification NLRI must be validated such that it is 721 considered feasible if and only if: 723 a) The originator of the flow specification matches the originator 724 of the best-match unicast route for the destination prefix 725 embedded in the flow specification. 727 b) There are no more specific unicast routes, when compared with 728 the flow destination prefix, that has been received from a 729 different neighboring AS than the best-match unicast route, which 730 has been determined in step a). 732 By originator of a BGP route, we mean either the BGP originator path 733 attribute, as used by route reflection, or the transport address of 734 the BGP peer, if this path attribute is not present. 736 BGP implementations MUST also enforce that the AS_PATH attribute of a 737 route received via the External Border Gateway Protocol (eBGP) 738 contains the neighboring AS in the left-most position of the AS_PATH 739 attribute. While this rule is optional in the BGP specification, it 740 becomes necessary to enforce it for security reasons. 742 The best-match unicast route may change over the time independently 743 of the flow specification NLRI. Therefore, a revalidation of the 744 flow specification NLRI MUST be performed whenever unicast routes 745 change. Revalidation is defined as retesting that clause a and 746 clause b above are true. 748 Explanation: 750 The underlying concept is that the neighboring AS that advertises the 751 best unicast route for a destination is allowed to advertise flow- 752 spec information that conveys a more or equally specific destination 753 prefix. Thus, as long as there are no more specific unicast routes, 754 received from a different neighboring AS, which would be affected by 755 that filtering rule. 757 The neighboring AS is the immediate destination of the traffic 758 described by the flow specification. If it requests these flows to 759 be dropped, that request can be honored without concern that it 760 represents a denial of service in itself. Supposedly, the traffic is 761 being dropped by the downstream autonomous system, and there is no 762 added value in carrying the traffic to it. 764 7. Traffic Filtering Actions 766 This specification defines a minimum set of filtering actions that it 767 standardizes as BGP extended community values [RFC4360]. This is not 768 meant to be an inclusive list of all the possible actions, but only a 769 subset that can be interpreted consistently across the network. 770 Additional actions can be defined as either requiring standards or as 771 vendor specific. 773 Implementations SHOULD provide mechanisms that map an arbitrary BGP 774 community value (normal or extended) to filtering actions that 775 require different mappings in different systems in the network. For 776 instance, providing packets with a worse-than-best-effort, per-hop 777 behavior is a functionality that is likely to be implemented 778 differently in different systems and for which no standard behavior 779 is currently known. Rather than attempting to define it here, this 780 can be accomplished by mapping a user-defined community value to 781 platform-/network-specific behavior via user configuration. 783 The default action for a traffic filtering flow specification is to 784 accept IP traffic that matches that particular rule. 786 This document defines the following extended communities values shown 787 in Table 2 in the form 0x8xnn where nn indicates the sub-type. 788 Encodings for these extended communities are described below. 790 +-----------+----------------------+--------------------------------+ 791 | community | action | encoding | 792 +-----------+----------------------+--------------------------------+ 793 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | 794 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | 795 | 0x8007 | traffic-action | bitmask | 796 | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value | 797 | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet | 798 | | | value | 799 | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value | 800 | 0x8009 | traffic-marking | DSCP value | 801 +-----------+----------------------+--------------------------------+ 803 Table 2: Traffic Action Extended Communities 805 Some traffic action communities may interfere with each other. 806 Section 7.6 of this specification provides rules for handling 807 interference between specific types of traffic actions, and error 808 handling based on [RFC7606]. Any additional definition of a traffic 809 actions specified by additional standards documents or vendor 810 documents MUST specify if the traffic action interacts with an 811 existing traffic actions, and provide error handling per [RFC7606]. 813 Multiple traffic actions may be present for a single NLRI. The 814 traffic actions are processed in ascending order of the sub-type 815 found in the BGP Extended Communities. If not all of them can be 816 processed the filter SHALL NOT be applied at all (for example: if for 817 a given flow there are the action communities rate-limit-bytes and 818 traffic-marking attached, and the plattform does not support one of 819 them also the other shall not be applied for that flow). 821 All traffic actions are specified as transitive BGP Extended 822 Communities. 824 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 826 The traffic-rate-bytes extended community uses the following extended 827 community encoding: 829 The first two octets carry the 2-octet id, which can be assigned from 830 a 2-byte AS number. When a 4-byte AS number is locally present, the 831 2 least significant bytes of such an AS number can be used. This 832 value is purely informational and should not be interpreted by the 833 implementation. 835 The remaining 4 octets carry the maximum rate information in IEEE 836 floating point [IEEE.754.1985] format, units being bytes per second. 838 A traffic-rate of 0 should result on all traffic for the particular 839 flow to be discarded. 841 Interferes with: No other BGP Flow Specification traffic action in 842 this document. 844 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD 846 The traffic-rate-packets extended community uses the same encoding as 847 the traffic-rate-bytes extended community. The floating point value 848 carries the maximum packet rate in packets per second. A traffic- 849 rate-packets of 0 should result in all traffic for the particular 850 flow to be discarded. 852 Interferes with: No other BGP Flow Specification traffic action in 853 this document. 855 7.3. Traffic-action (traffic-action) sub-type 0x07 857 The traffic-action extended community consists of 6 bytes of which 858 only the 2 least significant bits of the 6th byte (from left to 859 right) are currently defined. 861 40 41 42 43 44 45 46 47 862 +---+---+---+---+---+---+---+---+ 863 | reserved | S | T | 864 +---+---+---+---+---+---+---+---+ 866 where S and T are defined as: 868 o T: Terminal Action (bit 47): When this bit is set, the traffic 869 filtering engine will apply any subsequent filtering rules (as 870 defined by the ordering procedure). If not set, the evaluation of 871 the traffic filter stops when this rule is applied. 873 o S: Sample (bit 46): Enables traffic sampling and logging for this 874 flow specification. 876 o reserved: should always be set to 0 by the originator and not be 877 evaluated by the receiving BGP speaker. 879 The use of the Terminal Action (bit 47) may result in more than one 880 filter-rule matching a particular flow. All the flow actions from 881 these rules shall be collected and applied. If interfering actions 882 have been collected only the first occurence SHALL be applied. 883 However, if a single rule contains interfering actions this rule 884 SHALL still be handled as described in Section 7.6. 886 Interferes with: No other BGP Flow Specification traffic action in 887 this document. 889 7.4. RT Redirect (rt-redirect) sub-type 0x08 891 The redirect extended community allows the traffic to be redirected 892 to a VRF routing instance that lists the specified route-target in 893 its import policy. If several local instances match this criteria, 894 the choice between them is a local matter (for example, the instance 895 with the lowest Route Distinguisher value can be elected). This 896 extended community allows 3 different encodings formats for the 897 route-target (type 0x80, 0x81, 0x82). Is uses the same encoding as 898 the Route Target extended community [RFC4360]. 900 It should be noted that the low-order nibble of the Redirect's Type 901 field corresponds to the Route Target Extended Community format field 902 (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of 903 [RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended 904 Community remains 0x08 for all three encodings of the BGP Extended 905 Communities (AS 2-byte, AS 4-byte, and IPv4 address). 907 Interferes with: All other redirect functions. All redirect 908 functions are mutually exclusive. If this redirect function exists, 909 then no other redirect functions can be processed. 911 7.5. Traffic Marking (traffic-marking) sub-type 0x09 913 The traffic marking extended community instructs a system to modify 914 the DSCP bits of a transiting IP packet to the corresponding value. 915 This extended community is encoded as a sequence of 5 zero bytes 916 followed by the DSCP value encoded in the 6 least significant bits of 917 6th byte. 919 Interferes with: No other BGP Flow Specification traffic action in 920 this document. 922 7.6. Rules on Traffic Action Interference 924 Traffic actions may interfere with each other. If interfering 925 traffic actions are present for a single flow specification NLRI the 926 entire flow specification (irrespective if there are any other non 927 conflicting actions associated with the same flow specification) 928 SHALL be treated as BGP WITHDRAW. 930 This document defines 7 traffic actions which are interfering in the 931 following way: 933 1. Redirect-action-communities (0x8008, 0x8108, 0x8208): 935 The three redirect-communities are mutually exclusive. Only a 936 single redirect community may be associated with a flow 937 specification otherwise they are interfering. 939 2. All traffic-action communities (including redirect-actions): 941 Multiple occurences of the same (sub-type and type) traffic- 942 action associated with a flow specification are always 943 interfering. 945 When a traffic action is defined in a standards document the handling 946 of interaction with other/same traffic actions MUST be defined as 947 well. Invalid interactions between actions SHOULD NOT trigger a BGP 948 NOTIFICATION. All error handling for error conditions based on 949 [RFC7606]. 951 7.6.1. Examples 953 (rt-redirect vrf-a, rt-redirect vrf-b, traffic-rate-bytes 1Mbit/s) 955 RT-redirect vrf-a and rt-redirect vrf-b are interfering: The BGP 956 UPDATE is treated as WITHDRAW. 958 (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate-bytes 959 2Mbit/s) 961 Duplicate traffic-rate-bytes are interfering: The BGP UPDATE is 962 treated as WITHDRAW. 964 (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate- 965 packets 1000) 967 No interfering action communities: The BGP UPDATE is subject to 968 further processing. 970 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 972 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 973 MPLS IP VPN [RFC4364] control plane, may have different traffic 974 filtering requirements than Internet service providers. But also 975 Internet service providers may use those VPNs for scenarios like 976 having the Internet routing table in a VRF, resulting in the same 977 traffic filtering requirements as defined for the global routing 978 table environment within this document. This document proposes an 979 additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used 980 to propagate traffic filtering information in a BGP/MPLS VPN 981 environment. 983 The NLRI format for this address family consists of a fixed-length 984 Route Distinguisher field (8 bytes) followed by a flow specification, 985 following the encoding defined above in Section 4.2 of this document. 986 The NLRI length field shall include both the 8 bytes of the Route 987 Distinguisher as well as the subsequent flow specification. 989 +------------------------------+ 990 | length (0xnn or 0xfn nn) | 991 +------------------------------+ 992 | Route Distinguisher (8 bytes)| 993 +------------------------------+ 994 | NLRI value (variable) | 995 +------------------------------+ 997 Flow-spec NLRI for MPLS 999 Propagation of this NLRI is controlled by matching Route Target 1000 extended communities associated with the BGP path advertisement with 1001 the VRF import policy, using the same mechanism as described in "BGP/ 1002 MPLS IP VPNs" [RFC4364]. 1004 Flow specification rules received via this NLRI apply only to traffic 1005 that belongs to the VRF(s) in which it is imported. By default, 1006 traffic received from a remote PE is switched via an MPLS forwarding 1007 decision and is not subject to filtering. 1009 Contrary to the behavior specified for the non-VPN NLRI, flow rules 1010 are accepted by default, when received from remote PE routers. 1012 8.1. Validation Procedures for BGP/MPLS VPNs 1014 The validation procedures are the same as for IPv4. 1016 8.2. Traffic Actions Rules 1018 The traffic action rules are the same as for IPv4. 1020 9. Limitations of Previous Traffic Filtering Efforts 1022 9.1. Limitations in Previous DDoS Traffic Filtering Efforts 1024 The popularity of traffic-based, denial-of-service (DoS) attacks, 1025 which often requires the network operator to be able to use traffic 1026 filters for detection and mitigation, brings with it requirements 1027 that are not fully satisfied by existing tools. 1029 Increasingly, DoS mitigation requires coordination among several 1030 service providers in order to be able to identify traffic source(s) 1031 and because the volumes of traffic may be such that they will 1032 otherwise significantly affect the performance of the network. 1034 Several techniques are currently used to control traffic filtering of 1035 DoS attacks. Among those, one of the most common is to inject 1036 unicast route advertisements corresponding to a destination prefix 1037 being attacked (commonly known as remote triggered blackhole RTBH). 1038 One variant of this technique marks such route advertisements with a 1039 community that gets translated into a discard Next-Hop by the 1040 receiving router. Other variants attract traffic to a particular 1041 node that serves as a deterministic drop point. 1043 Using unicast routing advertisements to distribute traffic filtering 1044 information has the advantage of using the existing infrastructure 1045 and inter-AS communication channels. This can allow, for instance, a 1046 service provider to accept filtering requests from customers for 1047 address space they own. 1049 There are several drawbacks, however. An issue that is immediately 1050 apparent is the granularity of filtering control: only destination 1051 prefixes may be specified. Another area of concern is the fact that 1052 filtering information is intermingled with routing information. 1054 The mechanism defined in this document is designed to address these 1055 limitations. We use the flow specification NLRI defined above to 1056 convey information about traffic filtering rules for traffic that is 1057 subject to modified forwarding behavior (actions). The actions are 1058 defined as extended communities and include (but are not limited to) 1059 rate-limiting (including discard), traffic redirection, packet 1060 rewriting. 1062 9.2. Limitations in Previous BGP/MPLS Traffic Filtering 1064 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1065 MPLS IP VPN [RFC4364] control plane, may have different traffic 1066 filtering requirements than Internet service providers. 1068 In these environments, the VPN customer network often has traffic 1069 filtering capabilities towards their external network connections 1070 (e.g., firewall facing public network connection). Less common is 1071 the presence of traffic filtering capabilities between different VPN 1072 attachment sites. In an any-to-any connectivity model, which is the 1073 default, this means that site-to-site traffic is unfiltered. 1075 In circumstances where a security threat does get propagated inside 1076 the VPN customer network, there may not be readily available 1077 mechanisms to provide mitigation via traffic filter. 1079 But also Internet service providers may use those VPNs for scenarios 1080 like having the Internet routing table in a VRF. Therefore, 1081 limitations described in Section 9.1 also apply to this section. 1083 The BGP Flow Specification version 1 addresses these limitations. 1085 10. Traffic Monitoring 1087 Traffic filtering applications require monitoring and traffic 1088 statistics facilities. While this is an implementation-specific 1089 choice, implementations SHOULD provide: 1091 o A mechanism to log the packet header of filtered traffic. 1093 o A mechanism to count the number of matches for a given flow 1094 specification rule. 1096 11. IANA Considerations 1098 This section complies with [RFC7153]. 1100 11.1. AFI/SAFI Definitions 1102 IANA maintains a registry entitled "SAFI Values". For the purpose of 1103 this work, IANA updated the registry and allocated two additional 1104 SAFIs: 1106 +-------+------------------------------------------+----------------+ 1107 | Value | Name | Reference | 1108 +-------+------------------------------------------+----------------+ 1109 | 133 | IPv4 dissemination of flow specification | [this | 1110 | | rules | document] | 1111 | 134 | VPNv4 dissemination of flow | [this | 1112 | | specification rules | document] | 1113 +-------+------------------------------------------+----------------+ 1115 Table 3: Registry: SAFI Values 1117 11.2. Flow Component Definitions 1119 A flow specification consists of a sequence of flow components, which 1120 are identified by a an 8-bit component type. IANA has created and 1121 maintains a registry entitled "Flow Spec Component Types". This 1122 document defines the following Component Type Codes: 1124 +-------+--------------------+-----------------+ 1125 | Value | Name | Reference | 1126 +-------+--------------------+-----------------+ 1127 | 1 | Destination Prefix | [this document] | 1128 | 2 | Source Prefix | [this document] | 1129 | 3 | IP Protocol | [this document] | 1130 | 4 | Port | [this document] | 1131 | 5 | Destination port | [this document] | 1132 | 6 | Source port | [this document] | 1133 | 7 | ICMP type | [this document] | 1134 | 8 | ICMP code | [this document] | 1135 | 9 | TCP flags | [this document] | 1136 | 10 | Packet length | [this document] | 1137 | 11 | DSCP | [this document] | 1138 | 12 | Fragment | [this document] | 1139 +-------+--------------------+-----------------+ 1141 Table 4: Registry: Flow Spec Component Types 1143 In order to manage the limited number space and accommodate several 1144 usages, the following policies defined by [RFC5226] used: 1146 +--------------+-------------------------------+ 1147 | Range | Policy | 1148 +--------------+-------------------------------+ 1149 | 0 | Invalid value | 1150 | [1 .. 12] | Defined by this specification | 1151 | [13 .. 127] | Specification required | 1152 | [128 .. 255] | First Come First Served | 1153 +--------------+-------------------------------+ 1155 Table 5: Flow Spec Component Types Policies 1157 The specification of a particular "Flow Spec Component Type" must 1158 clearly identify what the criteria used to match packets forwarded by 1159 the router is. This criteria should be meaningful across router hops 1160 and not depend on values that change hop-by-hop such as TTL or Layer 1161 2 encapsulation. 1163 11.3. Extended Community Flow Specification Actions 1165 The Extended Community Flow Specification Action types defined in 1166 this document consist of two parts: 1168 Type (BGP Transitive Extended Community Type) 1170 Sub-Type 1172 For the type-part, IANA maintains a registry entitled "BGP Transitive 1173 Extended Community Types". For the purpose of this work (Section 7), 1174 IANA updated the registry to contain the values listed below: 1176 +----------+--------------------------------------------+-----------+ 1177 | Sub-Type | Name | Reference | 1178 | Value | | | 1179 +----------+--------------------------------------------+-----------+ 1180 | 0x80 | Generic Transitive Experimental Use | [RFC7153] | 1181 | | Extended Community (Sub-Types are defined | | 1182 | | in the "Generic Transitive Experimental | | 1183 | | Use Extended Community Sub-Types" | | 1184 | | registry) | | 1185 | 0x81 | Generic Transitive Experimental Use | [this | 1186 | | Extended Community Part 2 (Sub-Types are | document] | 1187 | | defined in the "Generic Transitive | [See | 1188 | | Experimental Use Extended Community Part 2 | Note-1] | 1189 | | Sub-Types" Registry) | | 1190 | 0x82 | Generic Transitive Experimental Use | [this | 1191 | | Extended Community Part 3 (Sub-Types are | document] | 1192 | | defined in the "Generic Transitive | [See | 1193 | | Experimental Use Extended Community Part 3 | Note-1] | 1194 | | Sub-Types" Registry) | | 1195 +----------+--------------------------------------------+-----------+ 1197 Table 6: Registry: Generic Transitive Experimental Use Extended 1198 Community Types 1200 Note-1: This document replaces [RFC7674]. 1202 For the sub-type part of the extended community actions IANA 1203 maintains and updated the following registries: 1205 +----------+------------------------------------------+-------------+ 1206 | Sub-Type | Name | Reference | 1207 | Value | | | 1208 +----------+------------------------------------------+-------------+ 1209 | 0x06 | Flow spec traffic-rate-bytes | [this | 1210 | | | document] | 1211 | TBD | Flow spec traffic-rate-packets | [this | 1212 | | | document] | 1213 | 0x07 | Flow spec traffic-action (Use of the | [this | 1214 | | "Value" field is defined in the "Traffic | document]. | 1215 | | Action Fields" registry) | [Note-2] | 1216 | 0x08 | Flow spec rt-redirect AS-2byte format | [this | 1217 | | | document] | 1218 | 0x09 | Flow spec traffic-remarking | [this | 1219 | | | document] | 1220 +----------+------------------------------------------+-------------+ 1222 Table 7: Registry: Generic Transitive Experimental Use Extended 1223 Community Sub-Types 1225 Note-2: This document replaces both [RFC7674] and [RFC5575]. 1227 +-------------+---------------------------+-------------------------+ 1228 | Sub-Type | Name | Reference | 1229 | Value | | | 1230 +-------------+---------------------------+-------------------------+ 1231 | 0x08 | Flow spec rt-redirect | [this document] [See | 1232 | | IPv4 format | Note-3] | 1233 +-------------+---------------------------+-------------------------+ 1235 Table 8: Registry: Generic Transitive Experimental Use Extended 1236 Community Part 2 Sub-Types 1238 +-------------+----------------------------+------------------------+ 1239 | Sub-Type | Name | Reference | 1240 | Value | | | 1241 +-------------+----------------------------+------------------------+ 1242 | 0x08 | Flow spec rt-redirect AS- | [this document] [See | 1243 | | 4byte format | Note-3] | 1244 +-------------+----------------------------+------------------------+ 1246 Table 9: Registry: Generic Transitive Experimental Use Extended 1247 Community Part 3 Sub-Types 1249 Note-3: This document replaces [RFC7674], and becomes the only 1250 reference for this table. 1252 The "traffic-action" extended community (Section 7.3) defined in this 1253 document has 46 unused bits, which can be used to convey additional 1254 meaning. IANA created and maintains a new registry entitled: 1255 "Traffic Action Fields". These values should be assigned via IETF 1256 Review rules only. The following traffic-action fields have been 1257 allocated: 1259 +-----+-----------------+-----------------+ 1260 | Bit | Name | Reference | 1261 +-----+-----------------+-----------------+ 1262 | 47 | Terminal Action | [this document] | 1263 | 46 | Sample | [this document] | 1264 +-----+-----------------+-----------------+ 1266 Table 10: Registry: Traffic Action Fields 1268 12. Security Considerations 1270 Inter-provider routing is based on a web of trust. Neighboring 1271 autonomous systems are trusted to advertise valid reachability 1272 information. If this trust model is violated, a neighboring 1273 autonomous system may cause a denial-of-service attack by advertising 1274 reachability information for a given prefix for which it does not 1275 provide service. 1277 As long as traffic filtering rules are restricted to match the 1278 corresponding unicast routing paths for the relevant prefixes, the 1279 security characteristics of this proposal are equivalent to the 1280 existing security properties of BGP unicast routing. 1282 Where it is not the case, this would open the door to further denial- 1283 of-service attacks. 1285 Enabling firewall-like capabilities in routers without centralized 1286 management could make certain failures harder to diagnose. For 1287 example, it is possible to allow TCP packets to pass between a pair 1288 of addresses but not ICMP packets. It is also possible to permit 1289 packets smaller than 900 or greater than 1000 bytes to pass between a 1290 pair of addresses, but not packets whose length is in the range 900- 1291 1000. Such behavior may be confusing and these capabilities should 1292 be used with care whether manually configured or coordinated through 1293 the protocol extensions described in this document. 1295 13. Original authors 1297 Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and 1298 Nischal Sheth were authors on [RFC5575], and therefore are 1299 contributing authors on this document. 1301 Note: Any original author of [RFC5575] who wants to work on this 1302 draft can be added as a co-author. 1304 14. Acknowledgements 1306 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 1307 Morrow, Charlie Kaufman, and David Smith for their comments for the 1308 comments on the original [RFC5575]. Chaitanya Kodeboyina helped 1309 design the flow validation procedure; and Steven Lin and Jim Washburn 1310 ironed out all the details necessary to produce a working 1311 implementation in the original [RFC5575]. 1313 Additional acknowledgements for this document will be included here. 1314 The current authors would like to thank Alexander Mayrhofer and 1315 Nicolas Fevrier for their comments and review. 1317 15. References 1319 15.1. Normative References 1321 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1322 RFC 793, DOI 10.17487/RFC0793, September 1981, 1323 . 1325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1326 Requirement Levels", BCP 14, RFC 2119, 1327 DOI 10.17487/RFC2119, March 1997, 1328 . 1330 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1331 "Definition of the Differentiated Services Field (DS 1332 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1333 DOI 10.17487/RFC2474, December 1998, 1334 . 1336 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1337 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1338 DOI 10.17487/RFC4271, January 2006, 1339 . 1341 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1342 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1343 February 2006, . 1345 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1346 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1347 2006, . 1349 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1350 "Multiprotocol Extensions for BGP-4", RFC 4760, 1351 DOI 10.17487/RFC4760, January 2007, 1352 . 1354 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1355 LAN Service (VPLS) Using BGP for Auto-Discovery and 1356 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1357 . 1359 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1360 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1361 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1362 . 1364 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1365 IANA Considerations Section in RFCs", RFC 5226, 1366 DOI 10.17487/RFC5226, May 2008, 1367 . 1369 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1370 and D. McPherson, "Dissemination of Flow Specification 1371 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1372 . 1374 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 1375 Specific BGP Extended Community", RFC 5668, 1376 DOI 10.17487/RFC5668, October 2009, 1377 . 1379 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1380 and A. Bierman, Ed., "Network Configuration Protocol 1381 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1382 . 1384 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1385 Origin Authorizations (ROAs)", RFC 6482, 1386 DOI 10.17487/RFC6482, February 2012, 1387 . 1389 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1390 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1391 March 2014, . 1393 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1394 Patel, "Revised Error Handling for BGP UPDATE Messages", 1395 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1396 . 1398 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1399 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1400 October 2015, . 1402 15.2. Informative References 1404 [I-D.ietf-idr-flow-spec-v6] 1405 McPherson, D., Raszuk, R., Pithawala, B., 1406 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 1407 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 1408 v6-08 (work in progress), March 2017. 1410 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1411 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1412 . 1414 Authors' Addresses 1416 Susan Hares 1417 Huawei 1418 7453 Hickory Hill 1419 Saline, MI 48176 1420 USA 1422 Email: shares@ndzh.com 1424 Robert Raszuk 1425 Bloomberg LP 1426 731 Lexington Ave 1427 New York City, NY 10022 1428 USA 1430 Email: robert@raszuk.net 1432 Danny McPherson 1433 Verisign 1434 USA 1436 Email: dmcpherson@verisign.com 1437 Christoph Loibl 1438 Next Layer Communications 1439 Mariahilfer Guertel 37/7 1440 Vienna 1150 1441 AT 1443 Phone: +43 664 1176414 1444 Email: cl@tix.at 1446 Martin Bacher 1447 T-Mobile Austria 1448 Rennweg 97-99 1449 Vienna 1030 1450 AT 1452 Email: mb.ietf@gmail.com