One document matched: draft-green-idr-ddosae-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd"
[
<!-- References -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"><!-- rfc keywords -->
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml"><!-- bgp -4 -->
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml"><!-- mp-bgp -->
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"><!-- rfc guidelines -->
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml"><!-- flowspec -->
<!ENTITY RFC5237 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5237.xml"><!-- iana protocol fields -->
<!ENTITY RFC7045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7045.xml"><!-- ipv6 headers -->
<!ENTITY RFC5492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5492.xml"><!-- bgp optional capabilities -->
<!ENTITY RFC7313 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7313.xml"><!-- bgp enhanced rr-->
]
>
<!-- Use the xml2rfc tool here: http://xml2rfc.tools.ietf.org/ -->
<!-- Change Log
v00 2015-09-09 HSG Initial Version
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<rfc docName="draft-green-idr-ddosae-00" category="std" ipr="trust200902">
<!-- Front Matter -->
<front>
<title abbrev="DDoS-AE">DDoS-Alert Extensions</title>
<author fullname="Harley Green" initials="H." surname="Green">
<organization>Blue Ridge Envisioneering, Inc.</organization>
<address>
<postal>
<street>5180 Parkstone Dr</street>
<city>Chantilly</city>
<region>Virginia</region>
<code>20151</code>
<country>USA</country>
</postal>
<email>harley@br-envision.com</email>
<uri>http://www.br-envision.com</uri>
</address>
</author>
<author fullname="Edward R. (Ned) Zimmer" initials="E.R." surname="Zimmer">
<organization>Blue Ridge Envisioneering, Inc.</organization>
<address>
<postal>
<street>5180 Parkstone Dr</street>
<city>Chantilly</city>
<region>Virginia</region>
<code>20151</code>
<country>USA</country>
</postal>
<email>ned@br-envision.com</email>
<uri>http://www.br-envision.com</uri>
</address>
</author>
<date year="2015"/>
<area>rtg</area>
<workgroup>Inter-Domain Routing</workgroup>
<keyword>bgp</keyword>
<keyword>alerts</keyword>
<keyword>security</keyword>
<keyword>ddos</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.
</t>
<t>
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
<xref target="RFC5575">solutions</xref> 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<section title="Requirements Language">
<t>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
<xref target="RFC2119"/>.
</t>
</section><!-- Requirements language -->
</section><!-- Introduction -->
<section title="DDoS-AE Alert Attribute - DDOSAE_ALERT (Type Code TBD1)"
anchor="ddosaealertattribute">
<t>
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 <xref target="RFC4271">UPDATE messages</xref>
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.
</t>
<t>
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.
</t>
<figure title="DDoS-AE Alert Attribute" anchor="attributespec">
<preamble>
The attribute is encoded as one or more entries of the following fields
shown below:
</preamble>
<artwork align="center"><![CDATA[
+-----------------------------------------------------+
| Alert Length (2 octets) |
+-----------------------------------------------------+
| Severity Metric (1 Nibble) | Alert Flags (1 Nibble) |
+-----------------------------------------------------+
| Traffic Descriptors (Variable) |
+-----------------------------------------------------+]]>
</artwork>
</figure>
<section title="Attribute Field Definitions">
<t>
<list style="hanging">
<t hangText="Alert Length">
<vspace/>
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.
</t>
<t hangText="Severity Metric (SM)">
<vspace/>
This field is used to report the measured severity of the
reported attack traffic. This field is also used by the Alert
Distribution Process.<!-- TODO: Include link to section! -->
<vspace blankLines="1"/>
The value is calculated by the node generating the alert based
on the measured rate of the described attack traffic observed
by that 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.
<vspace blankLines="1"/>
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.
</t>
<t hangText="Alert Flags">
<vspace/>
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:
<list style="hanging">
<t hangText="Reported to CS Flag (CS)">
<vspace/>
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.
</t>
<t hangText="Drop Safe Flag (DS)">
<vspace/>
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.
</t>
<t hangText="Reserved Flags">
<vspace/>
Bits 2 - 3 are currently reserved.
</t>
</list>
</t>
<t hangText="Traffic Descriptors">
<vspace/>
A variable length field that lists Traffic Descriptors that
further describes the attack traffic being reported. Traffic
Descriptors are encoded as the following triplet:
<vspace blankLines="1"/>
<Type (1 Octet), Length (1 Octet), Value (Variable)>
<vspace blankLines="1"/>
Descriptor Type is a one octet field that identifies the
traffic descriptor being described. See <xref target="trafficdesctypes"/>
for a complete listing of available Traffic Descriptor Types
and their associated Value encoding.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
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.
</t>
</list>
</t>
</section><!-- Attribute Field Definitions -->
<section title="Traffic Descriptor Types" anchor="trafficdesctypes">
<t>
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.
</t>
<t>
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.
</t>
<t anchor="trafficdescriptorlist">
This document defines the following values for
Traffic Descriptor Types:
<list style="hanging" >
<t hangText="0 - IP Protocol / Next Header">
<vspace blankLines="1"/>
Value Encoding: 1 Octet Integer
<vspace blankLines="1"/>
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
<xref target="RFC5237"/><xref target="RFC7045"/>.
</t><!-- IP Protocol / Next Header -->
<t hangText="1 - IP Protocol / Next Header Compare">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
Compare the value of the IPv4 Protocol field or IPv6 Next Header
field.
</t><!-- IP Protocol / next header compare -->
<t hangText="2 - Source Port Compare">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
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.
</t><!-- source port compare -->
<t hangText="3 - Destination Port Compare">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
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.
</t><!-- destination port compare -->
<t hangText="4 - Network Header Offset Compare*">
<vspace blankLines="1"/>
Value Encoding:
<xref target="offsetcompare">Offset Compare Quadlet</xref>
<vspace blankLines="1"/>
Used to compare a value at a specific offset from the start of the
Network Layer (IPv4/IPv6) header.
</t><!-- network header offset compare -->
<t hangText="5 - Transport Header Offset Compare*">
<vspace blankLines="1"/>
Value Encoding:
<xref target="offsetcompare">Offset Compare Quadlet</xref>
<vspace blankLines="1"/>
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.
</t><!-- transport header offset compare -->
<t hangText="6 - ANY IP Options Compare*">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
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.
</t><!-- any ip options compare -->
<t hangText="7 - ALL IP Options Compare*">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
Like Any IP Options, but ALL present IP Options in subject packet
must evaluate to true for the specified comparison.
</t><!-- all ip options compare -->
<t hangText="8 - NO IP Options Compare*">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
The opposite of All IP Options, in that NONE of the present IP
Options must evaluate to true for the specified comparison.
</t><!-- no ip options compare -->
<t hangText="9 - First Fragment">
<vspace blankLines="1"/>
Value Encoding: No Value Needed
<vspace blankLines="1"/>
Match packets that are the first of a fragmented packet series.
</t><!-- first fragment -->
<t hangText="10 - Is Fragment">
<vspace blankLines="1"/>
Value Encoding: No Value Needed
<vspace blankLines="1"/>
Match packets that are not the first of a fragmented packet series,
but are trailing fragments.
</t><!-- is fragment -->
<t hangText="11 - Not Fragment">
<vspace blankLines="1"/>
Value Encoding: No Value Needed
<vspace blankLines="1"/>
Match packets that are not fragmented.
</t><!-- not fragment -->
<t hangText="12 - TTL/Hop Limit Compare">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
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.
</t><!-- ttl/hop limit compare -->
<t hangText="13 - TCP Initial">
<vspace blankLines="1"/>
Value Encoding: No Value Needed
<vspace blankLines="1"/>
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
IP Protocol / Next Header (Type 0)
is present with a value of TCP (6).
</t><!-- tcp initial -->
<t hangText="14 - TCP Established">
<vspace blankLines="1"/>
Value Encoding: No Value Needed
<vspace blankLines="1"/>
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).
</t><!-- tcp established -->
<t hangText="15 - TCP Flags Compare*">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
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).
</t><!-- tcp flags compare -->
<t hangText="16 - ICMP Type Compare">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
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).
</t><!-- icmp type compare -->
<t hangText="17 - ICMP Code Compare">
<vspace blankLines="1"/>
Value Encoding: <xref target="comptrip">Compare Triplet</xref>
<vspace blankLines="1"/>
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).
</t><!-- icmp code compare -->
</list><!-- TDL -->
* - 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.
</t> <!-- Traffic Descriptor List -->
</section><!-- Traffic Descriptor Types -->
<section title="Compare Triplet Encoding" anchor="comptrip">
<t>
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:
</t>
<t>
<Compare Operator (1 Octet),
Length (1 Octet),
Value (Variable)>
</t>
<t>
Compare Operator is a 1 octet field specifying the comparison
operator/match behavior. Compare operators are defined in
<xref target="compareoperators"/>.
</t>
<t>
Comparator Value Length is a 1 octet field containing the length in
octets of the Comparator Value field.
</t>
<t>
Comparator Value is a variable length field containing the value to use
in the comparison operation.
</t>
</section><!-- Compare Triplet Encoding -->
<section title="Offset Compare Quadlet Encoding" anchor="offsetcompare">
<t>
The Offset Compare Quadlet is similar to the <xref target="comptrip">
Compare Triplet</xref>, but adds a 2 octet Offset Amount field to the
beginning of the Triplet.The Compare Quadlet is encoded as the following
quadlet:
</t>
<t>
<Offset (2 Octets),
Compare Operator (1 Octet),
Length (1 Octet), Value (Variable)>
</t>
<t>
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
<xref target="comptrip">Compare Triplet Encoding</xref>.
</t>
</section><!-- Offset Compare Quadlet Encoding -->
<section title="Compare Operator Definitions" anchor="compareoperators">
<t>
This document defines the following values for
Compare Operators:
<list style="hanging">
<t hangText="0 - Match"><vspace blankLines="1"/>
Match the exact value.
</t>
<t hangText="1 - Mask"><vspace blankLines="1"/>
Perform bit-wise AND operation then match result to the mask value.
</t>
<t hangText="2 - Less Than (<)"><vspace blankLines="1"/>
Determine if the value at the specified offset is < the
Comparator Value.
</t>
<t hangText="3 - Greater Than (>)"><vspace blankLines="1"/>
Determine if the value at the specified offset is > the
Comparator Value.
</t>
<t hangText="4 - Not Equal (!=)"><vspace blankLines="1"/>
Determine if the value at the specified offset is != to the Comparator
Value.
</t>
<t hangText="5-255 - Reserved"><vspace blankLines="1"/>
Reserved for future use.
</t>
</list><!-- Compare operator list -->
</t>
</section><!-- Compare Operators -->
</section><!-- DDoS-AE Alert Attribute -->
<section title="Alert Processing" anchor="alertprocessing">
<t>
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.
</t>
<t>
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.
</t>
<section title="Alert Generation/Updating" anchor="alertgeneration">
<t>
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.
</t>
<t>
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.
</t>
<t>
The content of the Alert attribute SHOULD be minimal, with
sufficient detail to accurately describe the malicious traffic,
while avoiding 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section><!-- Generation/updating -->
<section title="Alert Distribution">
<t>
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.
</t>
</section><!-- Alert distribution -->
<section title="Alert Aggregation">
<t>
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.
</t>
<t>
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.
</t>
</section><!-- Alert Aggregation -->
<section title="Alert Removal">
<t>
Alerts can be removed two ways:
<list style="numbers">
<t>
Removing the advertised
route using the Withdrawn Routes field in the UPDATE message
(or the MP_UNREACH_NLRI attribute in <xref target="RFC4760"/>).
</t>
<t>
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.
</t>
</list>
</t>
</section><!-- Alert Removal -->
</section><!-- Alert Processing -->
<section title="BGP Capability Advertisement" anchor="bgpcap">
<t>
A BGP speaker that uses DDoS-AE SHOULD use the Capability
Advertisement procedures <xref target="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.
</t>
<t>
To indicate support for DDoS-AE the Capability Optional Parameter Code
field is set to TBD2
(requesting 74 in <xref target="IANA">IANA Considerations</xref>).
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.
</t>
</section><!-- BGP Capability Adv. -->
<section title="Alert Refresh">
<t>
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
<xref target="RFC7313"/>.
</t>
</section><!-- Alert refresh -->
<section title="Acknowledgements">
<t>
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.
</t>
</section><!-- Acknowledgements -->
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is requested <xref target="RFC5226"/> to assign a
BGP Path Attribute code through Standards
Action <xref target="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
<xref target="ddosaealertattribute">TBD1</xref>.
The IANA registry for BGP Path Attributes is located at
<eref target="http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml"/>.
</t>
<t>
IANA is requested <xref target="RFC5226"/> to assign a
BGP Capability Code from the
First Come First Served range <xref target="RFC5492"/>.
The BGP Capability Code value requested is 74.
It is referenced in this document as
<xref target="bgpcap">TBD2</xref>.
The IANA registry for BGP Capability Codes is located at
<eref target="http://www.iana.org/assignments/capability-codes/capability-codes.xml"/>.
</t>
<texttable align="center"
style="headers"
title="IANA Considerations Summary">
<ttcol>
Value
</ttcol>
<ttcol>
Description
</ttcol>
<ttcol>
Reference
</ttcol>
<!-- Path Attribute -->
<c>
TBD1 (30)
</c>
<c>
BGP Path Attribute Type Code (DDOSAE_ALERT)
</c>
<c>
<xref target="RFC4271"/>
</c>
<!-- Capability Code -->
<c>
TBD2 (74)
</c>
<c>
BGP Capability Code (DDoS-AE Capability)
</c>
<c>
<xref target="RFC5492"/>
</c>
</texttable>
</section><!-- iana considerations -->
<section anchor="Security" title="Security Considerations">
<t>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 be mitigated using the same techniques used
to account for potentially bad BGP speakers.
</t>
<t>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).
</t>
<t>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.
</t>
<t>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.
</t>
</section><!-- security -->
</middle>
<back>
<references title="Normative References">
&RFC4271;
&RFC4760;
&RFC5575;
&RFC5226;
&RFC2119;
&RFC5237;
&RFC7045;
&RFC5492;
&RFC7313;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:39:41 |