| 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
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.
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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.
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].
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
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:
* - 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.
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)>
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.
The Offset Compare Quadlet is similar to the Compare Triplet [comptrip], 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 [comptrip].
This document defines the following values for Compare Operators:
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.
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 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.
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.
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.
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.
Alerts can be removed two ways:
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 [IANA]). 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.
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].
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.
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 [ddosaealertattribute]. 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 [bgpcap]. 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] |
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.
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.