rfc9387xml2.original.xml | rfc9387.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="US-ASCII"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<!-- | ||||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []> | <!DOCTYPE rfc [ | |||
<?rfc toc="yes"?> | <!ENTITY nbsp " "> | |||
<?rfc tocompact="yes"?> | <!ENTITY zwsp "​"> | |||
<?rfc tocdepth="3"?> | <!ENTITY nbhy "‑"> | |||
<?rfc tocindent="yes"?> | <!ENTITY wj "⁠"> | |||
<?rfc symrefs="yes"?> | ||||
<?rfc sortrefs="yes"?> | ||||
<?rfc comments="yes"?> | ||||
<?rfc inline="yes"?> | ||||
<?rfc compact="yes"?> | ||||
<?rfc subcompact="no"?> | ||||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ | ||||
<!-- One method to get references from the online citation libraries. | ||||
There has to be one entity for each item to be referenced. | ||||
An alternate method (rfc include) is described in the references. --> | ||||
]> | ]> | |||
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | ||||
<!-- used by XSLT processors --> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" | |||
<!-- For a complete list and description of processing instructions (PIs), | info" consensus="true" docName="draft-ietf-dots-telemetry-use-cases-15" number=" | |||
please see http://xml.resource.org/authoring/README.html. --> | 9387" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" | |||
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds | tocDepth="4" symRefs="true" sortRefs="true" version="3"> | |||
might want to use. | ||||
(Here they are set differently than their defaults in xml2rfc v1.32) --> | <!-- xml2rfc v2v3 conversion 3.15.3 --> | |||
<?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="4"?> | ||||
<!-- 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" ?> | ||||
<!-- keep one blank line between list items --> | ||||
<!-- end of list of popular I-D processing instructions --> | ||||
<rfc category="info" docName="draft-ietf-dots-telemetry-use-cases-15" | ||||
ipr="trust200902"> | ||||
<!-- ***** FRONT MATTER ***** --> | ||||
<front> | <front> | |||
<title abbrev="DOTS Telemetry Use Cases">Use Cases for DDoS Open Threat | <title abbrev="DOTS Telemetry Use Cases">Use Cases for DDoS Open Threat | |||
Signaling (DOTS) Telemetry</title> | Signaling (DOTS) Telemetry</title> | |||
<seriesInfo name="RFC" value="9387"/> | ||||
<author fullname="Yuhei Hayashi" initials="Y." surname="Hayashi"> | <author fullname="Yuhei Hayashi" initials="Y." surname="Hayashi"> | |||
<organization abbrev="NTT">NTT</organization> | <organization abbrev="NTT">NTT</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>3-9-11, Midori-cho</street> | <street>3-9-11, Midori-cho</street> | |||
<city>Musashino-shi</city> | ||||
<region>Tokyo</region> | <region>Tokyo</region> | |||
<code>180-8585</code> | <code>180-8585</code> | |||
<country>Japan</country> | <country>Japan</country> | |||
</postal> | </postal> | |||
<email>yuuhei.hayashi@gmail.com</email> | <email>yuuhei.hayashi@gmail.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Meiling Chen" initials="M." surname="Chen"> | <author fullname="Meiling Chen" initials="M." surname="Chen"> | |||
<organization abbrev="CMCC">CMCC</organization> | <organization abbrev="China Mobile">China Mobile</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>32, Xuanwumen West</street> | <street>32, Xuanwumen West</street> | |||
<city>Beijing</city> | ||||
<city>BeiJing</city> | ||||
<region>BeiJing</region> | ||||
<code>100053</code> | <code>100053</code> | |||
<country>China</country> | <country>China</country> | |||
</postal> | </postal> | |||
<email>chenmeiling@chinamobile.com</email> | <email>chenmeiling@chinamobile.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Li Su" initials="L." surname="Su"> | ||||
<author fullname="Li Su" initials="Li." surname="Su"> | <organization abbrev="China Mobile">China Mobile</organization> | |||
<organization>CMCC</organization> | ||||
<address> | <address> | |||
<postal> | <postal> | |||
<street>32, Xuanwumen West</street> | <street>32, Xuanwumen West</street> | |||
<city>Beijing</city> | ||||
<city>BeiJing, BeiJing</city> | ||||
<code>100053</code> | <code>100053</code> | |||
<country>China</country> | <country>China</country> | |||
</postal> | </postal> | |||
<email>suli@chinamobile.com</email> | <email>suli@chinamobile.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date month="April" year="2023"/> | ||||
<date day="23" month="October" year="2022" /> | <area>sec</area> | |||
<workgroup>dots</workgroup> | ||||
<area>Security Area</area> | ||||
<workgroup>DOTS</workgroup> | ||||
<keyword>Internet-Draft</keyword> | ||||
<abstract> | <abstract> | |||
<t>DDoS Open Threat Signaling (DOTS) Telemetry enriches the | <t>DDoS Open Threat Signaling (DOTS) telemetry enriches the base DOTS | |||
base DOTS protocols to assist the mitigator in using efficient DDoS | protocols to assist the mitigator in using efficient DDoS attack | |||
attack mitigation techniques in a network. This document presents sample | mitigation techniques in a network. | |||
use cases for DOTS Telemetry. It discusses what components | This document presents sample use cases for DOTS telemetry. It discusses what | |||
are deployed in the network, how they cooperate, and what information is | components are deployed in the network, how they cooperate, and what | |||
exchanged to effectively use these techniques.</t> | information is exchanged to effectively use these techniques.</t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section anchor="section_introduction" title="Introduction"> | ||||
<section anchor="section_introduction" numbered="true" toc="default"> | ||||
<name>Introduction</name> | ||||
<t>Distributed Denial-of-Service (DDoS) attacks, such as volumetric | <t>Distributed Denial-of-Service (DDoS) attacks, such as volumetric | |||
attacks and resource-consumption attacks, are critical threats to be | attacks and resource-consuming attacks, are critical threats to be | |||
handled by service providers. When such DDoS attacks occur, service | handled by service providers. When such DDoS attacks occur, service | |||
providers have to mitigate them immediately to protect or recover their | providers have to mitigate them immediately to protect or recover their | |||
services.</t> | services.</t> | |||
<t>For service providers to immediately protect their network | ||||
<t>Therefore, for service providers to immediately protect their network | ||||
services from DDoS attacks, DDoS mitigation needs to be highly | services from DDoS attacks, DDoS mitigation needs to be highly | |||
automated. To that aim, multivendor components involved in DDoS attack | automated. To that aim, multivendor components involved in DDoS attack | |||
detection and mitigation should cooperate and support standard | detection and mitigation should cooperate and support standard | |||
interfaces.</t> | interfaces.</t> | |||
<t>DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time | <t>DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time | |||
signaling, threat-handling requests, and data filtering between the | signaling, threat-handling requests, and data filtering between the | |||
multivendor elements <xref target="RFC9132"></xref><xref | multivendor elements <xref target="RFC9132" format="default"/> <xref targe | |||
target="RFC8783"></xref>. DOTS Telemetry enriches the DOTS protocols | t="RFC8783" format="default"/>. DOTS telemetry enriches the DOTS protocols | |||
with various telemetry attributes allowing optimal DDoS attack | with various telemetry attributes allowing optimal DDoS attack | |||
mitigation <xref target="RFC9244"></xref>. This document | mitigation <xref target="RFC9244" format="default"/>. | |||
presents sample use cases for DOTS Telemetry which makes concrete | This document presents sample use cases for DOTS telemetry to enhance the | |||
overview and purpose described in <xref target="RFC9244"></xref>. | overview and the purpose described in | |||
<xref target="RFC9244" format="default"/>. | ||||
This document also presents what components are deployed | This document also presents what components are deployed | |||
in the network, how they cooperate, and what information is exchanged to | in the network, how they cooperate, and what information is exchanged to | |||
effectively use attack-mitigation techniques.</t> | effectively use attack-mitigation techniques.</t> | |||
</section> | </section> | |||
<section anchor="section_terms" numbered="true" toc="default"> | ||||
<section anchor="section_terms" title="Terminology"> | <name>Terminology</name> | |||
<t>The readers should be familiar with the terms defined in <xref | <t>Readers should be familiar with the terms defined in <xref target="RFC8 | |||
target="RFC8612"></xref>, <xref target="RFC8903"></xref> and <xref | 612" format="default"/>, <xref target="RFC8903" format="default"/>, and <xref ta | |||
target="RFC9244"></xref>.</t> | rget="RFC9244" format="default"/>.</t> | |||
<t>In addition, this document uses the following terms:</t> | <t>In addition, this document uses the following terms:</t> | |||
<dl newline="false" spacing="normal"> | ||||
<t><list style="hanging"> | <dt>Supervised Machine Learning:</dt> | |||
<t hangText="Top-talker:">A list of attack sources that are involved | <dd>A machine-learning | |||
in an attack and which are generating an important part of the | ||||
attack traffic.</t> | ||||
<t hangText="Supervised Machine Learning:">A machine-learning | ||||
technique in which labeled data is used to train the algorithms (the | technique in which labeled data is used to train the algorithms (the | |||
input and output data are known).</t> | input and output data are known).</dd> | |||
<dt>Unsupervised Machine Learning:</dt> | ||||
<t hangText="Unsupervised Machine Learning:">A machine learning | <dd>A machine-learning | |||
technique in which unlabeled data is used to train the algorithms | technique in which unlabeled data is used to train the algorithms | |||
(the data has no historical labels).</t> | (the data has no historical labels).</dd> | |||
</list></t> | </dl> | |||
</section> | </section> | |||
<section anchor="section_use_cases" title="Telemetry Use Cases"> | <section anchor="section_use_cases" numbered="true" toc="default"> | |||
<t>This section describes DOTS telemetry use cases that use attributes | <name>Telemetry Use Cases</name> | |||
included in the DOTS telemetry specification <xref | <t>This section describes DOTS telemetry use cases that use telemetry attr | |||
target="RFC9244"></xref>.</t> | ibutes | |||
included in the DOTS telemetry specification <xref target="RFC9244" format | ||||
="default"/>.</t> | ||||
<t>The following subsections assume that once the DOTS signal channel is | <t>The following subsections assume that once the DOTS signal channel is | |||
established, DOTS clients proceed with the telemetry setup configuration | established, DOTS clients will proceed with the telemetry setup configur | |||
as detailed in Section 7 of <xref target="RFC9244"></xref>. | ation | |||
detailed in <xref target="RFC9244" sectionFormat="of" section="7"/>. | ||||
The following telemetry parameters are used:</t> | The following telemetry parameters are used:</t> | |||
<ul spacing="normal" bare="false" empty="false" indent="3"> | <ul spacing="normal" bare="false" empty="false" indent="3"> | |||
<li> 'measurement-interval' to define the period during which percentile | <li>"measurement-interval" defines the period during which percentiles | |||
s | ||||
are computed.</li> | are computed.</li> | |||
<li>'measurement-sample' to define the time distribution for | <li>"measurement-sample" defines the time distribution for | |||
measuring values that are used to compute percentiles.</li> | measuring values that are used to compute percentiles.</li> | |||
</ul> | </ul> | |||
<section anchor="section_use_cases_ddos_mitigation_resource_assign" number | ||||
<section anchor="section_use_cases_ddos_mitigation_resource_assign" | ed="true" toc="default"> | |||
title="Mitigation Resources Assignment"> | <name>Mitigation Resources Assignment</name> | |||
<section anchor="section_use_cases_ddos_mitigation_bandwidth_top-talker" | <section anchor="section_use_cases_ddos_mitigation_bandwidth_top-talker" | |||
title="Mitigating Attack Flow of Top-talker Preferentially"> | numbered="true" toc="default"> | |||
<name>Mitigating Attack Flow of Top Talker Preferentially</name> | ||||
<t>Some transit providers have to mitigate large-scale DDoS | <t>Some transit providers have to mitigate large-scale DDoS | |||
attacks by using DDoS Mitigation Systems (DMSes) with limited | attacks using DDoS Mitigation Systems (DMSes) with limited | |||
resources, which are already deployed in their network. For example, | resources that are already deployed in their network. For example, | |||
recently reported large DDoS attacks exceeded several Tbps. | recently reported large DDoS attacks exceeded several Tbps | |||
<xref target="DOTS Overview"></xref></t> | <xref target="DOTS_Overview" format="default"/>.</t> | |||
<t>This use case enables transit providers to use | <t>This use case enables transit providers to use | |||
their DMS efficiently under volume-based DDoS attacks whose volume | their DMS efficiently under volume-based DDoS attacks whose volume | |||
is more than the available capacity of the DMS. To enable this, the | is more than the available capacity of the DMS. To enable this, the | |||
attack traffic of top-talkers is redirected to the DMS | attack traffic of top talkers is redirected to the DMS | |||
preferentially by cooperation among forwarding nodes, flow | preferentially by cooperation among forwarding nodes, flow | |||
collectors, and orchestrators. </t> | collectors, and orchestrators. </t> | |||
<t><xref target="DDos_attack-flow"/> gives an overview of this use cas | ||||
<t>Figure 1 gives an overview of this use case. Figure 2 provides an | e. <xref target="example_message_body"/> provides an | |||
example of a DOTS telemetry message body that is used to signal | example of a DOTS telemetry message body that is used to signal | |||
top-talkers (2001:db8:1::/48 and 2001:db8:2::/48).</t> | top talkers (2001:db8:1::/48 and 2001:db8:2::/48).</t> | |||
<figure anchor="DDos_attack-flow"> | ||||
<t><figure align="center"> | <name>Mitigating Attack Flow of Top Talker Preferentially</name> | |||
<artwork><![CDATA[ | <artwork type="" align="left" alt=""><![CDATA[ | |||
(Internet Transit Provider) | (Internet Transit Provider) | |||
+-----------+ +--------------+ SNMP or YANG/NETCONF | +-----------+ +--------------+ SNMP or YANG/NETCONF | |||
IPFIX +-----------+| DOTS | |<--- | IPFIX +-----------+| DOTS | |<--- | |||
--->| Flow ||C<-->S| Orchestrator | BGP Flowspec | --->| Flow ||C<-->S| Orchestrator | BGP Flowspec | |||
| collector |+ | |---> (Redirect) | | collector |+ | |---> (Redirect) | |||
+-----------+ +--------------+ | +-----------+ +--------------+ | |||
+-------------+ | +-------------+ | |||
IPFIX +-------------+| BGP Flowspec (Redirect) | IPFIX +-------------+| BGP Flowspec (Redirect) | |||
<---| Forwarding ||<--- | <---| Forwarding ||<--- | |||
| nodes || | | nodes || | |||
| || DDoS Attack | | || DDoS Attack | |||
[ Target(s) ]<========================================== | [ Target(s) ]<========================================== | |||
| ++=========================[top-talker] | | ++=========================[top talker] | |||
| || ++======================[top-talker] | | || ++======================[top talker] | |||
+----|| ||---+ | +----|| ||----+ | |||
|| || | || || | |||
|| || | || || | |||
|/ |/ | |/ |/ | |||
+----x--x----+ | +----x--x----+ | |||
| DDoS | SNMP or YANG/NETCONF | | DDoS | SNMP or YANG/NETCONF | |||
| mitigation |<--- | | mitigation |<--- | |||
| system | | | system | | |||
+------------+ | +------------+ | |||
* C is for DOTS client functionality | C: DOTS client functionality | |||
* S is for DOTS server functionality | S: DOTS server functionality | |||
]]></artwork> | ||||
Figure 1: Mitigating DDoS Attack Flow of Top-talkers Preferentially | </figure> | |||
<figure anchor="example_message_body"> | ||||
]]></artwork> | <name>Example of Message Body to Signal Top Talkers</name> | |||
</figure> <figure> | <sourcecode type="json"><![CDATA[ | |||
<artwork><![CDATA[ | ||||
{ | { | |||
"ietf-dots-telemetry:telemetry": { | "ietf-dots-telemetry:telemetry": { | |||
"pre-or-ongoing-mitigation": [ | "pre-or-ongoing-mitigation": [ | |||
{ | { | |||
"target": { | "target": { | |||
"target-prefix": [ | "target-prefix": [ | |||
"2001:db8::1/128" | "2001:db8::1/128" | |||
] | ] | |||
}, | }, | |||
"total-attack-traffic-protocol": [ | "total-attack-traffic-protocol": [ | |||
skipping to change at line 301 ¶ | skipping to change at line 229 ¶ | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ||||
</figure> | ||||
Figure 2: An Example of Message Body to Signal Top-Talkers | <t>The forwarding nodes send traffic statistics to the flow collectors, e.g., | |||
]]></artwork> | using IP Flow Information Export (IPFIX) <xref target="RFC7011" | |||
</figure></t> | format="default"/>. When DDoS attacks occur, the flow collectors identify the | |||
attack traffic and send information about the top talkers to the orchestrator | ||||
<t>The forwarding nodes send traffic statistics to the flow | using the "target-prefix" and "top-talkers" DOTS telemetry attributes. The | |||
collectors, e.g., using IP Flow Information Export (IPFIX) <xref targe | orchestrator then checks the available capacity of the DMSes using a | |||
t="RFC7011"></xref>. | network management protocol, such as the Simple Network Management Protocol | |||
When DDoS attacks occur, the flow collectors identify the attack | (SNMP) <xref target="RFC3413" format="default"/> or YANG with the Network | |||
traffic and send information about the top-talkers to the orchestrator | Configuration Protocol (YANG/NETCONF) <xref target="RFC7950" | |||
using the "target-prefix" and "top-talkers" DOTS telemetry | format="default"/>. After that, the orchestrator orders the forwarding nodes | |||
attributes. The orchestrator then checks the available capacity of | to redirect as much of the top talker's traffic to the DMSes as they can | |||
the DMSes by using a network management protocol, such as Simple Netwo | handle by dissemination of Flow Specifications using tools such as Border | |||
rk | Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) | |||
Management Protocol (SNMP) <xref target="RFC3413"></xref> or | <xref target="RFC8955" format="default"/>. </t> | |||
YANG with Network Configuration Protocol (YANG/NETCONF) <xref target=" | ||||
RFC7950"></xref>. | ||||
After that, the orchestrator | ||||
orders the forwarding nodes to redirect as much of the top-talker's tr | ||||
affic | ||||
to each DMS as that DMS can handle by dissemination of Flow | ||||
Specifications using tools such as Border Gateway Protocol | ||||
Dissemination of Flow Specification Rules (BGP Flowspec) <xref target= | ||||
"RFC8955"></xref>. </t> | ||||
<t>The flow collector implements a DOTS client while the | <t>The flow collector implements a DOTS client while the | |||
orchestrator implements a DOTS server.</t> | orchestrator implements a DOTS server.</t> | |||
</section> | </section> | |||
<section anchor="dms_selection" numbered="true" toc="default"> | ||||
<section anchor="dms_selection" | <name>DMS Selection for Mitigation</name> | |||
title="DMS Selection for Mitigation"> | ||||
<t>Transit providers can deploy their DMSes in clusters. | <t>Transit providers can deploy their DMSes in clusters. | |||
Then, they can select the DMS to be used to mitigate | Then, they can select the DMS to be used to mitigate | |||
a DDoS attack at the time of an attack.</t> | a DDoS attack at the time of an attack.</t> | |||
<t>This use case enables transit providers to select a DMS with | ||||
<t>This use case enables transit providers to select | sufficient capacity for mitigation based on the volume of the attack | |||
a DMS with sufficient capacity for mitigation based on the volume of t | traffic and the capacity of the DMS. <xref target="DMS_selection"/> | |||
he attack | gives an overview of this use case. <xref target="message_body"/> | |||
traffic and the capacity of a DMS. Figure 3 gives an overview of | provides an example of a DOTS telemetry message body that is used to | |||
this use case. Figure 4 provides an example of a DOTS telemetry | signal percentiles for total attack traffic. | |||
message body that is used to signal various attack traffic | </t> | |||
percentiles.</t> | <figure anchor="DMS_selection"><name>DMS Selection for Mitigation</name | |||
> | ||||
<t><figure align="center"> | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
<artwork><![CDATA[ | ||||
(Internet Transit Provider) | (Internet Transit Provider) | |||
+-----------+ +--------------+ SNMP or YANG/NETCONF | +-----------+ +--------------+ SNMP or YANG/NETCONF | |||
IPFIX +-----------+| DOTS | |<--- | IPFIX +-----------+| DOTS | |<--- | |||
--->| Flow ||C<-->S| Orchestrator | BGP (Redirect) | --->| Flow ||C<-->S| Orchestrator | BGP (Redirect) | |||
| collector |+ | |---> | | collector |+ | |---> | |||
+-----------+ +--------------+ | +-----------+ +--------------+ | |||
+------------+ | +------------+ | |||
IPFIX +------------+| BGP (Redirect) | IPFIX +------------+| BGP (Redirect) | |||
skipping to change at line 367 ¶ | skipping to change at line 290 ¶ | |||
++====++ || (congested DMS) | ++====++ || (congested DMS) | |||
|| || +-----------+ | || || +-----------+ | |||
|| |/ | DMS3 | | || |/ | DMS3 | | |||
|| +-----x------+ |<--- SNMP or YANG/NETCONF | || +-----x------+ |<--- SNMP or YANG/NETCONF | |||
|/ | DMS2 |--------+ | |/ | DMS2 |--------+ | |||
+--x---------+ |<--- SNMP or YANG/NETCONF | +--x---------+ |<--- SNMP or YANG/NETCONF | |||
| DMS1 |------+ | | DMS1 |------+ | |||
| |<--- SNMP or YANG/NETCONF | | |<--- SNMP or YANG/NETCONF | |||
+------------+ | +------------+ | |||
* C is for DOTS client functionality | C: DOTS client functionality | |||
* S is for DOTS server functionality | S: DOTS server functionality | |||
]]></artwork></figure> | ||||
Figure 3: DMS Selection for Mitigation | <figure anchor="message_body"><name>Example of Message Body with Total | |||
]]></artwork> | Attack Traffic</name> | |||
</figure> <figure> | <sourcecode name="" type="json"><![CDATA[ | |||
<artwork><![CDATA[ | ||||
{ | { | |||
"ietf-dots-telemetry:telemetry": { | "ietf-dots-telemetry:telemetry": { | |||
"pre-or-ongoing-mitigation": [ | "pre-or-ongoing-mitigation": [ | |||
{ | { | |||
"target": { | "target": { | |||
"target-prefix": [ | "target-prefix": [ | |||
"192.0.2.3/32" | "192.0.2.3/32" | |||
] | ] | |||
}, | }, | |||
"total-attack-traffic": [ | "total-attack-traffic": [ | |||
skipping to change at line 398 ¶ | skipping to change at line 318 ¶ | |||
"mid-percentile-g": "800", | "mid-percentile-g": "800", | |||
"high-percentile-g": "1000", | "high-percentile-g": "1000", | |||
"peak-g":"1100", | "peak-g":"1100", | |||
"current-g":"700" | "current-g":"700" | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ||||
Figure 4: Example of Message Body with Total Attack Traffic | </figure> | |||
]]></artwork> | ||||
</figure></t> | ||||
<t>The forwarding nodes send traffic statistics to the flow | <t>The forwarding nodes send traffic statistics to the flow | |||
collectors, e.g., using IPFIX. When DDoS attacks occur, the flow | collectors, e.g., using IPFIX. When DDoS attacks occur, the flow | |||
collectors identify the attack traffic and send information about the | collectors identify the attack traffic and send information about | |||
attack traffic volume to the orchestrator by using the "target-prefix" | the attack traffic volume to the orchestrator using the | |||
and "total-attack-traffic" DOTS telemetry attributes. The | "target-prefix" and "total-attack-traffic" DOTS telemetry | |||
orchestrator then checks the available capacity of the DMSes by using | attributes. The orchestrator then checks the available capacity of | |||
a network management protocol, such as Simple Network | the DMSes using a network management protocol, such as the Simple | |||
Management Protocol (SNMP) <xref target="RFC3413"></xref> or | Network Management Protocol (SNMP) <xref target="RFC3413" | |||
YANG with Network Configuration Protocol (YANG/NETCONF) <xref target= | format="default"/> or YANG with the Network Configuration Protocol | |||
"RFC7950"></xref>. | (YANG/NETCONF) <xref target="RFC7950" format="default"/>. After | |||
After that, the | that, the orchestrator selects a DMS with sufficient capacity to | |||
orchestrator selects a DMS with sufficient capacity to which attack tr | which attack traffic should be redirected. For example, a simple | |||
affic | DMS selection algorithm can be used to choose a DMS whose available | |||
should be redirected. For example, a simple DMS selection algorithm | capacity is greater than the "peak-g" telemetry attribute indicated in | |||
is to choose a DMS whose available capacity is greater than the | the | |||
"peak-g" attribute indicated in the DOTS telemetry message. The | DOTS telemetry message. The orchestrator orders the appropriate | |||
orchestrator orders the appropriate forwarding nodes to redirect the | forwarding nodes to redirect the attack traffic to the DMS relying | |||
attack traffic to the DMS relying upon routing policies, | upon routing policies, such as BGP <xref target="RFC4271" | |||
such as BGP <xref target="RFC4271"></xref>. </t> | format="default"/>. </t> | |||
<t>The detailed DMS selection algorithm is out of the scope of this | <t>The detailed DMS selection algorithm is out of the scope of this | |||
document.</t> | document.</t> | |||
<t>The flow collector implements a DOTS client while the | <t>The flow collector implements a DOTS client while the | |||
orchestrator implements a DOTS server.</t> | orchestrator implements a DOTS server.</t> | |||
</section> | </section> | |||
<section anchor="redirection_path_selection" numbered="true" toc="defaul | ||||
<section anchor="redirection_path_selection" | t"> | |||
title="Path Selection for Redirection"> | <name>Path Selection for Redirection</name> | |||
<t>A transit provider network has multiple paths to convey attack | <t>A transit provider network has multiple paths to convey attack | |||
traffic to a DMS. In such a network, the attack traffic can be | traffic to a DMS. In such a network, the attack traffic can be | |||
conveyed while avoiding congested links by adequately selecting an | conveyed while avoiding congested links by adequately selecting an | |||
available path.</t> | available path.</t> | |||
<t>This use case enables transit providers to select a path with | ||||
sufficient bandwidth for redirecting attack traffic to a DMS | ||||
according to the bandwidth of the attack traffic and total | ||||
traffic. <xref target="path_selection"/> gives an overview of this | ||||
use case. <xref target="message_total_attack"/> provides an example | ||||
of a DOTS telemetry message body that is used to signal percentiles | ||||
for total traffic and total attack traffic. | ||||
</t> | ||||
<t>This use case enables transit providers to select | <figure anchor="path_selection"><name>Path Selection for Redirection</name> | |||
a path with sufficient bandwidth for redirecting attack traffic to a D | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
MS according to | ||||
the bandwidth of the attack traffic and total traffic. Figure 5 | ||||
gives an overview of this use case. Figure 6 provides an example of | ||||
a DOTS telemetry message body that is used to signal various attack | ||||
traffic percentiles and total traffic percentiles.</t> | ||||
<t><figure align="center"> | ||||
<artwork><![CDATA[ | ||||
(Internet Transit Provider) | (Internet Transit Provider) | |||
+-----------+ +--------------+ DOTS | +-----------+ +--------------+ DOTS | |||
+-----------+| | |S<--- | +-----------+| | |S<--- | |||
IPFIX | Flow || DOTS | Orchestrator | | IPFIX | Flow || DOTS | Orchestrator | | |||
-->| collector ||C<-->S| | BGP Flowspec (Redirect) | -->| collector ||C<-->S| | BGP Flowspec (Redirect) | |||
| |+ | |---> | | |+ | |---> | |||
+-----------+ +--------------+ | +-----------+ +--------------+ | |||
DOTS +------------+ DOTS +------------+ IPFIX | DOTS +------------+ DOTS +------------+ IPFIX | |||
skipping to change at line 471 ¶ | skipping to change at line 387 ¶ | |||
|| / | || / | |||
DOTS +-||----------------+ BGP Flowspec (Redirect) | DOTS +-||----------------+ BGP Flowspec (Redirect) | |||
--->C| || Forwarding |<--- | --->C| || Forwarding |<--- | |||
| ++=== node | | | ++=== node | | |||
+----||-------------+ | +----||-------------+ | |||
|/ | |/ | |||
+--x-----------+ | +--x-----------+ | |||
| DMS | | | DMS | | |||
+--------------+ | +--------------+ | |||
* C is for DOTS client functionality | C: DOTS client functionality | |||
* S is for DOTS server functionality | S: DOTS server functionality | |||
]]></artwork> | ||||
Figure 5: Path Selection for Redirection | </figure> | |||
]]></artwork> | <figure anchor="message_total_attack"><name>Example of Message Body with Total A | |||
</figure> <figure> | ttack Traffic and Total Traffic</name> | |||
<artwork><![CDATA[ | <sourcecode name="" type="json"><![CDATA[ | |||
{ | { | |||
"ietf-dots-telemetry:telemetry": { | "ietf-dots-telemetry:telemetry": { | |||
"pre-or-ongoing-mitigation": [ | "pre-or-ongoing-mitigation": [ | |||
{ | { | |||
"target": { | "target": { | |||
"target-prefix": [ | "target-prefix": [ | |||
"2001:db8::1/128" | "2001:db8::1/128" | |||
] | ] | |||
}, | }, | |||
"total-traffic": [ | "total-traffic": [ | |||
skipping to change at line 509 ¶ | skipping to change at line 423 ¶ | |||
"mid-percentile-g": "800", | "mid-percentile-g": "800", | |||
"high-percentile-g": "1000", | "high-percentile-g": "1000", | |||
"peak-g": "1100", | "peak-g": "1100", | |||
"current-g": "700" | "current-g": "700" | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ||||
</figure> | ||||
Figure 6: An Example of Message Body with Total Attack | <t>The forwarding nodes send traffic statistics to the flow collectors, e.g., | |||
Traffic and Total Traffic | using IPFIX. When DDoS attacks occur, the flow collectors identify attack | |||
]]></artwork> | traffic and send information about the attack traffic volume to the | |||
</figure></t> | orchestrator using the "target-prefix" and "total-attack-traffic" DOTS | |||
telemetry attributes. The underlying forwarding nodes send the volume of the | ||||
<t>The forwarding nodes send traffic statistics to the flow | total traffic passing the node to the orchestrator using the | |||
collectors, e.g., using IPFIX. When DDoS attacks occur, the flow | "total-traffic" telemetry attributes. The orchestrator then selects a path | |||
collectors identify attack traffic and send information about the | with sufficient bandwidth to which the flow of attack traffic should be | |||
attack traffic volume to the orchestrator by using "target-prefix" | redirected. For example, a simple selection algorithm can be used to | |||
and "total-attack-traffic" DOTS telemetry attributes. | choose a path whose available capacity is greater than the "peak-g" telemetry at | |||
The underlying forwarding nodes send the volume on the total | tribute | |||
traffic passing the node to the orchestrator by using "total-traffic" | that was indicated in a DOTS telemetry message. After that, the orchestrator | |||
telemetry attributes. The orchestrator then selects a path with suffic | orders the appropriate forwarding nodes to redirect the attack traffic to the | |||
ient bandwidth | DMS by dissemination of Flow Specifications using tools such as BGP Flowspec | |||
to which attack-traffic flow should be redirected. For example, | <xref target="RFC8955" format="default"/>.</t> | |||
the simple algorithm of the selection is to choose a path whose | ||||
available capacity is greater than the "peak-g" attribute that was | ||||
indicated in a DOTS telemetry message. After that, the orchestrator or | ||||
ders the | ||||
appropriate forwarding nodes to redirect the attack traffic to the | ||||
DMS by dissemination of Flow Specifications using tools | ||||
such as Border Gateway Protocol Dissemination of Flow Specification | ||||
Rules (BGP Flowspec) <xref target="RFC8955"></xref>.</t> | ||||
<t>The detailed path selection algorithm is out of the scope of this | <t>The detailed path selection algorithm is out of the scope of this | |||
document.</t> | document.</t> | |||
<t>The flow collector and forwarding nodes implement a DOTS client | <t>The flow collector and forwarding nodes implement a DOTS client | |||
while the orchestrator implements a DOTS server.</t> | while the orchestrator implements a DOTS server.</t> | |||
</section> | </section> | |||
<section anchor="section_use_cases_ddos_mitigation_bandwidth_offloadingv | ||||
<section anchor="section_use_cases_ddos_mitigation_bandwidth_offloadingv | olumetricattackflow" numbered="true" toc="default"> | |||
olumetricattackflow" | <name>Short but Extreme Volumetric Attack Mitigation</name> | |||
title="Short but Extreme Volumetric Attack Mitigation"> | ||||
<t>Short but extreme volumetric attacks, such as pulse wave DDoS | <t>Short but extreme volumetric attacks, such as pulse wave DDoS | |||
attacks, are threats to Internet transit provider networks. | attacks, are threats to Internet transit provider networks. These | |||
These attacks start from zero and go to maximum | attacks start from zero and go to maximum values in a very short | |||
values in a very short time span, then go back to zero, and then back | time span. The attacks go back to zero and then back to maximum | |||
to | values, repeating in continuous cycles at short intervals. It is | |||
maximum, repeating in continuous cycles at short intervals. It is | difficult for transit providers to mitigate such an attack with | |||
difficult for the transit providers to mitigate such an attack with th | their DMSes by redirecting attack flows because this may cause route | |||
eir | flapping in the network. The practical way to mitigate short but | |||
DMSes using a redirecting attack flows because this may cause route fl | extreme volumetric attacks is to offload mitigation actions to a | |||
apping | forwarding node.</t> | |||
in the network. | <t>This use case enables transit providers to mitigate short but | |||
The practical way to mitigate short but extreme volumetric attacks is | extreme volumetric attacks. Furthermore, the aim is to estimate the | |||
to | network-access success rate based on the bandwidth of the attack | |||
offload mitigation actions to a forwarding node.</t> | traffic. <xref target="attack_mitigation"/> gives an overview of | |||
this use case. <xref target="total_pipe_capacity"/> provides an | ||||
<t>This use case enables transit providers to | ||||
mitigate short but extreme volumetric attacks. Furthermore, the aim | ||||
is to estimate the network-access success rate based on the | ||||
bandwidth of the attack traffic. Figure 7 gives an overview of this us | ||||
e | ||||
case. Figure 8 provides an example of a DOTS telemetry message body | ||||
that is used to signal total pipe capacity. Figure 9 provides an | ||||
example of a DOTS telemetry message body that is used to signal | example of a DOTS telemetry message body that is used to signal | |||
various attack traffic percentiles and total traffic | total pipe capacity. <xref target="total_attack_traffic"/> provides | |||
percentiles.</t> | an example of a DOTS telemetry message body that is used to signal | |||
various percentiles for total traffic and total attack traffic. | ||||
<t><figure align="center"> | </t> | |||
<artwork><![CDATA[ | ||||
(Internet Transit Provider) | ||||
+------------+ +----------------+ | <figure anchor="attack_mitigation"><name>Short but Extreme Volumetric A | |||
| Network | DOTS | Administrative | | ttack Mitigation</name> | |||
Alert ----->| Management |C<--->S| System | BGP Flowspec (Rate-Limit) | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
| System | | |---> | (Internet Transit Provider) | |||
+------------+ +----------------+ | ||||
+------------+ +------------+ BGP Flowspec (Rate-Limit X bps) | +------------+ +----------------+ | |||
| Forwarding | | Forwarding |<--- | | Network | DOTS | Administrative | BGP Flowspec | |||
| node | | node | | Alert----->| Management |C<--->S| System | (Rate-Limit) | |||
Link1 | | | | DDoS & Normal traffic | | System | | |---> | |||
+------------+ +----------------+ | ||||
BGP Flowspec | ||||
+------------+ +------------+ (Rate-Limit X bps) | ||||
| Forwarding | | Forwarding |<--- | ||||
| node | | node | | ||||
Link1 | | | | DDoS & Normal traffic | ||||
[Target]<------------------------------------================ | [Target]<------------------------------------================ | |||
Pipe +------------+ +------------+ Attack Traffic | Pipe +------------+ +------------+ Attack Traffic | |||
Capability Bandwidth | Capability Bandwidth | |||
X bps Y bps | X bps Y bps | |||
Network access success rate | Network-access success rate | |||
X / (X + Y) | X / (X + Y) | |||
* C is for DOTS client functionality | C: DOTS client functionality | |||
* S is for DOTS server functionality | S: DOTS server functionality | |||
]]></artwork> | ||||
Figure 7: Short but Extreme Volumetric Attack Mitigation | </figure> | |||
<figure anchor="total_pipe_capacity"><name>Example of Message Body with Total Pi | ||||
]]></artwork> | pe Capacity</name> | |||
</figure> <figure> | <sourcecode name="" type="json"><![CDATA[ | |||
<artwork><![CDATA[ | ||||
{ | { | |||
"ietf-dots-telemetry:telemetry-setup": { | "ietf-dots-telemetry:telemetry-setup": { | |||
"telemetry": [ | "telemetry": [ | |||
{ | { | |||
"total-pipe-capacity": [ | "total-pipe-capacity": [ | |||
{ | { | |||
"link-id": "link1", | "link-id": "link1", | |||
"capacity": "1000", | "capacity": "1000", | |||
"unit": "megabit-ps" | "unit": "megabit-ps" | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
Figure 8: Example of Message Body with Total Pipe Capacity | ]]></sourcecode> | |||
]]></artwork> | </figure> | |||
</figure> <figure> | <figure anchor="total_attack_traffic"><name>Example of Message Body with Total A | |||
<artwork><![CDATA[ | ttack Traffic and Total Traffic</name> | |||
<sourcecode name="" type="json"><![CDATA[ | ||||
{ | { | |||
"ietf-dots-telemetry:telemetry": { | "ietf-dots-telemetry:telemetry": { | |||
"pre-or-ongoing-mitigation": [ | "pre-or-ongoing-mitigation": [ | |||
{ | { | |||
"target": { | "target": { | |||
"target-prefix": [ | "target-prefix": [ | |||
"2001:db8::1/128" | "2001:db8::1/128" | |||
] | ] | |||
}, | }, | |||
"total-traffic": [ | "total-traffic": [ | |||
skipping to change at line 643 ¶ | skipping to change at line 546 ¶ | |||
"mid-percentile-g": "400", | "mid-percentile-g": "400", | |||
"high-percentile-g": "500", | "high-percentile-g": "500", | |||
"peak-g": "600", | "peak-g": "600", | |||
"current-g": "400" | "current-g": "400" | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ||||
Figure 9: Example of Message Body with Total Attack Traffic, | </figure> | |||
and Total Traffic | ||||
]]></artwork> | ||||
</figure></t> | ||||
<t>When DDoS attacks occur, the network management system receives | <t>When DDoS attacks occur, the network management system receives | |||
alerts. Then, it sends the target IP address(es) and volume of the | alerts. Then, it sends the target IP address(es) and volume of the | |||
DDoS attack traffic to the administrative system by using the | DDoS attack traffic to the administrative system using the | |||
"target-prefix" and "total-attack-traffic" DOTS telemetry | "target-prefix" and "total-attack-traffic" DOTS telemetry | |||
attributes. After that, the administrative system orders relevant for | attributes. After that, the administrative system orders relevant | |||
warding | forwarding nodes to carry out rate-limiting of all traffic destined | |||
nodes to carry out rate-limiting of all traffic destined to the target | to the target based on the pipe capability by the dissemination of | |||
based on the pipe capability by the dissemination of the Flow | the Flow Specifications using tools such as BGP Flowspec <xref | |||
Specifications using tools such as Border Gateway Protocol | target="RFC8955" format="default"/>. In addition, the | |||
Dissemination of Flow Specification Rules (BGP Flowspec) <xref target= | administrative system estimates the network-access success rate of | |||
"RFC8955"></xref>. | the target, which is calculated by (total-pipe-capability / | |||
In addition, the administrative system estimates the network-access | (total-pipe-capability + total-attack-traffic)). </t> | |||
success rate of the target, which is calculated by | ||||
(total-pipe-capability / (total-pipe-capability + | ||||
total-attack-traffic)). </t> | ||||
<t>Note that total pipe capability information can be gathered by | <t>Note that total pipe capability information can be gathered by | |||
telemetry setup in advance (Section 7.2 of <xref | telemetry setup in advance (<xref target="RFC9244" sectionFormat="of" | |||
target="RFC9244"></xref>).</t> | section="7.2"/>).</t> | |||
<t>The network management system implements a DOTS client | <t>The network management system implements a DOTS client | |||
while the administrative system implements a DOTS server.</t> | while the administrative system implements a DOTS server.</t> | |||
</section> | </section> | |||
<section anchor="section_use_cases_ddos_mitigation_attack_type_technique | ||||
<section anchor="section_use_cases_ddos_mitigation_attack_type_technique | selection" numbered="true" toc="default"> | |||
selection" | <name>Selecting Mitigation Technique Based on Attack Type</name> | |||
title="Selecting Mitigation Technique Based on Attack Type"> | ||||
<t>Some volumetric attacks, such as DNS amplification attacks, can be | <t>Some volumetric attacks, such as DNS 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 by using IPFIX. It may also be necessary to inspect the Lay er 7 | collectors using IPFIX. It may also be necessary to inspect the Layer 7 | |||
information of suspicious packets to detect attacks such as DNS | information of suspicious packets to detect attacks such as DNS | |||
Water Torture Attacks <xref target="DNS Water Torture Attack"></xref>. | water torture attacks <xref target="DNS_Water_Torture_Attack" format=" default"/>. | |||
To carry out the DNS water torture attack, | To carry out the DNS water torture attack, | |||
an attacker commands a botnet to make thousands of DNS requests | an attacker commands a botnet to make thousands of DNS requests | |||
for fake subdomains against an Authoritative Name Server. | for fake subdomains against an authoritative name server. | |||
Such attack traffic should be detected and mitigated at the DMS.</t> | Such attack traffic should be detected and mitigated at the DMS.</t> | |||
<t>This use case enables transit providers to select | <t>This use case enables transit providers to select | |||
a mitigation technique based on the type of attack traffic: | a mitigation technique based on the type of attack traffic, whether it | |||
amplification attack or not. To use such a technique, the attack | is an amplification attack or not. To use such a technique, the attack | |||
traffic is blocked by forwarding nodes or redirected to a DMS based | traffic is blocked by forwarding nodes or redirected to a DMS based | |||
on the attack type through cooperation among forwarding nodes, flow | on the attack type through cooperation among forwarding nodes, flow | |||
collectors, and an orchestrator. </t> | collectors, and an orchestrator. </t> | |||
<t><xref target="mitigation_attack_type"/> gives an overview of this | ||||
<t>Figure 10 gives an overview of this use case. Figure 11 provides | use case. <xref target="attack_mappings"/> provides an example of | |||
an example of attack mappings that are shared by using the DOTS | attack mappings that are shared using the DOTS data channel in | |||
data channel in advance. Figure 12 provides an example of a DOTS | advance. <xref target="attack_connection_type"/> provides an example | |||
telemetry message body that is used to signal various attack traffic | of a DOTS telemetry message body that is used to signal percentiles | |||
percentiles, total traffic percentiles, total attack connection, and | for total attack traffic, total attack traffic protocol, and total | |||
attack type.</t> | attack connection; it also shows attack details. | |||
</t> | ||||
<t>The example in Figure 11 uses the folding defined in <xref | <t>The example in <xref target="attack_mappings"/> uses the folding de | |||
target="RFC8792"></xref> for long lines. </t> | fined in | |||
<xref target="RFC8792" format="default"/> for long lines. </t> | ||||
<t><figure align="center"> | <figure anchor="mitigation_attack_type"><name>Selecting Mitigation Tech | |||
<artwork><![CDATA[ | nique Based on Attack Type</name> | |||
(Internet Transit Provider) | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
(Internet Transit Provider) | ||||
+-----------+ DOTS +--------------+ | +-----------+ DOTS +--------------+ | |||
+-----------+|<---->| | BGP (Redirect) | +-----------+|<---->| | BGP (Redirect) | |||
IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop) | IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop) | |||
--->| collector |+ | |---> | --->| collector |+ | |---> | |||
+-----------+ +--------------+ | +-----------+ +--------------+ | |||
+------------+ BGP (Redirect) | +------------+ BGP (Redirect) | |||
IPFIX +------------+| BGP Flowspec (Drop) | IPFIX +------------+| BGP Flowspec (Drop) | |||
<---| Forwarding ||<--- | <---| Forwarding ||<--- | |||
skipping to change at line 729 ¶ | skipping to change at line 619 ¶ | |||
| || |+x<==============[NTP Amp] | | || |+x<==============[NTP Amp] | |||
+-----||-----+ | +-----||-----+ | |||
|| | || | |||
|/ | |/ | |||
+-----x------+ | +-----x------+ | |||
| DDoS | | | DDoS | | |||
| mitigation | | | mitigation | | |||
| system | | | system | | |||
+------------+ | +------------+ | |||
* C is for DOTS client functionality | C: DOTS client functionality | |||
* S is for DOTS server functionality | S: DOTS server functionality | |||
* DNS Amp: DNS Amplification | DNS Amp: DNS Amplification | |||
* NTP Amp: NTP Amplification | NTP Amp: NTP Amplification | |||
]]></artwork></figure> | ||||
Figure 10: DDoS Mitigation Based on Attack Type | <figure anchor="attack_mappings"><name>Example of Message Body with Attack Mappi | |||
ngs</name> | ||||
]]></artwork> | <sourcecode name="" type="json"><![CDATA[=============== NOTE: '\' lin | |||
</figure> <figure> | e wrapping per RFC 8792 ================ | |||
<artwork><![CDATA[=============== NOTE: '\' line wrapping per RFC | ||||
8792 ================ | ||||
{ | { | |||
"ietf-dots-mapping:vendor-mapping": { | "ietf-dots-mapping:vendor-mapping": { | |||
"vendor": [ | "vendor": [ | |||
{ | { | |||
"vendor-id": 32473, | "vendor-id": 32473, | |||
"vendor-name": "mitigator-c", | "vendor-name": "mitigator-c", | |||
"last-updated": "1629898958", | "last-updated": "1629898958", | |||
"attack-mapping": [ | "attack-mapping": [ | |||
{ | { | |||
skipping to change at line 767 ¶ | skipping to change at line 654 ¶ | |||
"attack-description":"NTP amplification Attack: \ | "attack-description":"NTP amplification Attack: \ | |||
This attack is a type of reflection attack in which attackers \ | This attack is a type of reflection attack in which attackers \ | |||
spoof a target's IP address. The attackers abuse vulnerabilities \ | spoof a target's IP address. The attackers abuse vulnerabilities \ | |||
in NTP servers to turn small queries into larger payloads." | in NTP servers to turn small queries into larger payloads." | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ||||
Figure 11: Example of Message Body with Attack Mappings | </figure> | |||
]]></artwork> | <figure anchor="attack_connection_type"><name>Example of Message Body with Total | |||
</figure> <figure> | Attack Traffic, Total Attack Traffic Protocol, Total Attack Connection, and Att | |||
<artwork><![CDATA[ | ack Detail</name> | |||
<sourcecode name="" type="json"><![CDATA[ | ||||
{ | { | |||
"ietf-dots-telemetry:telemetry": { | "ietf-dots-telemetry:telemetry": { | |||
"pre-or-ongoing-mitigation": [ | "pre-or-ongoing-mitigation": [ | |||
{ | { | |||
"target": { | "target": { | |||
"target-prefix": [ | "target-prefix": [ | |||
"2001:db8::1/128" | "2001:db8::1/128" | |||
] | ] | |||
}, | }, | |||
"total-attack-traffic": [ | "total-attack-traffic": [ | |||
skipping to change at line 838 ¶ | skipping to change at line 723 ¶ | |||
"vendor-id": 32473, | "vendor-id": 32473, | |||
"attack-id": 92, | "attack-id": 92, | |||
"start-time": "1641172809", | "start-time": "1641172809", | |||
"attack-severity": "high" | "attack-severity": "high" | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ||||
Figure 12: Example of Message Body with Total Attack Traffic, | </figure> | |||
Total Attack Traffic Protocol, Total Attack Connection and Attack Type | <t>Attack mappings are shared using the DOTS data channel in | |||
]]></artwork> | advance (<xref target="RFC9244" sectionFormat="of" | |||
</figure></t> | section="8.1.6"/>). The forwarding nodes send traffic statistics to | |||
the flow collectors, e.g., using IPFIX. When DDoS attacks occur, the | ||||
<t>Attack mappings are shared by using the DOTS data channel in advanc | flow collectors identify attack traffic and send attack type | |||
e | information to the orchestrator using the "vendor-id" and | |||
(Section 8.1.6 of <xref target="RFC9244"></xref>). | "attack-id" telemetry attributes. The orchestrator then resolves | |||
The forwarding nodes send traffic statistics to the flow collectors, | abused port numbers and orders relevant forwarding nodes to block | |||
e.g., using IPFIX. When DDoS attacks occur, the flow collectors | the amplification attack traffic flow by dissemination of Flow | |||
identify attack traffic and send attack type information to the | Specifications using tools such as BGP Flowspec <xref | |||
orchestrator by using "vendor-id" and "attack-id" telemetry | target="RFC8955" format="default"/>. Also, the orchestrator orders | |||
attributes. The orchestrator then resolves abused port numbers and | relevant forwarding nodes to redirect traffic other than the | |||
orders relevant forwarding nodes to block the amplification attack | amplification attack traffic using a routing protocol, such as | |||
traffic flow by dissemination of Flow Specifications using tools such | BGP <xref target="RFC4271" format="default"/>.</t> | |||
as Border Gateway Protocol Dissemination of Flow Specification Rules | ||||
(BGP Flowspec) <xref target="RFC8955"></xref>. Also, the orchestrator | ||||
orders relevant | ||||
forwarding nodes to redirect other traffic than the amplification | ||||
attack traffic by using a routing protocol, | ||||
such as BGP <xref target="RFC4271"></xref>.</t> | ||||
<t>The flow collector implements a DOTS client while the | <t>The flow collector implements a DOTS client while the | |||
orchestrator implements a DOTS server.</t> | orchestrator implements a DOTS server.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="section_ddos_detailed_mitigation_report" numbered="true" | ||||
<section anchor="section_ddos_detailed_mitigation_report" | toc="default"> | |||
title="Detailed DDoS Mitigation Report"> | <name>Detailed DDoS Mitigation Report</name> | |||
<t>It is possible for the transit provider to add value to the DDoS | <t>It is possible for the transit provider to add value to the DDoS | |||
mitigation service by reporting ongoing and detailed DDoS | mitigation service by reporting ongoing and detailed DDoS | |||
countermeasure status to the enterprise network. In addition, it is | countermeasure status to the enterprise network. In addition, it is | |||
possible for the transit provider to know whether the DDoS countermeasur e | possible for the transit provider to know whether the DDoS countermeasur e | |||
is effective or not by receiving reports from the enterprise | is effective or not by receiving reports from the enterprise | |||
network.</t> | network.</t> | |||
<t>This use case enables sharing of information about ongoing | <t>This use case enables the mutual sharing of information about ongoing DDoS | |||
DDoS countermeasures between the transit provider and the enterprise | countermeasures between the transit provider and the enterprise network. | |||
network mutually. Figure 13 gives an overview of this use case. Figure | <xref target="mitigation_report"/> gives an overview of this use case. <xref | |||
14 provides an example of a DOTS telemetry message body that is used | target="pipe_capacity"/> provides an example of a DOTS telemetry message body | |||
to signal total pipe capacity from the enterprise network | that is used to signal total pipe capacity from the enterprise network | |||
administrator to the orchestrator in the ISP. Figure 15 provides an | administrator to the orchestrator in the ISP. <xref target="example_message"/> | |||
example of a DOTS telemetry message body that is used to signal | provides an example of a DOTS telemetry message body that is used to signal | |||
various total traffic percentiles, total attack traffic percentiles, | percentiles for total traffic and total attack traffic as well as attack | |||
and attack details from the orchestrator to the network.</t> | details from the orchestrator to the network. | |||
</t> | ||||
<t><figure align="center"> | <figure anchor="mitigation_report"><name>Detailed DDoS Mitigation Report< | |||
<artwork><![CDATA[ | /name> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
+------------------+ +------------------------+ | +------------------+ +------------------------+ | |||
| Enterprise | | Upstream | | | Enterprise | | Upstream | | |||
| Network | | Internet Transit | | | Network | | Internet Transit | | |||
| +------------+ | | Provider | | | +------------+ | | Provider | | |||
| | Network |C | | S+--------------+ | | | | Network |C | | S+--------------+ | | |||
| | admini- |<-----DOTS---->| Orchestrator | | | | | admini- |<-----DOTS---->| Orchestrator | | | |||
| | strator | | | +--------------+ | | | | strator | | | +--------------+ | | |||
| +------------+ | | C ^ | | | +------------+ | | C ^ | | |||
| | | | DOTS | | | | | | DOTS | | |||
| | | S v | | | | | S v | | |||
skipping to change at line 906 ¶ | skipping to change at line 785 ¶ | |||
| | | | DMS |+======= | | | | | DMS |+======= | |||
| | | +---------------+ | | | | | +---------------+ | | |||
| | | || Clean | | | | | || Clean | | |||
| | | |/ Traffic | | | | | |/ Traffic | | |||
| +---------+ | | +---------------+ | | | +---------+ | | +---------------+ | | |||
| | DDoS | | | | Forwarding | Normal Traffic | | | DDoS | | | | Forwarding | Normal Traffic | |||
| | Target |<================| Node |======== | | | Target |<================| Node |======== | |||
| +---------+ | Link1 | +---------------+ | | | +---------+ | Link1 | +---------------+ | | |||
+------------------+ +------------------------+ | +------------------+ +------------------------+ | |||
* C is for DOTS client functionality | C: DOTS client functionality | |||
* S is for DOTS server functionality | S: DOTS server functionality | |||
]]></artwork> | ||||
Figure 13: Detailed DDoS Mitigation Report | </figure> | |||
]]></artwork> | <figure anchor="pipe_capacity"><name>Example of Message Body with Total P | |||
</figure> <figure> | ipe Capacity</name> | |||
<artwork><![CDATA[ | <sourcecode name="" type="json"><![CDATA[ | |||
{ | { | |||
"ietf-dots-telemetry:telemetry-setup": { | "ietf-dots-telemetry:telemetry-setup": { | |||
"telemetry": [ | "telemetry": [ | |||
{ | { | |||
"total-pipe-capacity": [ | "total-pipe-capacity": [ | |||
{ | { | |||
"link-id": "link1", | "link-id": "link1", | |||
"capacity": "1000", | "capacity": "1000", | |||
"unit": "megabit-ps" | "unit": "megabit-ps" | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
Figure 14: An Example of Message Body with Total Pipe Capacity | ]]></sourcecode> | |||
]]></artwork> | </figure> | |||
</figure> <figure> | <figure anchor="example_message"> | |||
<artwork><![CDATA[ | <name>Example of Message Body with Total Traffic, Total Attack Traffic, | |||
and Attack Detail | ||||
</name> | ||||
<sourcecode name="" type="json"><![CDATA[ | ||||
{ | { | |||
"ietf-dots-telemetry:telemetry": { | "ietf-dots-telemetry:telemetry": { | |||
"pre-or-ongoing-mitigation": [ | "pre-or-ongoing-mitigation": [ | |||
{ | { | |||
"tmid": 567, | "tmid": 567, | |||
"target": { | "target": { | |||
"target-prefix": [ | "target-prefix": [ | |||
"2001:db8::1/128" | "2001:db8::1/128" | |||
] | ] | |||
}, | }, | |||
skipping to change at line 969 ¶ | skipping to change at line 849 ¶ | |||
"vendor-id": 32473, | "vendor-id": 32473, | |||
"attack-id": 77, | "attack-id": 77, | |||
"start-time": "1644819611", | "start-time": "1644819611", | |||
"attack-severity": "high" | "attack-severity": "high" | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ||||
Figure 15: An Example of Message Body with Total Traffic, | </figure> | |||
Total Attack Traffic Protocol, and Attack Detail | ||||
]]></artwork> | ||||
</figure></t> | ||||
<t>The network management system in the enterprise network reports | <t>The network management system in the enterprise network reports | |||
limits of incoming traffic volume from the transit provider to the | limits of incoming traffic volume from the transit provider to the | |||
orchestrator in the transit provider in advance. It is reported by | orchestrator in the transit provider in advance. It is reported | |||
using the "total-pipe-capacity" telemetry attribute in the DOTS telemetr y | using the "total-pipe-capacity" telemetry attribute in the DOTS telemetr y | |||
setup.</t> | setup.</t> | |||
<t>When DDoS attacks occur, DDoS mitigation orchestration <xref target=" | ||||
<t>When DDoS attacks occur, DDoS mitigation orchestration <xref | RFC8903" format="default"/> is carried out in the transit provider. Then, | |||
target="RFC8903"></xref> is carried out in the transit provider. Then, | ||||
the DDoS mitigation systems report the status of DDoS countermeasures | the DDoS mitigation systems report the status of DDoS countermeasures | |||
to the orchestrator by sending "attack-detail" telemetry attributes. | to the orchestrator by sending "attack-detail" telemetry attributes. | |||
After that, the orchestrator integrates the reports from the DDoS | After that, the orchestrator integrates the reports from the DDoS | |||
mitigation systems, while removing duplicate contents, and sends the int egrated report to a | mitigation systems, while removing duplicate contents, and sends the int egrated report to a | |||
network administrator by using DOTS telemetry periodically.</t> | network administrator using DOTS telemetry periodically.</t> | |||
<t>During the DDoS mitigation, the orchestrator in the transit | <t>During the DDoS mitigation, the orchestrator in the transit | |||
provider retrieves link congestion status from the network manager in | provider retrieves the link congestion status from the network manager i | |||
the enterprise network by using "total-traffic" telemetry attributes. | n | |||
Then, the orchestrator checks whether the DDoS countermeasures are | the enterprise network using the "total-traffic" telemetry attributes. | |||
effective or not by comparing the "total-traffic" and the | Then, the orchestrator checks whether or not the DDoS countermeasures ar | |||
"total-pipe-capacity" attributes.</t> | e | |||
effective by comparing the "total-traffic" and the | ||||
"total-pipe-capacity" telemetry attributes.</t> | ||||
<t>The DMS implements a DOTS server while the orchestrator behaves as | <t>The DMS implements a DOTS server while the orchestrator behaves as | |||
a DOTS client and a server in the transit provider. In addition, the | a DOTS client and a server in the transit provider. In addition, the | |||
network administrator implements a DOTS client.</t> | network administrator implements a DOTS client.</t> | |||
</section> | </section> | |||
<section anchor="section_use_cases_dms_tuning" numbered="true" toc="defaul | ||||
<section anchor="section_use_cases_dms_tuning" | t"> | |||
title="Tuning Mitigation Resources"> | <name>Tuning Mitigation Resources</name> | |||
<section anchor="section_use_cases_ddos_detection_training" | <section anchor="section_use_cases_ddos_detection_training" numbered="tr | |||
title="Supervised Machine Learning of Flow Collector"> | ue" toc="default"> | |||
<t>DDoS detection based on tools, such as IPFIX, is a lighter weight | <name>Supervised Machine Learning of Flow Collector</name> | |||
method of detecting DDoS attacks than DMSes in Internet transit | <t>DDoS detection based on tools, such as IPFIX, is a lighter-weight | |||
method of detecting DDoS attacks compared to DMSes in Internet transit | ||||
provider networks. DDoS detection based on the | provider networks. DDoS detection based on the | |||
DMSes is a more accurate method for detecting attack traffic | DMSes is a more accurate method for detecting attack traffic | |||
than flow monitoring.</t> | than flow monitoring.</t> | |||
<t>The aim of this use case is to increase flow collectors' detection | <t>The aim of this use case is to increase flow collectors' | |||
accuracy by carrying out supervised machine-learning | detection accuracy by carrying out supervised machine-learning | |||
techniques according to attack detail reported by the DMSes. To use | techniques according to attack detail reported by the DMSes. To use | |||
such a technique, forwarding nodes, flow collectors, and a DMS should | such a technique, forwarding nodes, flow collectors, and a DMS | |||
cooperate. Figure 16 gives an overview of this use case. Figure 17 | should cooperate. <xref target="training_supervised"/> gives an | |||
overview of this use case. <xref target="message_body_attack"/> | ||||
provides an example of a DOTS telemetry message body that is used to | provides an example of a DOTS telemetry message body that is used to | |||
signal various total attack traffic percentiles and attack | signal attack detail. | |||
detail.</t> | </t> | |||
<figure anchor="training_supervised"> | ||||
<t><figure align="center"> | <name>Supervised Machine Learning of Flow Collector</name> | |||
<artwork><![CDATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
+-----------+ | +-----------+ | |||
+-----------+| DOTS | +-----------+| DOTS | |||
IPFIX | Flow ||S<--- | IPFIX | Flow ||S<--- | |||
--->| collector || | --->| collector || | |||
+-----------++ | +-----------++ | |||
+------------+ | +------------+ | |||
IPFIX +------------+| | IPFIX +------------+| | |||
<---| Forwarding || | <---| Forwarding || | |||
| nodes || DDoS Attack | | nodes || DDoS Attack | |||
skipping to change at line 1044 ¶ | skipping to change at line 915 ¶ | |||
| || || ++======================== | | || || ++======================== | |||
+---||-|| ||-+ | +---||-|| ||-+ | |||
|| || || | || || || | |||
|/ |/ |/ | |/ |/ |/ | |||
DOTS +---X--X--X--+ | DOTS +---X--X--X--+ | |||
--->C| DDoS | | --->C| DDoS | | |||
| mitigation | | | mitigation | | |||
| system | | | system | | |||
+------------+ | +------------+ | |||
* C is for DOTS client functionality | C: DOTS client functionality | |||
* S is for DOTS server functionality | S: DOTS server functionality | |||
]]></artwork> | ||||
Figure 16: Training Supervised Machine Learning of Flow Collectors | </figure> | |||
]]></artwork> | <figure anchor="message_body_attack"> | |||
</figure> <figure> | <name>Example of Message Body with Attack Detail and Top Talkers</nam | |||
<artwork><![CDATA[ | e> | |||
<sourcecode name="" type="json"><![CDATA[ | ||||
{ | { | |||
"ietf-dots-telemetry:telemetry": { | "ietf-dots-telemetry:telemetry": { | |||
"pre-or-ongoing-mitigation": [ | "pre-or-ongoing-mitigation": [ | |||
{ | { | |||
"target": { | "target": { | |||
"target-prefix": [ | "target-prefix": [ | |||
"2001:db8::1/128" | "2001:db8::1/128" | |||
] | ] | |||
}, | }, | |||
"attack-detail": [ | "attack-detail": [ | |||
skipping to change at line 1079 ¶ | skipping to change at line 950 ¶ | |||
"source-prefix": "2001:db8::2/127" | "source-prefix": "2001:db8::2/127" | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ||||
Figure 17: An Example of Message Body with Attack Type | </figure> | |||
and top-talkers | ||||
]]></artwork> | ||||
</figure></t> | ||||
<t>The forwarding nodes send traffic statistics to the flow | <t>The forwarding nodes send traffic statistics to the flow | |||
collectors, e.g., using IPFIX. When DDoS attacks occur, DDoS | collectors, e.g., using IPFIX. When DDoS attacks occur, DDoS | |||
mitigation orchestration is carried out (as per Section 3.3 of <xref | mitigation orchestration is carried out (as per <xref target="RFC8903" | |||
target="RFC8903"></xref>) and the DMS mitigates all attack traffic | sectionFormat="of" section="3.3"/>), and the DMS mitigates all attack traffic | |||
destined for a target. The DDoS mitigation system reports the | destined for a target. The DDoS mitigation system reports the | |||
"vendor-id", "attack-id", and "top-talker" telemetry attributes to a | "vendor-id", "attack-id", and "top-talker" telemetry attributes to a | |||
flow collector.</t> | flow collector.</t> | |||
<t>After mitigating a DDoS attack, the flow collector attaches | <t>After mitigating a DDoS attack, the flow collector attaches | |||
outputs of the DMS as labels to the statistics of traffic flow of top- talkers. | outputs of the DMS as labels to the statistics of the traffic flow of top talkers. | |||
The outputs, for example, are the "attack-id" telemetry attributes. | The outputs, for example, are the "attack-id" telemetry attributes. | |||
The flow collector then carries out supervised machine learning to | The flow collector then carries out supervised machine learning to | |||
increase its detection accuracy, setting the statistics as an | increase its detection accuracy, setting the statistics as an | |||
explanatory variable and setting the labels as an objective | explanatory variable and setting the labels as an objective | |||
variable.</t> | variable.</t> | |||
<t>The DMS implements a DOTS client while the flow collector | <t>The DMS implements a DOTS client while the flow collector | |||
implements a DOTS server.</t> | implements a DOTS server.</t> | |||
</section> | </section> | |||
<section anchor="section_use_cases_tuning_threshold" numbered="true" toc | ||||
<section anchor="section_use_cases_tuning_threshold" | ="default"> | |||
title="Unsupervised Machine Learning of Flow Collector"> | <name>Unsupervised Machine Learning of Flow Collector</name> | |||
<t>DMSes can detect DDoS attack traffic, which means DMSes can also | <t>DMSes can detect DDoS attack traffic, which means DMSes can also | |||
identify clean traffic. This use case supports | identify clean traffic. This use case supports unsupervised | |||
unsupervised machine-learning for anomaly detection according to | machine learning for anomaly detection according to a baseline | |||
a baseline reported by the DMSes. To use such a technique, forwarding | reported by the DMSes. To use such a technique, forwarding nodes, | |||
nodes, flow collectors, and a DMS should cooperate. Figure 18 gives | flow collectors, and a DMS should cooperate. <xref | |||
an overview of this use case. Figure 19 provides an example of a | target="training_unsupervised"/> gives an overview of this use | |||
DOTS telemetry message body that is used to signal baseline.</t> | case. <xref target="traffic_baseline"/> provides an example of a DOTS | |||
telemetry message body | ||||
<t><figure align="center"> | that is used to signal baseline.</t> | |||
<artwork><![CDATA[ | <figure anchor="training_unsupervised"> | |||
<name>Unsupervised Machine Learning of Flow Collector</name> | ||||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
+-----------+ | +-----------+ | |||
+-----------+| | +-----------+| | |||
DOTS | Flow || | DOTS | Flow || | |||
--->S| collector || | --->S| collector || | |||
+-----------++ | +-----------++ | |||
+------------+ | +------------+ | |||
+------------+| | +------------+| | |||
| Forwarding || | | Forwarding || | |||
| nodes || Traffic | | nodes || Traffic | |||
skipping to change at line 1140 ¶ | skipping to change at line 1003 ¶ | |||
| || |+ | | || |+ | |||
+---||-------+ | +---||-------+ | |||
|| | || | |||
|/ | |/ | |||
DOTS +---X--------+ | DOTS +---X--------+ | |||
--->C| DDoS | | --->C| DDoS | | |||
| mitigation | | | mitigation | | |||
| system | | | system | | |||
+------------+ | +------------+ | |||
* C is for DOTS client functionality | C: DOTS client functionality | |||
* S is for DOTS server functionality | S: DOTS server functionality | |||
]]></artwork> | ||||
Figure 18: Training Unsupervised Machine Learning of Flow Collectors | </figure> | |||
]]></artwork> | <figure anchor="traffic_baseline"> | |||
</figure> <figure> | <name>Example of Message Body with Traffic Baseline</name> | |||
<artwork><![CDATA[ | <sourcecode name="" type="json"><![CDATA[ | |||
{ | { | |||
"ietf-dots-telemetry:telemetry-setup": { | "ietf-dots-telemetry:telemetry-setup": { | |||
"telemetry": [ | "telemetry": [ | |||
{ | { | |||
"baseline": [ | "baseline": [ | |||
{ | { | |||
"id": 1, | "id": 1, | |||
"target-prefix": [ | "target-prefix": [ | |||
"2001:db8:6401::1/128" | "2001:db8:6401::1/128" | |||
], | ], | |||
skipping to change at line 1180 ¶ | skipping to change at line 1043 ¶ | |||
"high-percentile-g": "60", | "high-percentile-g": "60", | |||
"peak-g": "70" | "peak-g": "70" | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ||||
</figure> | ||||
Figure 19: An Example of Message Body with Traffic Baseline | <t>The forwarding nodes carry out traffic mirroring to copy the traffic | |||
]]></artwork> | destined to an IP address and to monitor the traffic by a DMS. The DMS then | |||
</figure></t> | identifies clean traffic and reports the baseline telemetry attributes to the | |||
flow collector using DOTS telemetry.</t> | ||||
<t>The forwarding nodes carry out traffic mirroring to copy the traffi | ||||
c | ||||
destined an IP address and to monitor the traffic by a DMS. | ||||
The DMS then identifies "clean" traffic and reports the | ||||
baseline attributes to the flow collector by using DOTS telemetry.< | ||||
/t> | ||||
<t>The flow collector then carries out unsupervised machine | <t>The flow collector then carries out unsupervised machine | |||
learning to be able to carry out anomaly detection.</t> | learning to be able to carry out anomaly detection.</t> | |||
<t>The DMS implements a DOTS client while the flow collector | <t>The DMS implements a DOTS client while the flow collector | |||
implements a DOTS server.</t> | implements a DOTS server.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Security Considerations"> | <name>Security Considerations</name> | |||
<t>DOTS telemetry security considerations are discussed in Section 14 of | <t>Security considerations for DOTS telemetry are discussed in <xref targe | |||
<xref target="RFC9244"></xref>. These considerations | t="RFC9244" sectionFormat="of" section="14"/>. These considerations | |||
apply for the communication interfaces where DOTS is used. </t> | apply to the communication interfaces where DOTS is used. </t> | |||
<t>Some use cases involve controllers, orchestrators, and programmable | <t>Some use cases involve controllers, orchestrators, and programmable | |||
interfaces. These interfaces can be misused by misbehaving nodes to | interfaces. These interfaces can be misused by misbehaving nodes to | |||
further exacerbate DDoS attacks. The considerations are for end-to-end sys | further exacerbate DDoS attacks. The considerations are for end-to-end | |||
tems for DoS mitigation, | systems for DoS mitigation, so the mechanics are outside the scope of | |||
so the mechanics are outside the scope of DOTS protocols. | DOTS protocols. <xref target="RFC7149" sectionFormat="of" section="5"/> | |||
Section 5 of <xref | discusses some generic security considerations to take into account in | |||
target="RFC7149"></xref> discusses some generic security considerations | such contexts (e.g., reliable access control). Specific security | |||
to take into account in such contexts (e.g., reliable access control). | measures depend on the actual mechanism used to control underlying | |||
Specific security measures depend on the actual mechanism used to | forwarding nodes and other controlled elements. For example, <xref | |||
control underlying forwarding nodes and other controlled elements. For | target="RFC8955" sectionFormat="of" section="12"/> discusses security | |||
example, Section 13 of <xref target="RFC8955"></xref> discusses security | considerations that are relevant to BGP Flowspec. IPFIX-specific | |||
considerations that are relevant to BGP Flowspec. | considerations are discussed in <xref target="RFC7011" | |||
IPFIX-specific considerations are discussed in Section 11 of <xref | sectionFormat="of" section="11"/>.</t> | |||
target="RFC7011"></xref>.</t> | ||||
</section> | ||||
<section title="IANA Considerations"> | ||||
<t>This document does not require any action from IANA.</t> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Acknowledgement"> | <name>IANA Considerations</name> | |||
<t>The authors would like to thank Mohamed Boucadair and Valery Smyslov fo | <t>This document has no IANA actions.</t> | |||
r their valuable feedback.</t> | ||||
<t>Thanks to Paul Wouters for the detailed AD review.</t> | ||||
<t>Many thanks to Donald Eastlake, Phillip Hallam-Baker, Sean Turner, and | ||||
Peter Yee for the AD review.</t> | ||||
<t>Thanks to Lars Eggert, Murray Kucherawy, Roman Danyliw, Robert Wiltonm, | ||||
and Eric Vyncke for the IESG review.</t> | ||||
</section> | </section> | |||
</middle> | </middle> | |||
<!-- ***** BACK MATTER ***** --> | ||||
<back> | <back> | |||
<references title="Normative References"> | <references> | |||
<?rfc include="reference.RFC.9244"?> | <name>References</name> | |||
</references> | <references> | |||
<name>Normative References</name> | ||||
<references title="Informative References"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
<?rfc include="reference.RFC.8903"?> | 244.xml"/> | |||
</references> | ||||
<?rfc include="reference.RFC.4271"?> | <references> | |||
<name>Informative References</name> | ||||
<?rfc include="reference.RFC.8955"?> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | |||
903.xml"/> | ||||
<?rfc include="reference.RFC.8612"?> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 | |||
271.xml"/> | ||||
<?rfc include="reference.RFC.3413"?> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | |||
955.xml"/> | ||||
<?rfc include="reference.RFC.7950"?> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | |||
612.xml"/> | ||||
<?rfc include="reference.RFC.7011"?> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 | |||
413.xml"/> | ||||
<?rfc include="reference.RFC.9132"?> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | |||
950.xml"/> | ||||
<?rfc include="reference.RFC.8783"?> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | |||
011.xml"/> | ||||
<?rfc include='reference.RFC.8792'?> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
132.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
783.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
792.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
149.xml"/> | ||||
<?rfc include='reference.RFC.7149'?> | <reference anchor="DOTS_Overview" target="https://datatracker.ietf.org/meeting/1 08/materials/slides-108-saag-dots-overview-00"> | |||
<reference anchor="DOTS Overview" target="https://datatracker.ietf.org/mee | ||||
ting/108/materials/slides-108-saag-dots-overview-00"> | ||||
<!-- Manually added reference --> | ||||
<front> | <front> | |||
<title>DOTS Overview (RFCs 8782, 8783)</title> | <title>DDoS Open Threat Signaling (DOTS)</title> | |||
<author initials="T." surname="Reddy" fullname="T. Reddy"> | <author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<author initials="M." surname="Boucadair" fullname="M. Boucadair"> | <author initials="M." surname="Boucadair" fullname="Mohamed Boucadai | |||
<organization/> | r"> | |||
</author> | <organization/> | |||
<date year="2020" month="July"/> | </author> | |||
</front> | <date year="2020" month="July"/> | |||
</reference> | </front> | |||
</reference> | ||||
<reference anchor="DNS Water Torture Attack" target="https://dl.acm.org/do | <reference anchor="DNS_Water_Torture_Attack" target="https://dl.acm.org/ | |||
i/10.1145/3297156.3297272"> | doi/10.1145/3297156.3297272"> | |||
<!-- Manually added reference --> | ||||
<front> | <front> | |||
<title>A Large Scale Analysis of DNS Water Torture Attack</title> | <title>A Large Scale Analysis of DNS Water Torture Attack</title> | |||
<author initials="L." surname="Xi" fullname="L. Xi"> | <author initials="X." surname="Luo" fullname="Xi Luo"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2018" month="December"/> | <author initials="L." surname="Wang" fullname="Liming Wang"> | |||
</front> | <organization/> | |||
<seriesInfo name="DOI" value="10.1145/3297156.3297272"/> | </author> | |||
</reference> | <author initials="Z." surname="Xu" fullname="Zhen Xu"> | |||
<organization/> | ||||
</author> | ||||
<author initials="K." surname="Chen" fullname="Kai Chen"> | ||||
<organization/> | ||||
</author> | ||||
<author initials="J." surname="Yang" fullname="Jing Yang"> | ||||
<organization/> | ||||
</author> | ||||
<author initials="T." surname="Tian" fullname="Tian Tian"> | ||||
<organization/> | ||||
</author> | ||||
<date year="2018" month="December"/> | ||||
</front> | ||||
<seriesInfo name="DOI" value="10.1145/3297156.3297272"/> | ||||
<refcontent>CSAI '18: Proceedings of the 2018 2nd International | ||||
Conference on Computer Science and Artificial Intelligence, | ||||
pp. 168-173</refcontent> | ||||
</reference> | ||||
</references> | ||||
</references> | </references> | |||
<section numbered="false" toc="default"> | ||||
<name>Acknowledgements</name> | ||||
<t>The authors would like to thank <contact fullname="Mohamed | ||||
Boucadair"/> and <contact fullname="Valery Smyslov"/> for their valuable | ||||
feedback.</t> | ||||
<t>Thanks to <contact fullname="Paul Wouters"/> for the detailed AD | ||||
review.</t> | ||||
<t>Many thanks to <contact fullname="Donald Eastlake 3rd"/>, <contact | ||||
fullname="Phillip Hallam-Baker"/>, <contact fullname="Sean Turner"/>, | ||||
and <contact fullname="Peter Yee"/> for their reviews.</t> | ||||
<t>Thanks to <contact fullname="Lars Eggert"/>, <contact | ||||
fullname="Murray Kucherawy"/>, <contact fullname="Roman Danyliw"/>, | ||||
<contact fullname="Robert Wilton"/>, and <contact fullname="Éric | ||||
Vyncke"/> for the IESG review.</t> | ||||
</section> | ||||
<!-- Appendix --> | ||||
</back> | </back> | |||
</rfc> | </rfc> | |||
End of changes. 118 change blocks. | ||||
611 lines changed or deleted | 511 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |