| DOTS | M. Chen |
| Internet-Draft | Li. Su |
| Intended status: Informational | Jin. Peng |
| Expires: January 23, 2020 | CMCC |
| July 22, 2019 |
DOTS client carry ddos attack informations in signal channel
draft-chen-dots-attack-informations-02
This document describes DDoS attack information which can be obtained by DOTS client when the enterprise suspects it is under DDoS attack, these informations will be send from DOTS client to DOTS server using Signal channel within Mitigation Request.
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 https://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 January 23, 2020.
Copyright (c) 2019 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 (https://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) is a type of resource-consuming attack, which exploits a large number of attack resources and uses standard protocols to attack target objects. DDoS attacks consume a large amount of target network resources or server resources (including computing power, storage capacity, etc.). At present, DDoS attack is one of the most powerful and indefensible attacks on the Internet, and due to the extensive use of mobile devices and IoT devices in recent years, it is easier for DDoS attackers to attack with real attack sources (broilers).
The IETF is specifying the DDoS Open Threat Signaling (DOTS) [I-D.ietf-dots-architecture]architecture, where a DOTS client can inform a DOTS server that the network is under a potential attack and that appropriate mitigation actions are required. In the architecture draft, it says in the draft the enterprise has a DOTS client, which obtains information about the DDoS attack, and signals the DOTS server for help in mitigating the attack. but it doesn't says what the information of DDoS attack is. the scope of this draft is about the information of DDoS attack which DOTS client can obtain.
In the architecture draft, it says in the draft the client signal may also include telemetry information about the attack, if the DOTS client has such information available. But in the signal channel draft it doesn't define optional parameter about the telemetry information which will be regarded as DDoS portrait information.
"DDoS portrait information" is defined as the collection of attributes characterizing the actual attacks that have been detected and mitigated. The DDoS portrait information is an optional set of attributes that can be signaled in the DOTS signal channel. The portrait can be optionally sent from the DOTS Client to Server and vice versa.
This document will divide two directions, before mitigation request and after mitigation is complete. Before mitigation request, DOTS client can obtain informations of attack; After mitigation, DOTS server can obtain from mitigator.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]
The readers should be familiar with the terms defined in [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases]
The terminology related to YANG data modules is defined in [RFC7950]
In addition, this document uses the terms defined below:
when attack target is under attack, it has to make corresponding disposal, there are two options for disposal, one is blackhole directly which may be take effect in routers, in this way all the attack flow will be discarded by router upper path of attack target, this means that the attack target will not receive any traffic during the attack depending on the routing strategy, all the traffic forwards attack target will be discarded, this has a huge impact on the work environment, especially the host that provide external service. The other way of the disposition is to drainage all the traffic flow to clean center from router, then the clean center will use pattern matching or any other method to find out the attack traffic flow to discard, finally, clean center reinage the normal business traffic back to attack target by upper router, the whole process above is defined as flow clean(Figure 1).
attack flow +--------+ +--------+
----------->| router |------------------>| clean |
1 +--------+ 2 | center |
| +--------+
3 | |
| +--------+ |
+------>| attack |<-------------+
| target |
+--------+
Figure 1: diagram of DDoS Mitigation usecase
Generally, the bandwidth of the link 1 must be larger than link 2 and link 3, and the clean ability of clean center limited to hardware resources. An example of link situation is as below(Figure 2):
+------------+------------+
| figure | bandwidth/ |
| tag | capability |
+------------+------------+
| link 1 | 100Gb |
| link 2 | 50Gb |
| link 3 | 10Gb |
|clean center| 80Gb |
+------------+------------+
Figure 2: an example of link bandwidth
The Figure2 is a scenario of the link bandwidth, when a ddos attack is ongoing, if the link 1 bandwidth is completely jammed, the best way to mitigate the attack is to discard all the attack flow; if the amount of the traffic flow is lower than the remainder cleaning ability, the most suitable disposition is to drainage all the attack flow to clean center. Therefore, it is an obvious requirement in the current network environment.
Mitigator may owns a cleaning device cluster and can manage cleaning devices. The capacity of each cleaning equipment is variable, usually each cleaning equipment utilization rate is different, then the remaining cleaning capacity is not consistent. When the attack flow is less than the ability of a cleaning equipment, according to the attack-bandwidth can choose a suitable cleaning equipment, that is conducive to the utilization of equipment; When the attack flow is larger than the cleaning capacity of one cleaning device, several cleaning devices can be optimally scheduled according to the attack-bandwidth.
When mitigator is an attack flow cleaning service, they typically deployed the mitigator in a distributed way because of the cost of bandwidth usage with their own leased operator's link bandwidth, and choosing the best traction path was the key to profitability. If the parameter of attack-bandwidth is carried, then the generation of the best drainage path is very meaningful.
When mitigator is at the upstream service operator level, they might have multiple networks, with the attack alert using one network and the flow drainage using another, and the link load is not the same, then carrying the attack-bandwidth is very beneficial for choosing the drainage path, mainly for link load balancing.
When a DOTS client requires mitigation for some reason, the DOTS client uses the CoAP PUT method to send a mitigation request to its DOTS server(s). If a DOTS client is entitled to solicit the DOTS service, the DOTS server enables mitigation on behalf of the DOTS client by communicating the DOTS client's request to a mitigator (which may be colocated with the DOTS server) and relaying the feedback of the thus-selected mitigator to the requesting DOTS client.
DOTS clients use the PUT method to request mitigation from a DOTS server. During active mitigation, DOTS clients may use PUT requests to carry mitigation efficacy updates to the DOTS server. We suggest to add attack bandwidth to satiesfy the requirement.
total traffic when ddos attack occur, The recommended format is numerical form, such as xxGb. Different attack has different attack bandwidth, numerical value directly reflects the urgency of the current attack. Serious attacks are treated with blackhole, Other cases use flow cleaning, attack-bandwidth is conducive to the selection of disposal mode.
This is an optional attribute.
DDoS attack is a hybrid attack across multiple protocol layers and multiple method, when we deal with DDoS attacks, we find it more reasonable and effective to deal with them according to the types of attacks, It is easier to handle if the type of attack is already included in the mitigation request. There is no doubt that the information may not be accurate, but we can take it as a reference. Therefore, with attack type the disposal process is more helpful. The ddos attack alarm in the industry is set according to the attack type, from the point of view of cleaning, different types of attacks are handled differently. For example, Memcached reflection flood use UDP 11211 port for DDoS flood, but tcp syn flood use defects of TCP three-way handshake to consuming connection resources. This two attacks are alarmed respectively and cleaned in different ways. We suggest to add attack type to satiesfy the requirement.
A list of attack types involved in an attack.
There is no uniform definition of attack types, It is often the case that the same type of attack has different names, An attack type is defined in section 4.
The parameter of Target-attack-type contains two value, one is Attack-Name, the other is Attack-Alias, Attack-Alias will solve the abbreviation problem.An attack could be a hybrid attack, then the target-attack-type represents major types of attacks
This is an optional attribute.
For the target-attack-type field, we define it as a string Type, and define the two fields according to the attack method and extension name. there may be problems in the actual network environment, that attack target and mitigator (such as cleaning equipment) belong to different models of different vendors, because different vendors have different definitions of Attack in understanding and implementation. When an attack occurs, some devices may not be considered as an attack. It is also possible that the detection device considere it as A type attack, while the cleaning device consider it as B type attack. When performing the cleaning schedule, it will cause the problem of incorrect cleaning or over-cleaning. Both of these errors will cause the normal business to fail to link. Therefore, it is necessary to unify the attack definition, form a standard attack definition, and solve the problem of cleaning errors from the source. we give out a complete format for DDoS attacks as below:
[protocol layer] [protocol name] [message name/operation name/port] [attack methods feature description field 1] [attack methods feature description field 2] [attack methods describe the standard field]
protocol layer(mandatory): Network layer, transport layer, application layer;
protocol name(mandatory): The protocol type used for the attack, such as http, TCP, ICMP, NTP...;
message name/ operation name/ port(optional): The message name, operation name, or port used for the attack is a further addition to the protocol used for the attack, with message names such as SYN and operation names such as GET, Post, SYN, ACK, Query...;
attack methods feature description field 1 or 2 (optional): Description of the method used in the attack, such as Fragment, Amplification, Misuse, Slow...;
attack methods describe the standard field(mandatory): Used to describe the type of attack, as the end field, such as flood, attack;
The protocol name and message name must contain at least one item in the abbreviation.
interval between each field operators use special symbol or any other symbol agreed. For example:HTTP Get Flood(CC) definition, we defined the target-Attack-Type field as below(Figure 3):
{
"Attack-Name":" Application_Layer, HTTP, Get,,, Flood"
"Attack-Alias":"HTTP CC Flood"
}
Figure 3: Attack type definition example
An example of abbreviation: Define the target-attack-type using the methods specified above, complete attack name: Transport_Layer TCP SYN Flood; abbreviated form: TCP SYN Flood.
Attack target looks like to be attacked by DDoS, then DOTS client send mitigation request to DOTS server, So there are exist false alarms. In practice, there are standards for alerting whether or not they are appropriate, such as alarm baseline. With this parameter, it is possible to determine whether the standard is reasonable or not, False alarms can be corrected and normal alarms can be optimized. It is suggested to use target_attack_Type_threshold to carry this information.
DDoS attacks are distributed attacks, it means there are many sources of attack that the traffic from each attack source varies little, so it is more efficient to record the numbers of source ip than the details ip address. Blocking every IP address is a thankless task and short-lived. After mitigation, mitigators can feedback the source ip number to DOTS server, and this information must be more closer to the attack scene, these informations will be used in the feedback module for more application.
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"string"
],
"target-port-range": [
{
"lower-port": number,
"upper-port": number
}
],
"target-protocol": [
number
],
"target-fqdn": [
"string"
],
"target-Attack-Type": [
{
"Attack-Name": ["string"],
"Attack-Alias": ["string"],
"target_attack_Type_threshold":["string"]
}
],
"target-bandwidth":[
"string"
],
attack_src_ip_number:[
"string"
],
"target-uri": [
"string"
],
"alias-name": [
"string"
],
"lifetime": number,
"trigger-mitigation": true|false
}
]
}
}
Figure 4: Mitigation Response for Get Request
Added parameters show in put method are show as below(Figure 4)
After the mitigation of a DDoS attack, DOTS server can obtain some informations from mitigator, these informations are optional parameters only as a suggestion when use DOTS to inform the message between attack target and mitigator.Figure5Figure 5 shows a response example of a mitigation request.
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 12332,
"mitigation-start": "1507818434",
"target-prefix": [
"2001:db8:6401::1/128",
"2001:db8:6401::2/128"
],
"target-protocol": [
17
],
"lifetime": 1756,
"status": "attack-successfully-mitigated",
"bytes-dropped": "134334555",
"bps-dropped": "43344",
"pkts-dropped": "333334444",
"pps-dropped": "432432",
"attack_src_ip_number": "5231"
},
]
}
}
}
Figure 5: PUT to Convey DOTS Mitigation Requests
TBD
TBD
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7950] | Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016. |
| [I-D.ietf-dots-architecture] | Mortensen, A., K, R., Andreasen, F., Teague, N. and R. Compton, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Internet-Draft draft-ietf-dots-architecture-14, May 2019. |
| [I-D.ietf-dots-requirements] | Mortensen, A., K, R. and R. Moskowitz, "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements", Internet-Draft draft-ietf-dots-requirements-22, March 2019. |
| [I-D.ietf-dots-signal-channel] | K, R., Boucadair, M., Patil, P., Mortensen, A. and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Internet-Draft draft-ietf-dots-signal-channel-35, July 2019. |
| [I-D.ietf-dots-use-cases] | Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Teague, N., Xia, L. and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", Internet-Draft draft-ietf-dots-use-cases-18, July 2019. |