[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Inter-Domain Routing                                            H. Green
Internet-Draft                                                 E. Zimmer
Intended status: Standards Track         Blue Ridge Envisioneering, Inc.
Expires: April 10, 2016                                  October 8, 2015


                         DDoS-Alert Extensions
                       draft-green-idr-ddosae-00

Abstract

   This document defines extensions to BGP-4 to enable the exchange of
   information about detected malicious traffic (e.g., Distributed
   Denial of Service Attacks) and provide options for coordinated,
   collaborative responses to mitigate such traffic.  The extensions are
   backward compatible - a BGP speaker that supports the extensions can
   interoperate with speakers that do not support the extensions.

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 April 10, 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
   (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




Green & Zimmer           Expires April 10, 2016                 [Page 1]


Internet-Draft                   DDoS-AE                    October 2015


   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 . . . . . . . . . . . . . . . . . .   3
   2.  DDoS-AE Alert Attribute - DDOSAE_ALERT (Type Code TBD1) . . .   4
     2.1.  Attribute Field Definitions . . . . . . . . . . . . . . .   4
     2.2.  Traffic Descriptor Types  . . . . . . . . . . . . . . . .   6
     2.3.  Compare Triplet Encoding  . . . . . . . . . . . . . . . .   9
     2.4.  Offset Compare Quadlet Encoding . . . . . . . . . . . . .  10
     2.5.  Compare Operator Definitions  . . . . . . . . . . . . . .  10
   3.  Alert Processing  . . . . . . . . . . . . . . . . . . . . . .  11
     3.1.  Alert Generation/Updating . . . . . . . . . . . . . . . .  11
     3.2.  Alert Distribution  . . . . . . . . . . . . . . . . . . .  12
     3.3.  Alert Aggregation . . . . . . . . . . . . . . . . . . . .  12
     3.4.  Alert Removal . . . . . . . . . . . . . . . . . . . . . .  13
   4.  BGP Capability Advertisement  . . . . . . . . . . . . . . . .  13
   5.  Alert Refresh . . . . . . . . . . . . . . . . . . . . . . . .  13
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Distributed Denial of Service (DDoS) attacks pose a significant risk
   to network operations.  Mitigating these attacks requires a
   coordinated response, as many systems do not have the capacity to
   work through a large scale attack.  BGP enabled devices are also
   likely to have the ability to filter and/or throttle traffic; they
   are also widely distributed throughout networks, making them ideal
   for mitigating DDoS attacks.

   DDoS-AE provides an open, vendor agnostic, mechanism to enable
   network devices to rapidly disseminate information about detected
   attacks; thereby, enabling a distributed response to mitigate the
   detected attacks.  A key advantage of DDoS-AE over other solutions
   [RFC5575] is that the DDoS Alert messages can traverse over BGP
   speakers that do not directly support the extension, allowing greater
   dissemination of information about ongoing network attacks.  An
   optional feature in the DDoS-AE system is interfacing to a Central
   Service (CS) for bridging the gap between DDoS-AE BGP speakers that
   are not connected, and to receive tailored DDoS response cues to
   improve coordination and efficacy of the response to the detected
   attacks.



Green & Zimmer           Expires April 10, 2016                 [Page 2]


Internet-Draft                   DDoS-AE                    October 2015


   Participants in the DDoS-AE system do not have to implement traffic
   filtering or DDoS detection mechanisms to still benefit and
   contribute to the overall system.  For example, if a device or policy
   limits the ability to perform filtering and/or throttling of
   identified malicious traffic, the device could still generate alert
   messages when it detects new attack traffic.  Similarly, if a device
   does not have the capability to inspect traffic and detect attacks,
   it could still receive alerts and implement traffic policies to
   mitigate the reported attacks.  Finally, if all a device does is
   forward the DDoS-AE alerts between DDoS-AE participants it still
   improves the ability of the system as a whole to detect and mitigate
   attacks.

   Because some attacks may attempt various techniques for concealment
   in legitimate traffic, more advanced and complex descriptions/
   signatures of the traffic may be required to ensure minimal impact to
   legitimate traffic.  In these more complex cases, the DDoS-AE system
   offers the option to report detailed signatures through the web-based
   Central Service (CS), which will then coordinate responses with
   participants using a more rich set of traffic descriptors that would
   be too difficult and cumbersome to include in BGP messages.  The BGP
   messages in these cases are still useful as a first response,
   however, as they can enable participants to begin throttling traffic
   matching a more course signature; reducing the effects of the attack
   and minimizing impacts to legitimate traffic matching the course
   signature.  Participants interfacing with the CS then would receive
   verbose traffic signatures enabling them to setup targeted policies
   that take more severe actions to matching traffic, such as dropping
   the packets entirely.

   To simplify the introduction of DDoS-AE a new optional, transitive,
   attribute is introduced into BGP-4 that will contain the information
   needed to identify and respond to malicious traffic.  The DDoS-AE
   attribute (DDOSAE_ALERT) will specify information about identified
   attack traffic in a standardized, yet minimal manner, so that devices
   can implement traffic policies to help mitigate the attack.
   Guidelines are also defined for how devices should respond to
   received DDoS-AE alert messages, beyond the core protocol message
   exchange functions.  Details about the interface to the CS are not
   included in this description as they are auxiliary to the functions
   of the described BGP extensions.

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




Green & Zimmer           Expires April 10, 2016                 [Page 3]


Internet-Draft                   DDoS-AE                    October 2015


2.  DDoS-AE Alert Attribute - DDOSAE_ALERT (Type Code TBD1)

   This is an optional transitive attribute that can be used to
   distribute information about malicious traffic, i.e. Distributed
   Denial of Service (DDoS) attack traffic, called Alerts.  The DDoS-AE
   Alert Attribute is included on UPDATE messages [RFC4271] where the
   advertised NLRI is the detected target of a network attack.  By
   following the existing rules for BGP route processing, information
   regarding the attack to the specified network can be efficiently
   propagated to devices that may transport traffic destined to the
   network under attack.

   Because there may be multiple types of attacks targeting the same
   destination at any given time, this attribute may contain multiple
   Alert entries.  The Attribute Length field for the Path Attribute and
   the Alert Length fields in the individual entries are used to
   determine the individual Alert entry boundaries.

   The attribute is encoded as one or more entries of the following
   fields shown below:

          +-----------------------------------------------------+
          |             Alert Length (2 octets)                 |
          +-----------------------------------------------------+
          | Severity Metric (1 Nibble) | Alert Flags (1 Nibble) |
          +-----------------------------------------------------+
          |           Traffic Descriptors (Variable)            |
          +-----------------------------------------------------+

                     Figure 1: DDoS-AE Alert Attribute

2.1.  Attribute Field Definitions

   Alert Length
      This field is used to differentiate between multiple Alert entries
      for a given target prefix.  It is a 2 octet field describing the
      length in octets of the current Alert entry.  The length count
      includes the 2 octets of the Alert Length field.  It can be used
      to completely skip over an Alert entry during processing if an
      unrecognized Traffic Descriptor or error is found.

   Severity Metric (SM)
      This field is used to report the measured severity of the reported
      attack traffic.  This field is also used by the Alert Distribution
      Process.

      The value is calculated by the node generating the alert based on
      the measured rate of the described attack traffic observed by that



Green & Zimmer           Expires April 10, 2016                 [Page 4]


Internet-Draft                   DDoS-AE                    October 2015


      node in relation to the total amount of all measured traffic at
      the observing node.  The ratio is then normalized so that it
      ranges between 0 and 15, where a value of 15 indicates the attack
      traffic has saturated the observing node.

      A value of 0 SHOULD not be used because it means there is no
      longer an attack detected.  If that was the case, then the entire
      attribute for the target should be removed, either by sending
      another UPDATE for the same target, with the DDoS-AE Alert
      attribute removed, or by sending an UPDATE removing the specific
      route entirely.

   Alert Flags
      This field is used to provide additional information about the
      processing state of the information included in the Alert message.
      It is a 4 bit field consisting of the following flags:

      Reported to CS Flag (CS)
         High order bit (0) that when set (1) indicates that the Alert
         message has been reported to the Central Service (CS).  This
         allows nodes that do not interact with the CS to report Alerts
         and have other nodes that do interact with the CS ensure the
         Alert is reported.

      Drop Safe Flag (DS)
         Second high order bit (1) that when set (1) indicates that the
         description in this Alert contains sufficient detail that nodes
         are encouraged to completely drop all matching traffic.  When
         not set (0), the implication is the description may match a
         significant amount of legitimate traffic and dropping that
         traffic would not be recommended, in this case bandwidth
         throttling policies would be the preferred response.

      Reserved Flags
         Bits 2 - 3 are currently reserved.

   Traffic Descriptors
      A variable length field that lists Traffic Descriptors that
      further describes the attack traffic being reported.  Traffic
      Descriptors are encoded as the following triplet:

      <Type (1 Octet), Length (1 Octet), Value (Variable)>

      Descriptor Type is a one octet field that identifies the traffic
      descriptor being described.  See Section 2.2 for a complete
      listing of available Traffic Descriptor Types and their associated
      Value encoding.




Green & Zimmer           Expires April 10, 2016                 [Page 5]


Internet-Draft                   DDoS-AE                    October 2015


      Descriptor Length is a one octet field that contains the length of
      the Descriptor Value field in octets.  Descriptor Value is a
      variable length field that is interpreted according to the value
      of the Descriptor Type field.

      Some Descriptor Types MAY appear multiple times in one Alert
      message.  If a Descriptor Type entry conflicts with a previous
      entry in the same Alert message then the later entry SHOULD be
      ignored.  If a node detects an unknown or unsupported Descriptor
      Type it MAY ignore the value in the Response Action, however, it
      MUST maintain the entry for distribution to other nodes.

2.2.  Traffic Descriptor Types

   Traffic Descriptors are used to further describe attack traffic so
   that it can be targeted more accurately, minimizing impact to
   legitimate traffic on a network.  These Traffic Descriptors have been
   selected and designed to be high level, generic, and flexible to
   ensure compatibility with as many traffic filtering/policing
   implementations as possible.  Specifically, the descriptors are such
   that they do not require a filter to maintain state of traffic
   streams, meaning these descriptors should be compatible with any
   stateless filter.

   To minimize complexity in the Alerts and ease interpretation by
   traffic filtering/policing implementations all Traffic Descriptor
   entries in an Alert SHOULD be considered to be the minimum criteria
   for matching described traffic.  In other words, ALL supported
   Traffic Descriptor entries in an Alert SHOULD be satisfied by traffic
   in question in order to be considered a match.  If attack traffic
   cannot be completely distinguished from legitimate traffic using the
   provided Traffic Descriptors then the Drop Safe flag SHOULD be set to
   0.

   This document defines the following values for Traffic Descriptor
   Types:

   0 - IP Protocol / Next Header

      Value Encoding: 1 Octet Integer

      Value of the IPv4 Protocol field or IPv6 Next Header field.  An
      entry of this type MUST be specified if any of the protocol
      independent convenience Descriptor Types are present in the Alert.
      Valid values are those found in the IANA Assigned Internet
      Protocol Numbers [RFC5237][RFC7045].

   1 - IP Protocol / Next Header Compare



Green & Zimmer           Expires April 10, 2016                 [Page 6]


Internet-Draft                   DDoS-AE                    October 2015


      Value Encoding: Compare Triplet (Section 2.3)

      Compare the value of the IPv4 Protocol field or IPv6 Next Header
      field.

   2 - Source Port Compare

      Value Encoding: Compare Triplet (Section 2.3)

      Protocol independent way to compare the Source Port of the
      Transport Layer protocol of the described traffic.  How this field
      is applied depends on the value of the
      IP Protocol / Next Header (Type 0) entry.

   3 - Destination Port Compare

      Value Encoding: Compare Triplet (Section 2.3)

      Protocol independent way to compare the Destination Port of the
      Transport Layer protocol of the described traffic.  How this field
      is applied depends on the value of the
      IP Protocol / Next Header (Type 0) entry.

   4 - Network Header Offset Compare*

      Value Encoding: Offset Compare Quadlet (Section 2.4)

      Used to compare a value at a specific offset from the start of the
      Network Layer (IPv4/IPv6) header.

   5 - Transport Header Offset Compare*

      Value Encoding: Offset Compare Quadlet (Section 2.4)

      Similar to Network Header Offset Compare, except the start of the
      offset begins at the beginning of the first Transport Layer
      Protocol Header.  This allows for variable length options in the
      Network Layer Protocol Header.

   6 - ANY IP Options Compare*

      Value Encoding: Compare Triplet (Section 2.3)

      Specify comparisons to perform over the IP Options present in the
      subject packet.  A match is valid if ANY of the IP Options present
      in the subject packet evaluate to true for the specified
      comparison.




Green & Zimmer           Expires April 10, 2016                 [Page 7]


Internet-Draft                   DDoS-AE                    October 2015


   7 - ALL IP Options Compare*

      Value Encoding: Compare Triplet (Section 2.3)

      Like Any IP Options, but ALL present IP Options in subject packet
      must evaluate to true for the specified comparison.

   8 - NO IP Options Compare*

      Value Encoding: Compare Triplet (Section 2.3)

      The opposite of All IP Options, in that NONE of the present IP
      Options must evaluate to true for the specified comparison.

   9 - First Fragment

      Value Encoding: No Value Needed

      Match packets that are the first of a fragmented packet series.

   10 - Is Fragment

      Value Encoding: No Value Needed

      Match packets that are not the first of a fragmented packet
      series, but are trailing fragments.

   11 - Not Fragment

      Value Encoding: No Value Needed

      Match packets that are not fragmented.

   12 - TTL/Hop Limit Compare

      Value Encoding: Compare Triplet (Section 2.3)

      Protocol independent way to compare value of the TTL/Hop Limit.
      How this field is applied depends on the value of the
      IP Protocol / Next Header (Type 0) entry.

   13 - TCP Initial

      Value Encoding: No Value Needed

      Match packets that are the initial packet in a TCP connection.
      Essentially looking for TCP packets with ACK flag set to 0 and SYN
      flag set to 1.  Should only have an effect if the



Green & Zimmer           Expires April 10, 2016                 [Page 8]


Internet-Draft                   DDoS-AE                    October 2015


      IP Protocol / Next Header (Type 0) is present with a value of TCP
      (6).

   14 - TCP Established

      Value Encoding: No Value Needed

      Match packets that are not the initial packet in a TCP connection.
      Essentially looking for TCP packets with the ACK or RST flags set.
      Should only have an effect if the
      IP Protocol / Next Header (Type 0) is present with a value of TCP
      (6).

   15 - TCP Flags Compare*

      Value Encoding: Compare Triplet (Section 2.3)

      Compare values of TCP flags.  Should only have an effect if the
      IP Protocol / Next Header (Type 0) is present with a value of TCP
      (6).

   16 - ICMP Type Compare

      Value Encoding: Compare Triplet (Section 2.3)

      Compare value of ICMP Type field.  Should only have an effect if
      the IP Protocol / Next Header (Type 0) is present with a value of
      ICMP (1) or ICMPv6 (58).

   17 - ICMP Code Compare

      Value Encoding: Compare Triplet (Section 2.3)

      Compare value of ICMP Code field.  Should only have an effect if
      the IP Protocol / Next Header (Type 0) is present with a value of
      ICMP (1) or ICMPv6 (58).

   * - Indicates Traffic Descriptor Type may be present more than once
   per Alert.  Unless otherwise specified there SHOULD be no more than
   one entry per Traffic Descriptor Type per Alert.

2.3.  Compare Triplet Encoding

   The Compare Triplet is used by several Traffic Descriptor types to
   specify a comparison operator, and comparator value.  The Compare
   Triplet is encoded as the following triplet:

   <Compare Operator (1 Octet), Length (1 Octet), Value (Variable)>



Green & Zimmer           Expires April 10, 2016                 [Page 9]


Internet-Draft                   DDoS-AE                    October 2015


   Compare Operator is a 1 octet field specifying the comparison
   operator/match behavior.  Compare operators are defined in
   Section 2.5.

   Comparator Value Length is a 1 octet field containing the length in
   octets of the Comparator Value field.

   Comparator Value is a variable length field containing the value to
   use in the comparison operation.

2.4.  Offset Compare Quadlet Encoding

   The Offset Compare Quadlet is similar to the Compare Triplet
   (Section 2.3), but adds a 2 octet Offset Amount field to the
   beginning of the Triplet.The Compare Quadlet is encoded as the
   following quadlet:

   <Offset (2 Octets), Compare Operator (1 Octet), Length (1 Octet),
   Value (Variable)>

   The Offset Amount field is a 2 octet value specifying the offset in
   bytes.  The starting point for offset calculation is dependent on the
   context in which the type is used.  The other fields have the same
   definition as in the Compare Triplet Encoding (Section 2.3).

2.5.  Compare Operator Definitions

   This document defines the following values for Compare Operators:

   0 - Match

      Match the exact value.

   1 - Mask

      Perform bit-wise AND operation then match result to the mask
      value.

   2 - Less Than (<)

      Determine if the value at the specified offset is < the Comparator
      Value.

   3 - Greater Than (>)

      Determine if the value at the specified offset is > the Comparator
      Value.




Green & Zimmer           Expires April 10, 2016                [Page 10]


Internet-Draft                   DDoS-AE                    October 2015


   4 - Not Equal (!=)

      Determine if the value at the specified offset is != to the
      Comparator Value.

   5-255 - Reserved

      Reserved for future use.

3.  Alert Processing

   An Alert is used to describe detected malicious traffic so that
   participants in the DDoS-AE system can coordinate a response to
   mitigate the attack.  Alerts leverage existing BGP processes for
   exchanging NLRI and therefore the same rules for NLRI announcements
   are followed.  This helps ensure that Alerts are generated by
   speakers about network segments with which they have a legitimate
   interest, and ensures the Alerts are propagated only to other
   speakers that also have concern with the network under attack.

   Alerts are target centric, meaning they focus on malicious traffic
   streams destined to the same target.  The target could be a single
   host or an entire subnet.  While it is possible that one party could
   direct a single attack against multiple targets, for the purposes of
   DDoS-AE each distinct subnet target would be considered a unique
   attack for Alert generation purposes.  Due to the nature of DDoS
   attacks, there will likely be multiple sources generating the
   malicious traffic destined to the identified target.

3.1.  Alert Generation/Updating

   Alerts are generated when a participating node detects a new attack
   or malicious traffic stream.  The details of how malicious traffic
   streams are detected are outside the scope of this document and left
   up to the discretion of the node implementing this extension.  It is
   recommended that system designers allow for flexibility in the
   generation of alerts so they may be generated in both an automated
   and manual fashion.

   When a new malicious traffic stream is detected at a DDoS-AE node, an
   Alert is generated by sending an UPDATE message advertising an
   updated NLRI message for the detected traffic stream destination.
   The UPDATE should follow the existing BGP rules for propagation to
   peers as if any other optional transitive attribute regarding the
   route had been updated.

   The content of the Alert attribute SHOULD be minimal, with sufficient
   detail to accurately describe the malicious traffic, while avoiding



Green & Zimmer           Expires April 10, 2016                [Page 11]


Internet-Draft                   DDoS-AE                    October 2015


   legitimate traffic.  If an organization detects an attack that is
   targeting multiple addresses in their network block, then it would be
   recommended to generate the Alert for the smallest possible subnet
   capturing the addresses under attack.  However, if there is the
   possibility that portions of the advertised subnet are not under
   attack and there is the potential that another sub-organization is
   using portions of that address space, then it is RECOMMENDED to
   generate multiple Alerts for each minimal address block, rather than
   one Alert for a larger block that encompasses more addresses than are
   really under attack.

   In many cases, due to attack traffic masquerading as legitimate
   traffic, it may be very difficult to distinguish legitimate traffic
   from malicious traffic.  In these cases the Drop Safe flag should be
   cleared so that speakers implementing filters know to simply throttle
   matching target.  In cases where the attack traffic can be perfectly
   described in the content of the Alert and virtually all legitimate
   traffic can be excluded, the Drop Flag SHOULD be set so that
   participating speakers implementing filters know it is safe to drop
   matching traffic completely.

   The Severity Metric (SM) field SHOULD be set to a non-zero value
   based on the ratio of observed malicious traffic to legitimate
   traffic at the reporting node.  A zero value would mean no traffic is
   observed, in which case, sending an Alert is meaningless and
   wasteful.  See Alert Removal section for details about removing
   previous Alerts.

3.2.  Alert Distribution

   Alerts are distributed using the same mechanism as regular NLRI in
   BGP, through UPDATE messages.  The same rules for processing UPDATE
   NLRI and distributing the NLRI should be followed.  This is effective
   at distributing the Alert to speakers that may be in position to help
   mitigate the attack by following the reverse path of the incoming
   attack traffic.  It also minimizes the Alerts that are sent to
   speakers that may not be able to assist in mitigating the detected
   attack.  The DDoS-AE Alert attribute SHOULD NOT be used in the
   decision process for route selection.

3.3.  Alert Aggregation

   Alert aggregation is possible following the same rules as route
   aggregation in general.  The DDoS-AE Alert attribute may be
   aggregated by combining the individual Alert entries within each of
   the aggregated DDoS-AE Alert Attributes, dropping duplicate entries.





Green & Zimmer           Expires April 10, 2016                [Page 12]


Internet-Draft                   DDoS-AE                    October 2015


   Individual DDoS-AE Alert entries within a given DDoS-AE Alert
   Attribute may be further aggregated if the Traffic Descriptor entries
   all match.  The Severity Metric value should contain the maximum
   value of the aggregated Alert entries.  The Reported to CS Flag value
   is set if any of the aggregated Alerts have this flag set.  The Drop
   Safe (DS) flag SHOULD be set to 0, unless all of the aggregated
   Alerts have this flag set.

3.4.  Alert Removal

   Alerts can be removed two ways:

   1.  Removing the advertised route using the Withdrawn Routes field in
       the UPDATE message (or the MP_UNREACH_NLRI attribute in
       [RFC4760]).

   2.  Sending an updated advertisement for the route but removing the
       DDoS-AE Alert attribute, or removing the specific Alert entry
       from the DDoS-AE Alert attribute in the updated advertisement.

4.  BGP Capability Advertisement

   A BGP speaker that uses DDoS-AE SHOULD use the Capability
   Advertisement procedures [RFC5492] to determine whether the speaker
   could use DDoS-AE with a particular peer and if any optional DDoS-AE
   features may be enabled.  However, because DDoS-AE does not introduce
   new message types and the DDoS-AE path attributes are transitive
   optional, speakers MAY send Alert messages to peers in order to
   enable the possibility that the Alert values are passed on beyond the
   non-DDoS-AE peer and eventually make it to another indirectly
   connected DDoS-AE speaker.

   To indicate support for DDoS-AE the Capability Optional Parameter
   Code field is set to TBD2 (requesting 74 in IANA Considerations
   (Section 7)).  The Capability Length field is set to the value that
   minimally captures all the bits representing the supported optional
   DDoS-AE capabilities.  Currently this length is 0.

5.  Alert Refresh

   Because DDoS-AE Alerts are distributed as attributes of existing
   NLRI, the ability to refresh information about active Alerts comes
   free with any BGP speaker that supports existing Route Refresh
   capabilities [RFC7313].







Green & Zimmer           Expires April 10, 2016                [Page 13]


Internet-Draft                   DDoS-AE                    October 2015


6.  Acknowledgements

   The authors would like to thank Dr. Dan Massey and the Cyber Security
   Divison (CSD) at the Department of Homeland Security (DHS) for their
   support of this effort.  The authors would like to thank Nick
   Richard, David Fox, Andrew Krause, Keyur Patel, and Donald Sharp for
   support developing this concept.  The authors also appreciate the
   support from the Quagga development community for the prototyping
   effort and the USC ISI DETER testbed team for providing the resources
   for evaluating the prototype system.

7.  IANA Considerations

   IANA is requested [RFC5226] to assign a BGP Path Attribute code
   through Standards Action [RFC4271].  The BGP Path Attribute code
   value requested is 30.  The label for the requested BGP Path
   Attribute is requested to be DDOSAE_ALERT.  It is referenced in this
   document as TBD1 (Section 2).  The IANA registry for BGP Path
   Attributes is located at <http://www.iana.org/assignments/bgp-
   parameters/bgp-parameters.xhtml>.

   IANA is requested [RFC5226] to assign a BGP Capability Code from the
   First Come First Served range [RFC5492].  The BGP Capability Code
   value requested is 74.  It is referenced in this document as TBD2
   (Section 4).  The IANA registry for BGP Capability Codes is located
   at <http://www.iana.org/assignments/capability-codes/capability-
   codes.xml>.

    Value      Description                                  Reference
    ---------- -------------------------------------------- ----------
    TBD1 (30)  BGP Path Attribute Type Code (DDOSAE_ALERT)  [RFC4271]
    TBD2 (74)  BGP Capability Code (DDoS-AE Capability)     [RFC5492]

                        IANA Considerations Summary

8.  Security Considerations

   Exchanging information about detected malicious traffic, relies on
   the same trust relationship already present between BGP speakers.  On
   its own, the exchange of traffic descriptors adds no additional
   security concerns to BGP.  The trust and security levels are
   maintained because the Alerts are target centric, so the speaker that
   is announcing the Alert must also be advertising the network prefix
   associated with the Alert.  Therefore existing policies and rules
   provide the assurance that the source of the Alert is the
   organization that is also the victim of the described attack(s).
   Scenarios where a false or malicous Alert might be issued are no
   different than what a poorly behaived BGP speaker might do, and can



Green & Zimmer           Expires April 10, 2016                [Page 14]


Internet-Draft                   DDoS-AE                    October 2015


   be mitigated using the same techniques used to account for
   potentially bad BGP speakers.

   Organizations that execute traffic shaping based on received Alerts
   should take care to ensure the source of the Alert is the same
   organization that they would expect to be advertising the NLRI on its
   own.  This ensures the same degree of trust and security that is
   already inherent in BGP (for better or for worse).

   Implementing traffic shaping in response to dynamic Alerts could make
   troubleshooting network issues more difficult.  It is recommended
   that organizations generate detailed logs and human readable alerts
   whenever new traffic shaping policies are executed as a result of an
   Alert.

   It is possible that malicious actors could specify traffic
   descriptors in an Alert to match NLRI destinations other than those
   in the associated NLRI announced by the BGP speaker.  This could
   cause incautious routers to effect traffic destined to destinations
   other than the one in the associated NLRI update message.  It is
   recommended that participants ensure the resulting traffic shaping
   policies only effect traffic destined to the addresses associated
   with the NLRI in the update message.

9.  Normative References

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

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI
              10.17487/RFC4271, January 2006,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760, DOI
              10.17487/RFC4760, January 2007,
              <http://www.rfc-editor.org/info/rfc4760>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.






Green & Zimmer           Expires April 10, 2016                [Page 15]


Internet-Draft                   DDoS-AE                    October 2015


   [RFC5237]  Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
              the Protocol Field", BCP 37, RFC 5237, DOI 10.17487/
              RFC5237, February 2008,
              <http://www.rfc-editor.org/info/rfc5237>.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
              2009, <http://www.rfc-editor.org/info/rfc5492>.

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

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045, DOI 10.17487/
              RFC7045, December 2013,
              <http://www.rfc-editor.org/info/rfc7045>.

   [RFC7313]  Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced
              Route Refresh Capability for BGP-4", RFC 7313, DOI
              10.17487/RFC7313, July 2014,
              <http://www.rfc-editor.org/info/rfc7313>.

Authors' Addresses

   Harley Green
   Blue Ridge Envisioneering, Inc.
   5180 Parkstone Dr
   Chantilly, Virginia  20151
   USA

   Email: harley@br-envision.com
   URI:   http://www.br-envision.com


   Edward R. (Ned) Zimmer
   Blue Ridge Envisioneering, Inc.
   5180 Parkstone Dr
   Chantilly, Virginia  20151
   USA

   Email: ned@br-envision.com
   URI:   http://www.br-envision.com







Green & Zimmer           Expires April 10, 2016                [Page 16]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/