idnits 2.17.1 draft-ietf-idr-rfc5575bis-08.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC7674, but the abstract doesn't seem to directly say this. It does mention RFC7674 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2018) is 2098 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 585 -- Looks like a reference, but probably isn't: '139' on line 585 -- Looks like a reference, but probably isn't: '1' on line 1448 == Unused Reference: 'RFC4761' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 1396, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1406, but no explicit reference was found in the text == Unused Reference: 'RFC6482' is defined on line 1411, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-09 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group S. Hares 3 Internet-Draft Huawei 4 Obsoletes: 5575,7674 (if approved) C. Loibl 5 Intended status: Standards Track Next Layer Communications 6 Expires: December 23, 2018 R. Raszuk 7 Bloomberg LP 8 D. McPherson 9 Verisign 10 M. Bacher 11 T-Mobile Austria 12 June 21, 2018 14 Dissemination of Flow Specification Rules 15 draft-ietf-idr-rfc5575bis-08 17 Abstract 19 This document defines a Border Gateway Protocol Network Layer 20 Reachability Information (BGP NLRI) encoding format that can be used 21 to distribute traffic Flow Specifications. This allows the routing 22 system to propagate information regarding more specific components of 23 the traffic aggregate defined by an IP destination prefix. 25 It specifies IPv4 traffic Flow Specifications via a BGP NLRI which 26 carries traffic Flow Specification filter, and an Extended community 27 value which encodes actions a routing system can take if the packet 28 matches the traffic flow filters. The flow filters and the actions 29 are processed in a fixed order. Other drafts specify IPv6, MPLS 30 addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. 32 This document obsoletes RFC5575 and RFC7674 to correct unclear 33 specifications in the flow filters and to provide rules for actions 34 which interfere (e.g. redirection of traffic and flow filtering). 36 Applications which use the bgp Flow Specification are: 1) application 37 which automate inter-domain coordination of traffic filtering, such 38 as what is required in order to mitigate (distributed) denial-of- 39 service attacks; 2) applications 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 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 https://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 23, 2018. 63 Copyright Notice 65 Copyright (c) 2018 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 (https://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 19 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 . . . . . . . . . . 21 110 7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 111 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 22 112 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 23 113 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 23 114 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 23 115 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 23 116 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 24 117 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24 118 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 119 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 120 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 25 121 11.3. Extended Community Flow Specification Actions . . . . . 26 122 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 123 13. Original authors . . . . . . . . . . . . . . . . . . . . . . 29 124 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 125 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 126 15.1. Normative References . . . . . . . . . . . . . . . . . . 29 127 15.2. Informative References . . . . . . . . . . . . . . . . . 31 128 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 129 Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 32 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 132 1. Introduction 134 Modern IP routers contain both the capability to forward traffic 135 according to IP prefixes as well as to classify, shape, rate limit, 136 filter, or redirect packets based on administratively defined 137 policies. 139 These traffic policy mechanisms allow the router to define match 140 rules that operate on multiple fields of the packet header. Actions 141 such as the ones described above can be associated with each rule. 143 The n-tuple consisting of the matching criteria defines an aggregate 144 traffic Flow Specification. The matching criteria can include 145 elements such as source and destination address prefixes, IP 146 protocol, and transport protocol port numbers. 148 This document defines a general procedure to encode flow 149 specification rules for aggregated traffic flows so that they can be 150 distributed as a BGP [RFC4271] NLRI. Additionally, we define the 151 required mechanisms to utilize this definition to the problem of 152 immediate concern to the authors: intra- and inter-provider 153 distribution of traffic filtering rules to filter (distributed) 154 denial-of-service (DoS) attacks. 156 By expanding routing information with Flow Specifications, the 157 routing system can take advantage of the ACL (Access Control List) or 158 firewall capabilities in the router's forwarding path. Flow 159 specifications can be seen as more specific routing entries to a 160 unicast prefix and are expected to depend upon the existing unicast 161 data information. 163 A Flow Specification received from an external autonomous system will 164 need to be validated against unicast routing before being accepted. 165 If the aggregate traffic flow defined by the unicast destination 166 prefix is forwarded to a given BGP peer, then the local system can 167 safely install more specific flow rules that may result in different 168 forwarding behavior, as requested by this system. 170 The key technology components required to address the class of 171 problems targeted by this document are: 173 1. Efficient point-to-multipoint distribution of control plane 174 information. 176 2. Inter-domain capabilities and routing policy support. 178 3. Tight integration with unicast routing, for verification 179 purposes. 181 Items 1 and 2 have already been addressed using BGP for other types 182 of control plane information. Close integration with BGP also makes 183 it feasible to specify a mechanism to automatically verify flow 184 information against unicast routing. These factors are behind the 185 choice of BGP as the carrier of Flow Specification information. 187 As with previous extensions to BGP, this specification makes it 188 possible to add additional information to Internet routers. These 189 are limited in terms of the maximum number of data elements they can 190 hold as well as the number of events they are able to process in a 191 given unit of time. The authors believe that, as with previous 192 extensions, service providers will be careful to keep information 193 levels below the maximum capacity of their devices. 195 In many deployments of BGP Flow Specification, the Flow Specification 196 information has replace existing host length route advertisements. 198 Experience with previous BGP extensions has also shown that the 199 maximum capacity of BGP speakers has been gradually increased 200 according to expected loads. Taking into account Internet unicast 201 routing as well as additional applications as they gain popularity. 203 From an operational perspective, the utilization of BGP as the 204 carrier for this information allows a network service provider to 205 reuse both internal route distribution infrastructure (e.g., route 206 reflector or confederation design) and existing external 207 relationships (e.g., inter-domain BGP sessions to a customer 208 network). 210 While it is certainly possible to address this problem using other 211 mechanisms, this solution has been utilized in deployments because of 212 the substantial advantage of being an incremental addition to already 213 deployed mechanisms. 215 In current deployments, the information distributed by the flow-spec 216 extension is originated both manually as well as automatically. The 217 latter by systems that are able to detect malicious flows. When 218 automated systems are used, care should be taken to ensure their 219 correctness as well as to limit the number and advertisement rate of 220 flow routes. 222 This specification defines required protocol extensions to address 223 most common applications of IPv4 unicast and VPNv4 unicast filtering. 224 The same mechanism can be reused and new match criteria added to 225 address similar filtering needs for other BGP address families such 226 as IPv6 families [I-D.ietf-idr-flow-spec-v6], 228 2. Definitions of Terms Used in This Memo 230 NLRI - Network Layer Reachability Information. 232 RIB - Routing Information Base. 234 Loc-RIB - Local RIB. 236 AS - Autonomous System. 238 VRF - Virtual Routing and Forwarding instance. 240 PE - Provider Edge router 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 244 "OPTIONAL" in this document are to be interpreted as described in BCP 245 14 [RFC2119] [RFC8174] when, and only when, they appear in all 246 capitals, as shown here. 248 3. Flow Specifications 250 A Flow Specification is an n-tuple consisting of several matching 251 criteria that can be applied to IP traffic. A given IP packet is 252 said to match the defined flow if it matches all the specified 253 criteria. 255 A given flow may be associated with a set of attributes, depending on 256 the particular application; such attributes may or may not include 257 reachability information (i.e., NEXT_HOP). Well-known or AS-specific 258 community attributes can be used to encode a set of predetermined 259 actions. 261 A particular application is identified by a specific (Address Family 262 Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair 263 [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs 264 should be treated independently from each other in order to assure 265 non-interference between distinct applications. 267 BGP itself treats the NLRI as an opaque key to an entry in its 268 databases. Entries that are placed in the Loc-RIB are then 269 associated with a given set of semantics, which is application 270 dependent. This is consistent with existing BGP applications. For 271 instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast 272 reverse-path information (AFI=1, SAFI=2) are handled by BGP without 273 any particular semantics being associated with them until installed 274 in the Loc-RIB. 276 Standard BGP policy mechanisms, such as UPDATE filtering by NLRI 277 prefix as well as community matching and manipulation, MUST apply to 278 the Flow Specification defined NLRI-type, especially in an inter- 279 domain environment. Network operators can also control propagation 280 of such routing updates by enabling or disabling the exchange of a 281 particular (AFI, SAFI) pair on a given BGP peering session. 283 4. Dissemination of IPv4 FLow Specification Information 285 We define a "Flow Specification" NLRI type (Figure 1) that may 286 include several components such as destination prefix, source prefix, 287 protocol, ports, and others (see Section 4.2 below). This NLRI is 288 treated as an opaque bit string prefix by BGP. Each bit string 289 identifies a key to a database entry with which a set of attributes 290 can be associated. 292 This NLRI information is encoded using MP_REACH_NLRI and 293 MP_UNREACH_NLRI attributes as defined in [RFC4760]. Whenever the 294 corresponding application does not require Next-Hop information, this 295 shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI 296 attribute and ignored on receipt. 298 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 299 a 1- or 2-octet NLRI length field followed by a variable-length NLRI 300 value. The NLRI length is expressed in octets. 302 +------------------------------+ 303 | length (0xnn or 0xfn nn) | 304 +------------------------------+ 305 | NLRI value (variable) | 306 +------------------------------+ 308 Figure 1: Flow-spec NLRI for IPv4 310 Implementations wishing to exchange Flow Specification rules MUST use 311 BGP's Capability Advertisement facility to exchange the Multiprotocol 312 Extension Capability Code (Code 1) as defined in [RFC4760]. The 313 (AFI, SAFI) pair carried in the Multiprotocol Extension Capability 314 MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification, and (AFI=1, 315 SAFI=134) for VPNv4 Flow Specification. 317 4.1. Length Encoding 319 o If the NLRI length value is smaller than 240 (0xf0 hex), the 320 length field can be encoded as a single octet. 322 o Otherwise, it is encoded as an extended-length 2-octet value in 323 which the most significant nibble of the first byte is all ones. 325 In figure 1 above, values less-than 240 are encoded using two hex 326 digits (0xnn). Values above 239 are encoded using 3 hex digits 327 (0xfnnn). The highest value that can be represented with this 328 encoding is 4095. The value 241 is encoded as 0xf0f1. 330 4.2. NLRI Value Encoding 332 The Flow Specification NLRI-type consists of several optional 333 subcomponents. A specific packet is considered to match the flow 334 specification when it matches the intersection (AND) of all the 335 components present in the specification. 337 The encoding of each of the NLRI components begins with a type field 338 (1 octet) followed by a variable length parameter. Section 4.2.1 to 339 Section 4.2.12 define component types and parameter encodings for the 340 IPv4 IP layer and transport layer headers. IPv6 NLRI component types 341 are described in [I-D.ietf-idr-flow-spec-v6]. 343 Flow Specification components must follow strict type ordering by 344 increasing numerical order. A given component type may (exactly 345 once) or may not be present in the specification. If present, it 346 MUST precede any component of higher numeric type value. 348 All combinations of component types within a single NLRI are allowed, 349 even if the combination makes no sense from a semantical perspective. 350 If a given component type within a prefix in unknown, the prefix in 351 question cannot be used for traffic filtering purposes by the 352 receiver. Since a Flow Specification has the semantics of a logical 353 AND of all components, if a component is FALSE, by definition it 354 cannot be applied. However, for the purposes of BGP route 355 propagation, this prefix should still be transmitted since BGP route 356 distribution is independent on NLRI semantics. 358 The encoding is chosen in order to allow for future 359 extensibility. 361 4.2.1. Type 1 - Destination Prefix 363 Encoding: 365 Defines: the destination prefix to match. Prefixes are encoded as 366 in BGP UPDATE messages, a length in bits is followed by enough 367 octets to contain the prefix information. 369 4.2.2. Type 2 - Source Prefix 371 Encoding: 373 Defines the source prefix to match. 375 4.2.3. Type 3 - IP Protocol 377 Encoding: 379 Contains a set of {operator, value} pairs that are used to match 380 the IP protocol value byte in IP packets. 382 The operator byte is encoded as: 384 0 1 2 3 4 5 6 7 385 +---+---+---+---+---+---+---+---+ 386 | e | a | len | 0 |lt |gt |eq | 387 +---+---+---+---+---+---+---+---+ 389 Numeric operator 391 e - end-of-list bit. Set in the last {op, value} pair in the 392 list. 394 a - AND bit. If unset, the previous term is logically ORed with 395 the current one. If set, the operation is a logical AND. It 396 should be unset in the first operator byte of a sequence. The AND 397 operator has higher priority than OR for the purposes of 398 evaluating logical expressions. 400 len - length of the value field for this operand encodes 1 (00) - 401 4 (11) bytes. Type 3 flow component values are always encoded as 402 single byte (len = 00). 404 lt - less than comparison between data and value. 406 gt - greater than comparison between data and value. 408 eq - equality between data and value. 410 The bits lt, gt, and eq can be combined to produce common relational 411 operators such as "less or equal", "greater or equal", and "not equal 412 to". 414 +----+----+----+----------------------------------+ 415 | lt | gt | eq | Resulting operation | 416 +----+----+----+----------------------------------+ 417 | 0 | 0 | 0 | true (independent of the value) | 418 | 0 | 0 | 1 | == (equal) | 419 | 0 | 1 | 0 | > (greater than) | 420 | 0 | 1 | 1 | >= (greater than or equal) | 421 | 1 | 0 | 0 | < (less than) | 422 | 1 | 0 | 1 | <= (less than or equal) | 423 | 1 | 1 | 0 | != (not equal value) | 424 | 1 | 1 | 1 | false (independent of the value) | 425 +----+----+----+----------------------------------+ 427 Table 1: Comparison operation combinations 429 4.2.4. Type 4 - Port 431 Encoding: 433 Defines a list of {operator, value} pairs that matches source OR 434 destination TCP/UDP ports. This list is encoded using the numeric 435 operator format defined in Section 4.2.3. Values are encoded as 436 1- or 2-byte quantities. 438 Port, source port, and destination port components evaluate to 439 FALSE if the IP protocol field of the packet has a value other 440 than TCP or UDP, if the packet is fragmented and this is not the 441 first fragment, or if the system in unable to locate the transport 442 header. Different implementations may or may not be able to 443 decode the transport header in the presence of IP options or 444 Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. 446 4.2.5. Type 5 - Destination Port 448 Encoding: 450 Defines a list of {operator, value} pairs used to match the 451 destination port of a TCP or UDP packet. This list is encoded 452 using the numeric operator format defined in Section 4.2.3. 453 Values are encoded as 1- or 2-byte quantities. 455 4.2.6. Type 6 - Source Port 457 Encoding: 459 Defines a list of {operator, value} pairs used to match the source 460 port of a TCP or UDP packet. This list is encoded using the 461 numeric operator format defined in Section 4.2.3. Values are 462 encoded as 1- or 2-byte quantities. 464 4.2.7. Type 7 - ICMP type 466 Encoding: 468 Defines a list of {operator, value} pairs used to match the type 469 field of an ICMP packet. This list is encoded using the numeric 470 operator format defined in Section 4.2.3. Values are encoded 471 using a single byte. 473 The ICMP type specifiers evaluate to FALSE whenever the protocol 474 value is not ICMP. 476 4.2.8. Type 8 - ICMP code 478 Encoding: 480 Defines a list of {operator, value} pairs used to match the code 481 field of an ICMP packet. This list is encoded using the numeric 482 operator format defined in Section 4.2.3. Values are encoded 483 using a single byte. 485 The ICMP code specifiers evaluate to FALSE whenever the protocol 486 value is not ICMP. 488 4.2.9. Type 9 - TCP flags 490 Encoding: 492 Bitmask values can be encoded as a 1- or 2-byte bitmask. When a 493 single byte is specified, it matches byte 13 of the TCP header 494 [RFC0793], which contains bits 8 though 15 of the 4th 32-bit word. 495 When a 2-byte encoding is used, it matches bytes 12 and 13 of the 496 TCP header with the data offset field having a "don't care" value. 498 This component evaluates to FALSE for packets that are not TCP 499 packets. 501 This type uses the bitmask operand format, which differs from the 502 numeric operator format in the lower nibble. 504 0 1 2 3 4 5 6 7 505 +---+---+---+---+---+---+---+---+ 506 | e | a | len | 0 | 0 |not| m | 507 +---+---+---+---+---+---+---+---+ 509 Bitmask format 511 e, a, len - Most significant nibble: (end-of-list bit, AND bit, and 512 length field), as defined for in the numeric operator format in 513 Section 4.2.3. 515 not - NOT bit. If set, logical negation of operation. 517 m - Match bit. If set, this is a bitwise match operation defined 518 as "(data AND value) == value"; if unset, (data AND value) 519 evaluates to TRUE if any of the bits in the value mask are set in 520 the data 522 4.2.10. Type 10 - Packet length 524 Encoding: 526 Defines a list of {operator, value} pairs used to match on the 527 total IP packet length (excluding Layer 2 but including IP 528 header). This list is encoded using the numeric operator format 529 defined in Section 4.2.3. Values are encoded using 1- or 2-byte 530 quantities. 532 4.2.11. Type 11 - DSCP (Diffserv Code Point) 534 Encoding: 536 Defines a list of {operator, value} pairs used to match the 6-bit 537 DSCP field [RFC2474]. This list is encoded using the numeric 538 operator format defined in Section 4.2.3. Values are encoded 539 using a single byte. The two most significant bits are zero and 540 the six least significant bits contain the DSCP value. 542 4.2.12. Type 12 - Fragment 544 Encoding: 546 Uses bitmask operand format defined in Section 4.2.9. 548 0 1 2 3 4 5 6 7 549 +---+---+---+---+---+---+---+---+ 550 | Reserved |LF |FF |IsF|DF | 551 +---+---+---+---+---+---+---+---+ 553 Bitmask values: 555 Bit 7 - Don't fragment (DF) 557 Bit 6 - Is a fragment (IsF) 559 Bit 5 - First fragment (FF) 561 Bit 4 - Last fragment (LF) 563 4.3. Examples of Encodings 565 An example of a Flow Specification encoding for: "all packets to 566 10.0.1/24 and TCP port 25". 568 +------------------+----------+----------+ 569 | destination | proto | port | 570 +------------------+----------+----------+ 571 | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | 572 +------------------+----------+----------+ 574 Decode for protocol: 576 +-------+----------+------------------------------+ 577 | Value | | | 578 +-------+----------+------------------------------+ 579 | 0x03 | type | | 580 | 0x81 | operator | end-of-list, value size=1, = | 581 | 0x06 | value | | 582 +-------+----------+------------------------------+ 584 An example of a Flow Specification encoding for: "all packets to 585 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". 587 +------------------+----------+-------------------------+ 588 | destination | source | port | 589 +------------------+----------+-------------------------+ 590 | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | 591 +------------------+----------+-------------------------+ 593 Decode for port: 595 +--------+----------+------------------------------+ 596 | Value | | | 597 +--------+----------+------------------------------+ 598 | 0x04 | type | | 599 | 0x03 | operator | size=1, >= | 600 | 0x89 | value | 137 | 601 | 0x45 | operator | "AND", value size=1, <= | 602 | 0x8b | value | 139 | 603 | 0x91 | operator | end-of-list, value-size=2, = | 604 | 0x1f90 | value | 8080 | 605 +--------+----------+------------------------------+ 607 This constitutes an NLRI with an NLRI length of 16 octets. 609 5. Traffic Filtering 611 Traffic filtering policies have been traditionally considered to be 612 relatively static. Limitations of the static mechanisms caused this 613 mechanism to be designed for the three new applications of traffic 614 filtering (prevention of traffic-based, denial-of-service (DOS) 615 attacks, traffic filtering in the context of BGP/MPLS VPN service, 616 and centralized traffic control for SDN/NFV networks) requires 617 coordination among service providers and/or coordination among the AS 618 within a service provider. Section 8 has details on the limitation 619 of previous mechanisms and why BGP Flow Specification version 1 620 provides a solution for to prevent DOS and aid BGP/MPLS VPN filtering 621 rules. 623 This Flow Specification NLRI defined above to convey information 624 about traffic filtering rules for traffic that should be discarded or 625 handled in manner specified by a set of pre-defined actions (which 626 are defined in BGP Extended Communities). This mechanism is 627 primarily designed to allow an upstream autonomous system to perform 628 inbound filtering in their ingress routers of traffic that a given 629 downstream AS wishes to drop. 631 In order to achieve this goal, this draft specifies two application 632 specific NLRI identifiers that provide traffic filters, and a set of 633 actions encoding in BGP Extended Communities. The two application 634 specific NLRI identifiers are: 636 o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with 637 specific semantic rules for IPv4 routes, and 639 o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which 640 can be used to propagate traffic filtering information in a BGP/ 641 MPLS VPN environment. 643 Distribution of the IPv4 Flow Specification is described in section 644 6, and distibution of BGP/MPLS traffic Flow Specification is 645 described in section 8. The traffic filtering actions are described 646 in section 7. 648 5.1. Ordering of Traffic Filtering Rules 650 With traffic filtering rules, more than one rule may match a 651 particular traffic flow. Thus, it is necessary to define the order 652 at which rules get matched and applied to a particular traffic flow. 653 This ordering function must be such that it must not depend on the 654 arrival order of the Flow Specification's rules and must be 655 consistent in the network. 657 The relative order of two Flow Specification rules is determined by 658 comparing their respective components. The algorithm starts by 659 comparing the left-most components of the rules. If the types 660 differ, the rule with lowest numeric type value has higher precedence 661 (and thus will match before) than the rule that doesn't contain that 662 component type. If the component types are the same, then a type- 663 specific comparison is performed (see below) if the types are equal 664 the algorithm continues with the next component. 666 For IP prefix values (IP destination or source prefix): If the 667 prefixes overlap, the one with the longer prefix-length has higher 668 precedence. If they do not overlap the one with the lowest IP value 669 has higher precedence. 671 For all other component types, unless otherwise specified, the 672 comparison is performed by comparing the component data as a binary 673 string using the memcmp() function as defined by the ISO C standard. 674 For strings with equal lengths the lowest string (memcmp) has higher 675 precedence. For strings of different lengths, the common prefix is 676 compared. If the common prefix is not equal the string with the 677 lowest prefix has higher precedence. If the common prefix is equal, 678 the longest string is considered to have higher precedence than the 679 shorter one. 681 The code below shows a Python3 implementation of the comparison 682 algorithm. The full code was tested with Python 3.6.3 and can be 683 obtained at https://github.com/stoffi92/flowspec-cmp [1]. 685 686 import itertools 687 import ipaddress 689 def flow_rule_cmp(a, b): 690 for comp_a, comp_b in itertools.zip_longest(a.components, 691 b.components): 692 # If a component type does not exist in one rule 693 # this rule has lower precedence 694 if not comp_a: 695 return B_HAS_PRECEDENCE 696 if not comp_b: 697 return A_HAS_PRECEDENCE 698 # higher precedence for lower component type 699 if comp_a.component_type < comp_b.component_type: 700 return A_HAS_PRECEDENCE 701 if comp_a.component_type > comp_b.component_type: 702 return B_HAS_PRECEDENCE 703 # component types are equal -> type specific comparison 704 if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): 705 # assuming comp_a.value, comp_b.value of type ipaddress 706 if comp_a.value.overlaps(comp_b.value): 707 # longest prefixlen has precedence 708 if comp_a.value.prefixlen > comp_b.value.prefixlen: 709 return A_HAS_PRECEDENCE 710 if comp_a.value.prefixlen < comp_b.value.prefixlen: 712 return B_HAS_PRECEDENCE 713 # components equal -> continue with next component 714 elif comp_a.value > comp_b.value: 715 return B_HAS_PRECEDENCE 716 elif comp_a.value < comp_b.value: 717 return A_HAS_PRECEDENCE 718 else: 719 # assuming comp_a.value, comp_b.value of type bytearray 720 if len(comp_a.value) == len(comp_b.value): 721 if comp_a.value > comp_b.value: 722 return B_HAS_PRECEDENCE 723 if comp_a.value < comp_b.value: 724 return A_HAS_PRECEDENCE 725 # components equal -> continue with next component 726 else: 727 common = min(len(comp_a.value), len(comp_b.value)) 728 if comp_a.value[:common] > comp_b.value[:common]: 729 return B_HAS_PRECEDENCE 730 elif comp_a.value[:common] < comp_b.value[:common]: 731 return A_HAS_PRECEDENCE 732 # the first common bytes match 733 elif len(comp_a.value) > len(comp_b.value): 734 return A_HAS_PRECEDENCE 735 else: 736 return B_HAS_PRECEDENCE 737 return EQUAL 738 740 6. Validation Procedure 742 Flow Specifications received from a BGP peer that are accepted in the 743 respective Adj-RIB-In are used as input to the route selection 744 process. Although the forwarding attributes of two routes for the 745 same Flow Specification prefix may be the same, BGP is still required 746 to perform its path selection algorithm in order to select the 747 correct set of attributes to advertise. 749 The first step of the BGP Route Selection procedure (Section 9.1.2 of 750 [RFC4271] is to exclude from the selection procedure routes that are 751 considered non-feasible. In the context of IP routing information, 752 this step is used to validate that the NEXT_HOP attribute of a given 753 route is resolvable. 755 The concept can be extended, in the case of Flow Specification NLRI, 756 to allow other validation procedures. 758 A Flow Specification NLRI must be validated such that it is 759 considered feasible if and only if: 761 a) The originator of the Flow Specification matches the originator 762 of the best-match unicast route for the destination prefix 763 embedded in the Flow Specification. 765 b) There are no more specific unicast routes, when compared with 766 the flow destination prefix, that has been received from a 767 different neighboring AS than the best-match unicast route, which 768 has been determined in step a). 770 By originator of a BGP route, we mean either the BGP originator path 771 attribute, as used by route reflection, or the transport address of 772 the BGP peer, if this path attribute is not present. 774 BGP implementations MUST also enforce that the AS_PATH attribute of a 775 route received via the External Border Gateway Protocol (eBGP) 776 contains the neighboring AS in the left-most position of the AS_PATH 777 attribute. While this rule is optional in the BGP specification, it 778 becomes necessary to enforce it for security reasons. 780 The best-match unicast route may change over the time independently 781 of the Flow Specification NLRI. Therefore, a revalidation of the 782 Flow Specification NLRI MUST be performed whenever unicast routes 783 change. Revalidation is defined as retesting that clause a and 784 clause b above are true. 786 Explanation: 788 The underlying concept is that the neighboring AS that advertises the 789 best unicast route for a destination is allowed to advertise flow- 790 spec information that conveys a more or equally specific destination 791 prefix. Thus, as long as there are no more specific unicast routes, 792 received from a different neighboring AS, which would be affected by 793 that filtering rule. 795 The neighboring AS is the immediate destination of the traffic 796 described by the Flow Specification. If it requests these flows to 797 be dropped, that request can be honored without concern that it 798 represents a denial of service in itself. Supposedly, the traffic is 799 being dropped by the downstream autonomous system, and there is no 800 added value in carrying the traffic to it. 802 7. Traffic Filtering Actions 804 This specification defines a minimum set of filtering actions that it 805 standardizes as BGP extended community values [RFC4360]. This is not 806 meant to be an inclusive list of all the possible actions, but only a 807 subset that can be interpreted consistently across the network. 809 Additional actions can be defined as either requiring standards or as 810 vendor specific. 812 Implementations SHOULD provide mechanisms that map an arbitrary BGP 813 community value (normal or extended) to filtering actions that 814 require different mappings in different systems in the network. For 815 instance, providing packets with a worse-than-best-effort, per-hop 816 behavior is a functionality that is likely to be implemented 817 differently in different systems and for which no standard behavior 818 is currently known. Rather than attempting to define it here, this 819 can be accomplished by mapping a user-defined community value to 820 platform-/network-specific behavior via user configuration. 822 The default action for a traffic filtering Flow Specification is to 823 accept IP traffic that matches that particular rule. 825 This document defines the following extended communities values shown 826 in Table 2 in the form 0x8xnn where nn indicates the sub-type. 827 Encodings for these extended communities are described below. 829 +-----------+----------------------+--------------------------------+ 830 | community | action | encoding | 831 +-----------+----------------------+--------------------------------+ 832 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | 833 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | 834 | 0x8007 | traffic-action | bitmask | 835 | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value | 836 | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet | 837 | | | value | 838 | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value | 839 | 0x8009 | traffic-marking | DSCP value | 840 +-----------+----------------------+--------------------------------+ 842 Table 2: Traffic Action Extended Communities 844 Some traffic action communities may interfere with each other. 845 Section 7.6 of this specification provides rules for handling 846 interference between specific types of traffic actions, and error 847 handling based on [RFC7606]. Any additional definition of a traffic 848 actions specified by additional standards documents or vendor 849 documents MUST specify if the traffic action interacts with an 850 existing traffic actions, and provide error handling per [RFC7606]. 852 Multiple traffic actions may be present for a single NLRI. The 853 traffic actions are processed in ascending order of the sub-type 854 found in the BGP Extended Communities. If not all of them can be 855 processed the filter SHALL NOT be applied at all (for example: if for 856 a given flow there are the action communities rate-limit-bytes and 857 traffic-marking attached, and the plattform does not support one of 858 them also the other shall not be applied for that flow). 860 All traffic actions are specified as transitive BGP Extended 861 Communities. 863 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 865 The traffic-rate-bytes extended community uses the following extended 866 community encoding: 868 The first two octets carry the 2-octet id, which can be assigned from 869 a 2-byte AS number. When a 4-byte AS number is locally present, the 870 2 least significant bytes of such an AS number can be used. This 871 value is purely informational and should not be interpreted by the 872 implementation. 874 The remaining 4 octets carry the maximum rate information in IEEE 875 floating point [IEEE.754.1985] format, units being bytes per second. 876 A traffic-rate of 0 should result on all traffic for the particular 877 flow to be discarded. 879 Interferes with: No other BGP Flow Specification traffic action in 880 this document. 882 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD 884 The traffic-rate-packets extended community uses the same encoding as 885 the traffic-rate-bytes extended community. The floating point value 886 carries the maximum packet rate in packets per second. A traffic- 887 rate-packets of 0 should result in all traffic for the particular 888 flow to be discarded. 890 Interferes with: No other BGP Flow Specification traffic action in 891 this document. 893 7.3. Traffic-action (traffic-action) sub-type 0x07 895 The traffic-action extended community consists of 6 bytes of which 896 only the 2 least significant bits of the 6th byte (from left to 897 right) are currently defined. 899 40 41 42 43 44 45 46 47 900 +---+---+---+---+---+---+---+---+ 901 | reserved | S | T | 902 +---+---+---+---+---+---+---+---+ 904 where S and T are defined as: 906 o T: Terminal Action (bit 47): When this bit is set, the traffic 907 filtering engine will apply any subsequent filtering rules (as 908 defined by the ordering procedure). If not set, the evaluation of 909 the traffic filter stops when this rule is applied. 911 o S: Sample (bit 46): Enables traffic sampling and logging for this 912 Flow Specification. 914 o reserved: should always be set to 0 by the originator and not be 915 evaluated by the receiving BGP speaker. 917 The use of the Terminal Action (bit 47) may result in more than one 918 filter-rule matching a particular flow. All the flow actions from 919 these rules shall be collected and applied. If interfering actions 920 have been collected only the first occurence SHALL be applied. 921 However, if a single rule contains interfering actions this rule 922 SHALL still be handled as described in Section 7.6. 924 Interferes with: No other BGP Flow Specification traffic action in 925 this document. 927 7.4. RT Redirect (rt-redirect) sub-type 0x08 929 The redirect extended community allows the traffic to be redirected 930 to a VRF routing instance that lists the specified route-target in 931 its import policy. If several local instances match this criteria, 932 the choice between them is a local matter (for example, the instance 933 with the lowest Route Distinguisher value can be elected). This 934 extended community allows 3 different encodings formats for the 935 route-target (type 0x80, 0x81, 0x82). Is uses the same encoding as 936 the Route Target extended community [RFC4360]. 938 It should be noted that the low-order nibble of the Redirect's Type 939 field corresponds to the Route Target Extended Community format field 940 (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of 941 [RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended 942 Community remains 0x08 for all three encodings of the BGP Extended 943 Communities (AS 2-byte, AS 4-byte, and IPv4 address). 945 Interferes with: All other redirect functions. All redirect 946 functions are mutually exclusive. If this redirect function exists, 947 then no other redirect functions can be processed. 949 7.5. Traffic Marking (traffic-marking) sub-type 0x09 951 The traffic marking extended community instructs a system to modify 952 the DSCP bits of a transiting IP packet to the corresponding value. 953 This extended community is encoded as a sequence of 5 zero bytes 954 followed by the DSCP value encoded in the 6 least significant bits of 955 6th byte. 957 Interferes with: No other BGP Flow Specification traffic action in 958 this document. 960 7.6. Rules on Traffic Action Interference 962 Traffic actions may interfere with each other. If interfering 963 traffic actions are present for a single Flow Specification NLRI the 964 entire Flow Specification (irrespective if there are any other non 965 conflicting actions associated with the same Flow Specification) 966 SHALL be treated as BGP WITHDRAW. 968 This document defines 7 traffic actions which are interfering in the 969 following way: 971 1. Redirect-action-communities (0x8008, 0x8108, 0x8208): 973 The three redirect-communities are mutually exclusive. Only a 974 single redirect community may be associated with a Flow 975 Specification otherwise they are interfering. 977 2. All traffic-action communities (including redirect-actions): 979 Multiple occurences of the same (sub-type and type) traffic- 980 action associated with a Flow Specification are always 981 interfering. 983 When a traffic action is defined in a standards document the handling 984 of interaction with other/same traffic actions MUST be defined as 985 well. Invalid interactions between actions SHOULD NOT trigger a BGP 986 NOTIFICATION. All error handling for error conditions based on 987 [RFC7606]. 989 7.6.1. Examples 991 (rt-redirect vrf-a, rt-redirect vrf-b, traffic-rate-bytes 1Mbit/s) 993 RT-redirect vrf-a and rt-redirect vrf-b are interfering: The BGP 994 UPDATE is treated as WITHDRAW. 996 (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate-bytes 997 2Mbit/s) 999 Duplicate traffic-rate-bytes are interfering: The BGP UPDATE is 1000 treated as WITHDRAW. 1002 (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate- 1003 packets 1000) 1005 No interfering action communities: The BGP UPDATE is subject to 1006 further processing. 1008 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 1010 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1011 MPLS IP VPN [RFC4364] control plane, may have different traffic 1012 filtering requirements than Internet service providers. But also 1013 Internet service providers may use those VPNs for scenarios like 1014 having the Internet routing table in a VRF, resulting in the same 1015 traffic filtering requirements as defined for the global routing 1016 table environment within this document. This document proposes an 1017 additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used 1018 to propagate traffic filtering information in a BGP/MPLS VPN 1019 environment. 1021 The NLRI format for this address family consists of a fixed-length 1022 Route Distinguisher field (8 bytes) followed by a Flow Specification, 1023 following the encoding defined above in Section 4.2 of this document. 1024 The NLRI length field shall include both the 8 bytes of the Route 1025 Distinguisher as well as the subsequent Flow Specification. 1027 +------------------------------+ 1028 | length (0xnn or 0xfn nn) | 1029 +------------------------------+ 1030 | Route Distinguisher (8 bytes)| 1031 +------------------------------+ 1032 | NLRI value (variable) | 1033 +------------------------------+ 1035 Flow-spec NLRI for MPLS 1037 Propagation of this NLRI is controlled by matching Route Target 1038 extended communities associated with the BGP path advertisement with 1039 the VRF import policy, using the same mechanism as described in "BGP/ 1040 MPLS IP VPNs" [RFC4364]. 1042 Flow Specification rules received via this NLRI apply only to traffic 1043 that belongs to the VRF(s) in which it is imported. By default, 1044 traffic received from a remote PE is switched via an MPLS forwarding 1045 decision and is not subject to filtering. 1047 Contrary to the behavior specified for the non-VPN NLRI, flow rules 1048 are accepted by default, when received from remote PE routers. 1050 8.1. Validation Procedures for BGP/MPLS VPNs 1052 The validation procedures are the same as for IPv4. 1054 8.2. Traffic Actions Rules 1056 The traffic action rules are the same as for IPv4. 1058 9. Limitations of Previous Traffic Filtering Efforts 1060 9.1. Limitations in Previous DDoS Traffic Filtering Efforts 1062 The popularity of traffic-based, denial-of-service (DoS) attacks, 1063 which often requires the network operator to be able to use traffic 1064 filters for detection and mitigation, brings with it requirements 1065 that are not fully satisfied by existing tools. 1067 Increasingly, DoS mitigation requires coordination among several 1068 service providers in order to be able to identify traffic source(s) 1069 and because the volumes of traffic may be such that they will 1070 otherwise significantly affect the performance of the network. 1072 Several techniques are currently used to control traffic filtering of 1073 DoS attacks. Among those, one of the most common is to inject 1074 unicast route advertisements corresponding to a destination prefix 1075 being attacked (commonly known as remote triggered blackhole RTBH). 1076 One variant of this technique marks such route advertisements with a 1077 community that gets translated into a discard Next-Hop by the 1078 receiving router. Other variants attract traffic to a particular 1079 node that serves as a deterministic drop point. 1081 Using unicast routing advertisements to distribute traffic filtering 1082 information has the advantage of using the existing infrastructure 1083 and inter-AS communication channels. This can allow, for instance, a 1084 service provider to accept filtering requests from customers for 1085 address space they own. 1087 There are several drawbacks, however. An issue that is immediately 1088 apparent is the granularity of filtering control: only destination 1089 prefixes may be specified. Another area of concern is the fact that 1090 filtering information is intermingled with routing information. 1092 The mechanism defined in this document is designed to address these 1093 limitations. We use the Flow Specification NLRI defined above to 1094 convey information about traffic filtering rules for traffic that is 1095 subject to modified forwarding behavior (actions). The actions are 1096 defined as extended communities and include (but are not limited to) 1097 rate-limiting (including discard), traffic redirection, packet 1098 rewriting. 1100 9.2. Limitations in Previous BGP/MPLS Traffic Filtering 1102 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1103 MPLS IP VPN [RFC4364] control plane, may have different traffic 1104 filtering requirements than Internet service providers. 1106 In these environments, the VPN customer network often has traffic 1107 filtering capabilities towards their external network connections 1108 (e.g., firewall facing public network connection). Less common is 1109 the presence of traffic filtering capabilities between different VPN 1110 attachment sites. In an any-to-any connectivity model, which is the 1111 default, this means that site-to-site traffic is unfiltered. 1113 In circumstances where a security threat does get propagated inside 1114 the VPN customer network, there may not be readily available 1115 mechanisms to provide mitigation via traffic filter. 1117 But also Internet service providers may use those VPNs for scenarios 1118 like having the Internet routing table in a VRF. Therefore, 1119 limitations described in Section 9.1 also apply to this section. 1121 The BGP Flow Specification version 1 addresses these limitations. 1123 10. Traffic Monitoring 1125 Traffic filtering applications require monitoring and traffic 1126 statistics facilities. While this is an implementation-specific 1127 choice, implementations SHOULD provide: 1129 o A mechanism to log the packet header of filtered traffic. 1131 o A mechanism to count the number of matches for a given flow 1132 specification rule. 1134 11. IANA Considerations 1136 This section complies with [RFC7153]. 1138 11.1. AFI/SAFI Definitions 1140 IANA maintains a registry entitled "SAFI Values". For the purpose of 1141 this work, IANA updated the registry and allocated two additional 1142 SAFIs: 1144 +-------+------------------------------------------+----------------+ 1145 | Value | Name | Reference | 1146 +-------+------------------------------------------+----------------+ 1147 | 133 | IPv4 dissemination of Flow Specification | [this | 1148 | | rules | document] | 1149 | 134 | VPNv4 dissemination of Flow | [this | 1150 | | Specification rules | document] | 1151 +-------+------------------------------------------+----------------+ 1153 Table 3: Registry: SAFI Values 1155 11.2. Flow Component Definitions 1157 A Flow Specification consists of a sequence of flow components, which 1158 are identified by a an 8-bit component type. IANA has created and 1159 maintains a registry entitled "Flow Spec Component Types". This 1160 document defines the following Component Type Codes: 1162 +-------+--------------------+-----------------+ 1163 | Value | Name | Reference | 1164 +-------+--------------------+-----------------+ 1165 | 1 | Destination Prefix | [this document] | 1166 | 2 | Source Prefix | [this document] | 1167 | 3 | IP Protocol | [this document] | 1168 | 4 | Port | [this document] | 1169 | 5 | Destination port | [this document] | 1170 | 6 | Source port | [this document] | 1171 | 7 | ICMP type | [this document] | 1172 | 8 | ICMP code | [this document] | 1173 | 9 | TCP flags | [this document] | 1174 | 10 | Packet length | [this document] | 1175 | 11 | DSCP | [this document] | 1176 | 12 | Fragment | [this document] | 1177 +-------+--------------------+-----------------+ 1179 Table 4: Registry: Flow Spec Component Types 1181 In order to manage the limited number space and accommodate several 1182 usages, the following policies defined by [RFC8126] used: 1184 +--------------+-------------------------------+ 1185 | Range | Policy | 1186 +--------------+-------------------------------+ 1187 | 0 | Invalid value | 1188 | [1 .. 12] | Defined by this specification | 1189 | [13 .. 127] | Specification required | 1190 | [128 .. 255] | First Come First Served | 1191 +--------------+-------------------------------+ 1193 Table 5: Flow Spec Component Types Policies 1195 The specification of a particular "Flow Spec Component Type" must 1196 clearly identify what the criteria used to match packets forwarded by 1197 the router is. This criteria should be meaningful across router hops 1198 and not depend on values that change hop-by-hop such as TTL or Layer 1199 2 encapsulation. 1201 11.3. Extended Community Flow Specification Actions 1203 The Extended Community Flow Specification Action types defined in 1204 this document consist of two parts: 1206 Type (BGP Transitive Extended Community Type) 1208 Sub-Type 1210 For the type-part, IANA maintains a registry entitled "BGP Transitive 1211 Extended Community Types". For the purpose of this work (Section 7), 1212 IANA updated the registry to contain the values listed below: 1214 +-------+-----------------------------------------------+-----------+ 1215 | Type | Name | Reference | 1216 | Value | | | 1217 +-------+-----------------------------------------------+-----------+ 1218 | 0x80 | Generic Transitive Experimental Use Extended | [RFC7153] | 1219 | | Community (Sub-Types are defined in the | | 1220 | | "Generic Transitive Experimental Use Extended | | 1221 | | Community Sub-Types" registry) | | 1222 | 0x81 | Generic Transitive Experimental Use Extended | [this | 1223 | | Community Part 2 (Sub-Types are defined in | document] | 1224 | | the "Generic Transitive Experimental Use | [See | 1225 | | Extended Community Part 2 Sub-Types" | Note-1] | 1226 | | Registry) | | 1227 | 0x82 | Generic Transitive Experimental Use Extended | [this | 1228 | | Community Part 3 (Sub-Types are defined in | document] | 1229 | | the "Generic Transitive Experimental Use | [See | 1230 | | Extended Community Part 3 Sub-Types" | Note-1] | 1231 | | Registry) | | 1232 +-------+-----------------------------------------------+-----------+ 1234 Table 6: Registry: Generic Transitive Experimental Use Extended 1235 Community Types 1237 Note-1: This document obsoletes RFC7674. 1239 For the sub-type part of the extended community actions IANA 1240 maintains and updated the following registries: 1242 +----------+-----------------------------------------+--------------+ 1243 | Sub-Type | Name | Reference | 1244 | Value | | | 1245 +----------+-----------------------------------------+--------------+ 1246 | 0x06 | Flow spec traffic-rate-bytes | [this | 1247 | | | document] | 1248 | TBD | Flow spec traffic-rate-packets | [this | 1249 | | | document] | 1250 | 0x07 | Flow spec traffic-action (Use of the | [this | 1251 | | "Value" field is defined in the | document] | 1252 | | "Traffic Action Fields" registry) | [See Note-2] | 1253 | 0x08 | Flow spec rt-redirect AS-2byte format | [this | 1254 | | | document] | 1255 | 0x09 | Flow spec traffic-remarking | [this | 1256 | | | document] | 1257 +----------+-----------------------------------------+--------------+ 1259 Table 7: Registry: Generic Transitive Experimental Use Extended 1260 Community Sub-Types 1262 Note-2: This document obsoletes both RFC7674 and RFC5575. 1264 +-------------+---------------------------+-------------------------+ 1265 | Sub-Type | Name | Reference | 1266 | Value | | | 1267 +-------------+---------------------------+-------------------------+ 1268 | 0x08 | Flow spec rt-redirect | [this document] [See | 1269 | | IPv4 format | Note-3] | 1270 +-------------+---------------------------+-------------------------+ 1272 Table 8: Registry: Generic Transitive Experimental Use Extended 1273 Community Part 2 Sub-Types 1275 +-------------+----------------------------+------------------------+ 1276 | Sub-Type | Name | Reference | 1277 | Value | | | 1278 +-------------+----------------------------+------------------------+ 1279 | 0x08 | Flow spec rt-redirect AS- | [this document] [See | 1280 | | 4byte format | Note-3] | 1281 +-------------+----------------------------+------------------------+ 1283 Table 9: Registry: Generic Transitive Experimental Use Extended 1284 Community Part 3 Sub-Types 1286 Note-3: This document obsoletes RFC7674, and becomes the only 1287 reference for this table. 1289 The "traffic-action" extended community (Section 7.3) defined in this 1290 document has 46 unused bits, which can be used to convey additional 1291 meaning. IANA created and maintains a new registry entitled: 1292 "Traffic Action Fields". These values should be assigned via IETF 1293 Review rules only. The following traffic-action fields have been 1294 allocated: 1296 +-----+-----------------+-----------------+ 1297 | Bit | Name | Reference | 1298 +-----+-----------------+-----------------+ 1299 | 47 | Terminal Action | [this document] | 1300 | 46 | Sample | [this document] | 1301 +-----+-----------------+-----------------+ 1303 Table 10: Registry: Traffic Action Fields 1305 12. Security Considerations 1307 Inter-provider routing is based on a web of trust. Neighboring 1308 autonomous systems are trusted to advertise valid reachability 1309 information. If this trust model is violated, a neighboring 1310 autonomous system may cause a denial-of-service attack by advertising 1311 reachability information for a given prefix for which it does not 1312 provide service. 1314 As long as traffic filtering rules are restricted to match the 1315 corresponding unicast routing paths for the relevant prefixes, the 1316 security characteristics of this proposal are equivalent to the 1317 existing security properties of BGP unicast routing. 1319 Where it is not the case, this would open the door to further denial- 1320 of-service attacks. 1322 Enabling firewall-like capabilities in routers without centralized 1323 management could make certain failures harder to diagnose. For 1324 example, it is possible to allow TCP packets to pass between a pair 1325 of addresses but not ICMP packets. It is also possible to permit 1326 packets smaller than 900 or greater than 1000 bytes to pass between a 1327 pair of addresses, but not packets whose length is in the range 900- 1328 1000. Such behavior may be confusing and these capabilities should 1329 be used with care whether manually configured or coordinated through 1330 the protocol extensions described in this document. 1332 13. Original authors 1334 Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and 1335 Nischal Sheth were authors on RFC5575, and therefore are contributing 1336 authors on this document. 1338 14. Acknowledgements 1340 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 1341 Morrow, Charlie Kaufman, and David Smith for their comments for the 1342 comments on the original RFC5575. Chaitanya Kodeboyina helped design 1343 the flow validation procedure; and Steven Lin and Jim Washburn ironed 1344 out all the details necessary to produce a working implementation in 1345 the original RFC5575. 1347 Additional the authors would like to thank Alexander Mayrhofer, 1348 Nicolas Fevrier and Job Snijders for their comments and review. 1350 15. References 1352 15.1. Normative References 1354 [IEEE.754.1985] 1355 IEEE, "Standard for Binary Floating-Point Arithmetic", 1356 IEEE 754-1985, August 1985. 1358 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1359 RFC 793, DOI 10.17487/RFC0793, September 1981, 1360 . 1362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1363 Requirement Levels", BCP 14, RFC 2119, 1364 DOI 10.17487/RFC2119, March 1997, 1365 . 1367 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1368 "Definition of the Differentiated Services Field (DS 1369 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1370 DOI 10.17487/RFC2474, December 1998, 1371 . 1373 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1374 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1375 DOI 10.17487/RFC4271, January 2006, 1376 . 1378 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1379 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1380 February 2006, . 1382 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1383 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1384 2006, . 1386 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1387 "Multiprotocol Extensions for BGP-4", RFC 4760, 1388 DOI 10.17487/RFC4760, January 2007, 1389 . 1391 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1392 LAN Service (VPLS) Using BGP for Auto-Discovery and 1393 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1394 . 1396 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1397 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1398 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1399 . 1401 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 1402 Specific BGP Extended Community", RFC 5668, 1403 DOI 10.17487/RFC5668, October 2009, 1404 . 1406 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1407 and A. Bierman, Ed., "Network Configuration Protocol 1408 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1409 . 1411 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1412 Origin Authorizations (ROAs)", RFC 6482, 1413 DOI 10.17487/RFC6482, February 2012, 1414 . 1416 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1417 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1418 March 2014, . 1420 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1421 Patel, "Revised Error Handling for BGP UPDATE Messages", 1422 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1423 . 1425 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1426 Writing an IANA Considerations Section in RFCs", BCP 26, 1427 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1428 . 1430 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1431 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1432 May 2017, . 1434 15.2. Informative References 1436 [I-D.ietf-idr-flow-spec-v6] 1437 McPherson, D., Raszuk, R., Pithawala, B., 1438 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 1439 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 1440 v6-09 (work in progress), November 2017. 1442 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1443 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1444 . 1446 15.3. URIs 1448 [1] https://github.com/stoffi92/flowspec-cmp 1450 Appendix A. Comparison with RFC 5575 1452 This document includes numerous editorial changes to RFC5575. It is 1453 recommended to read the entire document. The authors, however want 1454 to point out the following technical changes to RFC5575: 1456 Section 4.2.3 defines a numeric operator and comparison bit 1457 combinations. In RFC5575 the meaning of those bit combination was 1458 not explicitly defined and left open to the reader. 1460 Section 4.2.3 - Section 4.2.8, Section 4.2.10, Section 4.2.11 make 1461 use of the above numeric operator. The allowed length of the 1462 comparison value was not consistently defined in RFC5575. 1464 Section 7 defines all traffic action extended communities as 1465 transitive extended communities. RFC5575 defined the traffic-rate 1466 action to be non-transitive and did not define the transitivity of 1467 the other action communities at all. 1469 Section 7.2 introduces a new traffic filtering action (traffic- 1470 rate-packets). This action did not exist in RFC5575. 1472 Section 7.4 contains the same redirect actions already defined in 1473 RFC5575 however, these actions have been renamed to "rt-redirect" 1474 to make it clearer that the redirection is based on route-target. 1476 Section 7.6 introduces rules how updates of Flow Specifications 1477 shall be handled in case they contain interfering actions. 1478 Section 7.3 also cross-references this section. RFC5575 did not 1479 define this. 1481 Authors' Addresses 1483 Susan Hares 1484 Huawei 1485 7453 Hickory Hill 1486 Saline, MI 48176 1487 USA 1489 Email: shares@ndzh.com 1490 Christoph Loibl 1491 Next Layer Communications 1492 Mariahilfer Guertel 37/7 1493 Vienna 1150 1494 AT 1496 Phone: +43 664 1176414 1497 Email: cl@tix.at 1499 Robert Raszuk 1500 Bloomberg LP 1501 731 Lexington Ave 1502 New York City, NY 10022 1503 USA 1505 Email: robert@raszuk.net 1507 Danny McPherson 1508 Verisign 1509 USA 1511 Email: dmcpherson@verisign.com 1513 Martin Bacher 1514 T-Mobile Austria 1515 Rennweg 97-99 1516 Vienna 1030 1517 AT 1519 Email: mb.ietf@gmail.com