idnits 2.17.1 draft-hr-idr-rfc5575bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5575, but the abstract doesn't seem to directly say this. It does mention RFC5575 though, so this could be OK. -- The draft header indicates that this document updates RFC7674, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC5575, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 14, 2017) is 2618 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '137' on line 577 -- Looks like a reference, but probably isn't: '139' on line 577 == Missing Reference: 'IEEE.754.1985' is mentioned on line 826, but not defined == Missing Reference: 'RFC5226' is mentioned on line 1122, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Missing Reference: 'RFC7674' is mentioned on line 1181, but not defined ** Obsolete undefined reference: RFC 7674 (Obsoleted by RFC 8955) == Unused Reference: 'RFC4761' is defined on line 1272, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1292, but no explicit reference was found in the text == Unused Reference: 'RFC6482' is defined on line 1297, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-07 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group S. Hares 3 Internet-Draft Huawei 4 Obsoletes: 5575 (if approved) R. Raszuk 5 Updates: 7674 (if approved) Bloomberg LP 6 Intended status: Standards Track D. McPherson 7 Expires: August 18, 2017 Verisign 8 C. Loibl 9 Next Layer Communications 10 M. Bacher 11 T-Mobile Austria 12 February 14, 2017 14 Dissemination of Flow Specification Rules 15 draft-hr-idr-rfc5575bis-03.txt 17 Abstract 19 This document updates RFC5575 which defines a Border Gateway Protocol 20 Network Layer Reachability Information (BGP NLRI) encoding format 21 that can be used to distribute traffic flow specifications. This 22 allows the routing system to propagate information regarding more 23 specific components of the traffic aggregate defined by an IP 24 destination prefix. This draft specifies IPv4 traffic flow 25 specifications via a BGP NLRI which carries traffic flow 26 specification filter, and an Extended community value which encodes 27 actions a routing system can take if the packet matches the traffic 28 flow filters. The flow filters and the actions are processed in a 29 fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN 30 addresses, and NV03 encapsulation of IP addresses. 32 This document updates RFC5575 to correct unclear specifications in 33 the flow filters and to provide rules for actions which interfere 34 (e.g. redirection of traffic and flow filtering). 36 Applications which use the bgp flow specification are: 1) application 37 which automate of inter-domain coordination of traffic filtering, 38 such as what is required in order to mitigate (distributed) denial- 39 of-service attacks; 2) application which control traffic filtering in 40 the context of a BGP/MPLS VPN service, and 3) applications with 41 centralized control of traffic in a SDN or NFV context. Some of 42 deployments of these three applications can be handled by the strict 43 ordering of the BGP NLRI traffic flow filters, and the strict actions 44 encoded in the Extended Community Flow Specification actions. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on August 18, 2017. 63 Copyright Notice 65 Copyright (c) 2017 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Definitions of Terms Used in This Memo . . . . . . . . . . . 5 82 3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 6 83 4. Dissemination of IPv4 FLow Specification Information . . . . 6 84 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7 85 4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7 86 4.2.1. Type 1 - Destination Prefix . . . . . . . . . . . . . 8 87 4.2.2. Type 2 - Source Prefix . . . . . . . . . . . . . . . 8 88 4.2.3. Type 3 - IP Protocol . . . . . . . . . . . . . . . . 8 89 4.2.4. Type 4 - Port . . . . . . . . . . . . . . . . . . . . 10 90 4.2.5. Type 5 - Destination Port . . . . . . . . . . . . . . 10 91 4.2.6. Type 6 - Source Port . . . . . . . . . . . . . . . . 10 92 4.2.7. Type 7 - ICMP type . . . . . . . . . . . . . . . . . 10 93 4.2.8. Type 8 - ICMP code . . . . . . . . . . . . . . . . . 11 94 4.2.9. Type 9 - TCP flags . . . . . . . . . . . . . . . . . 11 95 4.2.10. Type 10 - Packet length . . . . . . . . . . . . . . . 12 96 4.2.11. Type 11 - DSCP (Diffserv Code Point) . . . . . . . . 12 97 4.2.12. Type 12 - Fragment . . . . . . . . . . . . . . . . . 12 98 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 12 99 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 13 100 5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 14 101 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 16 102 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17 103 7.1. Traffic Rate in Bytes (sub-type 0x06) . . . . . . . . . . 18 104 7.2. Traffic Rate in Packets (sub-type TBD) . . . . . . . . . 19 105 7.3. Traffic-action (sub-type 0x07) . . . . . . . . . . . . . 19 106 7.4. IP Redirect (sub-type 0x08) . . . . . . . . . . . . . . . 19 107 7.5. Traffic Marking (sub-type 0x09) . . . . . . . . . . . . . 20 108 7.6. Rules on Traffic Action Interference . . . . . . . . . . 20 109 7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 110 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 21 111 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 22 112 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 22 113 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 22 114 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 22 115 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 23 116 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 23 117 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 118 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 119 11.2. Flow Component definitions . . . . . . . . . . . . . . . 24 120 11.3. Extended Community Flow Specification Actions . . . . . 25 121 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 122 13. Original authors . . . . . . . . . . . . . . . . . . . . . . 27 123 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 124 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 125 15.1. Normative References . . . . . . . . . . . . . . . . . . 27 126 15.2. Informative References . . . . . . . . . . . . . . . . . 29 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 129 1. Introduction 131 Modern IP routers contain both the capability to forward traffic 132 according to IP prefixes as well as to classify, shape, rate limit, 133 filter, or redirect packets based on administratively defined 134 policies. 136 These traffic policy mechanisms allow the router to define match 137 rules that operate on multiple fields of the packet header. Actions 138 such as the ones described above can be associated with each rule. 140 The n-tuple consisting of the matching criteria defines an aggregate 141 traffic flow specification. The matching criteria can include 142 elements such as source and destination address prefixes, IP 143 protocol, and transport protocol port numbers. 145 This document defines a general procedure to encode flow 146 specification rules for aggregated traffic flows so that they can be 147 distributed as a BGP [RFC5575] NLRI. Additionally, we define the 148 required mechanisms to utilize this definition to the problem of 149 immediate concern to the authors: intra- and inter-provider 150 distribution of traffic filtering rules to filter (distributed) 151 denial-of-service (DoS) attacks. 153 By expanding routing information with flow specifications, the 154 routing system can take advantage of the ACL (Access Control List) or 155 firewall capabilities in the router's forwarding path. Flow 156 specifications can be seen as more specific routing entries to a 157 unicast prefix and are expected to depend upon the existing unicast 158 data information. 160 A flow specification received from an external autonomous system will 161 need to be validated against unicast routing before being accepted. 162 If the aggregate traffic flow defined by the unicast destination 163 prefix is forwarded to a given BGP peer, then the local system can 164 safely install more specific flow rules that may result in different 165 forwarding behavior, as requested by this system. 167 The key technology components required to address the class of 168 problems targeted by this document are: 170 1. Efficient point-to-multipoint distribution of control plane 171 information. 173 2. Inter-domain capabilities and routing policy support. 175 3. Tight integration with unicast routing, for verification 176 purposes. 178 Items 1 and 2 have already been addressed using BGP for other types 179 of control plane information. Close integration with BGP also makes 180 it feasible to specify a mechanism to automatically verify flow 181 information against unicast routing. These factors are behind the 182 choice of BGP as the carrier of flow specification information. 184 As with previous extensions to BGP, this specification makes it 185 possible to add additional information to Internet routers. These 186 are limited in terms of the maximum number of data elements they can 187 hold as well as the number of events they are able to process in a 188 given unit of time. The authors believe that, as with previous 189 extensions, service providers will be careful to keep information 190 levels below the maximum capacity of their devices. 192 In many deployments of BGP Flow Specification, the flow specification 193 information has replace existing host length route advertisements. 195 Experience with previous BGP extensions has also shown that the 196 maximum capacity of BGP speakers has been gradually increased 197 according to expected loads. Taking into account Internet unicast 198 routing as well as additional applications as they gain popularity. 200 From an operational perspective, the utilization of BGP as the 201 carrier for this information allows a network service provider to 202 reuse both internal route distribution infrastructure (e.g., route 203 reflector or confederation design) and existing external 204 relationships (e.g., inter-domain BGP sessions to a customer 205 network). 207 While it is certainly possible to address this problem using other 208 mechanisms, this solution has been utilized in deployments because of 209 the substantial advantage of being an incremental addition to already 210 deployed mechanisms. 212 In current deployments, the information distributed by the flow-spec 213 extension is originated both manually as well as automatically. The 214 latter by systems that are able to detect malicious flows. When 215 automated systems are used, care should be taken to ensure their 216 correctness as well as to limit the number and advertisement rate of 217 flow routes. 219 This specification defines required protocol extensions to address 220 most common applications of IPv4 unicast and VPNv4 unicast filtering. 221 The same mechanism can be reused and new match criteria added to 222 address similar filtering needs for other BGP address families such 223 as IPv6 families [I-D.ietf-idr-flow-spec-v6], 225 2. Definitions of Terms Used in This Memo 227 NLRI - Network Layer Reachability Information. 229 RIB - Routing Information Base. 231 Loc-RIB - Local RIB. 233 AS - Autonomous System number. 235 VRF - Virtual Routing and Forwarding instance. 237 PE - Provider Edge router 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in [RFC2119] 243 3. Flow Specifications 245 A flow specification is an n-tuple consisting of several matching 246 criteria that can be applied to IP traffic. A given IP packet is 247 said to match the defined flow if it matches all the specified 248 criteria. 250 A given flow may be associated with a set of attributes, depending on 251 the particular application; such attributes may or may not include 252 reachability information (i.e., NEXT_HOP). Well-known or AS-specific 253 community attributes can be used to encode a set of predetermined 254 actions. 256 A particular application is identified by a specific (Address Family 257 Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair 258 [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs 259 should be treated independently from each other in order to assure 260 non-interference between distinct applications. 262 BGP itself treats the NLRI as an opaque key to an entry in its 263 databases. Entries that are placed in the Loc-RIB are then 264 associated with a given set of semantics, which is application 265 dependent. This is consistent with existing BGP applications. For 266 instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast 267 reverse-path information (AFI=1, SAFI=2) are handled by BGP without 268 any particular semantics being associated with them until installed 269 in the Loc-RIB. 271 Standard BGP policy mechanisms, such as UPDATE filtering by NLRI 272 prefix as well as community matching and manipulation, MUST apply to 273 the Flow specification defined NLRI-type, especially in an inter- 274 domain environment. Network operators can also control propagation 275 of such routing updates by enabling or disabling the exchange of a 276 particular (AFI, SAFI) pair on a given BGP peering session. 278 4. Dissemination of IPv4 FLow Specification Information 280 We define a "Flow Specification" NLRI type (Figure 1) that may 281 include several components such as destination prefix, source prefix, 282 protocol, ports, and others (see Section 4.2 below). This NLRI is 283 treated as an opaque bit string prefix by BGP. Each bit string 284 identifies a key to a database entry with which a set of attributes 285 can be associated. 287 This NLRI information is encoded using MP_REACH_NLRI and 288 MP_UNREACH_NLRI attributes as defined in [RFC4760]. Whenever the 289 corresponding application does not require Next-Hop information, this 290 shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI 291 attribute and ignored on receipt. 293 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 294 a 1- or 2-octet NLRI length field followed by a variable-length NLRI 295 value. The NLRI length is expressed in octets. 297 +------------------------------+ 298 | length (0xnn or 0xfn nn) | 299 +------------------------------+ 300 | NLRI value (variable) | 301 +------------------------------+ 303 Figure 1: Flow-spec NLRI for IPv4 305 Implementations wishing to exchange flow specification rules MUST use 306 BGP's Capability Advertisement facility to exchange the Multiprotocol 307 Extension Capability Code (Code 1) as defined in [RFC4760]. The 308 (AFI, SAFI) pair carried in the Multiprotocol Extension Capability 309 MUST be the same as the one used to identify a particular application 310 that uses this NLRI-type. 312 4.1. Length Encoding 314 o If the NLRI length value is smaller than 240 (0xf0 hex), the 315 length field can be encoded as a single octet. 317 o Otherwise, it is encoded as an extended-length 2-octet value in 318 which the most significant nibble of the first byte is all ones. 320 In figure 1 above, values less-than 240 are encoded using two hex 321 digits (0xnn). Values above 239 are encoded using 3 hex digits 322 (0xfnnn). The highest value that can be represented with this 323 encoding is 4095. The value 241 is encoded as 0xf0f1. 325 4.2. NLRI Value Encoding 327 The Flow specification NLRI-type consists of several optional 328 subcomponents. A specific packet is considered to match the flow 329 specification when it matches the intersection (AND) of all the 330 components present in the specification. 332 The encoding of each of the NLRI components begins with a type field 333 (1 octet) followed by a variable length parameter. Section 4.2.1 to 334 Section 4.2.12 define component types and parameter encodings for the 335 IPv4 IP layer and transport layer headers. IPv6 NLRI component types 336 are described in [I-D.ietf-idr-flow-spec-v6]. 338 Flow specification components must follow strict type ordering by 339 increasing numerical order. A given component type may or may not be 340 present in the specification, but if present, it MUST precede any 341 component of higher numeric type value. 343 If a given component type within a prefix in unknown, the prefix in 344 question cannot be used for traffic filtering purposes by the 345 receiver. Since a flow specification has the semantics of a logical 346 AND of all components, if a component is FALSE, by definition it 347 cannot be applied. However, for the purposes of BGP route 348 propagation, this prefix should still be transmitted since BGP route 349 distribution is independent on NLRI semantics. 351 The encoding is chosen in order to allow for future 352 extensibility. 354 4.2.1. Type 1 - Destination Prefix 356 Encoding: 358 Defines: the destination prefix to match. Prefixes are encoded as 359 in BGP UPDATE messages, a length in bits is followed by enough 360 octets to contain the prefix information. 362 4.2.2. Type 2 - Source Prefix 364 Encoding: 366 Defines the source prefix to match. 368 4.2.3. Type 3 - IP Protocol 370 Encoding: 372 Contains a set of {operator, value} pairs that are used to match 373 the IP protocol value byte in IP packets. 375 The operator byte is encoded as: 377 0 1 2 3 4 5 6 7 378 +---+---+---+---+---+---+---+---+ 379 | e | a | len | 0 |lt |gt |eq | 380 +---+---+---+---+---+---+---+---+ 382 Numeric operator 384 e - end-of-list bit. Set in the last {op, value} pair in the 385 list. 387 a - AND bit. If unset, the previous term is logically ORed with 388 the current one. If set, the operation is a logical AND. It 389 should be unset in the first operator byte of a sequence. The AND 390 operator has higher priority than OR for the purposes of 391 evaluating logical expressions. 393 len - length of the value field for this operand encodes 1 (00) - 394 4 (11) bytes. Type 3 flow component values are always encoded as 395 single byte (len = 00). 397 lt - less than comparison between data and value. 399 gt - greater than comparison between data and value. 401 eq - equality between data and value. 403 The bits lt, gt, and eq can be combined to produce "less or equal", 404 "greater or equal", and inequality values. 406 +----+----+----+----------------------------------+ 407 | lt | gt | eq | Resulting operation | 408 +----+----+----+----------------------------------+ 409 | 0 | 0 | 0 | true (independent of the value) | 410 | 0 | 0 | 1 | == (equal) | 411 | 0 | 1 | 0 | > (greater than) | 412 | 0 | 1 | 1 | >= (greater than or equal) | 413 | 1 | 0 | 0 | < (less than) | 414 | 1 | 0 | 1 | <= (less than or equal) | 415 | 1 | 1 | 0 | != (not equal value) | 416 | 1 | 1 | 1 | false (independent of the value) | 417 +----+----+----+----------------------------------+ 419 Table 1: Comparison operation combinations 421 4.2.4. Type 4 - Port 423 Encoding: 425 Defines a list of {operator, value} pairs that matches source OR 426 destination TCP/UDP ports. This list is encoded using the numeric 427 operator format defined in Section 4.2.3. Values are encoded as 428 1- or 2-byte quantities. 430 Port, source port, and destination port components evaluate to 431 FALSE if the IP protocol field of the packet has a value other 432 than TCP or UDP, if the packet is fragmented and this is not the 433 first fragment, or if the system in unable to locate the transport 434 header. Different implementations may or may not be able to 435 decode the transport header in the presence of IP options or 436 Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. 438 4.2.5. Type 5 - Destination Port 440 Encoding: 442 Defines a list of {operator, value} pairs used to match the 443 destination port of a TCP or UDP packet. This list is encoded 444 using the numeric operator format defined in Section 4.2.3. 445 Values are encoded as 1- or 2-byte quantities. 447 4.2.6. Type 6 - Source Port 449 Encoding: 451 Defines a list of {operator, value} pairs used to match the source 452 port of a TCP or UDP packet. This list is encoded using the 453 numeric operator format defined in Section 4.2.3. Values are 454 encoded as 1- or 2-byte quantities. 456 4.2.7. Type 7 - ICMP type 458 Encoding: 460 Defines a list of {operator, value} pairs used to match the type 461 field of an ICMP packet. This list is encoded using the numeric 462 operator format defined in Section 4.2.3. Values are encoded 463 using a single byte. 465 The ICMP type specifiers evaluate to FALSE whenever the protocol 466 value is not ICMP. 468 4.2.8. Type 8 - ICMP code 470 Encoding: 472 Defines a list of {operator, value} pairs used to match the code 473 field of an ICMP packet. This list is encoded using the numeric 474 operator format defined in Section 4.2.3. Values are encoded 475 using a single byte. 477 The ICMP code specifiers evaluate to FALSE whenever the protocol 478 value is not ICMP. 480 4.2.9. Type 9 - TCP flags 482 Encoding: 484 Bitmask values can be encoded as a 1- or 2-byte bitmask. When a 485 single byte is specified, it matches byte 13 of the TCP header 486 [RFC0793], which contains bits 8 though 15 of the 4th 32-bit word. 487 When a 2-byte encoding is used, it matches bytes 12 and 13 of the 488 TCP header with the data offset field having a "don't care" value. 490 This component evaluates to FALSE for packets that are not TCP 491 packets. 493 This type uses the bitmask operand format, which differs from the 494 numeric operator format in the lower nibble. 496 0 1 2 3 4 5 6 7 497 +---+---+---+---+---+---+---+---+ 498 | e | a | len | 0 | 0 |not| m | 499 +---+---+---+---+---+---+---+---+ 501 Bitmask format 503 e, a, len - Most significant nibble: (end-of-list bit, AND bit, and 504 length field), as defined for in the numeric operator format in 505 Section 4.2.3. 507 not - NOT bit. If set, logical negation of operation. 509 m - Match bit. If set, this is a bitwise match operation defined 510 as "(data AND value) == value"; if unset, (data AND value) 511 evaluates to TRUE if any of the bits in the value mask are set in 512 the data 514 4.2.10. Type 10 - Packet length 516 Encoding: 518 Defines a list of {operator, value} pairs used to match on the 519 total IP packet length (excluding Layer 2 but including IP 520 header). This list is encoded using the numeric operator format 521 defined in Section 4.2.3. Values are encoded using 1- or 2-byte 522 quantities. 524 4.2.11. Type 11 - DSCP (Diffserv Code Point) 526 Encoding: 528 Defines a list of {operator, value} pairs used to match the 6-bit 529 DSCP field [RFC2474]. This list is encoded using the numeric 530 operator format defined in Section 4.2.3. Values are encoded 531 using a single byte. The two most significant bits are zero and 532 the six least significant bits contain the DSCP value. 534 4.2.12. Type 12 - Fragment 536 Encoding: 538 Uses bitmask operand format defined in Section 4.2.9. 540 0 1 2 3 4 5 6 7 541 +---+---+---+---+---+---+---+---+ 542 | Reserved |LF |FF |IsF|DF | 543 +---+---+---+---+---+---+---+---+ 545 Bitmask values: 547 Bit 7 - Don't fragment (DF) 549 Bit 6 - Is a fragment (IsF) 551 Bit 5 - First fragment (FF) 553 Bit 4 - Last fragment (LF) 555 4.3. Examples of Encodings 557 An example of a flow specification encoding for: "all packets to 558 10.0.1/24 and TCP port 25". 560 +------------------+----------+----------+ 561 | destination | proto | port | 562 +------------------+----------+----------+ 563 | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | 564 +------------------+----------+----------+ 566 Decode for protocol: 568 +-------+----------+------------------------------+ 569 | Value | | | 570 +-------+----------+------------------------------+ 571 | 0x03 | type | | 572 | 0x81 | operator | end-of-list, value size=1, = | 573 | 0x06 | value | | 574 +-------+----------+------------------------------+ 576 An example of a flow specification encoding for: "all packets to 577 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". 579 +------------------+----------+-------------------------+ 580 | destination | source | port | 581 +------------------+----------+-------------------------+ 582 | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | 583 +------------------+----------+-------------------------+ 585 Decode for port: 587 +--------+----------+------------------------------+ 588 | Value | | | 589 +--------+----------+------------------------------+ 590 | 0x04 | type | | 591 | 0x03 | operator | size=1, >= | 592 | 0x89 | value | 137 | 593 | 0x45 | operator | "AND", value size=1, <= | 594 | 0x8b | value | 139 | 595 | 0x91 | operator | end-of-list, value-size=2, = | 596 | 0x1f90 | value | 8080 | 597 +--------+----------+------------------------------+ 599 This constitutes an NLRI with an NLRI length of 16 octets. 601 5. Traffic Filtering 603 Traffic filtering policies have been traditionally considered to be 604 relatively static. Limitations of the static mechanisms caused this 605 mechanism to be designed for the three new applications of traffic 606 filtering (prevention of traffic-based, denial-of-service (DOS) 607 attacks, traffic filtering in the context of BGP/MPLS VPN service, 608 and centralized traffic control for SDN/NFV networks) requires 609 coordination among service providers and/or coordination among the AS 610 within a service provider. Section 8 has details on the limitation 611 of previous mechanisms and why BGP Flow Specification version 1 612 provides a solution for to prevent DOS and aid BGP/MPLS VPN filtering 613 rules. 615 This flow specification NLRI defined above to convey information 616 about traffic filtering rules for traffic that should be discarded or 617 handled in manner specified by a set of pre-defined actions (which 618 are defined in BGP Extended Communities). This mechanism is 619 primarily designed to allow an upstream autonomous system to perform 620 inbound filtering in their ingress routers of traffic that a given 621 downstream AS wishes to drop. 623 In order to achieve this goal, this draft specifies two application 624 specific NLRI identifiers that provide traffic filters, and a set of 625 actions encoding in BGP Extended Communities. The two application 626 specific NLRI identifiers are: 628 o IPv4 flow specification identifier (AFI=1, SAFI=133) along with 629 specific semantic rules for IPv4 routes, and 631 o BGP NLRI type (AFI=1, SAFI=134) value, which can be used to 632 propagate traffic filtering information in a BGP/MPLS VPN 633 environment. 635 Distribution of the IPv4 Flow specification is described in section 636 6, and distibution of BGP/MPLS traffic flow specification is 637 described in section 8. The traffic filtering actions are described 638 in section 7. 640 5.1. Ordering of Traffic Filtering Rules 642 With traffic filtering rules, more than one rule may match a 643 particular traffic flow. Thus, it is necessary to define the order 644 at which rules get matched and applied to a particular traffic flow. 645 This ordering function must be such that it must not depend on the 646 arrival order of the flow specification's rules and must be 647 consistent in the network. 649 The relative order of two flow specification rules is determined by 650 comparing their respective components. The algorithm starts by 651 comparing the left-most components of the rules. If the types 652 differ, the rule with lowest numeric type value has higher precedence 653 (and thus will match before) than the rule that doesn't contain that 654 component type. If the component types are the same, then a type- 655 specific comparison is performed. 657 For IP prefix values (IP destination and source prefix) precedence is 658 given to the lowest IP value of the common prefix length; if the 659 common prefix is equal, then the most specific prefix has precedence. 661 For all other component types, unless otherwise specified, the 662 comparison is performed by comparing the component data as a binary 663 string using the memcmp() function as defined by the ISO C standard. 664 For strings of different lengths, the common prefix is compared. If 665 equal, the longest string is considered to have higher precedence 666 than the shorter one. 668 Pseudocode: 670 flow_rule_cmp (a, b) 671 { 672 comp1 = next_component(a); 673 comp2 = next_component(b); 674 while (comp1 || comp2) { 675 // component_type returns infinity on end-of-list 676 if (component_type(comp1) < component_type(comp2)) { 677 return A_HAS_PRECEDENCE; 678 } 679 if (component_type(comp1) > component_type(comp2)) { 680 return B_HAS_PRECEDENCE; 681 } 683 if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) { 684 common = MIN(prefix_length(comp1), prefix_length(comp2)); 685 cmp = prefix_compare(comp1, comp2, common); 686 // not equal, lowest value has precedence 687 // equal, longest match has precedence 688 } else { 689 common = 690 MIN(component_length(comp1), component_length(comp2)); 691 cmp = memcmp(data(comp1), data(comp2), common); 692 // not equal, lowest value has precedence 693 // equal, longest string has precedence 694 } 695 } 696 return EQUAL; 697 } 699 6. Validation Procedure 701 Flow specifications received from a BGP peer that are accepted in the 702 respective Adj-RIB-In are used as input to the route selection 703 process. Although the forwarding attributes of two routes for the 704 same flow specification prefix may be the same, BGP is still required 705 to perform its path selection algorithm in order to select the 706 correct set of attributes to advertise. 708 The first step of the BGP Route Selection procedure (Section 9.1.2 of 709 [RFC4271] is to exclude from the selection procedure routes that are 710 considered non-feasible. In the context of IP routing information, 711 this step is used to validate that the NEXT_HOP attribute of a given 712 route is resolvable. 714 The concept can be extended, in the case of flow specification NLRI, 715 to allow other validation procedures. 717 A flow specification NLRI must be validated such that it is 718 considered feasible if and only if: 720 a) The originator of the flow specification matches the originator 721 of the best-match unicast route for the destination prefix 722 embedded in the flow specification. 724 b) There are no more specific unicast routes, when compared with 725 the flow destination prefix, that has been received from a 726 different neighboring AS than the best-match unicast route, which 727 has been determined in step a). 729 By originator of a BGP route, we mean either the BGP originator path 730 attribute, as used by route reflection, or the transport address of 731 the BGP peer, if this path attribute is not present. 733 BGP implementations MUST also enforce that the AS_PATH attribute of a 734 route received via the External Border Gateway Protocol (eBGP) 735 contains the neighboring AS in the left-most position of the AS_PATH 736 attribute. While this rule is optional in the BGP specification, it 737 becomes necessary to enforce it for security reasons. 739 The best-match unicast route may change over the time independently 740 of the flow specification NLRI. Therefore, a revalidation of the 741 flow specification NLRI MUST be performed whenever unicast routes 742 change. Revalidation is defined as retesting that clause a and 743 clause b above are true. 745 Explanation: 747 The underlying concept is that the neighboring AS that advertises the 748 best unicast route for a destination is allowed to advertise flow- 749 spec information that conveys a more or equally specific destination 750 prefix. Thus, as long as there are no more specific unicast routes, 751 received from a different neighboring AS, which would be affected by 752 that filtering rule. 754 The neighboring AS is the immediate destination of the traffic 755 described by the flow specification. If it requests these flows to 756 be dropped, that request can be honored without concern that it 757 represents a denial of service in itself. Supposedly, the traffic is 758 being dropped by the downstream autonomous system, and there is no 759 added value in carrying the traffic to it. 761 7. Traffic Filtering Actions 763 This specification defines a minimum set of filtering actions that it 764 standardizes as BGP extended community values [RFC4360]. This is not 765 meant to be an inclusive list of all the possible actions, but only a 766 subset that can be interpreted consistently across the network. 767 Additional actions can be defined as either requiring standards or as 768 vendor specific. 770 Implementations SHOULD provide mechanisms that map an arbitrary BGP 771 community value (normal or extended) to filtering actions that 772 require different mappings in different systems in the network. For 773 instance, providing packets with a worse-than-best-effort, per-hop 774 behavior is a functionality that is likely to be implemented 775 differently in different systems and for which no standard behavior 776 is currently known. Rather than attempting to define it here, this 777 can be accomplished by mapping a user-defined community value to 778 platform-/network-specific behavior via user configuration. 780 The default action for a traffic filtering flow specification is to 781 accept IP traffic that matches that particular rule. 783 This document defines the following extended communities values shown 784 in Table 2 in the form 0x8xnn where nn indicates the sub-type. 785 Encodings for these extended communities are described below. 787 +--------+----------------------+-----------------------------------+ 788 | type | extended community | encoding | 789 +--------+----------------------+-----------------------------------+ 790 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | 791 | 0x8007 | traffic-action | bitmask | 792 | 0x8008 | redirect AS-2byte | 2-octet AS, 4-octet value | 793 | 0x8108 | redirect IPv4 | 4-octet IPv4 addres, 2-octet | 794 | | | value | 795 | 0x8208 | redirect AS-4byte | 4-octet AS, 2-octet value | 796 | 0x8009 | traffic-marking | DSCP value | 797 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | 798 +--------+----------------------+-----------------------------------+ 800 Table 2: Traffic Action Extended Communities 802 Some traffic action communities may interfere with each other. 803 Section 7.6 of this specification provides rules for handling 804 interference between specific types of traffic actions, and error 805 handling based on [RFC7606]. Any additional definition of a traffic 806 actions specified by additional standards documents or vendor 807 documents MUST specify if the traffic action interacts with an 808 existing traffic actions, and provide error handling per [RFC7606]. 810 The traffic actions are processed in ascending order of the sub-type 811 found in the BGP Extended Communities. All traffic actions are 812 specified in transitive BGP Extended Communities. 814 7.1. Traffic Rate in Bytes (sub-type 0x06) 816 The traffic-rate-bytes extended community uses the following extended 817 community encoding: 819 The first two octets carry the 2-octet id, which can be assigned from 820 a 2-byte AS number. When a 4-byte AS number is locally present, the 821 2 least significant bytes of such an AS number can be used. This 822 value is purely informational and should not be interpreted by the 823 implementation. 825 The remaining 4 octets carry the maximum rate information in IEEE 826 floating point [IEEE.754.1985] format, units being bytes per second. 827 A traffic-rate of 0 should result on all traffic for the particular 828 flow to be discarded. 830 Interferes with: Traffic Rate in packets (traffic-rate-packets). 831 Process traffic rate in bytes (sub-type 0x06) action before traffic 832 rate in packets action (sub-type TBD). 834 7.2. Traffic Rate in Packets (sub-type TBD) 836 The traffic-rate-packets extended community uses the same encoding as 837 the traffic-rate-bytes extended community. The floating point value 838 carries the maximum packet rate in packets per second. A traffic- 839 rate-packets of 0 should result in all traffic for the particular 840 flow to be discarded. 842 Interferes with: Traffic Rate in bytes (traffic-rate-bytes). Process 843 traffic rate in bytes (sub-type 0x06) action before traffic rate in 844 packets action (sub-type TBD). 846 7.3. Traffic-action (sub-type 0x07) 848 The traffic-action extended community consists of 6 bytes of which 849 only the 2 least significant bits of the 6th byte (from left to 850 right) are currently defined. 852 40 41 42 43 44 45 46 47 853 +---+---+---+---+---+---+---+---+ 854 | reserved | S | T | 855 +---+---+---+---+---+---+---+---+ 857 where S and T are defined as: 859 o T: Terminal Action (bit 47): When this bit is set, the traffic 860 filtering engine will apply any subsequent filtering rules (as 861 defined by the ordering procedure). If not set, the evaluation of 862 the traffic filter stops when this rule is applied. 864 o S:Sample (bit 46): Enables traffic sampling and logging for this 865 flow specification. 867 Interferes with: No other BGP Flow Specification traffic action in 868 this document. 870 7.4. IP Redirect (sub-type 0x08) 872 The redirect extended community allows the traffic to be redirected 873 to a VRF routing instance that lists the specified route-target in 874 its import policy. If several local instances match this criteria, 875 the choice between them is a local matter (for example, the instance 876 with the lowest Route Distinguisher value can be elected). This 877 extended community uses the same encoding as the Route Target 878 extended community [RFC4360]. 880 It should be noted that the low-order nibble of the Redirect's Type 881 field corresponds to the Route Target Extended Community format field 882 (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of 883 [RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended 884 Community remains 0x08 for all three encodings of the BGP Extended 885 Communities (AS 2-byte, AS 4-byte, and IPv4 address). 887 Interferes with: All other redirect functions. All redirect 888 functions are mutually exclusive. If this redirect function exists, 889 then no other redirect functions can be processed. 891 7.5. Traffic Marking (sub-type 0x09) 893 The traffic marking extended community instructs a system to modify 894 the DSCP bits of a transiting IP packet to the corresponding value. 895 This extended community is encoded as a sequence of 5 zero bytes 896 followed by the DSCP value encoded in the 6 least significant bits of 897 6th byte. 899 Interferes with: No other action in this document. 901 7.6. Rules on Traffic Action Interference 903 Traffic actions may interfere with each other. If interfering 904 traffic actions are present for a single flow specification NLRI the 905 entire flow specification (irrespective if there are any other non 906 conflicting actions associated with the same flow specification) 907 SHALL be treated as BGP WITHDRAW. 909 This document defines 7 traffic actions which are interfering in the 910 following way: 912 1. Redirect-action-communities (0x8008, 0x8108, 0x8208): 914 The three redirect-communities are mutually exclusive. Only a 915 single redirect community may be associated with a flow 916 specification otherwise they are interfering. 918 2. All traffic-action communities (including redirect-actions): 920 Multiple occurences of the same (sub-type and type) traffic- 921 action associated with a flow specification are always 922 interfering. 924 When a traffic action is defined in a standards document the handling 925 of interaction with other/same traffic actions MUST be defined as 926 well. Invalid interactions between actions SHOULD NOT trigger a BGP 927 NOTIFICATION. All error handling for error conditions based on 928 [RFC7606]. 930 7.6.1. Examples 932 (redirect vpn-a, redirect vpn-b, traffic-rate-bytes 1Mbit/s) 934 Redirect vpn-a and redirect vpn-b are interfering: The BGP UPDATE 935 is treated as WITHDRAW. 937 (redirect vpn-a, traffic-rate-bytes 1Mbit/s, traffic-rate-bytes 938 2Mbit/s) 940 Duplicate traffic-rate-bytes are interfering: The BGP UPDATE is 941 treated as WITHDRAW. 943 (redirect vpn-a, traffic-rate-bytes 1Mbit/s, traffic-rate-packets 944 1000) 946 No interfering action communities: The BGP UPDATE is subject to 947 further processing. 949 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 951 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 952 MPLS IP VPN [RFC4364] control plane, may have different traffic 953 filtering requirements than Internet service providers. But also 954 Internet service providers may use those VPNs for scenarios like 955 having the Internet routing table in a VRF, resulting in the same 956 traffic filtering requirements as defined for the global routing 957 table environment within this document. This document proposes an 958 additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used 959 to propagate traffic filtering information in a BGP/MPLS VPN 960 environment. 962 The NLRI format for this address family consists of a fixed-length 963 Route Distinguisher field (8 bytes) followed by a flow specification, 964 following the encoding defined above in section x of this document. 965 The NLRI length field shall include both the 8 bytes of the Route 966 Distinguisher as well as the subsequent flow specification. 968 +------------------------------+ 969 | length (0xnn or 0xfn nn) | 970 +------------------------------+ 971 | Route Distinguisher (8 bytes)| 972 +------------------------------+ 973 | NLRI value (variable) | 974 +------------------------------+ 976 Flow-spec NLRI for MPLS 978 Propagation of this NLRI is controlled by matching Route Target 979 extended communities associated with the BGP path advertisement with 980 the VRF import policy, using the same mechanism as described in "BGP/ 981 MPLS IP VPNs" [RFC4364]. 983 Flow specification rules received via this NLRI apply only to traffic 984 that belongs to the VRF(s) in which it is imported. By default, 985 traffic received from a remote PE is switched via an MPLS forwarding 986 decision and is not subject to filtering. 988 Contrary to the behavior specified for the non-VPN NLRI, flow rules 989 are accepted by default, when received from remote PE routers. 991 8.1. Validation Procedures for BGP/MPLS VPNs 993 The validation procedures are the same as for IPv4. 995 8.2. Traffic Actions Rules 997 The traffic action rules are the same as for IPv4. 999 9. Limitations of Previous Traffic Filtering Efforts 1001 9.1. Limitations in Previous DDoS Traffic Filtering Efforts 1003 The popularity of traffic-based, denial-of-service (DoS) attacks, 1004 which often requires the network operator to be able to use traffic 1005 filters for detection and mitigation, brings with it requirements 1006 that are not fully satisfied by existing tools. 1008 Increasingly, DoS mitigation requires coordination among several 1009 service providers in order to be able to identify traffic source(s) 1010 and because the volumes of traffic may be such that they will 1011 otherwise significantly affect the performance of the network. 1013 Several techniques are currently used to control traffic filtering of 1014 DoS attacks. Among those, one of the most common is to inject 1015 unicast route advertisements corresponding to a destination prefix 1016 being attacked (commonly known as remote triggered blackhole RTBH). 1017 One variant of this technique marks such route advertisements with a 1018 community that gets translated into a discard Next-Hop by the 1019 receiving router. Other variants attract traffic to a particular 1020 node that serves as a deterministic drop point. 1022 Using unicast routing advertisements to distribute traffic filtering 1023 information has the advantage of using the existing infrastructure 1024 and inter-AS communication channels. This can allow, for instance, a 1025 service provider to accept filtering requests from customers for 1026 address space they own. 1028 There are several drawbacks, however. An issue that is immediately 1029 apparent is the granularity of filtering control: only destination 1030 prefixes may be specified. Another area of concern is the fact that 1031 filtering information is intermingled with routing information. 1033 The mechanism defined in this document is designed to address these 1034 limitations. We use the flow specification NLRI defined above to 1035 convey information about traffic filtering rules for traffic that is 1036 subject to modified forwarding behavior (actions). The actions are 1037 defined as extended communities and include (but are not limited to) 1038 rate-limiting (including discard), traffic redirection, packet 1039 rewriting. 1041 9.2. Limitations in Previous BGP/MPLS Traffic Filtering 1043 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1044 MPLS IP VPN [RFC4364] control plane, may have different traffic 1045 filtering requirements than Internet service providers. 1047 In these environments, the VPN customer network often has traffic 1048 filtering capabilities towards their external network connections 1049 (e.g., firewall facing public network connection). Less common is 1050 the presence of traffic filtering capabilities between different VPN 1051 attachment sites. In an any-to-any connectivity model, which is the 1052 default, this means that site-to-site traffic is unfiltered. 1054 In circumstances where a security threat does get propagated inside 1055 the VPN customer network, there may not be readily available 1056 mechanisms to provide mitigation via traffic filter. 1058 But also Internet service providers may use those VPNs for scenarios 1059 like having the Internet routing table in a VRF. Therefore, 1060 limitations described in Section 9.1 also apply to this section. 1062 The BGP Flow Specification version 1 addresses these limitations. 1064 10. Traffic Monitoring 1066 Traffic filtering applications require monitoring and traffic 1067 statistics facilities. While this is an implementation-specific 1068 choice, implementations SHOULD provide: 1070 o A mechanism to log the packet header of filtered traffic. 1072 o A mechanism to count the number of matches for a given flow 1073 specification rule. 1075 11. IANA Considerations 1077 This section complies with [RFC7153] 1079 11.1. AFI/SAFI Definitions 1081 For the purpose of this work, IANA has allocated values for two 1082 SAFIs: SAFI 133 for IPv4 dissemination of flow specification rules 1083 and SAFI 134 for VPNv4 dissemination of flow specification rules. 1085 11.2. Flow Component definitions 1087 A flow specification consists of a sequence of flow components, which 1088 are identified by a an 8-bit component type. Types must be assigned 1089 and interpreted uniquely. The current specification defines types 1 1090 though 12, with the value 0 being reserved. 1092 IANA created and maintains a new registry entitled: "Flow Spec 1093 Component Types". The following component types have been 1094 registered: 1096 Type 1 - Destination Prefix 1098 Type 2 - Source Prefix 1100 Type 3 - IP Protocol 1102 Type 4 - Port 1104 Type 5 - Destination port 1106 Type 6 - Source port 1108 Type 7 - ICMP type 1110 Type 8 - ICMP code 1112 Type 9 - TCP flags 1114 Type 10 - Packet length 1116 Type 11 - DSCP 1118 Type 12 - Fragment 1119 Type 13 - Bit Mask filter 1121 In order to manage the limited number space and accommodate several 1122 usages, the following policies defined by RFC 5226 [RFC5226] are 1123 used: 1125 +--------------+-------------------------------+ 1126 | Range | Policy | 1127 +--------------+-------------------------------+ 1128 | 0 | Invalid value | 1129 | [1 .. 12] | Defined by this specification | 1130 | [13 .. 127] | Specification Required | 1131 | [128 .. 255] | First Come First Served | 1132 +--------------+-------------------------------+ 1134 The specification of a particular "flow component type" must clearly 1135 identify what the criteria used to match packets forwarded by the 1136 router is. This criteria should be meaningful across router hops and 1137 not depend on values that change hop-by-hop such as TTL or Layer 2 1138 encapsulation. 1140 The "traffic-action" extended community defined in this document has 1141 46 unused bits, which can be used to convey additional meaning. IANA 1142 created and maintains a new registry entitled: "Traffic Action 1143 Fields". These values should be assigned via IETF Review rules only. 1144 The following traffic-action fields have been allocated: 1146 47 Terminal Action 1148 46 Sample 1150 0-45 Unassigned 1152 11.3. Extended Community Flow Specification Actions 1154 The Extended Community FLow Specification Action types consists of 1155 two parts: BGP Transitive Extended Community types and a set of sub- 1156 types. 1158 IANA has updated the following "BGP Transitive Extended Community 1159 Types" registries to contain the values listed below: 1161 0x80 - Generic Transitive Experimental Use Extended Community Part 1162 1 (Sub-Types are defined in the "Generic Transitive Experimental 1163 Extended Community Part 1 Sub-Types" Registry) 1165 0x81 - Generic Transitive Experimental Use Extended Community Part 1166 2 (Sub-Types are defined in the "Generic Transitive Experimental 1167 Extended Community Part 2 Sub-Types" Registry) 1169 0x82 - Generic Transitive Experimental Use Extended Community Part 1170 3 (Sub-Types are defined in the "Generic Transitive Experimental 1171 Use Extended Community Part 3 Sub-Types" Registry) 1173 RANGE REGISTRATION PROCEDURE 1174 0x00-0xbf First Come First Served 1175 0xc0-0xff IETF Review 1177 SUB-TYPE VALUE NAME REFERENCE 1178 0x00-0x05 unassigned 1179 0x06 traffic-rate [this document] 1180 0x07 traffic-action [this document] 1181 0x08 Flow spec redirect IPv4 [RFC5575] [RFC7674] 1182 [this document] 1183 0x09 traffic-marking [this document] 1184 0x0a-0xff Unassigned [this document] 1186 12. Security Considerations 1188 Inter-provider routing is based on a web of trust. Neighboring 1189 autonomous systems are trusted to advertise valid reachability 1190 information. If this trust model is violated, a neighboring 1191 autonomous system may cause a denial-of-service attack by advertising 1192 reachability information for a given prefix for which it does not 1193 provide service. 1195 As long as traffic filtering rules are restricted to match the 1196 corresponding unicast routing paths for the relevant prefixes, the 1197 security characteristics of this proposal are equivalent to the 1198 existing security properties of BGP unicast routing. 1200 Where it is not the case, this would open the door to further denial- 1201 of-service attacks. 1203 Enabling firewall-like capabilities in routers without centralized 1204 management could make certain failures harder to diagnose. For 1205 example, it is possible to allow TCP packets to pass between a pair 1206 of addresses but not ICMP packets. It is also possible to permit 1207 packets smaller than 900 or greater than 1000 bytes to pass between a 1208 pair of addresses, but not packets whose length is in the range 900- 1209 1000. Such behavior may be confusing and these capabilities should 1210 be used with care whether manually configured or coordinated through 1211 the protocol extensions described in this document. 1213 13. Original authors 1215 Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and 1216 Nischal Sheth were authors on [RFC5575], and therefore are 1217 contributing authors on this document. 1219 Note: Any original author of [RFC5575] who wants to work on this 1220 draft can be added as a co-author. 1222 14. Acknowledgements 1224 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 1225 Morrow, Charlie Kaufman, and David Smith for their comments for the 1226 comments on the original [RFC5575]. Chaitanya Kodeboyina helped 1227 design the flow validation procedure; and Steven Lin and Jim Washburn 1228 ironed out all the details necessary to produce a working 1229 implementation in the original [RFC5575]. 1231 Additional acknowledgements for this document will be included here. 1232 The current authors would like to thank Alexander Mayrhofer and 1233 Nicolas Fevrier for their comments and review. 1235 15. References 1237 15.1. Normative References 1239 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1240 RFC 793, DOI 10.17487/RFC0793, September 1981, 1241 . 1243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1244 Requirement Levels", BCP 14, RFC 2119, 1245 DOI 10.17487/RFC2119, March 1997, 1246 . 1248 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1249 "Definition of the Differentiated Services Field (DS 1250 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1251 DOI 10.17487/RFC2474, December 1998, 1252 . 1254 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1255 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1256 DOI 10.17487/RFC4271, January 2006, 1257 . 1259 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1260 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1261 February 2006, . 1263 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1264 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1265 2006, . 1267 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1268 "Multiprotocol Extensions for BGP-4", RFC 4760, 1269 DOI 10.17487/RFC4760, January 2007, 1270 . 1272 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1273 LAN Service (VPLS) Using BGP for Auto-Discovery and 1274 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1275 . 1277 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1278 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1279 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1280 . 1282 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1283 and D. McPherson, "Dissemination of Flow Specification 1284 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1285 . 1287 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 1288 Specific BGP Extended Community", RFC 5668, 1289 DOI 10.17487/RFC5668, October 2009, 1290 . 1292 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1293 and A. Bierman, Ed., "Network Configuration Protocol 1294 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1295 . 1297 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1298 Origin Authorizations (ROAs)", RFC 6482, 1299 DOI 10.17487/RFC6482, February 2012, 1300 . 1302 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1303 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1304 March 2014, . 1306 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1307 Patel, "Revised Error Handling for BGP UPDATE Messages", 1308 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1309 . 1311 15.2. Informative References 1313 [I-D.ietf-idr-flow-spec-v6] 1314 McPherson, D., Raszuk, R., Pithawala, B., 1315 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 1316 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 1317 v6-07 (work in progress), March 2016. 1319 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1320 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1321 . 1323 Authors' Addresses 1325 Susan Hares 1326 Huawei 1327 7453 Hickory Hill 1328 Saline, MI 48176 1329 USA 1331 Email: shares@ndzh.com 1333 Robert Raszuk 1334 Bloomberg LP 1335 731 Lexington Ave 1336 New York City, NY 10022 1337 USA 1339 Email: robert@raszuk.net 1341 Danny McPherson 1342 Verisign 1343 USA 1345 Email: dmcpherson@verisign.com 1346 Christoph Loibl 1347 Next Layer Communications 1348 Mariahilfer Guertel 37/7 1349 Vienna 1150 1350 AT 1352 Phone: +43 664 1176414 1353 Email: cl@tix.at 1355 Martin Bacher 1356 T-Mobile Austria 1357 Rennweg 97-99 1358 Vienna 1030 1359 AT 1361 Email: mb.ietf@gmail.com