idnits 2.17.1 draft-ietf-idr-rfc5575bis-16.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 (May 31, 2019) is 1785 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 588 -- Looks like a reference, but probably isn't: '139' on line 588 -- Looks like a reference, but probably isn't: '1' on line 1449 -- 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 (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group C. Loibl 3 Internet-Draft Next Layer Communications 4 Obsoletes: 5575,7674 (if approved) S. Hares 5 Intended status: Standards Track Huawei 6 Expires: December 2, 2019 R. Raszuk 7 Bloomberg LP 8 D. McPherson 9 Verisign 10 M. Bacher 11 T-Mobile Austria 12 May 31, 2019 14 Dissemination of Flow Specification Rules 15 draft-ietf-idr-rfc5575bis-16 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. 35 Applications which use the bgp Flow Specification are: 1) application 36 which automate inter-domain coordination of traffic filtering, such 37 as what is required in order to mitigate (distributed) denial-of- 38 service attacks; 2) applications which control traffic filtering in 39 the context of a BGP/MPLS VPN service, and 3) applications with 40 centralized control of traffic in a SDN or NFV context. Some 41 deployments of these three applications can be handled by the strict 42 ordering of the BGP NLRI traffic flow filters, and the strict actions 43 encoded in the extended community Flow Specification actions. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on December 2, 2019. 62 Copyright Notice 64 Copyright (c) 2019 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Definitions of Terms Used in This Memo . . . . . . . . . . . 5 81 3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 6 82 4. Dissemination of IPv4 FLow Specification Information . . . . 7 83 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7 84 4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 8 85 4.2.1. Type 1 - Destination Prefix . . . . . . . . . . . . . 8 86 4.2.2. Type 2 - Source Prefix . . . . . . . . . . . . . . . 8 87 4.2.3. Type 3 - IP Protocol . . . . . . . . . . . . . . . . 8 88 4.2.4. Type 4 - Port . . . . . . . . . . . . . . . . . . . . 10 89 4.2.5. Type 5 - Destination Port . . . . . . . . . . . . . . 10 90 4.2.6. Type 6 - Source Port . . . . . . . . . . . . . . . . 10 91 4.2.7. Type 7 - ICMP type . . . . . . . . . . . . . . . . . 11 92 4.2.8. Type 8 - ICMP code . . . . . . . . . . . . . . . . . 11 93 4.2.9. Type 9 - TCP flags . . . . . . . . . . . . . . . . . 11 94 4.2.10. Type 10 - Packet length . . . . . . . . . . . . . . . 12 95 4.2.11. Type 11 - DSCP (Diffserv Code Point) . . . . . . . . 12 96 4.2.12. Type 12 - Fragment . . . . . . . . . . . . . . . . . 12 97 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 13 98 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 14 99 5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 15 100 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 17 101 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 18 102 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 19 103 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type 104 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 20 106 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 21 107 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 21 108 7.6. Considerations on Traffic Action Interference . . . . . . 21 109 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 22 110 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 23 111 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 23 112 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 23 113 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 23 114 9.2. Limitations in Previous BGP/MPLS Traffic Filtering 115 Efforts . . . . . . . . . . . . . . . . . . . . . . . . . 24 116 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24 117 11. Error-Handling and Future NLRI Extensions . . . . . . . . . . 24 118 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 119 12.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25 120 12.2. Flow Component Definitions . . . . . . . . . . . . . . . 25 121 12.3. Extended Community Flow Specification Actions . . . . . 26 122 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 123 14. Operational Security Considerations . . . . . . . . . . . . . 30 124 15. Original authors . . . . . . . . . . . . . . . . . . . . . . 30 125 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 126 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 127 17.1. Normative References . . . . . . . . . . . . . . . . . . 30 128 17.2. Informative References . . . . . . . . . . . . . . . . . 32 129 17.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 130 Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 32 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 133 1. Introduction 135 Modern IP routers contain both the capability to forward traffic 136 according to IP prefixes as well as to classify, shape, rate limit, 137 filter, or redirect packets based on administratively defined 138 policies. 140 These traffic policy mechanisms allow the router to define match 141 rules that operate on multiple fields of the packet header. Actions 142 such as the ones described above can be associated with each rule. 144 The n-tuple consisting of the matching criteria defines an aggregate 145 traffic Flow Specification. The matching criteria can include 146 elements such as source and destination address prefixes, IP 147 protocol, and transport protocol port numbers. 149 This document defines a general procedure to encode flow 150 specification rules for aggregated traffic flows so that they can be 151 distributed as a BGP [RFC4271] NLRI. Additionally, we define the 152 required mechanisms to utilize this definition to the problem of 153 immediate concern to the authors: intra- and inter-provider 154 distribution of traffic filtering rules to filter (distributed) 155 denial-of-service (DoS) attacks. 157 By expanding routing information with Flow Specifications, the 158 routing system can take advantage of the ACL (Access Control List) or 159 firewall capabilities in the router's forwarding path. Flow 160 specifications can be seen as more specific routing entries to a 161 unicast prefix and are expected to depend upon the existing unicast 162 data information. 164 A Flow Specification received from an external autonomous system will 165 need to be validated against unicast routing before being accepted. 166 If the aggregate traffic flow defined by the unicast destination 167 prefix is forwarded to a given BGP peer, then the local system can 168 install more specific flow rules that may result in different 169 forwarding behavior, as requested by this system. 171 The key technology components required to address the class of 172 problems targeted by this document are: 174 1. Efficient point-to-multipoint distribution of control plane 175 information. 177 2. Inter-domain capabilities and routing policy support. 179 3. Tight integration with unicast routing, for verification 180 purposes. 182 Items 1 and 2 have already been addressed using BGP for other types 183 of control plane information. Close integration with BGP also makes 184 it feasible to specify a mechanism to automatically verify flow 185 information against unicast routing. These factors are behind the 186 choice of BGP as the carrier of Flow Specification information. 188 As with previous extensions to BGP, this specification makes it 189 possible to add additional information to Internet routers. These 190 are limited in terms of the maximum number of data elements they can 191 hold as well as the number of events they are able to process in a 192 given unit of time. The authors believe that, as with previous 193 extensions, service providers will be careful to keep information 194 levels below the maximum capacity of their devices. 196 Experience with previous BGP extensions has also shown that the 197 maximum capacity of BGP speakers has been gradually increased 198 according to expected loads. For example Internet unicast routing as 199 well as other BGP applications increased their maximum capacity as 200 they gain popularity. 202 From an operational perspective, the utilization of BGP as the 203 carrier for this information allows a network service provider to 204 reuse both internal route distribution infrastructure (e.g., route 205 reflector or confederation design) and existing external 206 relationships (e.g., inter-domain BGP sessions to a customer 207 network). 209 While it is certainly possible to address this problem using other 210 mechanisms, this solution has been utilized in deployments because of 211 the substantial advantage of being an incremental addition to already 212 deployed mechanisms. 214 In current deployments, the information distributed by the flow-spec 215 extension is originated both manually as well as automatically. The 216 latter by systems that are able to detect malicious flows. When 217 automated systems are used, care should be taken to ensure their 218 correctness as well as to limit the number and advertisement rate of 219 flow routes. 221 This specification defines required protocol extensions to address 222 most common applications of IPv4 unicast and VPNv4 unicast filtering. 223 The same mechanism can be reused and new match criteria added to 224 address similar filtering needs for other BGP address families such 225 as IPv6 families [I-D.ietf-idr-flow-spec-v6], 227 2. Definitions of Terms Used in This Memo 229 NLRI - Network Layer Reachability Information. 231 RIB - Routing Information Base. 233 Loc-RIB - Local RIB. 235 AS - Autonomous System. 237 VRF - Virtual Routing and Forwarding instance. 239 PE - Provider Edge router 241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 243 "OPTIONAL" in this document are to be interpreted as described in BCP 244 14 [RFC2119] [RFC8174] when, and only when, they appear in all 245 capitals, as shown here. 247 3. Flow Specifications 249 A Flow Specification is an n-tuple consisting of several matching 250 criteria that can be applied to IP traffic. A given IP packet is 251 said to match the defined flow if it matches all the specified 252 criteria. This n-tuple is encoded into a BGP NLRI defined below. 254 A given flow may be associated with a set of attributes, depending on 255 the particular application; such attributes may or may not include 256 reachability information (i.e., NEXT_HOP). Well-known or AS-specific 257 community attributes can be used to encode a set of predetermined 258 actions. 260 A particular application is identified by a specific (Address Family 261 Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair 262 [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs 263 should be treated independently from each other in order to assure 264 non-interference between distinct applications. 266 BGP itself treats the NLRI as an key to an entry in its databases. 267 Entries that are placed in the Loc-RIB are then associated with a 268 given set of semantics, which is application dependent. This is 269 consistent with existing BGP applications. For instance, IP unicast 270 routing (AFI=1, SAFI=1) and IP multicast reverse-path information 271 (AFI=1, SAFI=2) are handled by BGP without any particular semantics 272 being associated with them until installed in the Loc-RIB. 274 Standard BGP policy mechanisms, such as UPDATE filtering by NLRI 275 prefix as well as community matching and manipulation, MUST apply to 276 the Flow Specification defined NLRI-type, especially in an inter- 277 domain environment. Network operators can also control propagation 278 of such routing updates by enabling or disabling the exchange of a 279 particular (AFI, SAFI) pair on a given BGP peering session. 281 4. Dissemination of IPv4 FLow Specification Information 283 We define a "Flow Specification" NLRI type (Figure 1) that may 284 include several components such as destination prefix, source prefix, 285 protocol, ports, and others (see Section 4.2 below). 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 (AFI=1, SAFI=133) for IPv4 Flow Specification, and (AFI=1, 310 SAFI=134) for VPNv4 Flow Specification. 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 (exactly 340 once) or may not be present in the specification. If present, it 341 MUST precede any component of higher numeric type value. 343 All combinations of component types within a single NLRI are allowed, 344 even if the combination makes no sense from a semantical perspective. 345 If a given component type within a prefix in unknown, the prefix in 346 question cannot be used for traffic filtering purposes by the 347 receiver. Since a Flow Specification has the semantics of a logical 348 AND of all components, if a component is FALSE, by definition it 349 cannot be applied. However, for the purposes of BGP route 350 propagation, this prefix should still be transmitted since BGP route 351 distribution is independent on NLRI semantics. 353 4.2.1. Type 1 - Destination Prefix 355 Encoding: 357 Defines: the destination prefix to match. Prefixes are encoded as 358 in BGP UPDATE messages, a length in bits is followed by enough 359 octets to contain the prefix information. 361 4.2.2. Type 2 - Source Prefix 363 Encoding: 365 Defines the source prefix to match. 367 4.2.3. Type 3 - IP Protocol 369 Encoding: 371 Contains a set of {operator, value} pairs that are used to match 372 the IP protocol value byte in IP packets. 374 The operator byte is encoded as: 376 0 1 2 3 4 5 6 7 377 +---+---+---+---+---+---+---+---+ 378 | e | a | len | 0 |lt |gt |eq | 379 +---+---+---+---+---+---+---+---+ 381 Numeric operator 383 e - end-of-list bit. Set in the last {op, value} pair in the 384 list. 386 a - AND bit. If unset, the previous term is logically ORed with 387 the current one. If set, the operation is a logical AND. In the 388 first operator byte of a sequence it SHOULD be encoded as unset 389 and and MUST be treated as always unset on decoding. 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 operator given as (1 << 394 len). This encodes 1 (00) - 8 (11) bytes. Type 3 flow component 395 values SHOULD be encoded as single byte (len = 00). 397 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored 398 during decoding 400 lt - less than comparison between data and value. 402 gt - greater than comparison between data and value. 404 eq - equality between data and value. 406 The bits lt, gt, and eq can be combined to produce common relational 407 operators such as "less or equal", "greater or equal", and "not equal 408 to". 410 +----+----+----+----------------------------------+ 411 | lt | gt | eq | Resulting operation | 412 +----+----+----+----------------------------------+ 413 | 0 | 0 | 0 | false (independent of the value) | 414 | 0 | 0 | 1 | == (equal) | 415 | 0 | 1 | 0 | > (greater than) | 416 | 0 | 1 | 1 | >= (greater than or equal) | 417 | 1 | 0 | 0 | < (less than) | 418 | 1 | 0 | 1 | <= (less than or equal) | 419 | 1 | 1 | 0 | != (not equal value) | 420 | 1 | 1 | 1 | true (independent of the value) | 421 +----+----+----+----------------------------------+ 423 Table 1: Comparison operation combinations 425 4.2.4. Type 4 - Port 427 Encoding: 429 Defines a list of {operator, value} pairs that matches source OR 430 destination TCP/UDP ports. This list is encoded using the numeric 431 operator format defined in Section 4.2.3. Values SHOULD be 432 encoded as 1- or 2-byte quantities. 434 Port, source port, and destination port components evaluate to 435 FALSE if the IP protocol field of the packet has a value other 436 than TCP or UDP, if the packet is fragmented and this is not the 437 first fragment, or if the system in unable to locate the transport 438 header. Different implementations may or may not be able to 439 decode the transport header in the presence of IP options or 440 Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. 442 4.2.5. Type 5 - Destination Port 444 Encoding: 446 Defines a list of {operator, value} pairs used to match the 447 destination port of a TCP or UDP packet. This list is encoded 448 using the numeric operator format defined in Section 4.2.3. 449 Values SHOULD be encoded as 1- or 2-byte quantities. 451 4.2.6. Type 6 - Source Port 453 Encoding: 455 Defines a list of {operator, value} pairs used to match the source 456 port of a TCP or UDP packet. This list is encoded using the 457 numeric operator format defined in Section 4.2.3. Values SHOULD 458 be encoded as 1- or 2-byte quantities. 460 4.2.7. Type 7 - ICMP type 462 Encoding: 464 Defines a list of {operator, value} pairs used to match the type 465 field of an ICMP packet. This list is encoded using the numeric 466 operator format defined in Section 4.2.3. Values SHOULD be 467 encoded using a single byte. 469 The ICMP type specifiers evaluate to FALSE whenever the protocol 470 value is not ICMP. 472 4.2.8. Type 8 - ICMP code 474 Encoding: 476 Defines a list of {operator, value} pairs used to match the code 477 field of an ICMP packet. This list is encoded using the numeric 478 operator format defined in Section 4.2.3. Values SHOULD be 479 encoded using a single byte. 481 The ICMP code specifiers evaluate to FALSE whenever the protocol 482 value is not ICMP. 484 4.2.9. Type 9 - TCP flags 486 Encoding: 488 Bitmask values can be encoded as a 1- or 2-byte bitmask. When a 489 single byte is specified, it matches byte 13 of the TCP header 490 [RFC0793], which contains bits 8 though 15 of the 4th 32-bit word. 491 When a 2-byte encoding is used, it matches bytes 12 and 13 of the 492 TCP header with the data offset field having a "don't care" value. 494 This component evaluates to FALSE for packets that are not TCP 495 packets. 497 This type uses the bitmask operator format, which differs from the 498 numeric operator format in the lower nibble. 500 0 1 2 3 4 5 6 7 501 +---+---+---+---+---+---+---+---+ 502 | e | a | len | 0 | 0 |not| m | 503 +---+---+---+---+---+---+---+---+ 505 Bitmask operator 507 e, a, len - Most significant nibble: (end-of-list bit, AND bit, and 508 length field), as defined for in the numeric operator format in 509 Section 4.2.3. 511 not - NOT bit. If set, logical negation of operation. 513 m - Match bit. If set, this is a bitwise match operation defined 514 as "(data AND value) == value"; if unset, (data AND value) 515 evaluates to TRUE if any of the bits in the value mask are set in 516 the data 518 0 - all 0 bits SHOULD be set to 0 on NLRI encoding, and MUST be 519 ignored during decoding 521 4.2.10. Type 10 - Packet length 523 Encoding: 525 Defines a list of {operator, value} pairs used to match on the 526 total IP packet length (excluding Layer 2 but including IP 527 header). This list is encoded using the numeric operator format 528 defined in Section 4.2.3. Values SHOULD be encoded using 1- or 529 2-byte quantities. 531 4.2.11. Type 11 - DSCP (Diffserv Code Point) 533 Encoding: 535 Defines a list of {operator, value} pairs used to match the 6-bit 536 DSCP field [RFC2474]. This list is encoded using the numeric 537 operator format defined in Section 4.2.3. Values SHOULD be 538 encoded using a single byte. The six least significant bits 539 contain the DSCP value. All other bits SHOULD be encoded as zero 540 and ignored on decoding. 542 4.2.12. Type 12 - Fragment 544 Encoding: 546 Uses bitmask operator format defined in Section 4.2.9. 548 0 1 2 3 4 5 6 7 549 +---+---+---+---+---+---+---+---+ 550 | 0 | 0 | 0 | 0 |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 Bit 0-3 - SHOULD be set to 0 on NLRI encoding, and MUST be 564 ignored during decoding 566 4.3. Examples of Encodings 568 An example of a Flow Specification encoding for: "all packets to 569 10.0.1/24 and TCP port 25". 571 +------------------+----------+----------+ 572 | destination | proto | port | 573 +------------------+----------+----------+ 574 | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | 575 +------------------+----------+----------+ 577 Decode for protocol: 579 +-------+----------+------------------------------+ 580 | Value | | | 581 +-------+----------+------------------------------+ 582 | 0x03 | type | | 583 | 0x81 | operator | end-of-list, value size=1, = | 584 | 0x06 | value | | 585 +-------+----------+------------------------------+ 587 An example of a Flow Specification encoding for: "all packets to 588 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". 590 +------------------+----------+-------------------------+ 591 | destination | source | port | 592 +------------------+----------+-------------------------+ 593 | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | 594 +------------------+----------+-------------------------+ 596 Decode for port: 598 +--------+----------+------------------------------+ 599 | Value | | | 600 +--------+----------+------------------------------+ 601 | 0x04 | type | | 602 | 0x03 | operator | size=1, >= | 603 | 0x89 | value | 137 | 604 | 0x45 | operator | "AND", value size=1, <= | 605 | 0x8b | value | 139 | 606 | 0x91 | operator | end-of-list, value-size=2, = | 607 | 0x1f90 | value | 8080 | 608 +--------+----------+------------------------------+ 610 This constitutes an NLRI with an NLRI length of 16 octets. 612 5. Traffic Filtering 614 Traffic filtering policies have been traditionally considered to be 615 relatively static. Limitations of the static mechanisms caused this 616 mechanism to be designed for the three new applications of traffic 617 filtering (prevention of traffic-based, denial-of-service (DOS) 618 attacks, traffic filtering in the context of BGP/MPLS VPN service, 619 and centralized traffic control for SDN/NFV networks) requires 620 coordination among service providers and/or coordination among the AS 621 within a service provider. Section 9 has details on the limitation 622 of previous mechanisms and why BGP Flow Specification provides a 623 solution for to prevent DOS and aid BGP/MPLS VPN filtering rules. 625 This Flow Specification NLRI defined above to convey information 626 about traffic filtering rules for traffic that should be discarded or 627 handled in manner specified by a set of pre-defined actions (which 628 are defined in BGP Extended Communities). This mechanism is 629 primarily designed to allow an upstream autonomous system to perform 630 inbound filtering in their ingress routers of traffic that a given 631 downstream AS wishes to drop. 633 In order to achieve this goal, this draft specifies two application 634 specific NLRI identifiers that provide traffic filters, and a set of 635 actions encoding in BGP Extended Communities. The two application 636 specific NLRI identifiers are: 638 o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with 639 specific semantic rules for IPv4 routes, and 641 o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which 642 can be used to propagate traffic filtering information in a BGP/ 643 MPLS VPN environment. 645 Distribution of the IPv4 Flow Specification is described in 646 Section 6, and distibution of BGP/MPLS traffic Flow Specification is 647 described in Section 8. The traffic filtering actions are described 648 in Section 7. 650 5.1. Ordering of Traffic Filtering Rules 652 With traffic filtering rules, more than one rule may match a 653 particular traffic flow. Thus, it is necessary to define the order 654 at which rules get matched and applied to a particular traffic flow. 655 This ordering function must be such that it must not depend on the 656 arrival order of the Flow Specification's rules and must be 657 consistent in the network. 659 The relative order of two Flow Specification rules is determined by 660 comparing their respective components. The algorithm starts by 661 comparing the left-most components of the rules. If the types 662 differ, the rule with lowest numeric type value has higher precedence 663 (and thus will match before) than the rule that doesn't contain that 664 component type. If the component types are the same, then a type- 665 specific comparison is performed (see below) if the types are equal 666 the algorithm continues with the next component. 668 For IP prefix values (IP destination or source prefix): If the 669 prefixes overlap, the one with the longer prefix-length has higher 670 precedence. If they do not overlap the one with the lowest IP value 671 has higher precedence. 673 For all other component types, unless otherwise specified, the 674 comparison is performed by comparing the component data as a binary 675 string using the memcmp() function as defined by the ISO C standard. 676 For strings with equal lengths the lowest string (memcmp) has higher 677 precedence. For strings of different lengths, the common prefix is 678 compared. If the common prefix is not equal the string with the 679 lowest prefix has higher precedence. If the common prefix is equal, 680 the longest string is considered to have higher precedence than the 681 shorter one. 683 The code below shows a Python3 implementation of the comparison 684 algorithm. The full code was tested with Python 3.6.3 and can be 685 obtained at https://github.com/stoffi92/flowspec-cmp [1]. 687 688 import itertools 689 import ipaddress 691 def flow_rule_cmp(a, b): 692 for comp_a, comp_b in itertools.zip_longest(a.components, 693 b.components): 694 # If a component type does not exist in one rule 695 # this rule has lower precedence 696 if not comp_a: 697 return B_HAS_PRECEDENCE 698 if not comp_b: 699 return A_HAS_PRECEDENCE 700 # higher precedence for lower component type 701 if comp_a.component_type < comp_b.component_type: 702 return A_HAS_PRECEDENCE 703 if comp_a.component_type > comp_b.component_type: 704 return B_HAS_PRECEDENCE 705 # component types are equal -> type specific comparison 706 if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): 707 # assuming comp_a.value, comp_b.value of type ipaddress 708 if comp_a.value.overlaps(comp_b.value): 709 # longest prefixlen has precedence 710 if comp_a.value.prefixlen > comp_b.value.prefixlen: 711 return A_HAS_PRECEDENCE 712 if comp_a.value.prefixlen < comp_b.value.prefixlen: 713 return B_HAS_PRECEDENCE 714 # components equal -> continue with next component 715 elif comp_a.value > comp_b.value: 716 return B_HAS_PRECEDENCE 717 elif comp_a.value < comp_b.value: 718 return A_HAS_PRECEDENCE 719 else: 720 # assuming comp_a.value, comp_b.value of type bytearray 721 if len(comp_a.value) == len(comp_b.value): 722 if comp_a.value > comp_b.value: 723 return B_HAS_PRECEDENCE 724 if comp_a.value < comp_b.value: 725 return A_HAS_PRECEDENCE 726 # components equal -> continue with next component 727 else: 728 common = min(len(comp_a.value), len(comp_b.value)) 729 if comp_a.value[:common] > comp_b.value[:common]: 730 return B_HAS_PRECEDENCE 731 elif comp_a.value[:common] < comp_b.value[:common]: 732 return A_HAS_PRECEDENCE 733 # the first common bytes match 734 elif len(comp_a.value) > len(comp_b.value): 735 return A_HAS_PRECEDENCE 736 else: 738 return B_HAS_PRECEDENCE 739 return EQUAL 740 742 6. Validation Procedure 744 Flow Specifications received from a BGP peer that are accepted in the 745 respective Adj-RIB-In are used as input to the route selection 746 process. Although the forwarding attributes of two routes for the 747 same Flow Specification prefix may be the same, BGP is still required 748 to perform its path selection algorithm in order to select the 749 correct set of attributes to advertise. 751 The first step of the BGP Route Selection procedure (Section 9.1.2 of 752 [RFC4271] is to exclude from the selection procedure routes that are 753 considered non-feasible. In the context of IP routing information, 754 this step is used to validate that the NEXT_HOP attribute of a given 755 route is resolvable. 757 The concept can be extended, in the case of Flow Specification NLRI, 758 to allow other validation procedures. 760 A Flow Specification NLRI must be validated such that it is 761 considered feasible if and only if: 763 a) The originator of the Flow Specification matches the originator 764 of the best-match unicast route for the destination prefix 765 embedded in the Flow Specification. 767 b) There are no more specific unicast routes, when compared with 768 the flow destination prefix, that has been received from a 769 different neighboring AS than the best-match unicast route, which 770 has been determined in step a). 772 By originator of a BGP route, we mean either the BGP originator path 773 attribute, as used by route reflection, or the transport address of 774 the BGP peer, if this path attribute is not present. 776 BGP implementations MUST also enforce that the AS_PATH attribute of a 777 route received via the External Border Gateway Protocol (eBGP) 778 contains the neighboring AS in the left-most position of the AS_PATH 779 attribute. While this rule is optional in the BGP specification, it 780 becomes necessary to enforce it for security reasons. 782 The best-match unicast route may change over the time independently 783 of the Flow Specification NLRI. Therefore, a revalidation of the 784 Flow Specification NLRI MUST be performed whenever unicast routes 785 change. Revalidation is defined as retesting that clause a and 786 clause b above are true. 788 Explanation: 790 The underlying concept is that the neighboring AS that advertises the 791 best unicast route for a destination is allowed to advertise flow- 792 spec information that conveys a more or equally specific destination 793 prefix. Thus, as long as there are no more specific unicast routes, 794 received from a different neighboring AS, which would be affected by 795 that filtering rule. 797 The neighboring AS is the immediate destination of the traffic 798 described by the Flow Specification. If it requests these flows to 799 be dropped, that request can be honored without concern that it 800 represents a denial of service in itself. Supposedly, the traffic is 801 being dropped by the downstream autonomous system, and there is no 802 added value in carrying the traffic to it. 804 7. Traffic Filtering Actions 806 This specification defines a minimum set of filtering actions that it 807 standardizes as BGP extended community values [RFC4360]. This is not 808 meant to be an inclusive list of all the possible actions, but only a 809 subset that can be interpreted consistently across the network. 810 Additional actions can be defined as either requiring standards or as 811 vendor specific. 813 Implementations SHOULD provide mechanisms that map an arbitrary BGP 814 community value (normal or extended) to filtering actions that 815 require different mappings in different systems in the network. For 816 instance, providing packets with a worse-than-best-effort, per-hop 817 behavior is a functionality that is likely to be implemented 818 differently in different systems and for which no standard behavior 819 is currently known. Rather than attempting to define it here, this 820 can be accomplished by mapping a user-defined community value to 821 platform-/network-specific behavior via user configuration. 823 The default action for a traffic filtering Flow Specification is to 824 accept IP traffic that matches that particular rule. 826 This document defines the following extended communities values shown 827 in Table 2 in the form 0x8xnn where nn indicates the sub-type. 828 Encodings for these extended communities are described below. 830 +-----------+----------------------+--------------------------------+ 831 | community | action | encoding | 832 +-----------+----------------------+--------------------------------+ 833 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | 834 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | 835 | 0x8007 | traffic-action | bitmask | 836 | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value | 837 | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet | 838 | | | value | 839 | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value | 840 | 0x8009 | traffic-marking | DSCP value | 841 +-----------+----------------------+--------------------------------+ 843 Table 2: Traffic Action Extended Communities 845 Some traffic action communities may interfere with each other. 846 Section 7.6 of this specification provides general considerations on 847 such traffic action interference. Any additional definition of a 848 traffic 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. On encoding the traffic-rate MUST NOT be 878 negative. On decoding negative values MUST be treated as zero 879 (discard all traffic). 881 Interferes with: No other BGP Flow Specification traffic action in 882 this document. 884 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD 886 The traffic-rate-packets extended community uses the same encoding as 887 the traffic-rate-bytes extended community. The floating point value 888 carries the maximum packet rate in packets per second. A traffic- 889 rate-packets of 0 should result in all traffic for the particular 890 flow to be discarded. On encoding the traffic-rate-packets MUST NOT 891 be negative. On decoding negative values MUST be treated as zero 892 (discard all traffic). 894 Interferes with: No other BGP Flow Specification traffic action in 895 this document. 897 7.3. Traffic-action (traffic-action) sub-type 0x07 899 The traffic-action extended community consists of 6 bytes of which 900 only the 2 least significant bits of the 6th byte (from left to 901 right) are currently defined. 903 40 41 42 43 44 45 46 47 904 +---+---+---+---+---+---+---+---+ 905 | reserved | S | T | 906 +---+---+---+---+---+---+---+---+ 908 where S and T are defined as: 910 o T: Terminal Action (bit 47): When this bit is set, the traffic 911 filtering engine will apply any subsequent filtering rules (as 912 defined by the ordering procedure). If not set, the evaluation of 913 the traffic filter stops when this rule is applied. 915 o S: Sample (bit 46): Enables traffic sampling and logging for this 916 Flow Specification. 918 o reserved: should always be set to 0 by the originator and not be 919 evaluated by the receiving BGP speaker. 921 The use of the Terminal Action (bit 47) may result in more than one 922 filter-rule matching a particular flow. All the flow actions from 923 these rules shall be collected and applied. In case of interfering 924 traffic actions it is an implementation decision which actions are 925 selected. See also Section 7.6. 927 Interferes with: No other BGP Flow Specification traffic action in 928 this document. 930 7.4. RT Redirect (rt-redirect) sub-type 0x08 932 The redirect extended community allows the traffic to be redirected 933 to a VRF routing instance that lists the specified route-target in 934 its import policy. If several local instances match this criteria, 935 the choice between them is a local matter (for example, the instance 936 with the lowest Route Distinguisher value can be elected). This 937 extended community allows 3 different encodings formats for the 938 route-target (type 0x80, 0x81, 0x82). Is uses the same encoding as 939 the Route Target extended community [RFC4360]. 941 It should be noted that the low-order nibble of the Redirect's Type 942 field corresponds to the Route Target Extended Community format field 943 (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of 944 [RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended 945 Community remains 0x08 for all three encodings of the BGP Extended 946 Communities (AS 2-byte, AS 4-byte, and IPv4 address). 948 Interferes with: All other redirect functions. 950 7.5. Traffic Marking (traffic-marking) sub-type 0x09 952 The traffic marking extended community instructs a system to modify 953 the DSCP bits of a transiting IP packet to the corresponding value. 954 This extended community is encoded as a sequence of 5 zero bytes 955 followed by the DSCP value encoded in the 6 least significant bits of 956 6th byte. 958 Interferes with: No other BGP Flow Specification traffic action in 959 this document. 961 7.6. Considerations on Traffic Action Interference 963 Since traffic actions are represented as BGP extended community 964 values, traffic actions may interfere with each other (ie. there may 965 be more than one conflicting traffic-rate action associated with a 966 single flow-filter). Traffic action interference has no impact on 967 BGP propagation of flow filters (all communities are propagated 968 according to policies). 970 If a flow filter associated with interfering flow actions is selected 971 for packet forwarding, it is a implementation decision which of the 972 interfering traffic actions are selected. Implementors of this 973 specification SHOULD document the behaviour of their implementation 974 in such cases. 976 If required, operators are encouraged to make use of the BGP policy 977 framework supported by their implementation in order to achieve a 978 predictable behaviour (ie. match - replace - delete communities on 979 administrative boundaries). 981 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 983 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 984 MPLS IP VPN [RFC4364] control plane, may have different traffic 985 filtering requirements than Internet service providers. But also 986 Internet service providers may use those VPNs for scenarios like 987 having the Internet routing table in a VRF, resulting in the same 988 traffic filtering requirements as defined for the global routing 989 table environment within this document. This document proposes an 990 additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used 991 to propagate traffic filtering information in a BGP/MPLS VPN 992 environment. 994 The NLRI format for this address family consists of a fixed-length 995 Route Distinguisher field (8 bytes) followed by a Flow Specification, 996 following the encoding defined above in Section 4.2 of this document. 997 The NLRI length field shall include both the 8 bytes of the Route 998 Distinguisher as well as the subsequent Flow Specification. 1000 +------------------------------+ 1001 | length (0xnn or 0xfn nn) | 1002 +------------------------------+ 1003 | Route Distinguisher (8 bytes)| 1004 +------------------------------+ 1005 | NLRI value (variable) | 1006 +------------------------------+ 1008 Flow-spec NLRI for MPLS 1010 Propagation of this NLRI is controlled by matching Route Target 1011 extended communities associated with the BGP path advertisement with 1012 the VRF import policy, using the same mechanism as described in "BGP/ 1013 MPLS IP VPNs" [RFC4364]. 1015 Flow Specification rules received via this NLRI apply only to traffic 1016 that belongs to the VRF(s) in which it is imported. By default, 1017 traffic received from a remote PE is switched via an MPLS forwarding 1018 decision and is not subject to filtering. 1020 Contrary to the behavior specified for the non-VPN NLRI, flow rules 1021 are accepted by default, when received from remote PE routers. 1023 8.1. Validation Procedures for BGP/MPLS VPNs 1025 The validation procedures are the same as for IPv4. 1027 8.2. Traffic Actions Rules 1029 The traffic action rules are the same as for IPv4. 1031 9. Limitations of Previous Traffic Filtering Efforts 1033 9.1. Limitations in Previous DDoS Traffic Filtering Efforts 1035 The popularity of traffic-based, denial-of-service (DoS) attacks, 1036 which often requires the network operator to be able to use traffic 1037 filters for detection and mitigation, brings with it requirements 1038 that are not fully satisfied by existing tools. 1040 Increasingly, DoS mitigation requires coordination among several 1041 service providers in order to be able to identify traffic source(s) 1042 and because the volumes of traffic may be such that they will 1043 otherwise significantly affect the performance of the network. 1045 Several techniques are currently used to control traffic filtering of 1046 DoS attacks. Among those, one of the most common is to inject 1047 unicast route advertisements corresponding to a destination prefix 1048 being attacked (commonly known as remote triggered blackhole RTBH). 1049 One variant of this technique marks such route advertisements with a 1050 community that gets translated into a discard Next-Hop by the 1051 receiving router. Other variants attract traffic to a particular 1052 node that serves as a deterministic drop point. 1054 Using unicast routing advertisements to distribute traffic filtering 1055 information has the advantage of using the existing infrastructure 1056 and inter-AS communication channels. This can allow, for instance, a 1057 service provider to accept filtering requests from customers for 1058 address space they own. 1060 There are several drawbacks, however. An issue that is immediately 1061 apparent is the granularity of filtering control: only destination 1062 prefixes may be specified. Another area of concern is the fact that 1063 filtering information is intermingled with routing information. 1065 The mechanism defined in this document is designed to address these 1066 limitations. We use the Flow Specification NLRI defined above to 1067 convey information about traffic filtering rules for traffic that is 1068 subject to modified forwarding behavior (actions). The actions are 1069 defined as extended communities and include (but are not limited to) 1070 rate-limiting (including discard), traffic redirection, packet 1071 rewriting. 1073 9.2. Limitations in Previous BGP/MPLS Traffic Filtering Efforts 1075 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1076 MPLS IP VPN [RFC4364] control plane, may have different traffic 1077 filtering requirements than Internet service providers. 1079 In these environments, the VPN customer network often has traffic 1080 filtering capabilities towards their external network connections 1081 (e.g., firewall facing public network connection). Less common is 1082 the presence of traffic filtering capabilities between different VPN 1083 attachment sites. In an any-to-any connectivity model, which is the 1084 default, this means that site-to-site traffic is unfiltered. 1086 In circumstances where a security threat does get propagated inside 1087 the VPN customer network, there may not be readily available 1088 mechanisms to provide mitigation via traffic filter. 1090 But also Internet service providers may use those VPNs for scenarios 1091 like having the Internet routing table in a VRF. Therefore, 1092 limitations described in Section 9.1 also apply to this section. 1094 The BGP Flow Specification addresses these limitations. 1096 10. Traffic Monitoring 1098 Traffic filtering applications require monitoring and traffic 1099 statistics facilities. While this is an implementation-specific 1100 choice, implementations SHOULD provide: 1102 o A mechanism to log the packet header of filtered traffic. 1104 o A mechanism to count the number of matches for a given flow 1105 specification rule. 1107 11. Error-Handling and Future NLRI Extensions 1109 In case BGP encounters an error in a Flow Specification UPDATE 1110 message it SHOULD treat this message as Treat-as-withdraw according 1111 to [RFC7606] Section 2. 1113 Possible reasons for an error are (for more reasons see also 1114 [RFC7606]): 1116 o Incorrect implementation of this specification - the encoding/ 1117 decoding of the NLRI or traffic action extended-communities do not 1118 comply with this specification. 1120 o Unknown Flow Specification extensions - The sending party has 1121 implemented a Flow Specification NLRI extension unknown to the 1122 receiving party. 1124 In order to facilitate future extensions of the Flow Specification 1125 NLRI, such extensions SHOULD specify a way to encode a "always-true" 1126 match condition within the newly introduced components. This match 1127 condition can be used to propagate (and apply) certain filters only 1128 if a specific extension is known to the implemenation. 1130 12. IANA Considerations 1132 This section complies with [RFC7153]. 1134 12.1. AFI/SAFI Definitions 1136 IANA maintains a registry entitled "SAFI Values". For the purpose of 1137 this work, IANA updated the registry and allocated two additional 1138 SAFIs: 1140 +-------+------------------------------------------+----------------+ 1141 | Value | Name | Reference | 1142 +-------+------------------------------------------+----------------+ 1143 | 133 | IPv4 dissemination of Flow Specification | [this | 1144 | | rules | document] | 1145 | 134 | VPNv4 dissemination of Flow | [this | 1146 | | Specification rules | document] | 1147 +-------+------------------------------------------+----------------+ 1149 Table 3: Registry: SAFI Values 1151 12.2. Flow Component Definitions 1153 A Flow Specification consists of a sequence of flow components, which 1154 are identified by a an 8-bit component type. IANA has created and 1155 maintains a registry entitled "Flow Spec Component Types". This 1156 document defines the following Component Type Codes: 1158 +-------+--------------------+-----------------+ 1159 | Value | Name | Reference | 1160 +-------+--------------------+-----------------+ 1161 | 1 | Destination Prefix | [this document] | 1162 | 2 | Source Prefix | [this document] | 1163 | 3 | IP Protocol | [this document] | 1164 | 4 | Port | [this document] | 1165 | 5 | Destination port | [this document] | 1166 | 6 | Source port | [this document] | 1167 | 7 | ICMP type | [this document] | 1168 | 8 | ICMP code | [this document] | 1169 | 9 | TCP flags | [this document] | 1170 | 10 | Packet length | [this document] | 1171 | 11 | DSCP | [this document] | 1172 | 12 | Fragment | [this document] | 1173 +-------+--------------------+-----------------+ 1175 Table 4: Registry: Flow Spec Component Types 1177 In order to manage the limited number space and accommodate several 1178 usages, the following policies defined by [RFC8126] used: 1180 +--------------+-------------------------------+ 1181 | Range | Policy | 1182 +--------------+-------------------------------+ 1183 | 0 | Invalid value | 1184 | [1 .. 12] | Defined by this specification | 1185 | [13 .. 127] | Specification required | 1186 | [128 .. 255] | First Come First Served | 1187 +--------------+-------------------------------+ 1189 Table 5: Flow Spec Component Types Policies 1191 The specification of a particular "Flow Spec Component Type" must 1192 clearly identify what the criteria used to match packets forwarded by 1193 the router is. This criteria should be meaningful across router hops 1194 and not depend on values that change hop-by-hop such as TTL or Layer 1195 2 encapsulation. 1197 12.3. Extended Community Flow Specification Actions 1199 The Extended Community Flow Specification Action types defined in 1200 this document consist of two parts: 1202 Type (BGP Transitive Extended Community Type) 1204 Sub-Type 1206 For the type-part, IANA maintains a registry entitled "BGP Transitive 1207 Extended Community Types". For the purpose of this work (Section 7), 1208 IANA updated the registry to contain the values listed below: 1210 +-------+-----------------------------------------------+-----------+ 1211 | Type | Name | Reference | 1212 | Value | | | 1213 +-------+-----------------------------------------------+-----------+ 1214 | 0x80 | Generic Transitive Experimental Use Extended | [RFC7153] | 1215 | | Community (Sub-Types are defined in the | | 1216 | | "Generic Transitive Experimental Use Extended | | 1217 | | Community Sub-Types" registry) | | 1218 | 0x81 | Generic Transitive Experimental Use Extended | [this | 1219 | | Community Part 2 (Sub-Types are defined in | document] | 1220 | | the "Generic Transitive Experimental Use | [See | 1221 | | Extended Community Part 2 Sub-Types" | Note-1] | 1222 | | Registry) | | 1223 | 0x82 | Generic Transitive Experimental Use Extended | [this | 1224 | | Community Part 3 (Sub-Types are defined in | document] | 1225 | | the "Generic Transitive Experimental Use | [See | 1226 | | Extended Community Part 3 Sub-Types" | Note-1] | 1227 | | Registry) | | 1228 +-------+-----------------------------------------------+-----------+ 1230 Table 6: Registry: Generic Transitive Experimental Use Extended 1231 Community Types 1233 Note-1: This document obsoletes RFC7674. 1235 For the sub-type part of the extended community actions IANA 1236 maintains and updated the following registries: 1238 +----------+-----------------------------------------+--------------+ 1239 | Sub-Type | Name | Reference | 1240 | Value | | | 1241 +----------+-----------------------------------------+--------------+ 1242 | 0x06 | Flow spec traffic-rate-bytes | [this | 1243 | | | document] | 1244 | TBD | Flow spec traffic-rate-packets | [this | 1245 | | | document] | 1246 | 0x07 | Flow spec traffic-action (Use of the | [this | 1247 | | "Value" field is defined in the | document] | 1248 | | "Traffic Action Fields" registry) | [See Note-2] | 1249 | 0x08 | Flow spec rt-redirect AS-2byte format | [this | 1250 | | | document] | 1251 | 0x09 | Flow spec traffic-remarking | [this | 1252 | | | document] | 1253 +----------+-----------------------------------------+--------------+ 1255 Table 7: Registry: Generic Transitive Experimental Use Extended 1256 Community Sub-Types 1258 Note-2: This document obsoletes both RFC7674 and RFC5575. 1260 +-------------+---------------------------+-------------------------+ 1261 | Sub-Type | Name | Reference | 1262 | Value | | | 1263 +-------------+---------------------------+-------------------------+ 1264 | 0x08 | Flow spec rt-redirect | [this document] [See | 1265 | | IPv4 format | Note-3] | 1266 +-------------+---------------------------+-------------------------+ 1268 Table 8: Registry: Generic Transitive Experimental Use Extended 1269 Community Part 2 Sub-Types 1271 +-------------+----------------------------+------------------------+ 1272 | Sub-Type | Name | Reference | 1273 | Value | | | 1274 +-------------+----------------------------+------------------------+ 1275 | 0x08 | Flow spec rt-redirect AS- | [this document] [See | 1276 | | 4byte format | Note-3] | 1277 +-------------+----------------------------+------------------------+ 1279 Table 9: Registry: Generic Transitive Experimental Use Extended 1280 Community Part 3 Sub-Types 1282 Note-3: This document obsoletes RFC7674, and becomes the only 1283 reference for this table. 1285 The "traffic-action" extended community (Section 7.3) defined in this 1286 document has 46 unused bits, which can be used to convey additional 1287 meaning. IANA created and maintains a new registry entitled: 1288 "Traffic Action Fields". These values should be assigned via IETF 1289 Review rules only. The following traffic-action fields have been 1290 allocated: 1292 +-----+-----------------+-----------------+ 1293 | Bit | Name | Reference | 1294 +-----+-----------------+-----------------+ 1295 | 47 | Terminal Action | [this document] | 1296 | 46 | Sample | [this document] | 1297 +-----+-----------------+-----------------+ 1299 Table 10: Registry: Traffic Action Fields 1301 13. Security Considerations 1303 Inter-provider routing is based on a web of trust. Neighboring 1304 autonomous systems are trusted to advertise valid reachability 1305 information. If this trust model is violated, a neighboring 1306 autonomous system may cause a denial-of-service attack by advertising 1307 reachability information for a given prefix for which it does not 1308 provide service. 1310 As long as traffic filtering rules are restricted to match the 1311 corresponding unicast routing paths for the relevant prefixes, the 1312 security characteristics of this proposal are equivalent to the 1313 existing security properties of BGP unicast routing. However, this 1314 document also specifies traffic filtering actions that may need 1315 custom additional verification on the receiver side. See Section 14. 1317 Where it is not the case, this would open the door to further denial- 1318 of-service attacks. 1320 Enabling firewall-like capabilities in routers without centralized 1321 management could make certain failures harder to diagnose. For 1322 example, it is possible to allow TCP packets to pass between a pair 1323 of addresses but not ICMP packets. It is also possible to permit 1324 packets smaller than 900 or greater than 1000 bytes to pass between a 1325 pair of addresses, but not packets whose length is in the range 900- 1326 1000. Such behavior may be confusing and these capabilities should 1327 be used with care whether manually configured or coordinated through 1328 the protocol extensions described in this document. 1330 14. Operational Security Considerations 1332 While the general verification of the traffic filter NLRI is 1333 specified in this document (Section 6) the traffic filtering actions 1334 received by a third party may need custom verification or filtering. 1335 In particular all non traffic-rate actions may allow a third party to 1336 modify packet forwarding properties and potentially gain access to 1337 other routing-tables/VPNs or undesired queues. This can be avoided 1338 by proper filtering of action communities at network borders and by 1339 mapping user-defined communities (see Section 7) to expose certain 1340 forwarding properties to third parties. 1342 Since verfication of the traffic filtering NLRI is tied to the 1343 announcement of the best unicast route, a unfiltered address space 1344 hijack (e.g. advertisement of a more specific route) may cause this 1345 verification to fail and consequently prevent Flow Specification 1346 filters from being accepted by a peer. 1348 15. Original authors 1350 Barry Greene, Pedro Marques, Jared Mauch, Danny McPherson, and 1351 Nischal Sheth were authors on RFC5575, and therefore are contributing 1352 authors on this document. 1354 16. Acknowledgements 1356 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 1357 Morrow, Charlie Kaufman, and David Smith for their comments for the 1358 comments on the original RFC5575. Chaitanya Kodeboyina helped design 1359 the flow validation procedure; and Steven Lin and Jim Washburn ironed 1360 out all the details necessary to produce a working implementation in 1361 the original RFC5575. 1363 A packet rate flowspec action was also discribed in a flowspec 1364 extention draft and the authors like to thank Wesley Eddy, Justin 1365 Dailey and Gilbert Clark for their work. 1367 Additional the authors would like to thank Alexander Mayrhofer, 1368 Nicolas Fevrier, Job Snijders, Jeffrey Haas and Adam Chappell for 1369 their comments and review. 1371 17. References 1373 17.1. Normative References 1375 [IEEE.754.1985] 1376 IEEE, "Standard for Binary Floating-Point Arithmetic", 1377 IEEE 754-1985, August 1985. 1379 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1380 RFC 793, DOI 10.17487/RFC0793, September 1981, 1381 . 1383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1384 Requirement Levels", BCP 14, RFC 2119, 1385 DOI 10.17487/RFC2119, March 1997, 1386 . 1388 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1389 "Definition of the Differentiated Services Field (DS 1390 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1391 DOI 10.17487/RFC2474, December 1998, 1392 . 1394 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1395 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1396 DOI 10.17487/RFC4271, January 2006, 1397 . 1399 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1400 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1401 February 2006, . 1403 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1404 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1405 2006, . 1407 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1408 "Multiprotocol Extensions for BGP-4", RFC 4760, 1409 DOI 10.17487/RFC4760, January 2007, 1410 . 1412 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 1413 Specific BGP Extended Community", RFC 5668, 1414 DOI 10.17487/RFC5668, October 2009, 1415 . 1417 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1418 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1419 March 2014, . 1421 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1422 Patel, "Revised Error Handling for BGP UPDATE Messages", 1423 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1424 . 1426 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1427 Writing an IANA Considerations Section in RFCs", BCP 26, 1428 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1429 . 1431 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1432 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1433 May 2017, . 1435 17.2. Informative References 1437 [I-D.ietf-idr-flow-spec-v6] 1438 McPherson, D., Raszuk, R., Pithawala, B., 1439 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 1440 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 1441 v6-09 (work in progress), November 2017. 1443 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1444 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1445 . 1447 17.3. URIs 1449 [1] https://github.com/stoffi92/flowspec-cmp 1451 Appendix A. Comparison with RFC 5575 1453 This document includes numerous editorial changes to RFC5575. It is 1454 recommended to read the entire document. The authors, however want 1455 to point out the following technical changes to RFC5575: 1457 Section 1 introduces the Flow Specification NLRI. In RFC5575 this 1458 NLRI was defined as an opaque-key in BGPs database. This 1459 specification has removed all references to a opaque-key property. 1460 BGP is able understand the NLRI encoding. This change also 1461 resulted in a new section regarding error-handling and 1462 extensibility (Section 11). 1464 Section 4.2.3 defines a numeric operator and comparison bit 1465 combinations. In RFC5575 the meaning of those bit combination was 1466 not explicitly defined and left open to the reader. 1468 Section 4.2.3 - Section 4.2.8, Section 4.2.10, Section 4.2.11 make 1469 use of the above numeric operator. The allowed length of the 1470 comparison value was not consistently defined in RFC5575. 1472 Section 7 defines all traffic action extended communities as 1473 transitive extended communities. RFC5575 defined the traffic-rate 1474 action to be non-transitive and did not define the transitivity of 1475 the other action communities at all. 1477 Section 7.2 introduces a new traffic filtering action (traffic- 1478 rate-packets). This action did not exist in RFC5575. 1480 Section 7.4 contains the same redirect actions already defined in 1481 RFC5575 however, these actions have been renamed to "rt-redirect" 1482 to make it clearer that the redirection is based on route-target. 1484 Section 7.6 contains general considerations on interfering traffic 1485 actions. Section 7.3 also cross-references this section. RFC5575 1486 did not mention this. 1488 Section 11 contains a modified error handling to gracefully allow 1489 future extensions of flow specification. 1491 Authors' Addresses 1493 Christoph Loibl 1494 Next Layer Communications 1495 Mariahilfer Guertel 37/7 1496 Vienna 1150 1497 AT 1499 Phone: +43 664 1176414 1500 Email: cl@tix.at 1502 Susan Hares 1503 Huawei 1504 7453 Hickory Hill 1505 Saline, MI 48176 1506 USA 1508 Email: shares@ndzh.com 1510 Robert Raszuk 1511 Bloomberg LP 1512 731 Lexington Ave 1513 New York City, NY 10022 1514 USA 1516 Email: robert@raszuk.net 1517 Danny McPherson 1518 Verisign 1519 USA 1521 Email: dmcpherson@verisign.com 1523 Martin Bacher 1524 T-Mobile Austria 1525 Rennweg 97-99 1526 Vienna 1030 1527 AT 1529 Email: mb.ietf@gmail.com