< draft-ietf-dots-telemetry-use-cases-01.txt | draft-ietf-dots-telemetry-use-cases-00.txt > | |||
---|---|---|---|---|
DOTS Y. Hayashi | DOTS Y. Hayashi | |||
Internet-Draft NTT | Internet-Draft NTT | |||
Intended status: Informational M. Chen | Intended status: Informational M. Chen | |||
Expires: May 22, 2021 Li. Su | Expires: March 18, 2021 CMCC | |||
CMCC | September 14, 2020 | |||
November 18, 2020 | ||||
Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry | Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry | |||
draft-ietf-dots-telemetry-use-cases-01 | draft-ietf-dots-telemetry-use-cases-00 | |||
Abstract | Abstract | |||
Denial-of-service Open Threat Signaling (DOTS) Telemetry enriches the | Denial-of-service Open Threat Signaling (DOTS) Telemetry enriches the | |||
base DOTS protocols to assist the mitigator in using efficient DDoS- | base DOTS protocols to assist the mitigator in using efficient DDoS- | |||
attack-mitigation techniques in a network. This document presents | attack-mitigation techniques in a network. This document presents | |||
sample use cases for DOTS Telemetry: what components are deployed in | sample use cases for DOTS Telemetry: what components are deployed in | |||
the network, how they cooperate, and what information is exchanged to | the network, how they cooperate, and what information is exchanged to | |||
effectively use these techniques. | effectively use these techniques. | |||
skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 36 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 22, 2021. | This Internet-Draft will expire on March 18, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 20 ¶ | skipping to change at page 2, line 19 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3.1. DDoS Mitigation Based on Attack Traffic Bandwidth . . . . 3 | 3.1. DDoS Mitigation Based on Attack Traffic Bandwidth . . . . 3 | |||
3.1.1. Mitigating Attack Flow of Top-talker Preferentially . 3 | 3.1.1. Mitigating Attack Flow of Top-talker Preferentially . 3 | |||
3.1.2. Optimal DMS Selection for Mitigation . . . . . . . . 5 | 3.1.2. Optimal DMS Selection for Mitigation . . . . . . . . 5 | |||
3.1.3. Best-path Selection for Redirection . . . . . . . . . 6 | 3.1.3. Best-path Selection for Redirection . . . . . . . . . 6 | |||
3.1.4. Short but Extreme Volumetric Attack Mitigation . . . 8 | 3.1.4. Short but Extreme Volumetric Attack Mitigation . . . 8 | |||
3.2. DDoS Mitigation Based on Attack Type . . . . . . . . . . 9 | 3.2. DDoS Mitigation Based on Attack Type . . . . . . . . . . 9 | |||
3.2.1. Selecting Mitigation Technique . . . . . . . . . . . 9 | 3.2.1. Selecting Mitigation Technique . . . . . . . . . . . 9 | |||
3.3. Setting up for Detection Based on Attack Detail or | 3.3. Training Flow Collector Using Supervised Machine Learning 11 | |||
Baseline . . . . . . . . . . . . . . . . . . . . . . . . 11 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
3.3.1. Supervised Machine Learning of Flow Collector . . . . 11 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
3.3.2. Unsupervised Machine Learning of Flow Collector . . . 12 | 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 | 7.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 | ||||
7.2. Informative References . . . . . . . . . . . . . . . . . 15 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
1. Introduction | 1. Introduction | |||
Denial-of-Service (DDoS), attacks such as volumetric attacks and | Denial-of-Service (DDoS), attacks such as volumetric attacks and | |||
resource-consumption attacks, are critical threats to be handled by | resource-consumption attacks, are critical threats to be handled by | |||
service providers. When such DDoS attacks occur, service providers | service providers. When such DDoS attacks occur, service providers | |||
have to mitigate them immediately to protect or recover their | have to mitigate them immediately to protect or recover their | |||
services. | services. | |||
Therefore, for service providers to immediately protect their network | Therefore, for service providers to immediately protect their network | |||
skipping to change at page 3, line 21 ¶ | skipping to change at page 3, line 16 ¶ | |||
The readers should be familiar with the terms defined in [RFC8612] | The readers should be familiar with the terms defined in [RFC8612] | |||
In addition, this document uses the following terms: | In addition, this document uses the following terms: | |||
Top-talker: A top N list of attackers who attack the same target or | Top-talker: A top N list of attackers who attack the same target or | |||
targets. The list is ordered in terms of a two-tuple bandwidth | targets. The list is ordered in terms of a two-tuple bandwidth | |||
such as bps or pps. | such as bps or pps. | |||
Supervised Machine Learning: A machine-learning technique that maps | Supervised Machine Learning: A machine-learning technique that maps | |||
an input to an output based on example input-output pairs. | an input to an output based on example input-output pairs | |||
Unsupervised Machine Learning: Unsupervised Learning is a machine | ||||
learning technique in which the users do not need to supervise the | ||||
model. | ||||
3. Use Cases | 3. Use Cases | |||
This section describes DOTS-Telemetry use cases that use attributes | This section describes DOTS-Telemetry use cases that use attributes | |||
included in DOTS Telemetry specifications. | included in DOTS Telemetry specifications. | |||
3.1. DDoS Mitigation Based on Attack Traffic Bandwidth | 3.1. DDoS Mitigation Based on Attack Traffic Bandwidth | |||
3.1.1. Mitigating Attack Flow of Top-talker Preferentially | 3.1.1. Mitigating Attack Flow of Top-talker Preferentially | |||
skipping to change at page 4, line 40 ¶ | skipping to change at page 4, line 40 ¶ | |||
* C is for DOTS client functionality | * C is for DOTS client functionality | |||
* S is for DOTS client functionality | * S is for DOTS client functionality | |||
Figure 1: Mitigating DDoS Attack Flow of Top-talker Preferentially | Figure 1: Mitigating DDoS Attack Flow of Top-talker Preferentially | |||
In this use case, the forwarding nodes always send statistics of | In this use case, the forwarding nodes always send statistics of | |||
traffic flow to the flow collectors by using monitoring functions | traffic flow to the flow collectors by using monitoring functions | |||
such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors | such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors | |||
detect attack traffic and send (src_ip, dst_ip, bandwidth)-tuple | detect attack traffic and send (src_ip, dst_ip, bandwidth)-tuple | |||
information of the top talker to the orchestrator using the target- | information of the top talker to the orchestrator using the top- | |||
prefix and top-talkers attribute of DOTS Telemetry. The orchestrator | talkers attribute of DOTS Telemetry. The orchestrator then checks | |||
then checks the available capacity of DMS by using a network | the available capacity of DMS by using a network management protocol | |||
management protocol such as SNMP[RFC3413]. After that, the | such as SNMP[RFC3413]. After that, the orchestrator orders | |||
orchestrator orders forwarding nodes to redirect as much of the top | forwarding nodes to redirect as much of the top taker's traffic to | |||
taker's traffic to the DMS as possible by dissemination of flow- | the DMS as possible by dissemination of flow-specification-rule | |||
specification-rule protocols such as BGP Flowspec[RFC5575]. | protocols such as BGP Flowspec[RFC5575]. | |||
In this case, the flow collector implements a DOTS client while the | In this case, the flow collector implements a DOTS client while the | |||
orchestrator implements a DOTS server. | orchestrator implements a DOTS server. | |||
3.1.2. Optimal DMS Selection for Mitigation | 3.1.2. Optimal DMS Selection for Mitigation | |||
Transit providers, which have a number of DMSs, can deploy the DMSs | Transit providers, which have a number of DMSs, usually deploy a DMS | |||
in clustered form. In the form, they can select DMS to be used to | in various forms to satisfy their requirements; individual or | |||
mitigate DDoS attack under attack time. | clustered. In both forms, they can identify attributes of the DMSs | |||
such as total capacity, available capacity, and the last hop | ||||
bandwidth. | ||||
The aim of this use case is to enable transit providers to select an | The aim of this use case is to enable transit providers to select an | |||
optimal DMS for mitigation based on the bandwidth of attack traffic, | optimal DMS for mitigation based on the bandwidth of attack traffic, | |||
capacity of a DMS. Figure 2 gives an overview of this use case. | capacity of a DMS, and the last hop bandwidth. Figure 2 gives an | |||
overview of this use case. | ||||
(Internet Transit Provider) | (Internet Transit Provider) | |||
+-----------+ +--------------+ e.g., SNMP | +-----------+ +--------------+ e.g., SNMP | |||
e.g., IPFIX +-----------+| DOTS | |<--- | e.g., IPFIX +-----------+| DOTS | |<--- | |||
--->| Flow ||C<-->S| Orchestrator | e.g., BGP | --->| Flow ||C<-->S| Orchestrator | e.g., BGP | |||
| collector |+ | |---> (Redirect) | | collector |+ | |---> (Redirect) | |||
+-----------+ +--------------+ | +-----------+ +--------------+ | |||
+------------+ | +------------+ | |||
skipping to change at page 5, line 51 ¶ | skipping to change at page 6, line 5 ¶ | |||
* C is for DOTS client functionality | * C is for DOTS client functionality | |||
* S is for DOTS client functionality | * S is for DOTS client functionality | |||
Figure 2: Optimal DMS selection for Mitigation | Figure 2: Optimal DMS selection for Mitigation | |||
In this use case, the forwarding nodes always send statistics of | In this use case, the forwarding nodes always send statistics of | |||
traffic flow to the flow collectors by using monitoring functions | traffic flow to the flow collectors by using monitoring functions | |||
such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors | such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors | |||
detect attack traffic and send (dst_ip, bandwidth)-tuple information | detect attack traffic and send (dst_ip, bandwidth)-tuple information | |||
to the orchestrator using the target-prefix and total-attack-traffic | to the orchestrator using the total-attack-traffic attribute of DOTS | |||
attribute of DOTS Telemetry. The orchestrator then checks the | Telemetry. The orchestrator then checks the available capacity of | |||
available capacity of the DMSs by using a network management protocol | the DMSs by using a network management protocol such as | |||
such as SNMP[RFC3413]. After that, the orchestrator chooses optimal | SNMP[RFC3413]. After that, the orchestrator chooses optimal DMS | |||
DMS which each attack traffic should be redirected. The orchestrator | which each attack traffic should be redirected. The orchestrator | |||
then orders forwarding nodes to redirect the attack traffic to the | then orders forwarding nodes to redirect the attack traffic to the | |||
optimal DMS by a routing protocol such as BGP[RFC4271]. The | optimal DMS by a routing protocol such as BGP[RFC4271]. The | |||
algorithm of selecting a DMS is out of the scope of this draft. | algorithm of selecting a DMS is out of the scope of this draft. | |||
In this case, the flow collector implements a DOTS client while the | In this case, the flow collector implements a DOTS client while the | |||
orchestrator implements a DOTS server. | orchestrator implements a DOTS server. | |||
3.1.3. Best-path Selection for Redirection | 3.1.3. Best-path Selection for Redirection | |||
A transit-provider network, which adopts a mesh network, has multiple | A transit-provider network, which adopts a mesh network, has multiple | |||
skipping to change at page 7, line 33 ¶ | skipping to change at page 7, line 33 ¶ | |||
DOTS +-||----------------+ e.g., BGP Flow spec | DOTS +-||----------------+ e.g., BGP Flow spec | |||
--->C| || Forwarding |<--- (Redirect) | --->C| || Forwarding |<--- (Redirect) | |||
| ++=== node | | | ++=== node | | |||
+----||-------------+ | +----||-------------+ | |||
|/ | |/ | |||
+--x-----------+ | +--x-----------+ | |||
| DMS | | | DMS | | |||
+--------------+ | +--------------+ | |||
* C is for DOTS client functionality | * C is for DOTS client functionality | |||
* S is for DOTS client functionality | * S is for DOTS client functionality | |||
Figure 3: Best-path Selection for Redirection | Figure 3: Best-path Selection for Redirection | |||
In this use case, the forwarding nodes always send statistics of | In this use case, the forwarding nodes always send statistics of | |||
traffic flow to the flow collectors by using monitoring functions | traffic flow to the flow collectors by using monitoring functions | |||
such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors | such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors | |||
detect attack traffic and send (dst_ip, bandwidth)-tuple information | detect attack traffic and send (dst_ip, bandwidth)-tuple information | |||
to the orchestrator using a target-prefix and total-attack-traffic | to the orchestrator using a total-attack-traffic attribute of DOTS | |||
attribute of DOTS Telemetry. On the other hands, forwarding nodes | Telemetry. On the other hands, forwarding nodes send bandwidth of | |||
send bandwidth of total traffic passing the node and total pipe | total traffic passing the node and total pipe capability to the | |||
capability to the orchestrator using total-traffic and total-pipe- | orchestrator using total-traffic and total-pipe-capability attributes | |||
capability attributes of DOTS Telemetry. The orchestrator then | of DOTS Telemetry. The orchestrator then selects an optimal path to | |||
selects an optimal path to which each attack-traffic flow should be | which each attack-traffic flow should be redirected. After that, the | |||
redirected. After that, the orchestrator orders forwarding nodes to | orchestrator orders forwarding nodes to redirect the attack traffic | |||
redirect the attack traffic to the optimal DMS by dissemination of | to the optimal DMS by dissemination of flow-specification-rules | |||
flow-specification-rules protocols such as BGP Flowspec[RFC5575]. | protocols such as BGP Flowspec[RFC5575]. The algorithm of selecting | |||
The algorithm of selecting a path is out of the scope of this draft. | a path is out of the scope of this draft. | |||
3.1.4. Short but Extreme Volumetric Attack Mitigation | 3.1.4. Short but Extreme Volumetric Attack Mitigation | |||
Short but extreme volumetric attacks, such as pulse wave DDoS | Short but extreme volumetric attacks, such as pulse wave DDoS | |||
attacks, are threats to internet transit provider networks. It is | attacks, are threats to internet transit provider networks. It is | |||
difficult for them to mitigate an attack by DMS by redirecting attack | difficult for them to mitigate an attack by DMS by redirecting attack | |||
flows because it may cause route flapping in the network. The | flows because it may cause route flapping in the network. The | |||
practical way to mitigate short but extreme volumetric attacks is to | practical way to mitigate short but extreme volumetric attacks is to | |||
offload a mitigation actions to a forwarding node. | offload a mitigation actions to a forwarding node. | |||
The aim of this use case is to enable transit providers to mitigate | The aim of this use case is to enable transit providers to mitigate | |||
short but extreme volumetric attacks. Furthermore, the aim is to | short but extreme volumetric attacks and estimate the network-access | |||
estimate the network-access success rate based on the bandwidth of | success rate based on the bandwidth of attack traffic and total pipe | |||
attack traffic and total pipe capability. Figure 4 gives an overview | capability. Figure 4 gives an overview of this use case. | |||
of this use case. | ||||
(Internet Transit Provider) | (Internet Transit Provider) | |||
+------------+ +----------------+ | +------------+ +----------------+ | |||
e.g., | Network | DOTS | Administrative | | e.g., | Network | DOTS | Administrative | | |||
Alert --->| Management |C<--->S| System | e.g., BGP Flow spec | Alert --->| Management |C<--->S| System | e.g., BGP Flow spec | |||
| System | | |---> (Rate-Limit) | | System | | |---> (Rate-Limit) | |||
+------------+ +----------------+ | +------------+ +----------------+ | |||
+------------+ +------------+ e.g., BGP Flow spec | +------------+ +------------+ e.g., BGP Flow spec | |||
skipping to change at page 8, line 48 ¶ | skipping to change at page 8, line 47 ¶ | |||
e.g., X / (X + Y) | e.g., X / (X + Y) | |||
* C is for DOTS client functionality | * C is for DOTS client functionality | |||
* S is for DOTS client functionality | * S is for DOTS client functionality | |||
Figure 4: Short but Extreme Volumetric Attack Mitigation | Figure 4: Short but Extreme Volumetric Attack Mitigation | |||
In this use case, when DDoS attacks occur, the network management | In this use case, when DDoS attacks occur, the network management | |||
system receives alerts. It then sends the target ip address, pipe | system receives alerts. It then sends the target ip address, pipe | |||
capability of the target's link, and bandwidth of the DDoS attack | capability of the target's link, and bandwidth of the DDoS attack | |||
traffic to the administrative system using the target-prefix, total- | traffic to the administrative system using the target, total-pipe- | |||
pipe-capability and total-attack-traffic attributes of DOTS | capability and total-attack-traffic attributes of DOTS Telemetry. | |||
Telemetry. After that, the administrative system orders upper | After that, the administrative system orders upper forwarding nodes | |||
forwarding nodes to carry out rate-limit all traffic destined to the | to carry out rate-limit all traffic destined to the target based on | |||
target based on the pipe capability by the dissemination of the flow- | the pipe capability by the dissemination of the flow -specification- | |||
specification-rules protocols such as BGP Flowspec[RFC5575]. In | rules protocols such as BGP Flowspec[RFC5575]. In addition, the | |||
addition, the administrative system estimates the network-access | administrative system estimates the network-access success rate of | |||
success rate of the target, which is calculated by total pipe | the target, which is calculated by total pipe capability / (total | |||
capability / (total pipe capability + total attack traffic). | pipe capability + total attack traffic). | |||
3.2. DDoS Mitigation Based on Attack Type | 3.2. DDoS Mitigation Based on Attack Type | |||
3.2.1. Selecting Mitigation Technique | 3.2.1. Selecting Mitigation Technique | |||
Some volumetric attacks, such as amplification attacks, can be | Some volumetric attacks, such as amplification attacks, can be | |||
detected with high accuracy by checking the layer-3 or layer-4 | detected with high accuracy by checking the layer-3 or layer-4 | |||
information of attack packets. These attacks can be detected and | information of attack packets. These attacks can be detected and | |||
mitigated through cooperation among forwarding nodes and flow | mitigated through cooperation among forwarding nodes and flow | |||
collectors using IPFIX[RFC7011]. On the other hand, it is necessary | collectors using IPFIX[RFC7011]. On the other hand, it is necessary | |||
skipping to change at page 10, line 37 ¶ | skipping to change at page 10, line 37 ¶ | |||
+------------+ | +------------+ | |||
* C is for DOTS client functionality | * C is for DOTS client functionality | |||
* S is for DOTS server functionality | * S is for DOTS server functionality | |||
Figure 5: DDoS Mitigation Based on Attack Type | Figure 5: DDoS Mitigation Based on Attack Type | |||
In this use case, the forwarding nodes send statistics of traffic | In this use case, the forwarding nodes send statistics of traffic | |||
flow to the flow collectors by using a monitoring function such as | flow to the flow collectors by using a monitoring function such as | |||
IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors detect | IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors detect | |||
attack traffic and send (dst_ip, attack_type)-tuple information to | attack traffic and send (dst_ip, src_port, attack_type)-tuple | |||
the orchestrator the using vendor-id and attack-id attribute of DOTS | information to the orchestrator the using attack-name attribute of | |||
Telemetry. The orchestrator then resolves abused port and orders | DOTS Telemetry. The orchestrator then orders forwarding nodes to | |||
forwarding nodes to block the (dst_ip, src_port)-tuple flow of amp | block the (dst_ip, src_port)-tuple flow of amp attack traffic by | |||
attack traffic by dissemination of flow-specification-rule protocols | dissemination of flow-specification-rule protocols such as BGP | |||
such as BGP Flowspec[RFC5575]. On the other hand, the orchestrator | Flowspec[RFC5575]. On the other hand, the orchestrator orders | |||
orders forwarding nodes to redirect other traffic than the amp attack | forwarding nodes to redirect other traffic than the amp attack | |||
traffic by a routing protocol such as BGP[RFC4271]. | traffic by a routing protocol such as BGP[RFC4271]. | |||
In this case, the flow collector implements a DOTS client while the | In this case, the flow collector implements a DOTS client while the | |||
orchestrator implements a DOTS server. | orchestrator implements a DOTS server. | |||
3.3. Setting up for Detection Based on Attack Detail or Baseline | 3.3. Training Flow Collector Using Supervised Machine Learning | |||
3.3.1. Supervised Machine Learning of Flow Collector | ||||
DDoS detection based on monitoring functions, such as IPFIX[RFC7011], | DDoS detection based on monitoring functions, such as IPFIX[RFC7011], | |||
is a lighter weight method of detecting DDoS attacks than DMSs in | is a lighter weight method of detecting DDoS attacks than DMSs in | |||
internet transit provider networks. On the other hand, DDoS | internet transit provider networks. On the other hand, DDoS | |||
detection based on the DMSs is a more accurate method of detecting | detection based on the DMSs is a more accurate method of detecting | |||
attack traffic or DDoS attacks bettr than flow monitoring. | DDoS attacks than DDoS detection based on flow monitoring. | |||
The aim of this use case is to increases flow collector's detection | The aim of this use case is to increases flow collector's detection | |||
accuracy by carrying out supervised machine-learning techniques | accuracy by carrying out supervised machine-learning techniques based | |||
according to attack detail reported by the DMSs. To use such a | on the detection results of the DMSs. To use such a technique, | |||
technique, forwarding nodes, flow collector, and a DMS should | forwarding nodes, flow collector, and a DMS should cooperate. | |||
cooperate. Figure 5 gives an overview of this use case. | Figure 5 gives an overview of this use case. | |||
+-----------+ | +-----------+ | |||
+-----------+| DOTS | +-----------+| DOTS | |||
e.g., IPFIX | Flow ||S<--- | e.g., IPFIX | Flow ||S<--- | |||
--->| collector || | --->| collector || | |||
+-----------++ | +-----------++ | |||
+------------+ | +------------+ | |||
e.g., IPFIX +------------+| | e.g., IPFIX +------------+| | |||
<---| Forwarding || | <---| Forwarding || | |||
skipping to change at page 11, line 46 ¶ | skipping to change at page 11, line 44 ¶ | |||
|/ |/ |/ | |/ |/ |/ | |||
DOTS +---X--X--X--+ | DOTS +---X--X--X--+ | |||
--->C| DDoS | | --->C| DDoS | | |||
| mitigation | | | mitigation | | |||
| system | | | system | | |||
+------------+ | +------------+ | |||
* C is for DOTS client functionality | * C is for DOTS client functionality | |||
* S is for DOTS client functionality | * S is for DOTS client functionality | |||
Figure 6: Training Supervised Machine Learning of Flow Collector | Figure 6: Training Flow Collector Using Supervised Machine Learning | |||
In this use case, the forwarding nodes always send statistics of | In this use case, the forwarding nodes always send statistics of | |||
traffic flow to the flow collectors by using monitoring functions | traffic flow to the flow collectors by using monitoring functions | |||
such as IPFIX[RFC7011]. When DDoS attacks occur, DDoS orchestration | such as IPFIX[RFC7011]. When DDoS attacks occur, DDoS orchestration | |||
use case[I-D.ietf-dots-use-cases] is carried out and the DMS | use case[I-D.ietf-dots-use-cases] is carried out and the DMS | |||
mitigates all attack traffic destined for a target. The DDoS- | mitigates all attack traffic destined for a target. The DDoS- | |||
mitigation system reports the vendor-id, attack-id and top-talker to | mitigation system reports the (src_ip, dst_ip)-tuple information of | |||
the flow collector using DOTS telemetry. | the top talker to the orchestrator the using top-talkers attribute of | |||
DOTS Telemetry. | ||||
After mitigating a DDoS attack, the flow collector attaches teacher | After mitigating a DDoS attack, the flow collector attaches teacher | |||
labels, which shows normal traffic or attack type, to the statistics | labels to the statistics of traffic flow based on the reports. The | |||
of traffic flow of top-talker based on the reports. The flow | label shows normal traffic or attack name. The flow collector then | |||
collector then carries out supervised machine learning to increase | carries out supervised machine learning to increase its detection | |||
its detection accuracy, setting the statistics as an explanatory | accuracy, setting the statistics as an explanatory variable and | |||
variable and setting the labels as an objective variable. | setting the labels as an objective variable. | |||
In this case, the DMS implements a DOTS client while the flow | ||||
collector implements a DOTS server. | ||||
3.3.2. Unsupervised Machine Learning of Flow Collector | ||||
DMSs can detect DDoS attack traffic, which means DMSs can also | ||||
identify clean traffic. The aim of this use case is to carry out | ||||
unsupervised machine-learning for anomarly detection according to | ||||
baseline reported by DMSs. To use such a technique, forwarding | ||||
nodes, flow collector, and a DMS should cooperate. Figure 7 gives an | ||||
overview of this use case. | ||||
+-----------+ | ||||
+-----------+| | ||||
DOTS | Flow || | ||||
--->S| collector || | ||||
+-----------++ | ||||
+------------+ | ||||
+------------+| | ||||
| Forwarding || | ||||
| nodes || Traffic | ||||
[ Dst ] <========================++============================== | ||||
| || || | ||||
| || |+ | ||||
+---||-------+ | ||||
|| | ||||
|/ | ||||
DOTS +---X--------+ | ||||
--->C| DDoS | | ||||
| mitigation | | ||||
| system | | ||||
+------------+ | ||||
* C is for DOTS client functionality | ||||
* S is for DOTS client functionality | ||||
Figure 7: Training Unsupervised Machine Learning of Flow Collector | ||||
In this use case, the forwarding nodes carry out mirroring traffic | ||||
destined a dst ip address. The DMS then identifies clean traffic and | ||||
reports the baseline attributes to the flow collector using DOTS | ||||
telemetry. | ||||
The flow collector then carries out unsupervised machine learning to | ||||
be able to carry out anomarly detection. | ||||
In this case, the DMS implements a DOTS client while the flow | In this case, the DMS implements a DOTS client while the flow | |||
collector implements a DOTS server. | collector implements a DOTS server. | |||
4. Security Considerations | 4. Security Considerations | |||
TBD | TBD | |||
5. IANA Considerations | 5. IANA Considerations | |||
This document does not require any action from IANA. | This document does not require any action from IANA. | |||
6. Acknowledgement | 6. Acknowledgement | |||
TBD | The authors would like to thank among others brabra... | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[I-D.ietf-dots-telemetry] | [I-D.ietf-dots-telemetry] | |||
Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., | Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., | |||
and J. Shallow, "Distributed Denial-of-Service Open Threat | and J. Shallow, "Distributed Denial-of-Service Open Threat | |||
Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-14 | Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-11 | |||
(work in progress), November 2020. | (work in progress), July 2020. | |||
[I-D.ietf-dots-use-cases] | [I-D.ietf-dots-use-cases] | |||
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, | Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, | |||
L., and K. Nishizuka, "Use cases for DDoS Open Threat | L., and K. Nishizuka, "Use cases for DDoS Open Threat | |||
Signaling", draft-ietf-dots-use-cases-25 (work in | Signaling", draft-ietf-dots-use-cases-25 (work in | |||
progress), July 2020. | progress), July 2020. | |||
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network | [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network | |||
Management Protocol (SNMP) Applications", STD 62, | Management Protocol (SNMP) Applications", STD 62, | |||
RFC 3413, DOI 10.17487/RFC3413, December 2002, | RFC 3413, DOI 10.17487/RFC3413, December 2002, | |||
skipping to change at page 15, line 29 ¶ | skipping to change at page 14, line 4 ¶ | |||
Authors' Addresses | Authors' Addresses | |||
Yuhei Hayashi | Yuhei Hayashi | |||
NTT | NTT | |||
3-9-11, Midori-cho | 3-9-11, Midori-cho | |||
Musashino-shi, Tokyo 180-8585 | Musashino-shi, Tokyo 180-8585 | |||
Japan | Japan | |||
Email: yuuhei.hayashi@gmail.com | Email: yuuhei.hayashi@gmail.com | |||
Meiling Chen | Meiling Chen | |||
CMCC | CMCC | |||
32, Xuanwumen West | 32, Xuanwumen West | |||
BeiJing, BeiJing 100053 | BeiJing, BeiJing 100053 | |||
China | China | |||
Email: chenmeiling@chinamobile.com | Email: | |||
chenmeiling@chinamobile.com | ||||
Li Su | ||||
CMCC | ||||
32, Xuanwumen West | ||||
BeiJing 100053 | ||||
China | ||||
Email: suli@chinamobile.com | ||||
End of changes. 24 change blocks. | ||||
135 lines changed or deleted | 80 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |