idnits 2.17.1 draft-eddy-idr-flowspec-exp-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 31, 2015) is 3133 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'PS15' is defined on line 866, but no explicit reference was found in the text == Unused Reference: 'SSBP15' is defined on line 892, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgp-flowspec-oid-02 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-06 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-13 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Eddy 3 Internet-Draft J. Dailey 4 Intended status: Experimental G. Clark 5 Expires: March 3, 2016 MTI Systems 6 August 31, 2015 8 Experimental BGP Flow Specification Extensions 9 draft-eddy-idr-flowspec-exp-00 11 Abstract 13 This document discusses new extensions beyond the existing BGP 14 mechanisms that support mitigation of Distributed Denial of Service 15 (DDoS) attacks. The new extensions are focused on enabling an 16 increase in collaborative inter-domain defenses involving multiple 17 network providers, and enhancing the ability to describe desired 18 filtering rules and actions. This document is primarily intended for 19 discussion, and later on some ideas contained within it may be 20 exported into other documents or specifications. In some cases, 21 simple examples and proof-of-concept protocol mechanisms are 22 described, but this document is not intended to become a standard or 23 final protocol specification. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 3, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Packet Rate Action . . . . . . . . . . . . . . . . . . . 5 63 2.2. Tunnel Description . . . . . . . . . . . . . . . . . . . 6 64 2.3. Flowspec Identifier . . . . . . . . . . . . . . . . . . . 9 65 2.4. Cryptographic Enhancement . . . . . . . . . . . . . . . . 10 66 2.5. Flow Delegation . . . . . . . . . . . . . . . . . . . . . 13 67 2.6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . 15 68 3. Other Discussion . . . . . . . . . . . . . . . . . . . . . . 16 69 3.1. Other Extensions . . . . . . . . . . . . . . . . . . . . 18 70 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 75 7.2. Informative References . . . . . . . . . . . . . . . . . 19 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 78 1. Introduction 80 There is a long history of using BGP as a means to trigger filtering 81 at upstream routers to defend against Distributed Denial of Service 82 (DDoS) attacks. Destination-based Remote Triggered Black Hole (RTBH) 83 Filtering is described in [RFC3882]. An advancement of the RTBH 84 approach that additionally supports source-based filtering relying on 85 unicast Reverse Path Forwarding (uRPF) support in routers is 86 described in [RFC5635]. 88 RTBH techniques for DDoS mitigation partly are motivated by the 89 ability to use a router's packet forwarding hardware rather than its 90 access control lists (ACL) features or other filtering mechanisms. 91 This is desirable, because on some systems, use of ACLs can 92 negatively impact performance, and operators may have a more 93 difficult time in managing ACLs in comparison to routes. The 94 downsides of RTBH techniques in comparison to alternatives like ACLs 95 are that they can be slightly complex to setup and manage (though RFC 96 5635 is a very good guidebook for this), and are limited to making 97 decisions based on source and destination address fields. 98 Additionally, RTBH mechanisms work within an attacked network or 99 within an access provider's network used by a DDoS attack victim. On 100 its own, RTBH can't directly operate further upstream closer to 101 attack sources (where filtering would be most effective). 103 The Flow Specification (flowspec) [RFC5575] extension to BGP augments 104 the information conveyed through BGP to better facilitate the use of 105 ACLs and support more complex traffic signatures than just the 106 destination and possibly source addresses that RTBH utilizes. This 107 can somewhat reduce the management burden involved with ACLs, though 108 there may still be performance impacts. Regardless, the flowspec 109 mechanism offers a powerful means of signalling undesired traffic 110 signatures upstream, where there is a possibility that packets can be 111 more effectively filtered. There are basic validation procedures 112 defined for processing messages containing flowspec entries, though 113 these do require some trust as flowspec entries are not possible to 114 cryptographically verify back to the origin AS. Presently, fielded 115 systems such as UTRS [Kristoff15] rely on heuristics, such as 116 checking for a 30-day history of originating routes, limiting to 25 117 routes at a time, and only working for IPv4 /32 routes, in order to 118 provide some level of security. 120 In this document, we provide a number of improvements to the existing 121 flowspec mechanism that may foster improved power and utility in 122 inter-domain collaboration to mitigate DDoS: 124 Packet Rate Action - The existing flowspec standard supports 125 traffic-rate limits conveyed only in bytes per second. In some 126 cases, packets per second is a more relevant metric, and this 127 document adds a packet-rate action that can be used to indicate 128 this. 130 Tunnel Support - improving the ability for a flowspec to include 131 information about both the outer and inner headers of tunneled 132 traffic, beyond the existing capability that is mainly limited to 133 the outer headers, and has ambiguous applicability in the 134 specification for description of inner headers. 136 Flowspec Identification - currently, flow specifications are self- 137 identifying, in that there is no shorter way to describe or refer 138 to them other than to copy them. When an attack is detected and a 139 response is initiated, this will often be tracked in one or more 140 systems (e.g. through trouble tickets, etc), and it may be helpful 141 when operators are coordinating responses or debugging in order to 142 be able to refer to a flowspec by a shorter ID string. 144 Cryptographic Enhancement - the ability to use the Resource Public 145 Key Infrastructure (RPKI) in order to sign BGP messages including 146 flow specifications. This supports stronger verification upstream 147 that the flowspec is genuine and current, since careless use of 148 existing flowspec messages could enable new forms of routing 149 system abuse. 151 Flow Delegation - using flowspec advertisements so that only 152 traffic matching a particular flowspec is rerouted to a scrubbing 153 center, rather than delegating entire prefixes to the scrubbing 154 center. This can reduce the load on the scrubbing center or avoid 155 performance penalties for other classes of traffic not 156 specifically associated with an attack. Combined with the 157 cryptographic authentication, the ability of scrubbing center 158 services to "hijack" routes can now also be performed more 159 securely. This may have advantages over using the flowspec 160 redirect actions. 162 Flowspec Feedback - the ability to signal back to a flowspec 163 originator that the flowspec is being honored in a particular AS, 164 and optionally to indicate properties of the filtering activity 165 (e.g. number of packets dropped within a time interval, indication 166 of the previous-hop AS, etc.). This can support a form of 167 telemetry or monitoring capability for flow specifications that 168 have been distributed across multiple cooperating networks. 170 The enhanced flowspec validation procedure described in 171 [I-D.ietf-idr-bgp-flowspec-oid] is not necessary when cryptographic 172 means can be used to validate a received flowspec. That enhanced 173 validation procedure can be applied in conjunction with the one 174 described in this document. 176 There is an IETF effort (DOTS) currently working to standardize some 177 signalling for DDoS mitigation [I-D.teague-open-threat-signaling]. 178 This could likely be used in conjunction with the BGP extensions 179 discussed in this document, but we are not attempting to address the 180 DOTS problem space or scenarios directly. 182 1.1. Requirements Language 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 2. Protocol Extensions 190 This document section contains descriptions of protocol message 191 modifications that support the additional features described in this 192 document. In some cases, it does not fully describe all the details, 193 but only a sketch of proposed path in order to generate discussion. 194 It is possible that some extensions are more favorable to the 195 community than others, and could be factored out into separate 196 specifications in order to progress as standards. 198 2.1. Packet Rate Action 200 In network equipment, it may be easier, faster, or more convenient to 201 perform accounting or decision-making based on quantities of packets 202 rather than quantities of bytes. Additionally, many attacks are 203 effective due to the number of packets per second, and not 204 necessarily due to the number of bytes per second. It is desirable 205 to be able to specify rate limits in terms of the number of packets 206 per second, and not just the number of bytes per second. 208 Traffic filtering actions pertaining to a matched flow specification 209 are indicated using BGP extended communities. Particular extended 210 community values are defined in RFC 5575 for a small number of 211 possible actions. New types of actions can be defined using 212 additional extended community values. 214 The existing type 0x8006 ("traffic-rate") extended community value 215 carries a 2-octet ID value with only informational value, and a 216 4-byte floating point value indicating the number of bytes per second 217 that traffic should be limited to. 219 We propose to allocate an additional type number (TBD assigned by 220 IANA) called "packet-rate". Similar to the traffic-rate action, this 221 will carry an informational-only ID value, followed by a 4-byte 222 floating point value indicating the number of packets per second that 223 traffic should be limited to. 225 Although a floating-point value for packets per second may seem odd 226 or unnatural compared to an integer value, the motivations for this 227 are: 229 The maximum value that a 32-bit unsigned integer could hold would 230 limit to specifying under 2.15 Gpps (2.15 billion packets per 231 second). For large or high-performance networks especially in the 232 future, this may not be sufficient. The maximum floating point 233 value is much higher (on the order of 10^38) and should be future- 234 proof. 236 The reduced precision of the floating-point limit that can be 237 specified compared to an integer encoding does not seem to be a 238 major concern. 240 This maintains consistency with the present syntax for bytes per 241 second rate limits. 243 Please note that this is a transitive community type, as explained in 244 [RFC7153] and not a non-transitive type as mentioned narratively in 245 the RFC 5575 description of the traffic-rate action. 247 2.2. Tunnel Description 249 The existing flow specification format in RFC 5575 includes a mixture 250 of both IP-layer and TCP or UDP-layer fields used to describe a flow 251 or the packet signature to be matched. However, there is no means to 252 nest or scope the flow specification values so that they can be 253 describe flows that are carried within tunnels of various types. For 254 instance, a particular TCP flow within an IP-in-IP tunnel or a 255 particular UDP flow in a GRE tunnel would not be possible to 256 describe. Only values in the "outer" headers can be conveyed, and 257 not the inner headers. 259 To solve this, we propose to add two additional component types to 260 the flowspec mechanism. The first is necessary in order to separate 261 between outer and inner components of a flow specification. This new 262 "Tunnel Separator" component can be included multiple times in order 263 to select protocol headers nested several layers deep within a 264 tunnel. The second is necessary to compare arbitrary fields and 265 values at given offsets within a packet. This "Offset-Value-Mask" 266 component permits filtering of packets containing inner protocols 267 that upstream routers do not even need to parse or support 268 themselves. 270 This new separator component will be encoded as a single type byte (1 271 octet) followed by a tunnel-header-length 2-byte unsigned integer 272 value. The flowspec components preceding a tunnel header apply to 273 outer headers, and components following the separator apply to the 274 inner nested headers. 276 The tunnel-header-length is used when there are multiple nestings, in 277 order to indicate how much of the packet is within scope of the 278 current section defined by the separator, and to be matched before 279 the next separator is processed. For the final separator in a 280 flowspec, this can be set to 0. The value 0 indicates that no 281 further separators will be present. 283 For example, to describe a TCP flow to port X inside an IPv4-in-IPv4 284 tunnel to a particular outer prefix Pout and inner prefix Pin, the 285 flowspec components list would be: 287 1. Destination Prefix: Pout 289 2. IP Protocol: 4 (IP-in-IP encapsulation) 291 3. Tunnel Separator, tunnel-header-length: 0 (final separator) 293 4. Destination Prefix: Pin 295 5. IP Protocol: 6 (TCP) 297 6. Destination Port: X 299 For IPv4 as an inner protocol, the interpretation of the nested 300 flowspec is obvious per RFC 5575. For IPv6 as an inner protocol, the 301 interpretation of the nested flowspec is also direct per 302 [I-D.ietf-idr-flow-spec-v6]. For other inner protocols, we propose a 303 generic "Offset-Value-Mask" component in order to match particular 304 bits. This could be used, for instance, to match the Protocol Type 305 field of a GRE header along with IP address and TCP port bytes within 306 the inner protocol. 308 The format for an Offset-Value-Mask component is: 310 Encoding: Secure_Path 458 +------------------------------------+ / 459 | Flags (1 octet) | ---/ 460 +------------------------------------+ 461 | Algorithm Suite Id. (1 octet) | 462 +------------------------------------+ 463 | AFI (2 octets) | ---\ 464 +------------------------------------+ \ 465 | SAFI (1 octet) | > MP_REACH_NLRI 466 +------------------------------------+ / 467 | NLRI (variable) | ---/ 468 +------------------------------------+ 470 Figure from draft-ietf-sidr-bgpsec-protocol-13 472 The existing BGPsec specification [I-D.ietf-sidr-bgpsec-protocol] 473 covers AFI values for IPv4 and IPv6, but does not place an explicit 474 restriction on the SAFI. However, BGPsec does assume that the NLRI 475 has a destination prefix field corresponding to a Route Origination 476 Authorization (ROA). This may not be true for flowspec NLRI (e.g. 477 SAFI 133 for IPv4), which are not strictly required to have a 478 destination prefix. 480 It appears to us that this is an ommission in the BGPsec checks, 481 since mostly BGPsec is targeting IPv4 and IPv6 unicast forwarding 482 only. BGPsec should only be applicable when the SAFI also matches 483 the AFI, as other SAFI values may also not meet the assumption that 484 NLRI will contain a destination prefix corresponding to a ROA. 486 Current non-BGPsec flowspec validation procedures are intended to 487 verify that the neighboring AS advertising a flowspec is the same AS 488 advertising the best unicast route for the flowspec destination. 489 However, since the destination prefix field is an optional component, 490 this may not always even be possible. In this case, it might be 491 sufficient to ensure that the flowspec only is applied to traffic 492 that would be sent through the advertising AS and subject to their 493 downstream filtering anyways. For instance, if AS X sends a flowspec 494 to AS Y indicating that all ICMP of some type will be filtered, then 495 this can only be safely applied to packets on egress from AS Y to AS 496 X, but not immediately on ingress to AS Y until the next AS hop can 497 be determined to be AS X. It might be possible to compute all 498 destination prefixes that will be routed to AS X at any time and 499 create ingress ACLs to cover only these, but that set of destination 500 prefixes may need to be recomputed continuously or cause other 501 problems (such as exceeding limitations in the number of ACLs 502 possible). 504 For these reasons (flowspec validation in general, as well as 505 potential compatibility with BGPsec), it seems highly recommended 506 that flow specifications that are intended to travel multiple AS hops 507 into the Internet should explicitly include a destination prefix. 508 For a tunnel flowspec, there must be a destination prefix in the 509 outermost portion of the specification. 511 Beyond this, to use BGPsec for flowspec protection, there is a need 512 to also include the community attributes conveying the flowspec 513 actions within the fields covered by the signature. For instance, 514 when using the IP redirection capability 515 [I-D.ietf-idr-flowspec-redirect-ip] a community attribute holds the 516 IPv4 or IPv6 addresses that packets matching the flowspec are either 517 to be forwarded or copied to. Even if BGPsec was used to cover the 518 flowspec AFI, the signatures would not cover these redirection target 519 IP addresses, and they could be altered while in transit, or changed 520 to other types of actions (e.g. rate limits, etc). 522 Additionally, since DDoS attacks are dynamic and redirection or 523 filtering of a flow may only be necessary for some short time, and be 524 undesirable at other times, it seems useful for a secure flowspec 525 message to include a timestamp as part of the data protected by a 526 signature. Otherwise a replay could be used to re-initiate filtering 527 or redirection actions that would cause performance issues or packet 528 loss. Received flowspecs could be verified to have been timestamped 529 within some window of time (e.g. several minutes or hours), and 530 discarded if they are too stale. 532 The BGP Timestamp (BGP-TS) attribute 533 [I-D.litkowski-idr-bgp-timestamp] has other purposes (e.g. 534 performance measurements), but may be possible to use for this 535 purpose. A simpler construction intended only to include a single 536 and not-necessarily high-precision timestamp would also suffice for 537 the purposes described in this document, of limiting the potential to 538 replay flowspec messages. 540 If the Flowspec Identifier is used, then it also should be included 541 within the data covered by a signature. 543 For BGPsec use with the flowspec SAFI, we propose that the signatures 544 contained in the Signature_Blocks of the BGPsec_Path attribute be 545 computed over: 547 +------------------------------------+ 548 | Target AS Number (4 octets) | 549 +------------------------------------+ 550 | Origin AS Number (4 octets) | ---\ 551 +------------------------------------+ \ 552 | pCount (1 octet) | > Secure_Path 553 +------------------------------------+ / 554 | Flags (1 octet) | ---/ 555 +------------------------------------+ 556 | Algorithm Suite Id. (1 octet) | 557 +------------------------------------+ 558 | AFI (2 octets) | ---\ 559 +------------------------------------+ \ 560 | SAFI (1 octet) | > MP_REACH_NLRI 561 +------------------------------------+ / 562 | NLRI (variable) | ---/ 563 +------------------------------------+ 564 | Flowspec Action Community | ---\ 565 +------------------------------------+ \ 566 | Timestamp | > Other BGP 567 +------------------------------------+ / Attributes 568 | Flowspec Identification | ---/ 569 +------------------------------------+ 571 Suggested Signature Coverage for BGP use with Flowspec 573 A flow specification destination address may be narrower in scope 574 than the prefix included in a ROA. For instance, a single /32 may be 575 the destination address under attack, and which redirection or 576 filtering is requested for. ROA objects contain ROAIPAddress values 577 including an optional maxLength element. If the destination address 578 field within a flowspec NLRI are considered equivalent to the NLRI of 579 the normal IPv4 and IPv6 unicast SAFIs, then validation should check 580 this against the maxLength value in relevant ROAs. This will mean 581 that ASes intending to use fairly specific flow specifications will 582 need to produce ROAs with permissive maxLength values. If maxLength 583 is not present, the normal ROA validation requires the destination 584 prefix to match exactly with the prefix indicated in the ROA. 586 2.5. Flow Delegation 588 The RPKI enables the legitimate holder of an IP prefix to authorize 589 other ASes to originate routes to that prefix. ROA objects in the 590 RPKI express this authorization. ROAs are currently defined to 591 include AS numbers and IP address blocks [RFC6842]. ROAs are not 592 able to cover other types of NLRI, such as a flow specification. 594 Some current DDoS mitigation systems involve the attack victim 595 allowing another service provider with better connectivity to hijack 596 their prefix(es), filter or scrub the traffic to reduce the volume of 597 attack packets, and re-route the clean traffic to the original 598 destination. With BGPsec in use, the victim would have to publish 599 ROAs for any service provider ASes that they utilize for traffic 600 redirection, but otherwise the practice would still function. 602 However, since this redirection works at prefix granularity rather 603 than flow-level granularity, all traffic for the victim is impacted, 604 and there may be significant performance impacts for latency and 605 jitter-sensitive flows. This is generally better than leaving the 606 attack unmitigated, but can still impact the business operations of 607 the victim. Flow-level redirection, as enabled by BGP flowspec 608 advertisements would be superior to redirecting all traffic for the 609 prefix. 611 Additionally, it may reduce the load and burden on the scrubbing 612 center's resources if a majority of the acceptable traffic never has 613 to even be redirected through it, because only questionable traffic 614 identified by a flow specification needs to be rerouted. This could 615 help this mitigation approach to scale to even larger attack volumes 616 than currently seen, even when the heuristics used to distinguish 617 good from bad packets become exceedingly complex. 619 In order to allow a scrubbing center provider to advertise flow 620 specifications rather than entire prefixes, an additional type of ROA 621 will need to be defined, containing a list of the flowspec NLRI 622 entries that they're authorized to scrub, rather than the simple IP 623 prefix list currently in a ROA. We assume that the default action 624 (of forwarding matching traffic) will be used, and so the flowspec 625 action extended communities do not need to be included in the ROA for 626 the service provider, but this should be a topic for discussion. 628 This differs from having the victim AS originate a flowspec route 629 with an IP redirect action towards the mitigation service provider. 630 First, if the victim has been knocked completely offline or if some 631 facet of a coordinated attack also impacts their BGP infrastructure, 632 that may not even be possible. Second, it may offer scrubbing center 633 providers more flexibility in how their services are implemented, by 634 not requiring them to specify a single IP address in an IP redirect 635 action. This could aid in maintaining the scalability of this type 636 of mitigation. 638 2.6. Feedback 640 Currently, BGP flowspec updates can be sent, but there is no feedback 641 explicit in order to indicate whether the flow specifications are 642 being put into action or to monitor their effectiveness. Implicitly, 643 a reduction in attack traffic volume reaching the victim may suggest 644 that the flowspec is being honored, but this can also happen simply 645 because the attack is subsiding. 647 As attacks become more prevalent, more persistent, and more advanced 648 in their tactics, signatures, and dynamics, it will be useful for 649 coordinated defense efforts to be monitored and for the attack volume 650 at different vantage points within the network to be synthesized. 652 In order to enable this, we propose to add a feedback message to BGP 653 allowing individual ASes participating in attack mitigation to 654 optionally advertise this fact, and provide basic information about 655 their status. 657 Feedback messages should include fields for: 659 1. Reporting AS 661 2. Flowspec Identification 663 3. Report Time Interval (start and end timestamps) 665 4. (optional) Ingress AS List 667 5. (optional) List of Matched Packets Counter (within the time 668 interval) 670 The Ingress AS List identifies where the attack traffic matching the 671 flowspec is coming from, which may be multiple points. This can be 672 useful in tracing back the source of an attack, especially when IP 673 addresses are spoofed, and ingress filtering has either not been 674 properly implemented or has been defeated somehow (e.g. through 675 tunneling, or other abuses). The List of Match Packet Counters can 676 convey the volume of traffic coming from each AS in the ingress AS 677 list. 679 Since some of this information may be difficult to collect and 680 synthesize, it is marked as optional. At a basic level, the feedback 681 that a flowspec is being implemented by an upstream AS is useful to 682 the victim. 684 These messages could be signed, potentially reusing certificates from 685 the RPKI, in order to avoid potential abuse of the feedback mechanism 686 and to discourage fraudelent reporting of incorrect information. 688 Due to the number of ASes on the Internet, any given AS will need to 689 be very judicious about how it generates and propagates these 690 feedback indications. For instance, there may not be a problem one 691 AS-hop away from the victim to provide these reports on 1-minute 692 intervals, but deeper into the AS graph, generating and propagating 693 the feedback could become overwhelming. When responding to 694 particular attacks, and coordinating across provider on specific 695 attacks, it could be possible to enable reporting and tweak the time 696 intervals for reporting based on a particular Flowspec Identification 697 value. 699 Other heuristics will also help to reduce the volume of feedback, 700 such as using a small reporting interval for "fresh" flowspec 701 advertisements and backing off the reporting interval over time 702 either based on the age of the flowspec or the volume of matching 703 traffic observed. There are many algorithms that can be employed to 704 keep the feedback manageable, and these do not need to be uniform 705 across ASes. The mere presence and generation of any feedback adds 706 utility not present in the existing system. 708 Since Identification values might be reused over time by the 709 originating AS (either accidentally or on purpose) this could lead to 710 ambiguity in feedback or issues in accounting by other ASes). Since 711 this is likely to lead to poor utility for the originating AS, it 712 should be highly encouraged that when ASes generate flowspec 713 messages, that they select fresh Identifiers that do not collide with 714 other values that they have recently used. In the case that another 715 AS detects an apparent collision in its systems that utilize received 716 flow specifications or account on status of implemented flow 717 specifications, then the receiving AS is free to choose any 718 reasonable action that it pleases (e.g. suspending implementation of 719 the flowspecs, suspending reporting on the flowspecs, using only the 720 most recent flowspec, etc). 722 3. Other Discussion 724 The existing RFC 5575 flowspec definition can be translated easily 725 into Access Control List (ACL) rules in order to perform hardware- 726 based filtering on many platforms. The proposal to include tunnel 727 specifications in this document may not be as easily or directly 728 transformable into ACLs across such a wide range of systems. Future 729 platforms might be more capable. 731 Some of the flowspec components are able to specify comparison 732 operators (e.g. less-than or greater-than) that can be applied to 733 packet fields. This is useful for indicating a range of port 734 numbers, for instance. The Offset-Value-Mask component specified in 735 this document only includes a bitmask to check against, so is weaker 736 than existing flowspec components for checking some fields. We 737 thought that this generic bitwise comparison would be more easily 738 supported in hardware than a more complete set of comparison 739 operators that might apply to different sized fields at different 740 packet offsets. We hope to receive more feeback from the community 741 of implementers on this topic in particular. 743 Proper BGP operation is critical to the Internet's stability and 744 changes and extensions to BGP must be carefully deployed. The new 745 mechanisms described in this document are no exception. The text in 746 RFC 5575 which added the Flow Specification NLRI to BGP is also 747 applicable here: 749 As with previous extensions to BGP, this specification makes it 750 possible to add additional information to Internet routers. These 751 are limited in terms of the maximum number of data elements they 752 can hold as well as the number of events they are able to process 753 in a given unit of time. The authors believe that, as with 754 previous extensions, service providers will be careful to keep 755 information levels below the maximum capacity of their devices. 757 Certain types of DDoS attacks are still not possible to easily 758 indicate in flowspec messages. For instance, a "crossfire" attack 759 where traffic is directed at multiple destinations that share the 760 same tight link as the actual victim can be difficult to securely 761 signal even with the extensions described in this document. Other 762 types of attacks focused on particular application properties can 763 also be difficult to capture in packet-level flowspec logic. Future 764 work might address this limitation. 766 In some cases, the victims of an attack may be reticent to have 767 knowledge or acknowledgement of the attack on them propagated. Their 768 providers may be able to mitigate attacks within their networks, but 769 forbidden from working with other providers further upstream to more 770 efficiently mitigate the attack. This makes it very challenging to 771 apply collaborative defenses to aid these types of attack victims. 772 Future work is possible that considers this and whether there are 773 improvements to the flowspec construction that would support dealing 774 with these situations. 776 3.1. Other Extensions 778 IP options currently defy description within a flow specification, 779 and further complicate the parsing and processing of transport 780 headers in general and inner protocols in the case of tunnels. Other 781 future work may be possible in order to better deal with this. 783 4. Acknowledgements 785 Work on some of the material discussed in this document was sponsored 786 by the United States Department of Homeland Security (contract 787 HSHQDC-15-C-00017), but it does not necessarily reflect the position 788 or the policy of the Government and no official endorsement should be 789 inferred. Support and feedback from Dan Massey was helpful in 790 formulating ideas in this document. 792 5. IANA Considerations 794 If accepted for publication, IANA will need to allocate a BGP 795 extended community value for the packet-rate action from the "Generic 796 Transitive Experimental Use Extended Community Sub-Types" registry. 798 6. Security Considerations 800 This document provides enhanced capabilities to defend against DDoS 801 attacks. In doing so, there is an intent to not add any additional 802 vulnerabilities that could be exploited. 804 Because the mechanisms described in this document are conveyed over 805 BGP, they are subject to the risks posed by the underlying BGP 806 connection's configuration and its ability to implement security 807 features. 809 The extensions described in this document are not intended to reduce 810 the security properties of the BGP flowspec mechanism originally 811 defined in RFC 5575. By offering a means of cryptographic protection 812 for authenticating flowspec messages, it should provide an 813 improvement over the security properties of the basic RFC 5575 814 signalling. There is a dependancy on use of the RPKI in order to 815 obtain this improvement. 817 7. References 819 7.1. Normative References 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, 823 DOI 10.17487/RFC2119, March 1997, 824 . 826 7.2. Informative References 828 [I-D.ietf-idr-bgp-flowspec-oid] 829 Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. 830 Mohapatra, "Revised Validation Procedure for BGP Flow 831 Specifications", draft-ietf-idr-bgp-flowspec-oid-02 (work 832 in progress), January 2014. 834 [I-D.ietf-idr-flow-spec-v6] 835 Raszuk, R., Pithawala, B., McPherson, D., and A. Andy, 836 "Dissemination of Flow Specification Rules for IPv6", 837 draft-ietf-idr-flow-spec-v6-06 (work in progress), 838 November 2014. 840 [I-D.ietf-idr-flowspec-redirect-ip] 841 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 842 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 843 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 844 in progress), February 2015. 846 [I-D.ietf-sidr-bgpsec-protocol] 847 Lepinski, M., "BGPsec Protocol Specification", draft-ietf- 848 sidr-bgpsec-protocol-13 (work in progress), July 2015. 850 [I-D.litkowski-idr-bgp-timestamp] 851 Litkowski, S., Patel, K., and J. Haas, "Timestamp support 852 for BGP paths", draft-litkowski-idr-bgp-timestamp-02 (work 853 in progress), March 2015. 855 [I-D.teague-open-threat-signaling] 856 Teague, N., "Open Threat Signaling using RPC API over 857 HTTPS and IPFIX", draft-teague-open-threat-signaling-01 858 (work in progress), July 2015. 860 [Kristoff15] 861 Kristoff, J., "An Internet-wide BGP RTBH Service", April 862 2015. 864 2015 IAB CARIS workshop 866 [PS15] Pinkerton, S. and C. Strasburg, "Coordinating Attack 867 Response at Internet Scale", April 2015. 869 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 870 Attacks", RFC 3882, DOI 10.17487/RFC3882, September 2004, 871 . 873 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 874 and D. McPherson, "Dissemination of Flow Specification 875 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 876 . 878 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 879 Filtering with Unicast Reverse Path Forwarding (uRPF)", 880 RFC 5635, DOI 10.17487/RFC5635, August 2009, 881 . 883 [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client 884 Identifier Option in DHCP Server Replies", RFC 6842, 885 DOI 10.17487/RFC6842, January 2013, 886 . 888 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 889 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 890 March 2014, . 892 [SSBP15] Steinberger, J., Sperotto, A., Baier, H., and A. Pras, 893 "Exchanging Security Events of flow-based Intrusion 894 Detection Systems at Internet Scale", April 2015. 896 2015 IAB CARIS workshop 898 Authors' Addresses 900 Wesley Eddy 901 MTI Systems 903 Email: wes@mti-systems.com 905 Justin Dailey 906 MTI Systems 908 Email: justin@mti-systems.com 910 Gilbert Clark 911 MTI Systems 913 Email: gclark@mti-systems.com