Internet Engineering Task Force W. Eddy Internet-Draft J. Dailey Intended status: Experimental G. Clark Expires: March 3, 2016 MTI Systems August 31, 2015 Experimental BGP Flow Specification Extensions draft-eddy-idr-flowspec-exp-00 Abstract This document discusses new extensions beyond the existing BGP mechanisms that support mitigation of Distributed Denial of Service (DDoS) attacks. The new extensions are focused on enabling an increase in collaborative inter-domain defenses involving multiple network providers, and enhancing the ability to describe desired filtering rules and actions. This document is primarily intended for discussion, and later on some ideas contained within it may be exported into other documents or specifications. In some cases, simple examples and proof-of-concept protocol mechanisms are described, but this document is not intended to become a standard or final protocol specification. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 3, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Eddy, et al. Expires March 3, 2016 [Page 1] Internet-Draft Experimental BGP Flowspec Extensions August 2015 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 2.1. Packet Rate Action . . . . . . . . . . . . . . . . . . . 5 2.2. Tunnel Description . . . . . . . . . . . . . . . . . . . 6 2.3. Flowspec Identifier . . . . . . . . . . . . . . . . . . . 9 2.4. Cryptographic Enhancement . . . . . . . . . . . . . . . . 10 2.5. Flow Delegation . . . . . . . . . . . . . . . . . . . . . 13 2.6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Other Discussion . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Other Extensions . . . . . . . . . . . . . . . . . . . . 18 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction There is a long history of using BGP as a means to trigger filtering at upstream routers to defend against Distributed Denial of Service (DDoS) attacks. Destination-based Remote Triggered Black Hole (RTBH) Filtering is described in [RFC3882]. An advancement of the RTBH approach that additionally supports source-based filtering relying on unicast Reverse Path Forwarding (uRPF) support in routers is described in [RFC5635]. RTBH techniques for DDoS mitigation partly are motivated by the ability to use a router's packet forwarding hardware rather than its access control lists (ACL) features or other filtering mechanisms. This is desirable, because on some systems, use of ACLs can negatively impact performance, and operators may have a more difficult time in managing ACLs in comparison to routes. The downsides of RTBH techniques in comparison to alternatives like ACLs are that they can be slightly complex to setup and manage (though RFC 5635 is a very good guidebook for this), and are limited to making Eddy, et al. Expires March 3, 2016 [Page 2] Internet-Draft Experimental BGP Flowspec Extensions August 2015 decisions based on source and destination address fields. Additionally, RTBH mechanisms work within an attacked network or within an access provider's network used by a DDoS attack victim. On its own, RTBH can't directly operate further upstream closer to attack sources (where filtering would be most effective). The Flow Specification (flowspec) [RFC5575] extension to BGP augments the information conveyed through BGP to better facilitate the use of ACLs and support more complex traffic signatures than just the destination and possibly source addresses that RTBH utilizes. This can somewhat reduce the management burden involved with ACLs, though there may still be performance impacts. Regardless, the flowspec mechanism offers a powerful means of signalling undesired traffic signatures upstream, where there is a possibility that packets can be more effectively filtered. There are basic validation procedures defined for processing messages containing flowspec entries, though these do require some trust as flowspec entries are not possible to cryptographically verify back to the origin AS. Presently, fielded systems such as UTRS [Kristoff15] rely on heuristics, such as checking for a 30-day history of originating routes, limiting to 25 routes at a time, and only working for IPv4 /32 routes, in order to provide some level of security. In this document, we provide a number of improvements to the existing flowspec mechanism that may foster improved power and utility in inter-domain collaboration to mitigate DDoS: Packet Rate Action - The existing flowspec standard supports traffic-rate limits conveyed only in bytes per second. In some cases, packets per second is a more relevant metric, and this document adds a packet-rate action that can be used to indicate this. Tunnel Support - improving the ability for a flowspec to include information about both the outer and inner headers of tunneled traffic, beyond the existing capability that is mainly limited to the outer headers, and has ambiguous applicability in the specification for description of inner headers. Flowspec Identification - currently, flow specifications are self- identifying, in that there is no shorter way to describe or refer to them other than to copy them. When an attack is detected and a response is initiated, this will often be tracked in one or more systems (e.g. through trouble tickets, etc), and it may be helpful when operators are coordinating responses or debugging in order to be able to refer to a flowspec by a shorter ID string. Eddy, et al. Expires March 3, 2016 [Page 3] Internet-Draft Experimental BGP Flowspec Extensions August 2015 Cryptographic Enhancement - the ability to use the Resource Public Key Infrastructure (RPKI) in order to sign BGP messages including flow specifications. This supports stronger verification upstream that the flowspec is genuine and current, since careless use of existing flowspec messages could enable new forms of routing system abuse. Flow Delegation - using flowspec advertisements so that only traffic matching a particular flowspec is rerouted to a scrubbing center, rather than delegating entire prefixes to the scrubbing center. This can reduce the load on the scrubbing center or avoid performance penalties for other classes of traffic not specifically associated with an attack. Combined with the cryptographic authentication, the ability of scrubbing center services to "hijack" routes can now also be performed more securely. This may have advantages over using the flowspec redirect actions. Flowspec Feedback - the ability to signal back to a flowspec originator that the flowspec is being honored in a particular AS, and optionally to indicate properties of the filtering activity (e.g. number of packets dropped within a time interval, indication of the previous-hop AS, etc.). This can support a form of telemetry or monitoring capability for flow specifications that have been distributed across multiple cooperating networks. The enhanced flowspec validation procedure described in [I-D.ietf-idr-bgp-flowspec-oid] is not necessary when cryptographic means can be used to validate a received flowspec. That enhanced validation procedure can be applied in conjunction with the one described in this document. There is an IETF effort (DOTS) currently working to standardize some signalling for DDoS mitigation [I-D.teague-open-threat-signaling]. This could likely be used in conjunction with the BGP extensions discussed in this document, but we are not attempting to address the DOTS problem space or scenarios directly. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Eddy, et al. Expires March 3, 2016 [Page 4] Internet-Draft Experimental BGP Flowspec Extensions August 2015 2. Protocol Extensions This document section contains descriptions of protocol message modifications that support the additional features described in this document. In some cases, it does not fully describe all the details, but only a sketch of proposed path in order to generate discussion. It is possible that some extensions are more favorable to the community than others, and could be factored out into separate specifications in order to progress as standards. 2.1. Packet Rate Action In network equipment, it may be easier, faster, or more convenient to perform accounting or decision-making based on quantities of packets rather than quantities of bytes. Additionally, many attacks are effective due to the number of packets per second, and not necessarily due to the number of bytes per second. It is desirable to be able to specify rate limits in terms of the number of packets per second, and not just the number of bytes per second. Traffic filtering actions pertaining to a matched flow specification are indicated using BGP extended communities. Particular extended community values are defined in RFC 5575 for a small number of possible actions. New types of actions can be defined using additional extended community values. The existing type 0x8006 ("traffic-rate") extended community value carries a 2-octet ID value with only informational value, and a 4-byte floating point value indicating the number of bytes per second that traffic should be limited to. We propose to allocate an additional type number (TBD assigned by IANA) called "packet-rate". Similar to the traffic-rate action, this will carry an informational-only ID value, followed by a 4-byte floating point value indicating the number of packets per second that traffic should be limited to. Although a floating-point value for packets per second may seem odd or unnatural compared to an integer value, the motivations for this are: The maximum value that a 32-bit unsigned integer could hold would limit to specifying under 2.15 Gpps (2.15 billion packets per second). For large or high-performance networks especially in the future, this may not be sufficient. The maximum floating point value is much higher (on the order of 10^38) and should be future- proof. Eddy, et al. Expires March 3, 2016 [Page 5] Internet-Draft Experimental BGP Flowspec Extensions August 2015 The reduced precision of the floating-point limit that can be specified compared to an integer encoding does not seem to be a major concern. This maintains consistency with the present syntax for bytes per second rate limits. Please note that this is a transitive community type, as explained in [RFC7153] and not a non-transitive type as mentioned narratively in the RFC 5575 description of the traffic-rate action. 2.2. Tunnel Description The existing flow specification format in RFC 5575 includes a mixture of both IP-layer and TCP or UDP-layer fields used to describe a flow or the packet signature to be matched. However, there is no means to nest or scope the flow specification values so that they can be describe flows that are carried within tunnels of various types. For instance, a particular TCP flow within an IP-in-IP tunnel or a particular UDP flow in a GRE tunnel would not be possible to describe. Only values in the "outer" headers can be conveyed, and not the inner headers. To solve this, we propose to add two additional component types to the flowspec mechanism. The first is necessary in order to separate between outer and inner components of a flow specification. This new "Tunnel Separator" component can be included multiple times in order to select protocol headers nested several layers deep within a tunnel. The second is necessary to compare arbitrary fields and values at given offsets within a packet. This "Offset-Value-Mask" component permits filtering of packets containing inner protocols that upstream routers do not even need to parse or support themselves. This new separator component will be encoded as a single type byte (1 octet) followed by a tunnel-header-length 2-byte unsigned integer value. The flowspec components preceding a tunnel header apply to outer headers, and components following the separator apply to the inner nested headers. The tunnel-header-length is used when there are multiple nestings, in order to indicate how much of the packet is within scope of the current section defined by the separator, and to be matched before the next separator is processed. For the final separator in a flowspec, this can be set to 0. The value 0 indicates that no further separators will be present. Eddy, et al. Expires March 3, 2016 [Page 6] Internet-Draft Experimental BGP Flowspec Extensions August 2015 For example, to describe a TCP flow to port X inside an IPv4-in-IPv4 tunnel to a particular outer prefix Pout and inner prefix Pin, the flowspec components list would be: 1. Destination Prefix: Pout 2. IP Protocol: 4 (IP-in-IP encapsulation) 3. Tunnel Separator, tunnel-header-length: 0 (final separator) 4. Destination Prefix: Pin 5. IP Protocol: 6 (TCP) 6. Destination Port: X For IPv4 as an inner protocol, the interpretation of the nested flowspec is obvious per RFC 5575. For IPv6 as an inner protocol, the interpretation of the nested flowspec is also direct per [I-D.ietf-idr-flow-spec-v6]. For other inner protocols, we propose a generic "Offset-Value-Mask" component in order to match particular bits. This could be used, for instance, to match the Protocol Type field of a GRE header along with IP address and TCP port bytes within the inner protocol. The format for an Offset-Value-Mask component is: Encoding: Secure_Path +------------------------------------+ / | Flags (1 octet) | ---/ +------------------------------------+ | Algorithm Suite Id. (1 octet) | +------------------------------------+ | AFI (2 octets) | ---\ +------------------------------------+ \ | SAFI (1 octet) | > MP_REACH_NLRI +------------------------------------+ / | NLRI (variable) | ---/ +------------------------------------+ Figure from draft-ietf-sidr-bgpsec-protocol-13 The existing BGPsec specification [I-D.ietf-sidr-bgpsec-protocol] covers AFI values for IPv4 and IPv6, but does not place an explicit restriction on the SAFI. However, BGPsec does assume that the NLRI Eddy, et al. Expires March 3, 2016 [Page 10] Internet-Draft Experimental BGP Flowspec Extensions August 2015 has a destination prefix field corresponding to a Route Origination Authorization (ROA). This may not be true for flowspec NLRI (e.g. SAFI 133 for IPv4), which are not strictly required to have a destination prefix. It appears to us that this is an ommission in the BGPsec checks, since mostly BGPsec is targeting IPv4 and IPv6 unicast forwarding only. BGPsec should only be applicable when the SAFI also matches the AFI, as other SAFI values may also not meet the assumption that NLRI will contain a destination prefix corresponding to a ROA. Current non-BGPsec flowspec validation procedures are intended to verify that the neighboring AS advertising a flowspec is the same AS advertising the best unicast route for the flowspec destination. However, since the destination prefix field is an optional component, this may not always even be possible. In this case, it might be sufficient to ensure that the flowspec only is applied to traffic that would be sent through the advertising AS and subject to their downstream filtering anyways. For instance, if AS X sends a flowspec to AS Y indicating that all ICMP of some type will be filtered, then this can only be safely applied to packets on egress from AS Y to AS X, but not immediately on ingress to AS Y until the next AS hop can be determined to be AS X. It might be possible to compute all destination prefixes that will be routed to AS X at any time and create ingress ACLs to cover only these, but that set of destination prefixes may need to be recomputed continuously or cause other problems (such as exceeding limitations in the number of ACLs possible). For these reasons (flowspec validation in general, as well as potential compatibility with BGPsec), it seems highly recommended that flow specifications that are intended to travel multiple AS hops into the Internet should explicitly include a destination prefix. For a tunnel flowspec, there must be a destination prefix in the outermost portion of the specification. Beyond this, to use BGPsec for flowspec protection, there is a need to also include the community attributes conveying the flowspec actions within the fields covered by the signature. For instance, when using the IP redirection capability [I-D.ietf-idr-flowspec-redirect-ip] a community attribute holds the IPv4 or IPv6 addresses that packets matching the flowspec are either to be forwarded or copied to. Even if BGPsec was used to cover the flowspec AFI, the signatures would not cover these redirection target IP addresses, and they could be altered while in transit, or changed to other types of actions (e.g. rate limits, etc). Eddy, et al. Expires March 3, 2016 [Page 11] Internet-Draft Experimental BGP Flowspec Extensions August 2015 Additionally, since DDoS attacks are dynamic and redirection or filtering of a flow may only be necessary for some short time, and be undesirable at other times, it seems useful for a secure flowspec message to include a timestamp as part of the data protected by a signature. Otherwise a replay could be used to re-initiate filtering or redirection actions that would cause performance issues or packet loss. Received flowspecs could be verified to have been timestamped within some window of time (e.g. several minutes or hours), and discarded if they are too stale. The BGP Timestamp (BGP-TS) attribute [I-D.litkowski-idr-bgp-timestamp] has other purposes (e.g. performance measurements), but may be possible to use for this purpose. A simpler construction intended only to include a single and not-necessarily high-precision timestamp would also suffice for the purposes described in this document, of limiting the potential to replay flowspec messages. If the Flowspec Identifier is used, then it also should be included within the data covered by a signature. For BGPsec use with the flowspec SAFI, we propose that the signatures contained in the Signature_Blocks of the BGPsec_Path attribute be computed over: Eddy, et al. Expires March 3, 2016 [Page 12] Internet-Draft Experimental BGP Flowspec Extensions August 2015 +------------------------------------+ | Target AS Number (4 octets) | +------------------------------------+ | Origin AS Number (4 octets) | ---\ +------------------------------------+ \ | pCount (1 octet) | > Secure_Path +------------------------------------+ / | Flags (1 octet) | ---/ +------------------------------------+ | Algorithm Suite Id. (1 octet) | +------------------------------------+ | AFI (2 octets) | ---\ +------------------------------------+ \ | SAFI (1 octet) | > MP_REACH_NLRI +------------------------------------+ / | NLRI (variable) | ---/ +------------------------------------+ | Flowspec Action Community | ---\ +------------------------------------+ \ | Timestamp | > Other BGP +------------------------------------+ / Attributes | Flowspec Identification | ---/ +------------------------------------+ Suggested Signature Coverage for BGP use with Flowspec A flow specification destination address may be narrower in scope than the prefix included in a ROA. For instance, a single /32 may be the destination address under attack, and which redirection or filtering is requested for. ROA objects contain ROAIPAddress values including an optional maxLength element. If the destination address field within a flowspec NLRI are considered equivalent to the NLRI of the normal IPv4 and IPv6 unicast SAFIs, then validation should check this against the maxLength value in relevant ROAs. This will mean that ASes intending to use fairly specific flow specifications will need to produce ROAs with permissive maxLength values. If maxLength is not present, the normal ROA validation requires the destination prefix to match exactly with the prefix indicated in the ROA. 2.5. Flow Delegation The RPKI enables the legitimate holder of an IP prefix to authorize other ASes to originate routes to that prefix. ROA objects in the RPKI express this authorization. ROAs are currently defined to include AS numbers and IP address blocks [RFC6842]. ROAs are not able to cover other types of NLRI, such as a flow specification. Eddy, et al. Expires March 3, 2016 [Page 13] Internet-Draft Experimental BGP Flowspec Extensions August 2015 Some current DDoS mitigation systems involve the attack victim allowing another service provider with better connectivity to hijack their prefix(es), filter or scrub the traffic to reduce the volume of attack packets, and re-route the clean traffic to the original destination. With BGPsec in use, the victim would have to publish ROAs for any service provider ASes that they utilize for traffic redirection, but otherwise the practice would still function. However, since this redirection works at prefix granularity rather than flow-level granularity, all traffic for the victim is impacted, and there may be significant performance impacts for latency and jitter-sensitive flows. This is generally better than leaving the attack unmitigated, but can still impact the business operations of the victim. Flow-level redirection, as enabled by BGP flowspec advertisements would be superior to redirecting all traffic for the prefix. Additionally, it may reduce the load and burden on the scrubbing center's resources if a majority of the acceptable traffic never has to even be redirected through it, because only questionable traffic identified by a flow specification needs to be rerouted. This could help this mitigation approach to scale to even larger attack volumes than currently seen, even when the heuristics used to distinguish good from bad packets become exceedingly complex. In order to allow a scrubbing center provider to advertise flow specifications rather than entire prefixes, an additional type of ROA will need to be defined, containing a list of the flowspec NLRI entries that they're authorized to scrub, rather than the simple IP prefix list currently in a ROA. We assume that the default action (of forwarding matching traffic) will be used, and so the flowspec action extended communities do not need to be included in the ROA for the service provider, but this should be a topic for discussion. This differs from having the victim AS originate a flowspec route with an IP redirect action towards the mitigation service provider. First, if the victim has been knocked completely offline or if some facet of a coordinated attack also impacts their BGP infrastructure, that may not even be possible. Second, it may offer scrubbing center providers more flexibility in how their services are implemented, by not requiring them to specify a single IP address in an IP redirect action. This could aid in maintaining the scalability of this type of mitigation. Eddy, et al. Expires March 3, 2016 [Page 14] Internet-Draft Experimental BGP Flowspec Extensions August 2015 2.6. Feedback Currently, BGP flowspec updates can be sent, but there is no feedback explicit in order to indicate whether the flow specifications are being put into action or to monitor their effectiveness. Implicitly, a reduction in attack traffic volume reaching the victim may suggest that the flowspec is being honored, but this can also happen simply because the attack is subsiding. As attacks become more prevalent, more persistent, and more advanced in their tactics, signatures, and dynamics, it will be useful for coordinated defense efforts to be monitored and for the attack volume at different vantage points within the network to be synthesized. In order to enable this, we propose to add a feedback message to BGP allowing individual ASes participating in attack mitigation to optionally advertise this fact, and provide basic information about their status. Feedback messages should include fields for: 1. Reporting AS 2. Flowspec Identification 3. Report Time Interval (start and end timestamps) 4. (optional) Ingress AS List 5. (optional) List of Matched Packets Counter (within the time interval) The Ingress AS List identifies where the attack traffic matching the flowspec is coming from, which may be multiple points. This can be useful in tracing back the source of an attack, especially when IP addresses are spoofed, and ingress filtering has either not been properly implemented or has been defeated somehow (e.g. through tunneling, or other abuses). The List of Match Packet Counters can convey the volume of traffic coming from each AS in the ingress AS list. Since some of this information may be difficult to collect and synthesize, it is marked as optional. At a basic level, the feedback that a flowspec is being implemented by an upstream AS is useful to the victim. Eddy, et al. Expires March 3, 2016 [Page 15] Internet-Draft Experimental BGP Flowspec Extensions August 2015 These messages could be signed, potentially reusing certificates from the RPKI, in order to avoid potential abuse of the feedback mechanism and to discourage fraudelent reporting of incorrect information. Due to the number of ASes on the Internet, any given AS will need to be very judicious about how it generates and propagates these feedback indications. For instance, there may not be a problem one AS-hop away from the victim to provide these reports on 1-minute intervals, but deeper into the AS graph, generating and propagating the feedback could become overwhelming. When responding to particular attacks, and coordinating across provider on specific attacks, it could be possible to enable reporting and tweak the time intervals for reporting based on a particular Flowspec Identification value. Other heuristics will also help to reduce the volume of feedback, such as using a small reporting interval for "fresh" flowspec advertisements and backing off the reporting interval over time either based on the age of the flowspec or the volume of matching traffic observed. There are many algorithms that can be employed to keep the feedback manageable, and these do not need to be uniform across ASes. The mere presence and generation of any feedback adds utility not present in the existing system. Since Identification values might be reused over time by the originating AS (either accidentally or on purpose) this could lead to ambiguity in feedback or issues in accounting by other ASes). Since this is likely to lead to poor utility for the originating AS, it should be highly encouraged that when ASes generate flowspec messages, that they select fresh Identifiers that do not collide with other values that they have recently used. In the case that another AS detects an apparent collision in its systems that utilize received flow specifications or account on status of implemented flow specifications, then the receiving AS is free to choose any reasonable action that it pleases (e.g. suspending implementation of the flowspecs, suspending reporting on the flowspecs, using only the most recent flowspec, etc). 3. Other Discussion The existing RFC 5575 flowspec definition can be translated easily into Access Control List (ACL) rules in order to perform hardware- based filtering on many platforms. The proposal to include tunnel specifications in this document may not be as easily or directly transformable into ACLs across such a wide range of systems. Future platforms might be more capable. Eddy, et al. Expires March 3, 2016 [Page 16] Internet-Draft Experimental BGP Flowspec Extensions August 2015 Some of the flowspec components are able to specify comparison operators (e.g. less-than or greater-than) that can be applied to packet fields. This is useful for indicating a range of port numbers, for instance. The Offset-Value-Mask component specified in this document only includes a bitmask to check against, so is weaker than existing flowspec components for checking some fields. We thought that this generic bitwise comparison would be more easily supported in hardware than a more complete set of comparison operators that might apply to different sized fields at different packet offsets. We hope to receive more feeback from the community of implementers on this topic in particular. Proper BGP operation is critical to the Internet's stability and changes and extensions to BGP must be carefully deployed. The new mechanisms described in this document are no exception. The text in RFC 5575 which added the Flow Specification NLRI to BGP is also applicable here: As with previous extensions to BGP, this specification makes it possible to add additional information to Internet routers. These are limited in terms of the maximum number of data elements they can hold as well as the number of events they are able to process in a given unit of time. The authors believe that, as with previous extensions, service providers will be careful to keep information levels below the maximum capacity of their devices. Certain types of DDoS attacks are still not possible to easily indicate in flowspec messages. For instance, a "crossfire" attack where traffic is directed at multiple destinations that share the same tight link as the actual victim can be difficult to securely signal even with the extensions described in this document. Other types of attacks focused on particular application properties can also be difficult to capture in packet-level flowspec logic. Future work might address this limitation. In some cases, the victims of an attack may be reticent to have knowledge or acknowledgement of the attack on them propagated. Their providers may be able to mitigate attacks within their networks, but forbidden from working with other providers further upstream to more efficiently mitigate the attack. This makes it very challenging to apply collaborative defenses to aid these types of attack victims. Future work is possible that considers this and whether there are improvements to the flowspec construction that would support dealing with these situations. Eddy, et al. Expires March 3, 2016 [Page 17] Internet-Draft Experimental BGP Flowspec Extensions August 2015 3.1. Other Extensions IP options currently defy description within a flow specification, and further complicate the parsing and processing of transport headers in general and inner protocols in the case of tunnels. Other future work may be possible in order to better deal with this. 4. Acknowledgements Work on some of the material discussed in this document was sponsored by the United States Department of Homeland Security (contract HSHQDC-15-C-00017), but it does not necessarily reflect the position or the policy of the Government and no official endorsement should be inferred. Support and feedback from Dan Massey was helpful in formulating ideas in this document. 5. IANA Considerations If accepted for publication, IANA will need to allocate a BGP extended community value for the packet-rate action from the "Generic Transitive Experimental Use Extended Community Sub-Types" registry. 6. Security Considerations This document provides enhanced capabilities to defend against DDoS attacks. In doing so, there is an intent to not add any additional vulnerabilities that could be exploited. Because the mechanisms described in this document are conveyed over BGP, they are subject to the risks posed by the underlying BGP connection's configuration and its ability to implement security features. The extensions described in this document are not intended to reduce the security properties of the BGP flowspec mechanism originally defined in RFC 5575. By offering a means of cryptographic protection for authenticating flowspec messages, it should provide an improvement over the security properties of the basic RFC 5575 signalling. There is a dependancy on use of the RPKI in order to obtain this improvement. 7. References 7.1. Normative References Eddy, et al. Expires March 3, 2016 [Page 18] Internet-Draft Experimental BGP Flowspec Extensions August 2015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [I-D.ietf-idr-bgp-flowspec-oid] Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", draft-ietf-idr-bgp-flowspec-oid-02 (work in progress), January 2014. [I-D.ietf-idr-flow-spec-v6] Raszuk, R., Pithawala, B., McPherson, D., and A. Andy, "Dissemination of Flow Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6-06 (work in progress), November 2014. [I-D.ietf-idr-flowspec-redirect-ip] Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work in progress), February 2015. [I-D.ietf-sidr-bgpsec-protocol] Lepinski, M., "BGPsec Protocol Specification", draft-ietf- sidr-bgpsec-protocol-13 (work in progress), July 2015. [I-D.litkowski-idr-bgp-timestamp] Litkowski, S., Patel, K., and J. Haas, "Timestamp support for BGP paths", draft-litkowski-idr-bgp-timestamp-02 (work in progress), March 2015. [I-D.teague-open-threat-signaling] Teague, N., "Open Threat Signaling using RPC API over HTTPS and IPFIX", draft-teague-open-threat-signaling-01 (work in progress), July 2015. [Kristoff15] Kristoff, J., "An Internet-wide BGP RTBH Service", April 2015. 2015 IAB CARIS workshop [PS15] Pinkerton, S. and C. Strasburg, "Coordinating Attack Response at Internet Scale", April 2015. Eddy, et al. Expires March 3, 2016 [Page 19] Internet-Draft Experimental BGP Flowspec Extensions August 2015 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, DOI 10.17487/RFC3882, September 2004, . [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, August 2009, . [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client Identifier Option in DHCP Server Replies", RFC 6842, DOI 10.17487/RFC6842, January 2013, . [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, . [SSBP15] Steinberger, J., Sperotto, A., Baier, H., and A. Pras, "Exchanging Security Events of flow-based Intrusion Detection Systems at Internet Scale", April 2015. 2015 IAB CARIS workshop Authors' Addresses Wesley Eddy MTI Systems Email: wes@mti-systems.com Justin Dailey MTI Systems Email: justin@mti-systems.com Gilbert Clark MTI Systems Email: gclark@mti-systems.com Eddy, et al. Expires March 3, 2016 [Page 20]