Internet DRAFT - draft-eddy-idr-flowspec-exp

draft-eddy-idr-flowspec-exp







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: <type (1 octet), offset (2 octets), value-len (1 octet),
      value, mask

      offset - indicates a number of leading bytes to be skipped into
      the packet section being described

      value-len - indicates the length in bytes of the following "value"
      field

      value - conveys a number of bytes to be checked at the indicated
      offset within the packet

      mask - indicates a bitmask applied to the value being checked; a 1
      bit at a given position mean that the bit value must match in the
      packet, and 0 bits mean that the value does not need to match in
      that bit position; the mask must be the same length as the value

   As an example, the components that would describe an IPv4 flow to
   address A within a GRE flow to address Pout would be:

   1.  Destination Prefix: Pout



Eddy, et al.              Expires March 3, 2016                 [Page 7]

Internet-Draft    Experimental BGP Flowspec Extensions       August 2015


   2.  IP Protocol: 47 (GRE)

   3.  Tunnel Separator, tunnel-header-length: 0 (final separator)

   4.  Offset-Value-Mask: 2 (offset 2 bytes into packet), 2 (compare
       value 2 bytes long), 4 (IPv4 protocol type), 0xFFFF (match all
       bits)

   5.  Offset-Value-Mask: 24 (offset 24 bytes into the packet --- 8
       bytes for GRE plus 16 bytes into the IPv4 header for the
       destination address), 4 (compare value 4 bytes long), A,
       0xFFFFFFFF (match all 32 bits)

   For description of nested IP and transport protocol headers, having
   several Offset-Value-Mask components is less desirable than just
   being able to use normal flowspec components on the innermost set of
   headers, however, since the length of tunnel headers is not always
   known, this may not be possible in general.  In cases where the
   length of the tunnel header is known, this can be conveyed in the
   tunnel separator component.  As an example, the previous example can
   be encoded as:

   1.  Destination Prefix: Pout

   2.  IP Protocol: 47 (GRE)

   3.  Tunnel Separator, tunnel-header-length: 8 (GRE header is 8 bytes
       long)

   4.  Offset-Value-Mask: 2 (offset 2 bytes into packet), 2 (compare
       value 2 bytes long), 4 (IPv4 protocol type), 0xFFFF (match all
       bits)

   5.  Tunnel Separator, tunnel-header-length: 0 (final separator)

   6.  Destination Prefix: A

   While a set of Offset-Value-Mask rules can be created in order to
   check multiple nested protocol layers, this can become tedious and
   error-prone.  Instead, when flowspec components can be used to
   describe an inner header, use of non-zero tunnel-header-length values
   allows constructions that are more human-intelligible than Offset-
   Value-Mask permits.

   When tunnel flow specifications are used, the validity checking
   should be applied to the outer destination prefix only (appearing
   first within the flowspec NLRI).




Eddy, et al.              Expires March 3, 2016                 [Page 8]

Internet-Draft    Experimental BGP Flowspec Extensions       August 2015


2.3.  Flowspec Identifier

   BGP update messages are not uniquely identified in any way.  If there
   is a desire to link specific updates to the events that they relate
   to, or to refer to specific updates in conversation or collaboration
   between operators, then a BGP attribute that identifies the messages
   may be useful.

   For instance, "Are you implementing the flowspec 0xA1B2C3D4 from AS
   N?" (where 0xA1B2C3D4 is a Flowspec Identifier) is likely to be an
   easier question to communicate than trying to identify it by the full
   NLRI binary string.  It should also be easier to tie unambiguously to
   particular database entries for active ACLs, attacks being tracked,
   incident management records, etc.  The same flowspec NLRI values may
   end up being reused between different incidents if they share similar
   attack signatures.

   This attribute could be unique to updates containing the flow
   specification SAFI, or might be more generally useful in other BGP
   usages, but we do not have an opinion on that.

   For flowspec messages enhanced to use BGPsec, it is possible that the
   originator's signature (or some truncation of it) could act as an
   identifier, as long as it covers some field guaranteed to change over
   time between DDoS incidents, like the timestamp discussed later.

   The value of the attribute can be set by the system generating the
   message, and might be treated as an opaque set of bytes elsewhere in
   the network.  A 32-bit value is likely to be sufficient for any AS to
   uniquely identify its flowspec messages.  This could be generated by
   the originator in a number of ways, such as via a hash function over
   some set of fields, a counter, or any other means.

   In other ASes, assumptions about the identifier value should not be
   made, such as about its uniqueness or reuse by the originating AS.
   It is a purely informational value, not intended to be computed on
   directly.

   Potential approaches for adding an identifier to BGP flowspec
   messages include:

      New Attribute - Defining a new generic Identifier or "Flowspec
      Identifier" BGP attribute is a simple approach but requires a new
      attribute to be defined, understood, and conveyed by BGP speakers.

      BGPsec Signatures - The advantage to this approach is that no new
      fields are necessary.  The disadvantage is that it assumes a new
      form of BGPsec for flowspec messages is in use.



Eddy, et al.              Expires March 3, 2016                 [Page 9]

Internet-Draft    Experimental BGP Flowspec Extensions       August 2015


      ASN+NLRI - Simply composing the originator's AS number and the
      NLRI, or hashing over those with an agreed function, is another
      option that could be used to compute "mostly unique" identifiers
      for flowspec messages, without needing to add any fields.  A
      timestamp from the BGP-TS option could be included within the
      hashed fields in order to help make the result vary when similar
      NLRI are re-used between event mitigations.

   If there is agreement that identifying flowspecs is useful, then one
   of these (or some other) mechanism can be selected later.

2.4.  Cryptographic Enhancement

   BGP by default does not include cryptographic protection, and there
   are various attacks possible on BGP flows and BGP speakers.  Misuse
   or spoofing of flow specifications by an attacker could create new
   ways to inflict abuse that is difficult for a victim to detect and
   debug.  Because significant work has gone into designing, developing,
   and beginning to deploy BGPsec, it will be highly desirable to use
   BGPsec as a means of protecting and validating flow specifications.

   Existing BGPsec signatures cover the Network Layer Reachability
   Information (NLRI) and AS numbers in BGP updates:

           +------------------------------------+
           | 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)   |  ---/
           +------------------------------------+


              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,
              <http://www.rfc-editor.org/info/rfc2119>.

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,
              <http://www.rfc-editor.org/info/rfc3882>.

   [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,
              <http://www.rfc-editor.org/info/rfc5575>.

   [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,
              <http://www.rfc-editor.org/info/rfc5635>.

   [RFC6842]  Swamy, N., Halwasia, G., and P. Jhingran, "Client
              Identifier Option in DHCP Server Replies", RFC 6842,
              DOI 10.17487/RFC6842, January 2013,
              <http://www.rfc-editor.org/info/rfc6842>.

   [RFC7153]  Rosen, E. and Y. Rekhter, "IANA Registries for BGP
              Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
              March 2014, <http://www.rfc-editor.org/info/rfc7153>.

   [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]