idnits 2.17.1 draft-hr-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 (November 16, 2016) is 2717 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 577 -- Looks like a reference, but probably isn't: '139' on line 577 == Missing Reference: 'IEEE.754.1985' is mentioned on line 827, but not defined == Unused Reference: 'RFC4761' is defined on line 1273, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 1278, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1298, but no explicit reference was found in the text == Unused Reference: 'RFC6482' is defined on line 1303, but no explicit reference was found in the text == Unused Reference: 'RFC7223' is defined on line 1312, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-flowspec-label' is defined on line 1327, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-flowspec-oid' is defined on line 1333, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-flowspec-interfaceset' is defined on line 1345, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-flowspec-l2vpn' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-flowspec-mpls-match' is defined on line 1357, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-flowspec-nvo3' is defined on line 1362, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-flowspec-packet-rate' is defined on line 1367, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-wide-bgp-communities' is defined on line 1372, but no explicit reference was found in the text == Unused Reference: 'RFC6074' is defined on line 1382, but no explicit reference was found in the text == Unused Reference: 'RFC6483' is defined on line 1388, 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 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7674 (Obsoleted by RFC 8955) == Outdated reference: A later version (-02) exists of draft-ietf-idr-bgp-flowspec-label-00 == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgp-flowspec-oid-03 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-07 == Outdated reference: A later version (-05) exists of draft-ietf-idr-flowspec-interfaceset-02 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-04 == Outdated reference: A later version (-02) exists of draft-ietf-idr-flowspec-mpls-match-00 == Outdated reference: A later version (-19) exists of draft-ietf-idr-flowspec-nvo3-00 == Outdated reference: A later version (-01) exists of draft-ietf-idr-flowspec-packet-rate-00 == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-03 Summary: 5 errors (**), 0 flaws (~~), 27 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: May 20, 2017 Verisign 8 C. Loibl 9 Next Layer Communications 10 M. Bacher 11 T-Mobile Austria 12 November 16, 2016 14 Dissemination of Flow Specification Rules 15 draft-hr-idr-rfc5575bis-02.txt 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 May 20, 2017. 63 Copyright Notice 65 Copyright (c) 2016 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 (sub-type 0x06) . . . . . . . . . . 18 104 7.2. Traffic Rate in Packets (sub-type TBD) . . . . . . . . . 19 105 7.3. Traffic-action (sub-type 0x07) . . . . . . . . . . . . . 19 106 7.4. IP Redirect (sub-type 0x08) . . . . . . . . . . . . . . . 19 107 7.5. Traffic Marking (sub-type 0x09) . . . . . . . . . . . . . 20 108 7.6. Rules on Traffic Action Interference . . . . . . . . . . 20 109 7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 110 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 21 111 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 22 112 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 22 113 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 22 114 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 22 115 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 23 116 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 23 117 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 118 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 119 11.2. Flow Component definitions . . . . . . . . . . . . . . . 24 120 11.3. Extended Community Flow Specification Actions . . . . . 25 121 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 122 13. Original authors . . . . . . . . . . . . . . . . . . . . . . 27 123 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 124 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 125 15.1. Normative References . . . . . . . . . . . . . . . . . . 27 126 15.2. Informative References . . . . . . . . . . . . . . . . . 29 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 129 1. Introduction 131 Modern IP routers contain both the capability to forward traffic 132 according to IP prefixes as well as to classify, shape, rate limit, 133 filter, or redirect packets based on administratively defined 134 policies. 136 These traffic policy mechanisms allow the router to define match 137 rules that operate on multiple fields of the packet header. Actions 138 such as the ones described above can be associated with each rule. 140 The n-tuple consisting of the matching criteria defines an aggregate 141 traffic flow specification. The matching criteria can include 142 elements such as source and destination address prefixes, IP 143 protocol, and transport protocol port numbers. 145 This document defines a general procedure to encode flow 146 specification rules for aggregated traffic flows so that they can be 147 distributed as a BGP [RFC5575] NLRI. Additionally, we define the 148 required mechanisms to utilize this definition to the problem of 149 immediate concern to the authors: intra- and inter-provider 150 distribution of traffic filtering rules to filter (distributed) 151 denial-of-service (DoS) attacks. 153 By expanding routing information with flow specifications, the 154 routing system can take advantage of the ACL (Access Control List) or 155 firewall capabilities in the router's forwarding path. Flow 156 specifications can be seen as more specific routing entries to a 157 unicast prefix and are expected to depend upon the existing unicast 158 data information. 160 A flow specification received from an external autonomous system will 161 need to be validated against unicast routing before being accepted. 162 If the aggregate traffic flow defined by the unicast destination 163 prefix is forwarded to a given BGP peer, then the local system can 164 safely install more specific flow rules that may result in different 165 forwarding behavior, as requested by this system. 167 The key technology components required to address the class of 168 problems targeted by this document are: 170 1. Efficient point-to-multipoint distribution of control plane 171 information. 173 2. Inter-domain capabilities and routing policy support. 175 3. Tight integration with unicast routing, for verification 176 purposes. 178 Items 1 and 2 have already been addressed using BGP for other types 179 of control plane information. Close integration with BGP also makes 180 it feasible to specify a mechanism to automatically verify flow 181 information against unicast routing. These factors are behind the 182 choice of BGP as the carrier of flow specification information. 184 As with previous extensions to BGP, this specification makes it 185 possible to add additional information to Internet routers. These 186 are limited in terms of the maximum number of data elements they can 187 hold as well as the number of events they are able to process in a 188 given unit of time. The authors believe that, as with previous 189 extensions, service providers will be careful to keep information 190 levels below the maximum capacity of their devices. 192 In many deployments of BGP Flow Specification, the flow specification 193 information has replace existing host length route advertisements. 195 Experience with previous BGP extensions has also shown that the 196 maximum capacity of BGP speakers has been gradually increased 197 according to expected loads. Taking into account Internet unicast 198 routing as well as additional applications as they gain popularity. 200 From an operational perspective, the utilization of BGP as the 201 carrier for this information allows a network service provider to 202 reuse both internal route distribution infrastructure (e.g., route 203 reflector or confederation design) and existing external 204 relationships (e.g., inter-domain BGP sessions to a customer 205 network). 207 While it is certainly possible to address this problem using other 208 mechanisms, this solution has been utilized in deployments because of 209 the substantial advantage of being an incremental addition to already 210 deployed mechanisms. 212 In current deployments, the information distributed by the flow-spec 213 extension is originated both manually as well as automatically. The 214 latter by systems that are able to detect malicious flows. When 215 automated systems are used, care should be taken to ensure their 216 correctness as well as to limit the number and advertisement rate of 217 flow routes. 219 This specification defines required protocol extensions to address 220 most common applications of IPv4 unicast and VPNv4 unicast filtering. 221 The same mechanism can be reused and new match criteria added to 222 address similar filtering needs for other BGP address families such 223 as IPv6 families [I-D.ietf-idr-flow-spec-v6], 225 2. Definitions of Terms Used in This Memo 227 NLRI - Network Layer Reachability Information. 229 RIB - Routing Information Base. 231 Loc-RIB - Local RIB. 233 AS - Autonomous System number. 235 VRF - Virtual Routing and Forwarding instance. 237 PE - Provider Edge router 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in [RFC2119] 243 3. Flow Specifications 245 A flow specification is an n-tuple consisting of several matching 246 criteria that can be applied to IP traffic. A given IP packet is 247 said to match the defined flow if it matches all the specified 248 criteria. 250 A given flow may be associated with a set of attributes, depending on 251 the particular application; such attributes may or may not include 252 reachability information (i.e., NEXT_HOP). Well-known or AS-specific 253 community attributes can be used to encode a set of predetermined 254 actions. 256 A particular application is identified by a specific (Address Family 257 Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair 258 [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs 259 should be treated independently from each other in order to assure 260 non-interference between distinct applications. 262 BGP itself treats the NLRI as an opaque key to an entry in its 263 databases. Entries that are placed in the Loc-RIB are then 264 associated with a given set of semantics, which is application 265 dependent. This is consistent with existing BGP applications. For 266 instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast 267 reverse-path information (AFI=1, SAFI=2) are handled by BGP without 268 any particular semantics being associated with them until installed 269 in the Loc-RIB. 271 Standard BGP policy mechanisms, such as UPDATE filtering by NLRI 272 prefix as well as community matching and manipulation, MUST apply to 273 the Flow specification defined NLRI-type, especially in an inter- 274 domain environment. Network operators can also control propagation 275 of such routing updates by enabling or disabling the exchange of a 276 particular (AFI, SAFI) pair on a given BGP peering session. 278 4. Dissemination of IPv4 FLow Specification Information 280 We define a "Flow Specification" NLRI type (Figure 1) that may 281 include several components such as destination prefix, source prefix, 282 protocol, ports, and others (see Section 4.2 below). This NLRI is 283 treated as an opaque bit string prefix by BGP. Each bit string 284 identifies a key to a database entry with which a set of attributes 285 can be associated. 287 This NLRI information is encoded using MP_REACH_NLRI and 288 MP_UNREACH_NLRI attributes as defined in [RFC4760]. Whenever the 289 corresponding application does not require Next-Hop information, this 290 shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI 291 attribute and ignored on receipt. 293 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 294 a 1- or 2-octet NLRI length field followed by a variable-length NLRI 295 value. The NLRI length is expressed in octets. 297 +------------------------------+ 298 | length (0xnn or 0xfn nn) | 299 +------------------------------+ 300 | NLRI value (variable) | 301 +------------------------------+ 303 Figure 1: Flow-spec NLRI for IPv4 305 Implementations wishing to exchange flow specification rules MUST use 306 BGP's Capability Advertisement facility to exchange the Multiprotocol 307 Extension Capability Code (Code 1) as defined in [RFC4760]. The 308 (AFI, SAFI) pair carried in the Multiprotocol Extension Capability 309 MUST be the same as the one used to identify a particular application 310 that uses this NLRI-type. 312 4.1. Length Encoding 314 o If the NLRI length value is smaller than 240 (0xf0 hex), the 315 length field can be encoded as a single octet. 317 o Otherwise, it is encoded as an extended-length 2-octet value in 318 which the most significant nibble of the first byte is all ones. 320 In figure 1 above, values less-than 240 are encoded using two hex 321 digits (0xnn). Values above 239 are encoded using 3 hex digits 322 (0xfnnn). The highest value that can be represented with this 323 encoding is 4095. The value 241 is encoded as 0xf0f1. 325 4.2. NLRI Value Encoding 327 The Flow specification NLRI-type consists of several optional 328 subcomponents. A specific packet is considered to match the flow 329 specification when it matches the intersection (AND) of all the 330 components present in the specification. 332 The encoding of each of the NLRI components begins with a type field 333 (1 octet) followed by a variable length parameter. Section 4.2.1 to 334 Section 4.2.12 define component types and parameter encodings for the 335 IPv4 IP layer and transport layer headers. IPv6 NLRI component types 336 are described in [I-D.ietf-idr-flow-spec-v6]. 338 Flow specification components must follow strict type ordering by 339 increasing numerical order. A given component type may or may not be 340 present in the specification, but if present, it MUST precede any 341 component of higher numeric type value. 343 If a given component type within a prefix in unknown, the prefix in 344 question cannot be used for traffic filtering purposes by the 345 receiver. Since a flow specification has the semantics of a logical 346 AND of all components, if a component is FALSE, by definition it 347 cannot be applied. However, for the purposes of BGP route 348 propagation, this prefix should still be transmitted since BGP route 349 distribution is independent on NLRI semantics. 351 The encoding is chosen in order to allow for future 352 extensibility. 354 4.2.1. Type 1 - Destination Prefix 356 Encoding: 358 Defines: the destination prefix to match. Prefixes are encoded as 359 in BGP UPDATE messages, a length in bits is followed by enough 360 octets to contain the prefix information. 362 4.2.2. Type 2 - Source Prefix 364 Encoding: 366 Defines the source prefix to match. 368 4.2.3. Type 3 - IP Protocol 370 Encoding: 372 Contains a set of {operator, value} pairs that are used to match 373 the IP protocol value byte in IP packets. 375 The operator byte is encoded as: 377 0 1 2 3 4 5 6 7 378 +---+---+---+---+---+---+---+---+ 379 | e | a | len | 0 |lt |gt |eq | 380 +---+---+---+---+---+---+---+---+ 382 Numeric operator 384 e - end-of-list bit. Set in the last {op, value} pair in the 385 list. 387 a - AND bit. If unset, the previous term is logically ORed with 388 the current one. If set, the operation is a logical AND. It 389 should be unset in the first operator byte of a sequence. The AND 390 operator has higher priority than OR for the purposes of 391 evaluating logical expressions. 393 len - length of the value field for this operand encodes 1 (00) - 394 4 (11) bytes. Type 3 flow component values are always encoded as 395 single byte (len = 00). 397 lt - less than comparison between data and value. 399 gt - greater than comparison between data and value. 401 eq - equality between data and value. 403 The bits lt, gt, and eq can be combined to produce "less or equal", 404 "greater or equal", and inequality values. 406 +----+----+----+----------------------------------+ 407 | lt | gt | eq | Resulting operation | 408 +----+----+----+----------------------------------+ 409 | 0 | 0 | 0 | true (independent of the value) | 410 | 0 | 0 | 1 | == (equal) | 411 | 0 | 1 | 0 | > (greater than) | 412 | 0 | 1 | 1 | >= (greater than or equal) | 413 | 1 | 0 | 0 | < (less than) | 414 | 1 | 0 | 1 | <= (less than or equal) | 415 | 1 | 1 | 0 | != (not equal value) | 416 | 1 | 1 | 1 | false (independent of the value) | 417 +----+----+----+----------------------------------+ 419 Table 1: Comparison operation combinations 421 4.2.4. Type 4 - Port 423 Encoding: 425 Defines a list of {operator, value} pairs that matches source OR 426 destination TCP/UDP ports. This list is encoded using the numeric 427 operator format defined in Section 4.2.3. Values are encoded as 428 1- or 2-byte quantities. 430 Port, source port, and destination port components evaluate to 431 FALSE if the IP protocol field of the packet has a value other 432 than TCP or UDP, if the packet is fragmented and this is not the 433 first fragment, or if the system in unable to locate the transport 434 header. Different implementations may or may not be able to 435 decode the transport header in the presence of IP options or 436 Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. 438 4.2.5. Type 5 - Destination Port 440 Encoding: 442 Defines a list of {operator, value} pairs used to match the 443 destination port of a TCP or UDP packet. This list is encoded 444 using the numeric operator format defined in Section 4.2.3. 445 Values are encoded as 1- or 2-byte quantities. 447 4.2.6. Type 6 - Source Port 449 Encoding: 451 Defines a list of {operator, value} pairs used to match the source 452 port of a TCP or UDP packet. This list is encoded using the 453 numeric operator format defined in Section 4.2.3. Values are 454 encoded as 1- or 2-byte quantities. 456 4.2.7. Type 7 - ICMP type 458 Encoding: 460 Defines a list of {operator, value} pairs used to match the type 461 field of an ICMP packet. This list is encoded using the numeric 462 operator format defined in Section 4.2.3. Values are encoded 463 using a single byte. 465 The ICMP type specifiers evaluate to FALSE whenever the protocol 466 value is not ICMP. 468 4.2.8. Type 8 - ICMP code 470 Encoding: 472 Defines a list of {operator, value} pairs used to match the code 473 field of an ICMP packet. This list is encoded using the numeric 474 operator format defined in Section 4.2.3. Values are encoded 475 using a single byte. 477 The ICMP code specifiers evaluate to FALSE whenever the protocol 478 value is not ICMP. 480 4.2.9. Type 9 - TCP flags 482 Encoding: 484 Bitmask values can be encoded as a 1- or 2-byte bitmask. When a 485 single byte is specified, it matches byte 13 of the TCP header 486 [RFC0793], which contains bits 8 though 15 of the 4th 32-bit word. 487 When a 2-byte encoding is used, it matches bytes 12 and 13 of the 488 TCP header with the data offset field having a "don't care" value. 490 This component evaluates to FALSE for packets that are not TCP 491 packets. 493 This type uses the bitmask operand format, which differs from the 494 numeric operator format in the lower nibble. 496 0 1 2 3 4 5 6 7 497 +---+---+---+---+---+---+---+---+ 498 | e | a | len | 0 | 0 |not| m | 499 +---+---+---+---+---+---+---+---+ 501 Bitmask format 503 e, a, len - Most significant nibble: (end-of-list bit, AND bit, and 504 length field), as defined for in the numeric operator format in 505 Section 4.2.3. 507 not - NOT bit. If set, logical negation of operation. 509 m - Match bit. If set, this is a bitwise match operation defined 510 as "(data AND value) == value"; if unset, (data AND value) 511 evaluates to TRUE if any of the bits in the value mask are set in 512 the data 514 4.2.10. Type 10 - Packet length 516 Encoding: 518 Defines a list of {operator, value} pairs used to match on the 519 total IP packet length (excluding Layer 2 but including IP 520 header). This list is encoded using the numeric operator format 521 defined in Section 4.2.3. Values are encoded using 1- or 2-byte 522 quantities. 524 4.2.11. Type 11 - DSCP (Diffserv Code Point) 526 Encoding: 528 Defines a list of {operator, value} pairs used to match the 6-bit 529 DSCP field [RFC2474]. This list is encoded using the numeric 530 operator format defined in Section 4.2.3. Values are encoded 531 using a single byte. The two most significant bits are zero and 532 the six least significant bits contain the DSCP value. 534 4.2.12. Type 12 - Fragment 536 Encoding: 538 Uses bitmask operand format defined in Section 4.2.9. 540 0 1 2 3 4 5 6 7 541 +---+---+---+---+---+---+---+---+ 542 | Reserved |LF |FF |IsF|DF | 543 +---+---+---+---+---+---+---+---+ 545 Bitmask values: 547 Bit 7 - Don't fragment (DF) 549 Bit 6 - Is a fragment (IsF) 551 Bit 5 - First fragment (FF) 553 Bit 4 - Last fragment (LF) 555 4.3. Examples of Encodings 557 An example of a flow specification encoding for: "all packets to 558 10.0.1/24 and TCP port 25". 560 +------------------+----------+----------+ 561 | destination | proto | port | 562 +------------------+----------+----------+ 563 | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | 564 +------------------+----------+----------+ 566 Decode for protocol: 568 +-------+----------+------------------------------+ 569 | Value | | | 570 +-------+----------+------------------------------+ 571 | 0x03 | type | | 572 | 0x81 | operator | end-of-list, value size=1, = | 573 | 0x06 | value | | 574 +-------+----------+------------------------------+ 576 An example of a flow specification encoding for: "all packets to 577 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". 579 +------------------+----------+-------------------------+ 580 | destination | source | port | 581 +------------------+----------+-------------------------+ 582 | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | 583 +------------------+----------+-------------------------+ 585 Decode for port: 587 +--------+----------+------------------------------+ 588 | Value | | | 589 +--------+----------+------------------------------+ 590 | 0x04 | type | | 591 | 0x03 | operator | size=1, >= | 592 | 0x89 | value | 137 | 593 | 0x45 | operator | "AND", value size=1, <= | 594 | 0x8b | value | 139 | 595 | 0x91 | operator | end-of-list, value-size=2, = | 596 | 0x1f90 | value | 8080 | 597 +--------+----------+------------------------------+ 599 This constitutes an NLRI with an NLRI length of 16 octets. 601 5. Traffic Filtering 603 Traffic filtering policies have been traditionally considered to be 604 relatively static. Limitations of the static mechanisms caused this 605 mechanism to be designed for the three new applications of traffic 606 filtering (prevention of traffic-based, denial-of-service (DOS) 607 attacks, traffic filtering in the context of BGP/MPLS VPN service, 608 and centralized traffic control for SDN/NFV networks) requires 609 coordination among service providers and/or coordination among the AS 610 within a service provider. Section 8 has details on the limitation 611 of previous mechanisms and why BGP Flow Specification version 1 612 provides a solution for to prevent DOS and aid BGP/MPLS VPN filtering 613 rules. 615 This flow specification NLRI defined above to convey information 616 about traffic filtering rules for traffic that should be discarded or 617 handled in manner specified by a set of pre-defined actions (which 618 are defined in BGP Extended Communities). This mechanism is 619 primarily designed to allow an upstream autonomous system to perform 620 inbound filtering in their ingress routers of traffic that a given 621 downstream AS wishes to drop. 623 In order to achieve this goal, this draft specifies two application 624 specific NLRI identifiers that provide traffic filters, and a set of 625 actions encoding in BGP Extended Communities. The two application 626 specific NLRI identifiers are: 628 o IPv4 flow specification identifier (AFI=1, SAFI=133) along with 629 specific semantic rules for IPv4 routes, and 631 o BGP NLRI type (AFI=1, SAFI=134) value, which can be used to 632 propagate traffic filtering information in a BGP/MPLS VPN 633 environment. 635 Distribution of the IPv4 Flow specification is described in section 636 6, and distibution of BGP/MPLS traffic flow specification is 637 described in section 8. The traffic filtering actions are described 638 in section 7. 640 5.1. Ordering of Traffic Filtering Rules 642 With traffic filtering rules, more than one rule may match a 643 particular traffic flow. Thus, it is necessary to define the order 644 at which rules get matched and applied to a particular traffic flow. 645 This ordering function must be such that it must not depend on the 646 arrival order of the flow specification's rules and must be 647 consistent in the network. 649 The relative order of two flow specification rules is determined by 650 comparing their respective components. The algorithm starts by 651 comparing the left-most components of the rules. If the types 652 differ, the rule with lowest numeric type value has higher precedence 653 (and thus will match before) than the rule that doesn't contain that 654 component type. If the component types are the same, then a type- 655 specific comparison is performed. 657 For IP prefix values (IP destination and source prefix) precedence is 658 given to the lowest IP value of the common prefix length; if the 659 common prefix is equal, then the most specific prefix has precedence. 661 For all other component types, unless otherwise specified, the 662 comparison is performed by comparing the component data as a binary 663 string using the memcmp() function as defined by the ISO C standard. 664 For strings of different lengths, the common prefix is compared. If 665 equal, the longest string is considered to have higher precedence 666 than the shorter one. 668 Pseudocode: 670 flow_rule_cmp (a, b) 671 { 672 comp1 = next_component(a); 673 comp2 = next_component(b); 674 while (comp1 || comp2) { 675 // component_type returns infinity on end-of-list 676 if (component_type(comp1) < component_type(comp2)) { 677 return A_HAS_PRECEDENCE; 678 } 679 if (component_type(comp1) > component_type(comp2)) { 680 return B_HAS_PRECEDENCE; 681 } 683 if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) { 684 common = MIN(prefix_length(comp1), prefix_length(comp2)); 685 cmp = prefix_compare(comp1, comp2, common); 686 // not equal, lowest value has precedence 687 // equal, longest match has precedence 688 } else { 689 common = 690 MIN(component_length(comp1), component_length(comp2)); 691 cmp = memcmp(data(comp1), data(comp2), common); 692 // not equal, lowest value has precedence 693 // equal, longest string has precedence 694 } 695 } 697 return EQUAL; 698 } 700 6. Validation Procedure 702 Flow specifications received from a BGP peer that are accepted in the 703 respective Adj-RIB-In are used as input to the route selection 704 process. Although the forwarding attributes of two routes for the 705 same flow specification prefix may be the same, BGP is still required 706 to perform its path selection algorithm in order to select the 707 correct set of attributes to advertise. 709 The first step of the BGP Route Selection procedure (Section 9.1.2 of 710 [RFC4271] is to exclude from the selection procedure routes that are 711 considered non-feasible. In the context of IP routing information, 712 this step is used to validate that the NEXT_HOP attribute of a given 713 route is resolvable. 715 The concept can be extended, in the case of flow specification NLRI, 716 to allow other validation procedures. 718 A flow specification NLRI must be validated such that it is 719 considered feasible if and only if: 721 a) The originator of the flow specification matches the originator 722 of the best-match unicast route for the destination prefix 723 embedded in the flow specification. 725 b) There are no more specific unicast routes, when compared with 726 the flow destination prefix, that has been received from a 727 different neighboring AS than the best-match unicast route, which 728 has been determined in step a). 730 By originator of a BGP route, we mean either the BGP originator path 731 attribute, as used by route reflection, or the transport address of 732 the BGP peer, if this path attribute is not present. 734 BGP implementations MUST also enforce that the AS_PATH attribute of a 735 route received via the External Border Gateway Protocol (eBGP) 736 contains the neighboring AS in the left-most position of the AS_PATH 737 attribute. While this rule is optional in the BGP specification, it 738 becomes necessary to enforce it for security reasons. 740 The best-match unicast route may change over the time independently 741 of the flow specification NLRI. Therefore, a revalidation of the 742 flow specification NLRI MUST be performed whenever unicast routes 743 change. Revalidation is defined as retesting that clause a and 744 clause b above are true. 746 Explanation: 748 The underlying concept is that the neighboring AS that advertises the 749 best unicast route for a destination is allowed to advertise flow- 750 spec information that conveys a more or equally specific destination 751 prefix. Thus, as long as there are no more specific unicast routes, 752 received from a different neighboring AS, which would be affected by 753 that filtering rule. 755 The neighboring AS is the immediate destination of the traffic 756 described by the flow specification. If it requests these flows to 757 be dropped, that request can be honored without concern that it 758 represents a denial of service in itself. Supposedly, the traffic is 759 being dropped by the downstream autonomous system, and there is no 760 added value in carrying the traffic to it. 762 7. Traffic Filtering Actions 764 This specification defines a minimum set of filtering actions that it 765 standardizes as BGP extended community values [RFC4360]. This is not 766 meant to be an inclusive list of all the possible actions, but only a 767 subset that can be interpreted consistently across the network. 768 Additional actions can be defined as either requiring standards or as 769 vendor specific. 771 Implementations SHOULD provide mechanisms that map an arbitrary BGP 772 community value (normal or extended) to filtering actions that 773 require different mappings in different systems in the network. For 774 instance, providing packets with a worse-than-best-effort, per-hop 775 behavior is a functionality that is likely to be implemented 776 differently in different systems and for which no standard behavior 777 is currently known. Rather than attempting to define it here, this 778 can be accomplished by mapping a user-defined community value to 779 platform-/network-specific behavior via user configuration. 781 The default action for a traffic filtering flow specification is to 782 accept IP traffic that matches that particular rule. 784 This document defines the following extended communities values shown 785 in Table 2 in the form 0x8xnn where nn indicates the sub-type. 786 Encodings for these extended communities are described below. 788 +--------+----------------------+-----------------------------------+ 789 | type | extended community | encoding | 790 +--------+----------------------+-----------------------------------+ 791 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | 792 | 0x8007 | traffic-action | bitmask | 793 | 0x8008 | redirect AS-2byte | 2-octet AS, 4-octet value | 794 | 0x8108 | redirect IPv4 | 4-octet IPv4 addres, 2-octet | 795 | | | value | 796 | 0x8208 | redirect AS-4byte | 4-octet AS, 2-octet value | 797 | 0x8009 | traffic-marking | DSCP value | 798 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | 799 +--------+----------------------+-----------------------------------+ 801 Table 2: Traffic Action Extended Communities 803 Some traffic action communities may interfere with each other. 804 Section 7.6 of this specification provides rules for handling 805 interference between specific types of traffic actions, and error 806 handling based on [RFC7606]. Any additional definition of a traffic 807 actions specified by additional standards documents or vendor 808 documents MUST specify if the traffic action interacts with an 809 existing traffic actions, and provide error handling per [RFC7606]. 811 The traffic actions are processed in ascending order of the sub-type 812 found in the BGP Extended Communities. All traffic actions are 813 specified in transitive BGP Extended Communities. 815 7.1. Traffic Rate in Bytes (sub-type 0x06) 817 The traffic-rate-bytes extended community uses the following extended 818 community encoding: 820 The first two octets carry the 2-octet id, which can be assigned from 821 a 2-byte AS number. When a 4-byte AS number is locally present, the 822 2 least significant bytes of such an AS number can be used. This 823 value is purely informational and should not be interpreted by the 824 implementation. 826 The remaining 4 octets carry the maximum rate information in IEEE 827 floating point [IEEE.754.1985] format, units being bytes per second. 828 A traffic-rate of 0 should result on all traffic for the particular 829 flow to be discarded. 831 Interferes with: Traffic Rate in packets (traffic-rate-packets). 832 Process traffic rate in bytes (sub-type 0x06) action before traffic 833 rate in packets action (sub-type TBD). 835 7.2. Traffic Rate in Packets (sub-type TBD) 837 The traffic-rate-packets extended community uses the same encoding as 838 the traffic-rate-bytes extended community. The floating point value 839 carries the maximum packet rate in packets per second. A traffic- 840 rate-packets of 0 should result in all traffic for the particular 841 flow to be discarded. 843 Interferes with: Traffic Rate in bytes (traffic-rate-bytes). Process 844 traffic rate in bytes (sub-type 0x06) action before traffic rate in 845 packets action (sub-type TBD). 847 7.3. Traffic-action (sub-type 0x07) 849 The traffic-action extended community consists of 6 bytes of which 850 only the 2 least significant bits of the 6th byte (from left to 851 right) are currently defined. 853 40 41 42 43 44 45 46 47 854 +---+---+---+---+---+---+---+---+ 855 | reserved | S | T | 856 +---+---+---+---+---+---+---+---+ 858 where S and T are defined as: 860 o T: Terminal Action (bit 47): When this bit is set, the traffic 861 filtering engine will apply any subsequent filtering rules (as 862 defined by the ordering procedure). If not set, the evaluation of 863 the traffic filter stops when this rule is applied. 865 o S:Sample (bit 46): Enables traffic sampling and logging for this 866 flow specification. 868 Interferes with: No other BGP Flow Specification traffic action in 869 this document. 871 7.4. IP Redirect (sub-type 0x08) 873 The redirect extended community allows the traffic to be redirected 874 to a VRF routing instance that lists the specified route-target in 875 its import policy. If several local instances match this criteria, 876 the choice between them is a local matter (for example, the instance 877 with the lowest Route Distinguisher value can be elected). This 878 extended community uses the same encoding as the Route Target 879 extended community [RFC4360]. 881 It should be noted that the low-order nibble of the Redirect's Type 882 field corresponds to the Route Target Extended Community format field 883 (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of 884 [RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended 885 Community remains 0x08 for all three encodings of the BGP Extended 886 Communities (AS 2-byte, AS 4-byte, and IPv4 address). 888 Interferes with: All other redirect functions. All redirect 889 functions are mutually exclusive. If this redirect function exists, 890 then no other redirect functions can be processed. 892 7.5. Traffic Marking (sub-type 0x09) 894 The traffic marking extended community instructs a system to modify 895 the DSCP bits of a transiting IP packet to the corresponding value. 896 This extended community is encoded as a sequence of 5 zero bytes 897 followed by the DSCP value encoded in the 6 least significant bits of 898 6th byte. 900 Interferes with: No other action in this document. 902 7.6. Rules on Traffic Action Interference 904 Traffic actions may interfere with each other. If interfering 905 traffic actions are present for a single flow specification NLRI the 906 entire flow specification (irrespective if there are any other non 907 conflicting actions associated with the same flow specification) 908 SHALL be treated as BGP WITHDRAW. 910 This document defines 7 traffic actions which are interfering in the 911 following way: 913 1. Redirect-action-communities (0x8008, 0x8108, 0x8208): 915 The three redirect-communities are mutually exclusive. Only a 916 single redirect community may be associated with a flow 917 specification otherwise they are interfering. 919 2. All traffic-action communities (including redirect-actions): 921 Multiple occurences of the same (sub-type and type) traffic- 922 action associated with a flow specification are always 923 interfering. 925 When a traffic action is defined in a standards document the handling 926 of interaction with other/same traffic actions MUST be defined as 927 well. Invalid interactions between actions SHOULD NOT trigger a BGP 928 NOTIFICATION. All error handling for error conditions based on 929 [RFC7606]. 931 7.6.1. Examples 933 (redirect vpn-a, redirect vpn-b, traffic-rate-bytes 1Mbit/s) 935 Redirect vpn-a and redirect vpn-b are interfering: The BGP UPDATE 936 is treated as WITHDRAW. 938 (redirect vpn-a, traffic-rate-bytes 1Mbit/s, traffic-rate-bytes 939 2Mbit/s) 941 Duplicate traffic-rate-bytes are interfering: The BGP UPDATE is 942 treated as WITHDRAW. 944 (redirect vpn-a, traffic-rate-bytes 1Mbit/s, traffic-rate-packets 945 1000) 947 No interfering action communities: The BGP UPDATE is subject to 948 further processing. 950 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 952 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 953 MPLS IP VPN [RFC4364] control plane, may have different traffic 954 filtering requirements than Internet service providers. But also 955 Internet service providers may use those VPNs for scenarios like 956 having the Internet routing table in a VRF, resulting in the same 957 traffic filtering requirements as defined for the global routing 958 table environment within this document. This document proposes an 959 additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used 960 to propagate traffic filtering information in a BGP/MPLS VPN 961 environment. 963 The NLRI format for this address family consists of a fixed-length 964 Route Distinguisher field (8 bytes) followed by a flow specification, 965 following the encoding defined above in section x of this document. 966 The NLRI length field shall include both the 8 bytes of the Route 967 Distinguisher as well as the subsequent flow specification. 969 +------------------------------+ 970 | length (0xnn or 0xfn nn) | 971 +------------------------------+ 972 | Route Distinguisher (8 bytes)| 973 +------------------------------+ 974 | NLRI value (variable) | 975 +------------------------------+ 977 Flow-spec NLRI for MPLS 979 Propagation of this NLRI is controlled by matching Route Target 980 extended communities associated with the BGP path advertisement with 981 the VRF import policy, using the same mechanism as described in "BGP/ 982 MPLS IP VPNs" [RFC4364]. 984 Flow specification rules received via this NLRI apply only to traffic 985 that belongs to the VRF(s) in which it is imported. By default, 986 traffic received from a remote PE is switched via an MPLS forwarding 987 decision and is not subject to filtering. 989 Contrary to the behavior specified for the non-VPN NLRI, flow rules 990 are accepted by default, when received from remote PE routers. 992 8.1. Validation Procedures for BGP/MPLS VPNs 994 The validation procedures are the same as for IPv4. 996 8.2. Traffic Actions Rules 998 The traffic action rules are the same as for IPv4. 1000 9. Limitations of Previous Traffic Filtering Efforts 1002 9.1. Limitations in Previous DDoS Traffic Filtering Efforts 1004 The popularity of traffic-based, denial-of-service (DoS) attacks, 1005 which often requires the network operator to be able to use traffic 1006 filters for detection and mitigation, brings with it requirements 1007 that are not fully satisfied by existing tools. 1009 Increasingly, DoS mitigation requires coordination among several 1010 service providers in order to be able to identify traffic source(s) 1011 and because the volumes of traffic may be such that they will 1012 otherwise significantly affect the performance of the network. 1014 Several techniques are currently used to control traffic filtering of 1015 DoS attacks. Among those, one of the most common is to inject 1016 unicast route advertisements corresponding to a destination prefix 1017 being attacked (commonly known as remote triggered blackhole RTBH). 1018 One variant of this technique marks such route advertisements with a 1019 community that gets translated into a discard Next-Hop by the 1020 receiving router. Other variants attract traffic to a particular 1021 node that serves as a deterministic drop point. 1023 Using unicast routing advertisements to distribute traffic filtering 1024 information has the advantage of using the existing infrastructure 1025 and inter-AS communication channels. This can allow, for instance, a 1026 service provider to accept filtering requests from customers for 1027 address space they own. 1029 There are several drawbacks, however. An issue that is immediately 1030 apparent is the granularity of filtering control: only destination 1031 prefixes may be specified. Another area of concern is the fact that 1032 filtering information is intermingled with routing information. 1034 The mechanism defined in this document is designed to address these 1035 limitations. We use the flow specification NLRI defined above to 1036 convey information about traffic filtering rules for traffic that is 1037 subject to modified forwarding behavior (actions). The actions are 1038 defined as extended communities and include (but are not limited to) 1039 rate-limiting (including discard), traffic redirection, packet 1040 rewriting. 1042 9.2. Limitations in Previous BGP/MPLS Traffic Filtering 1044 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1045 MPLS IP VPN [RFC4364] control plane, may have different traffic 1046 filtering requirements than Internet service providers. 1048 In these environments, the VPN customer network often has traffic 1049 filtering capabilities towards their external network connections 1050 (e.g., firewall facing public network connection). Less common is 1051 the presence of traffic filtering capabilities between different VPN 1052 attachment sites. In an any-to-any connectivity model, which is the 1053 default, this means that site-to-site traffic is unfiltered. 1055 In circumstances where a security threat does get propagated inside 1056 the VPN customer network, there may not be readily available 1057 mechanisms to provide mitigation via traffic filter. 1059 But also Internet service providers may use those VPNs for scenarios 1060 like having the Internet routing table in a VRF. Therefore, 1061 limitations described in Section 9.1 also apply to this section. 1063 The BGP Flow Specification version 1 addresses these limitations. 1065 10. Traffic Monitoring 1067 Traffic filtering applications require monitoring and traffic 1068 statistics facilities. While this is an implementation-specific 1069 choice, implementations SHOULD provide: 1071 o A mechanism to log the packet header of filtered traffic. 1073 o A mechanism to count the number of matches for a given flow 1074 specification rule. 1076 11. IANA Considerations 1078 This section complies with [RFC7153] 1080 11.1. AFI/SAFI Definitions 1082 For the purpose of this work, IANA has allocated values for two 1083 SAFIs: SAFI 133 for IPv4 dissemination of flow specification rules 1084 and SAFI 134 for VPNv4 dissemination of flow specification rules. 1086 11.2. Flow Component definitions 1088 A flow specification consists of a sequence of flow components, which 1089 are identified by a an 8-bit component type. Types must be assigned 1090 and interpreted uniquely. The current specification defines types 1 1091 though 12, with the value 0 being reserved. 1093 IANA created and maintains a new registry entitled: "Flow Spec 1094 Component Types". The following component types have been 1095 registered: 1097 Type 1 - Destination Prefix 1099 Type 2 - Source Prefix 1101 Type 3 - IP Protocol 1103 Type 4 - Port 1105 Type 5 - Destination port 1107 Type 6 - Source port 1109 Type 7 - ICMP type 1111 Type 8 - ICMP code 1113 Type 9 - TCP flags 1115 Type 10 - Packet length 1117 Type 11 - DSCP 1119 Type 12 - Fragment 1120 Type 13 - Bit Mask filter 1122 In order to manage the limited number space and accommodate several 1123 usages, the following policies defined by RFC 5226 [RFC5226] are 1124 used: 1126 +--------------+-------------------------------+ 1127 | Range | Policy | 1128 +--------------+-------------------------------+ 1129 | 0 | Invalid value | 1130 | [1 .. 12] | Defined by this specification | 1131 | [13 .. 127] | Specification Required | 1132 | [128 .. 255] | First Come First Served | 1133 +--------------+-------------------------------+ 1135 The specification of a particular "flow component type" must clearly 1136 identify what the criteria used to match packets forwarded by the 1137 router is. This criteria should be meaningful across router hops and 1138 not depend on values that change hop-by-hop such as TTL or Layer 2 1139 encapsulation. 1141 The "traffic-action" extended community defined in this document has 1142 46 unused bits, which can be used to convey additional meaning. IANA 1143 created and maintains a new registry entitled: "Traffic Action 1144 Fields". These values should be assigned via IETF Review rules only. 1145 The following traffic-action fields have been allocated: 1147 47 Terminal Action 1149 46 Sample 1151 0-45 Unassigned 1153 11.3. Extended Community Flow Specification Actions 1155 The Extended Community FLow Specification Action types consists of 1156 two parts: BGP Transitive Extended Community types and a set of sub- 1157 types. 1159 IANA has updated the following "BGP Transitive Extended Community 1160 Types" registries to contain the values listed below: 1162 0x80 - Generic Transitive Experimental Use Extended Community Part 1163 1 (Sub-Types are defined in the "Generic Transitive Experimental 1164 Extended Community Part 1 Sub-Types" Registry) 1166 0x81 - Generic Transitive Experimental Use Extended Community Part 1167 2 (Sub-Types are defined in the "Generic Transitive Experimental 1168 Extended Community Part 2 Sub-Types" Registry) 1170 0x82 - Generic Transitive Experimental Use Extended Community Part 1171 3 (Sub-Types are defined in the "Generic Transitive Experimental 1172 Use Extended Community Part 3 Sub-Types" Registry) 1174 RANGE REGISTRATION PROCEDURE 1175 0x00-0xbf First Come First Served 1176 0xc0-0xff IETF Review 1178 SUB-TYPE VALUE NAME REFERENCE 1179 0x00-0x05 unassigned 1180 0x06 traffic-rate [this document] 1181 0x07 traffic-action [this document] 1182 0x08 Flow spec redirect IPv4 [RFC5575] [RFC7674] 1183 [this document] 1184 0x09 traffic-marking [this document] 1185 0x0a-0xff Unassigned [this document] 1187 12. Security Considerations 1189 Inter-provider routing is based on a web of trust. Neighboring 1190 autonomous systems are trusted to advertise valid reachability 1191 information. If this trust model is violated, a neighboring 1192 autonomous system may cause a denial-of-service attack by advertising 1193 reachability information for a given prefix for which it does not 1194 provide service. 1196 As long as traffic filtering rules are restricted to match the 1197 corresponding unicast routing paths for the relevant prefixes, the 1198 security characteristics of this proposal are equivalent to the 1199 existing security properties of BGP unicast routing. 1201 Where it is not the case, this would open the door to further denial- 1202 of-service attacks. 1204 Enabling firewall-like capabilities in routers without centralized 1205 management could make certain failures harder to diagnose. For 1206 example, it is possible to allow TCP packets to pass between a pair 1207 of addresses but not ICMP packets. It is also possible to permit 1208 packets smaller than 900 or greater than 1000 bytes to pass between a 1209 pair of addresses, but not packets whose length is in the range 900- 1210 1000. Such behavior may be confusing and these capabilities should 1211 be used with care whether manually configured or coordinated through 1212 the protocol extensions described in this document. 1214 13. Original authors 1216 Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and 1217 Nischal Sheth were authors on [RFC5575], and therefore are 1218 contributing authors on this document. 1220 Note: Any original author of [RFC5575] who wants to work on this 1221 draft can be added as a co-author. 1223 14. Acknowledgements 1225 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 1226 Morrow, Charlie Kaufman, and David Smith for their comments for the 1227 comments on the original [RFC5575]. Chaitanya Kodeboyina helped 1228 design the flow validation procedure; and Steven Lin and Jim Washburn 1229 ironed out all the details necessary to produce a working 1230 implementation in the original [RFC5575]. 1232 Additional acknowledgements for this document will be included here. 1233 The current authors would like to thank Alexander Mayrhofer and 1234 Nicolas Fevrier for their comments and review. 1236 15. References 1238 15.1. Normative References 1240 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1241 RFC 793, DOI 10.17487/RFC0793, September 1981, 1242 . 1244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1245 Requirement Levels", BCP 14, RFC 2119, 1246 DOI 10.17487/RFC2119, March 1997, 1247 . 1249 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1250 "Definition of the Differentiated Services Field (DS 1251 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1252 DOI 10.17487/RFC2474, December 1998, 1253 . 1255 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1256 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1257 DOI 10.17487/RFC4271, January 2006, 1258 . 1260 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1261 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1262 February 2006, . 1264 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1265 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1266 2006, . 1268 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1269 "Multiprotocol Extensions for BGP-4", RFC 4760, 1270 DOI 10.17487/RFC4760, January 2007, 1271 . 1273 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1274 LAN Service (VPLS) Using BGP for Auto-Discovery and 1275 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1276 . 1278 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1279 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1280 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1281 . 1283 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1284 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1285 DOI 10.17487/RFC5226, May 2008, 1286 . 1288 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1289 and D. McPherson, "Dissemination of Flow Specification 1290 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1291 . 1293 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 1294 Specific BGP Extended Community", RFC 5668, 1295 DOI 10.17487/RFC5668, October 2009, 1296 . 1298 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1299 and A. Bierman, Ed., "Network Configuration Protocol 1300 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1301 . 1303 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1304 Origin Authorizations (ROAs)", RFC 6482, 1305 DOI 10.17487/RFC6482, February 2012, 1306 . 1308 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1309 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1310 March 2014, . 1312 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1313 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1314 . 1316 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1317 Patel, "Revised Error Handling for BGP UPDATE Messages", 1318 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1319 . 1321 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1322 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1323 October 2015, . 1325 15.2. Informative References 1327 [I-D.ietf-idr-bgp-flowspec-label] 1328 liangqiandeng, l., Hares, S., You, J., Raszuk, R., and d. 1329 danma@cisco.com, "Carrying Label Information for BGP 1330 FlowSpec", draft-ietf-idr-bgp-flowspec-label-00 (work in 1331 progress), June 2016. 1333 [I-D.ietf-idr-bgp-flowspec-oid] 1334 Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. 1335 Mohapatra, "Revised Validation Procedure for BGP Flow 1336 Specifications", draft-ietf-idr-bgp-flowspec-oid-03 (work 1337 in progress), March 2016. 1339 [I-D.ietf-idr-flow-spec-v6] 1340 McPherson, D., Raszuk, R., Pithawala, B., 1341 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 1342 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 1343 v6-07 (work in progress), March 2016. 1345 [I-D.ietf-idr-flowspec-interfaceset] 1346 Litkowski, S., Simpson, A., Patel, K., Haas, J., and L. 1347 Yong, "Applying BGP flowspec rules on a specific interface 1348 set", draft-ietf-idr-flowspec-interfaceset-02 (work in 1349 progress), October 2016. 1351 [I-D.ietf-idr-flowspec-l2vpn] 1352 Weiguo, H., liangqiandeng, l., Litkowski, S., and S. 1353 Zhuang, "Dissemination of Flow Specification Rules for L2 1354 VPN", draft-ietf-idr-flowspec-l2vpn-04 (work in progress), 1355 May 2016. 1357 [I-D.ietf-idr-flowspec-mpls-match] 1358 Yong, L., Hares, S., liangqiandeng, l., and J. You, "BGP 1359 Flow Specification Filter for MPLS Label", draft-ietf-idr- 1360 flowspec-mpls-match-00 (work in progress), May 2016. 1362 [I-D.ietf-idr-flowspec-nvo3] 1363 Weiguo, H., Zhuang, S., Li, Z., and R. Gu, "Dissemination 1364 of Flow Specification Rules for NVO3", draft-ietf-idr- 1365 flowspec-nvo3-00 (work in progress), May 2016. 1367 [I-D.ietf-idr-flowspec-packet-rate] 1368 Eddy, W., Dailey, J., and G. Clark, "BGP Flow 1369 Specification Packet-Rate Action", draft-ietf-idr- 1370 flowspec-packet-rate-00 (work in progress), June 2016. 1372 [I-D.ietf-idr-wide-bgp-communities] 1373 Raszuk, R., Haas, J., Lange, A., Amante, S., Decraene, B., 1374 Jakma, P., and R. Steenbergen, "Wide BGP Communities 1375 Attribute", draft-ietf-idr-wide-bgp-communities-03 (work 1376 in progress), September 2016. 1378 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1379 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1380 . 1382 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1383 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1384 Virtual Private Networks (L2VPNs)", RFC 6074, 1385 DOI 10.17487/RFC6074, January 2011, 1386 . 1388 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 1389 Origination Using the Resource Certificate Public Key 1390 Infrastructure (PKI) and Route Origin Authorizations 1391 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 1392 . 1394 Authors' Addresses 1396 Susan Hares 1397 Huawei 1398 7453 Hickory Hill 1399 Saline, MI 48176 1400 USA 1402 Email: shares@ndzh.com 1403 Robert Raszuk 1404 Bloomberg LP 1405 731 Lexington Ave 1406 New York City, NY 10022 1407 USA 1409 Email: robert@raszuk.net 1411 Danny McPherson 1412 Verisign 1413 USA 1415 Email: dmcpherson@verisign.com 1417 Christoph Loibl 1418 Next Layer Communications 1419 Mariahilfer Guertel 37/7 1420 Vienna 1150 1421 AT 1423 Phone: +43 664 1176414 1424 Email: cl@tix.at 1426 Martin Bacher 1427 T-Mobile Austria 1428 Rennweg 97-99 1429 Vienna 1030 1430 AT 1432 Phone: +43 676 8200 5143 1433 Email: martin.bacher@t-mobile.at