<?xml version="1.0"encoding="US-ASCII"?> <!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd" []> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> -->encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "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. --><!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?rfc tocdepth="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 xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="info" consensus="true" docName="draft-ietf-dots-telemetry-use-cases-15"ipr="trust200902">number="9387" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!--***** FRONT MATTER *****xml2rfc v2v3 conversion 3.15.3 --> <front> <title abbrev="DOTS Telemetry Use Cases">Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry</title> <seriesInfo name="RFC" value="9387"/> <author fullname="Yuhei Hayashi" initials="Y." surname="Hayashi"> <organization abbrev="NTT">NTT</organization> <address> <postal> <street>3-9-11, Midori-cho</street><city>Musashino-shi</city><region>Tokyo</region> <code>180-8585</code> <country>Japan</country> </postal> <email>yuuhei.hayashi@gmail.com</email> </address> </author> <author fullname="Meiling Chen" initials="M." surname="Chen"> <organizationabbrev="CMCC">CMCC</organization>abbrev="China Mobile">China Mobile</organization> <address> <postal> <street>32, Xuanwumen West</street><city>BeiJing</city> <region>BeiJing</region><city>Beijing</city> <code>100053</code> <country>China</country> </postal> <email>chenmeiling@chinamobile.com</email> </address> </author> <author fullname="Li Su"initials="Li."initials="L." surname="Su"><organization>CMCC</organization><organization abbrev="China Mobile">China Mobile</organization> <address> <postal> <street>32, Xuanwumen West</street><city>BeiJing, BeiJing</city><city>Beijing</city> <code>100053</code> <country>China</country> </postal> <email>suli@chinamobile.com</email> </address> </author> <dateday="23" month="October" year="2022" /> <area>Security Area</area> <workgroup>DOTS</workgroup> <keyword>Internet-Draft</keyword>month="April" year="2023"/> <area>sec</area> <workgroup>dots</workgroup> <abstract> <t>DDoS Open Threat Signaling (DOTS)Telemetrytelemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS attack mitigation techniques in a network. This document presents sample use cases for DOTSTelemetry.telemetry. It discusses what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques.</t> </abstract> </front> <middle> <section anchor="section_introduction"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Distributed Denial-of-Service (DDoS) attacks, such as volumetric attacks andresource-consumptionresource-consuming attacks, are critical threats to be handled by service providers. When such DDoS attacks occur, service providers have to mitigate them immediately to protect or recover their services.</t><t>Therefore, for<t>For service providers to immediately protect their network services from DDoS attacks, DDoS mitigation needs to be highly automated. To that aim, multivendor components involved in DDoS attack detection and mitigation should cooperate and support standard interfaces.</t> <t>DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time signaling, threat-handling requests, and data filtering between the multivendor elements <xreftarget="RFC9132"></xref><xref target="RFC8783"></xref>.target="RFC9132" format="default"/> <xref target="RFC8783" format="default"/>. DOTSTelemetrytelemetry enriches the DOTS protocols with various telemetry attributes allowing optimal DDoS attack mitigation <xreftarget="RFC9244"></xref>.target="RFC9244" format="default"/>. This document presents sample use cases for DOTSTelemetry which makes concretetelemetry to enhance the overview and the purpose described in <xreftarget="RFC9244"></xref>.target="RFC9244" format="default"/>. This document also presents what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use attack-mitigation techniques.</t> </section> <section anchor="section_terms"title="Terminology"> <t>The readersnumbered="true" toc="default"> <name>Terminology</name> <t>Readers should be familiar with the terms defined in <xreftarget="RFC8612"></xref>,target="RFC8612" format="default"/>, <xreftarget="RFC8903"></xref>target="RFC8903" format="default"/>, and <xreftarget="RFC9244"></xref>.</t>target="RFC9244" format="default"/>.</t> <t>In addition, this document uses the following terms:</t><t><list style="hanging"> <t hangText="Top-talker:">A list of attack sources that are involved in an attack and which are generating an important part of the attack traffic.</t> <t hangText="Supervised<dl newline="false" spacing="normal"> <dt>Supervised MachineLearning:">ALearning:</dt> <dd>A machine-learning technique in which labeled data is used to train the algorithms (the input and output data areknown).</t> <t hangText="Unsupervisedknown).</dd> <dt>Unsupervised MachineLearning:">A machine learningLearning:</dt> <dd>A machine-learning technique in which unlabeled data is used to train the algorithms (the data has no historicallabels).</t> </list></t>labels).</dd> </dl> </section> <section anchor="section_use_cases"title="Telemetrynumbered="true" toc="default"> <name>Telemetry UseCases">Cases</name> <t>This section describes DOTS telemetry use cases that use telemetry attributes included in the DOTS telemetry specification <xreftarget="RFC9244"></xref>.</t>target="RFC9244" format="default"/>.</t> <t>The following subsections assume that once the DOTS signal channel is established, DOTS clients will proceed with the telemetry setup configurationasdetailed inSection 7 of<xreftarget="RFC9244"></xref>.target="RFC9244" sectionFormat="of" section="7"/>. The following telemetry parameters are used:</t> <ul spacing="normal" bare="false" empty="false" indent="3"><li> 'measurement-interval' to define<li>"measurement-interval" defines the period during which percentiles are computed.</li><li>'measurement-sample' to define<li>"measurement-sample" defines the time distribution for measuring values that are used to compute percentiles.</li> </ul> <section anchor="section_use_cases_ddos_mitigation_resource_assign"title="Mitigationnumbered="true" toc="default"> <name>Mitigation ResourcesAssignment">Assignment</name> <section anchor="section_use_cases_ddos_mitigation_bandwidth_top-talker"title="Mitigatingnumbered="true" toc="default"> <name>Mitigating Attack Flow ofTop-talker Preferentially">Top Talker Preferentially</name> <t>Some transit providers have to mitigate large-scale DDoS attacksbyusing DDoS Mitigation Systems (DMSes) with limitedresources, whichresources that are already deployed in their network. For example, recently reported large DDoS attacks exceeded severalTbps.Tbps <xreftarget="DOTS Overview"></xref></t>target="DOTS_Overview" format="default"/>.</t> <t>This use case enables transit providers to use their DMS efficiently under volume-based DDoS attacks whose volume is more than the available capacity of the DMS. To enable this, the attack traffic oftop-talkerstop talkers is redirected to the DMS preferentially by cooperation among forwarding nodes, flow collectors, and orchestrators. </t><t>Figure 1<t><xref target="DDos_attack-flow"/> gives an overview of this use case.Figure 2<xref target="example_message_body"/> provides an example of a DOTS telemetry message body that is used to signaltop-talkerstop talkers (2001:db8:1::/48 and 2001:db8:2::/48).</t><t><figure align="center"> <artwork><![CDATA[<figure anchor="DDos_attack-flow"> <name>Mitigating Attack Flow of Top Talker Preferentially</name> <artwork type="" align="left" alt=""><![CDATA[ (Internet Transit Provider) +-----------+ +--------------+ SNMP or YANG/NETCONF IPFIX +-----------+| DOTS | |<--- --->| Flow ||C<-->S| Orchestrator | BGP Flowspec | collector |+ | |---> (Redirect) +-----------+ +--------------+ +-------------+ IPFIX +-------------+| BGP Flowspec (Redirect) <---| Forwarding ||<--- | nodes || | || DDoS Attack [ Target(s) ]<========================================== |++=========================[top-talker]++=========================[top talker] | ||++======================[top-talker]++======================[top talker] +----||||---+||----+ || || || || |/ |/ +----x--x----+ | DDoS | SNMP or YANG/NETCONF | mitigation |<--- | system | +------------+* C is forC: DOTS client functionality* S is forS: DOTS server functionalityFigure 1: Mitigating DDoS Attack Flow of Top-talkers Preferentially]]></artwork> </figure><figure> <artwork><![CDATA[<figure anchor="example_message_body"> <name>Example of Message Body to Signal Top Talkers</name> <sourcecode type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "total-attack-traffic-protocol": [ { "protocol": 17, "unit": "megabit-ps", "mid-percentile-g": "900" } ], "attack-detail": [ { "vendor-id": 32473, "attack-id": 77, "start-time": "1645057211", "attack-severity": "high", "top-talker":{ "talker": [ { "source-prefix": "2001:db8:1::/48", "total-attack-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "100" } ] }, { "source-prefix": "2001:db8:2::/48", "total-attack-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "90" } ] } ] } } ] } ] } }Figure 2: An Example of Message Body to Signal Top-Talkers ]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The forwarding nodes send traffic statistics to the flow collectors, e.g., using IP Flow Information Export (IPFIX) <xreftarget="RFC7011"></xref>.target="RFC7011" format="default"/>. When DDoS attacks occur, the flow collectors identify the attack traffic and send information about thetop-talkerstop talkers to the orchestrator using the "target-prefix" and "top-talkers" DOTS telemetry attributes. The orchestrator then checks the available capacity of the DMSesbyusing a network management protocol, such as the Simple Network Management Protocol (SNMP) <xreftarget="RFC3413"></xref>target="RFC3413" format="default"/> or YANG with the Network Configuration Protocol (YANG/NETCONF) <xreftarget="RFC7950"></xref>.target="RFC7950" format="default"/>. After that, the orchestrator orders the forwarding nodes to redirect as much of thetop-talker'stop talker's traffic toeach DMSthe DMSes asthat DMSthey can handle by dissemination of Flow Specifications using tools such as Border Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) <xreftarget="RFC8955"></xref>.target="RFC8955" format="default"/>. </t> <t>The flow collector implements a DOTS client while the orchestrator implements a DOTS server.</t> </section> <section anchor="dms_selection"title="DMSnumbered="true" toc="default"> <name>DMS Selection forMitigation">Mitigation</name> <t>Transit providers can deploy their DMSes in clusters. Then, they can select the DMS to be used to mitigate a DDoS attack at the time of an attack.</t> <t>This use case enables transit providers to select a DMS with sufficient capacity for mitigation based on the volume of the attack traffic and the capacity ofathe DMS.Figure 3<xref target="DMS_selection"/> gives an overview of this use case.Figure 4<xref target="message_body"/> provides an example of a DOTS telemetry message body that is used to signalvariouspercentiles for total attacktraffic percentiles.</t> <t><figure align="center"> <artwork><![CDATA[traffic. </t> <figure anchor="DMS_selection"><name>DMS Selection for Mitigation</name> <artwork name="" type="" align="left" alt=""><![CDATA[ (Internet Transit Provider) +-----------+ +--------------+ SNMP or YANG/NETCONF IPFIX +-----------+| DOTS | |<--- --->| Flow ||C<-->S| Orchestrator | BGP (Redirect) | collector |+ | |---> +-----------+ +--------------+ +------------+ IPFIX +------------+| BGP (Redirect) <---| Forwarding ||<--- | nodes || | || DDoS Attack [Target A] | ++=================== [Destined for Target A] [Target B] | || ++=============== [Destined for Target B] +-||--||-----+ || || ++====++ || (congested DMS) || || +-----------+ || |/ | DMS3 | || +-----x------+ |<--- SNMP or YANG/NETCONF |/ | DMS2 |--------+ +--x---------+ |<--- SNMP or YANG/NETCONF | DMS1 |------+ | |<--- SNMP or YANG/NETCONF +------------+* C is forC: DOTS client functionality* S is forS: DOTS server functionalityFigure 3: DMS Selection for Mitigation ]]></artwork> </figure> <figure> <artwork><![CDATA[]]></artwork></figure> <figure anchor="message_body"><name>Example of Message Body with Total Attack Traffic</name> <sourcecode name="" type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "192.0.2.3/32" ] }, "total-attack-traffic": [ { "unit": "megabit-ps", "low-percentile-g": "600", "mid-percentile-g": "800", "high-percentile-g": "1000", "peak-g":"1100", "current-g":"700" } ] } ] } }Figure 4: Example of Message Body with Total Attack Traffic ]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The forwarding nodes send traffic statistics to the flow collectors, e.g., using IPFIX. When DDoS attacks occur, the flow collectors identify the attack traffic and send information about the attack traffic volume to the orchestratorbyusing the "target-prefix" and "total-attack-traffic" DOTS telemetry attributes. The orchestrator then checks the available capacity of the DMSesbyusing a network management protocol, such as the Simple Network Management Protocol (SNMP) <xreftarget="RFC3413"></xref>target="RFC3413" format="default"/> or YANG with the Network Configuration Protocol (YANG/NETCONF) <xreftarget="RFC7950"></xref>.target="RFC7950" format="default"/>. After that, the orchestrator selects a DMS with sufficient capacity to which attack traffic should be redirected. For example, a simple DMS selection algorithmiscan be used to choose a DMS whose available capacity is greater than the "peak-g" telemetry attribute indicated in the DOTS telemetry message. The orchestrator orders the appropriate forwarding nodes to redirect the attack traffic to the DMS relying upon routing policies, such as BGP <xreftarget="RFC4271"></xref>.target="RFC4271" format="default"/>. </t> <t>The detailed DMS selection algorithm is out of the scope of this document.</t> <t>The flow collector implements a DOTS client while the orchestrator implements a DOTS server.</t> </section> <section anchor="redirection_path_selection"title="Pathnumbered="true" toc="default"> <name>Path Selection forRedirection">Redirection</name> <t>A transit provider network has multiple paths to convey attack traffic to a DMS. In such a network, the attack traffic can be conveyed while avoiding congested links by adequately selecting an 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.Figure 5<xref target="path_selection"/> gives an overview of this use case.Figure 6<xref target="message_total_attack"/> provides an example of a DOTS telemetry message body that is used to signalvarious attack trafficpercentilesandfor total trafficpercentiles.</t> <t><figure align="center"> <artwork><![CDATA[and total attack traffic. </t> <figure anchor="path_selection"><name>Path Selection for Redirection</name> <artwork name="" type="" align="left" alt=""><![CDATA[ (Internet Transit Provider) +-----------+ +--------------+ DOTS +-----------+| | |S<--- IPFIX | Flow || DOTS | Orchestrator | -->| collector ||C<-->S| | BGP Flowspec (Redirect) | |+ | |---> +-----------+ +--------------+ DOTS +------------+ DOTS +------------+ IPFIX --->C| Forwarding | --->C| Forwarding |---> BGP Flowspec | node | | node | (Redirect) --->| | | | DDoS Attack [Target] | ++==================================== +-------||---+ +------------+ || / || / (congested link) || / DOTS +-||----------------+ BGP Flowspec (Redirect) --->C| || Forwarding |<--- | ++=== node | +----||-------------+ |/ +--x-----------+ | DMS | +--------------+* C is forC: DOTS client functionality* S is forS: DOTS server functionalityFigure 5: Path Selection for Redirection]]></artwork> </figure><figure> <artwork><![CDATA[<figure anchor="message_total_attack"><name>Example of Message Body with Total Attack Traffic and Total Traffic</name> <sourcecode name="" type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "total-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "1300", "peak-g": "800" } ], "total-attack-traffic": [ { "unit": "megabit-ps", "low-percentile-g": "600", "mid-percentile-g": "800", "high-percentile-g": "1000", "peak-g": "1100", "current-g": "700" } ] } ] } }Figure 6: An Example of Message Body with Total Attack Traffic and Total Traffic ]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The forwarding nodes send traffic statistics to the flow collectors, e.g., using IPFIX. When DDoS attacks occur, the flow collectors identify attack traffic and send information about the attack traffic volume to the orchestratorbyusing the "target-prefix" and "total-attack-traffic" DOTS telemetry attributes. The underlying forwarding nodes send the volumeonof the total traffic passing the node to the orchestratorbyusing the "total-traffic" telemetry attributes. The orchestrator then selects a path with sufficient bandwidth to whichattack-trafficthe flow of attack traffic should be redirected. For example,thea simplealgorithm of theselectionisalgorithm can be used to choose a path whose available capacity is greater than the "peak-g" telemetry attribute that was indicated in a DOTS telemetry message. After that, the orchestrator orders the appropriate forwarding nodes to redirect the attack traffic to the DMS by dissemination of Flow Specifications using tools such asBorder Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec)BGP Flowspec <xreftarget="RFC8955"></xref>.</t>target="RFC8955" format="default"/>.</t> <t>The detailed path selection algorithm is out of the scope of this document.</t> <t>The flow collector and forwarding nodes implement a DOTS client while the orchestrator implements a DOTS server.</t> </section> <section anchor="section_use_cases_ddos_mitigation_bandwidth_offloadingvolumetricattackflow"title="Shortnumbered="true" toc="default"> <name>Short but Extreme Volumetric AttackMitigation">Mitigation</name> <t>Short but extreme volumetric attacks, such as pulse wave DDoS attacks, are threats to Internet transit provider networks. These attacks start from zero and go to maximum values in a very short timespan, thenspan. The attacks go back tozero,zero and then back tomaximum,maximum values, repeating in continuous cycles at short intervals. It is difficult forthetransit providers to mitigate such an attack with their DMSesusing aby redirecting attack flows because this may cause route flapping in the network. The practical way to mitigate short but extreme volumetric attacks is to offload mitigation actions to a forwarding node.</t> <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<xref target="attack_mitigation"/> gives an overview of this use case.Figure 8<xref target="total_pipe_capacity"/> provides an example of a DOTS telemetry message body that is used to signal total pipe capacity.Figure 9<xref target="total_attack_traffic"/> provides an example of a DOTS telemetry message body that is used to signal variousattack trafficpercentilesandfor total trafficpercentiles.</t> <t><figure align="center"> <artwork><![CDATA[and total attack traffic. </t> <figure anchor="attack_mitigation"><name>Short but Extreme Volumetric Attack Mitigation</name> <artwork name="" type="" align="left" alt=""><![CDATA[ (Internet Transit Provider) +------------+ +----------------+ | Network | DOTS | Administrative |Alert ----->|BGP Flowspec Alert----->| Management |C<--->S| System |BGP Flowspec(Rate-Limit) | System | | |---> +------------+ +----------------++------------+ +------------+BGP Flowspec +------------+ +------------+ (Rate-Limit X bps) | Forwarding | | Forwarding |<--- | node | | node | Link1 | | | | DDoS & Normal traffic [Target]<------------------------------------================ Pipe +------------+ +------------+ Attack Traffic Capability Bandwidth X bps Y bpsNetwork accessNetwork-access success rate X / (X + Y)* C is forC: DOTS client functionality* S is forS: DOTS server functionalityFigure 7: Short but Extreme Volumetric Attack Mitigation]]></artwork> </figure><figure> <artwork><![CDATA[<figure anchor="total_pipe_capacity"><name>Example of Message Body with Total Pipe Capacity</name> <sourcecode name="" type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry-setup": { "telemetry": [ { "total-pipe-capacity": [ { "link-id": "link1", "capacity": "1000", "unit": "megabit-ps" } ] } ] } }Figure 8: Example]]></sourcecode> </figure> <figure anchor="total_attack_traffic"><name>Example of Message Body with TotalPipe Capacity ]]></artwork> </figure> <figure> <artwork><![CDATA[Attack Traffic and Total Traffic</name> <sourcecode name="" type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "total-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "800", "peak-g": "1300" } ], "total-attack-traffic": [ { "unit": "megabit-ps", "low-percentile-g": "200", "mid-percentile-g": "400", "high-percentile-g": "500", "peak-g": "600", "current-g": "400" } ] } ] } }Figure 9: Example of Message Body with Total Attack Traffic, and Total Traffic ]]></artwork> </figure></t>]]></sourcecode> </figure> <t>When DDoS attacks occur, the network management system receives alerts. Then, it sends the target IP address(es) and volume of the DDoS attack traffic to the administrative systembyusing the "target-prefix" and "total-attack-traffic" DOTS telemetry attributes. After that, the administrative system orders relevant forwarding nodes to carry out rate-limiting of all traffic destined to the target based on the pipe capability by the dissemination of the Flow Specifications using tools such asBorder Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec)BGP Flowspec <xreftarget="RFC8955"></xref>.target="RFC8955" format="default"/>. In addition, the administrative system estimates the network-access 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 telemetry setup in advance(Section 7.2 of <xref target="RFC9244"></xref>).</t>(<xref target="RFC9244" sectionFormat="of" section="7.2"/>).</t> <t>The network management system implements a DOTS client while the administrative system implements a DOTS server.</t> </section> <section anchor="section_use_cases_ddos_mitigation_attack_type_techniqueselection"title="Selectingnumbered="true" toc="default"> <name>Selecting Mitigation Technique Based on AttackType">Type</name> <t>Some volumetric attacks, such as DNS amplification attacks, can be detected with high accuracy by checking the Layer 3 or Layer 4 information of attack packets. These attacks can be detected and mitigated through cooperation among forwarding nodes and flow collectorsbyusing IPFIX. It may also be necessary to inspect the Layer 7 information of suspicious packets to detect attacks such as DNSWater Torture Attackswater torture attacks <xreftarget="DNS Water Torture Attack"></xref>.target="DNS_Water_Torture_Attack" format="default"/>. To carry out the DNS water torture attack, an attacker commands a botnet to make thousands of DNS requests for fake subdomains against anAuthoritative Name Server.authoritative name server. Such attack traffic should be detected and mitigated at the DMS.</t> <t>This use case enables transit providers to select a mitigation technique based on the type of attacktraffic:traffic, whether it 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 on the attack type through cooperation among forwarding nodes, flow collectors, and an orchestrator. </t><t>Figure 10<t><xref target="mitigation_attack_type"/> gives an overview of this use case.Figure 11<xref target="attack_mappings"/> provides an example of attack mappings that are sharedbyusing the DOTS data channel in advance.Figure 12<xref target="attack_connection_type"/> provides an example of a DOTS telemetry message body that is used to signalvariouspercentiles for total attacktraffic percentiles,traffic, total attack trafficpercentiles,protocol, and total attackconnection, andconnection; it also shows attacktype.</t>details. </t> <t>The example inFigure 11<xref target="attack_mappings"/> uses the folding defined in <xreftarget="RFC8792"></xref>target="RFC8792" format="default"/> for long lines. </t><t><figure align="center"> <artwork><![CDATA[<figure anchor="mitigation_attack_type"><name>Selecting Mitigation Technique Based on Attack Type</name> <artwork name="" type="" align="left" alt=""><![CDATA[ (Internet Transit Provider) +-----------+ DOTS +--------------+ +-----------+|<---->| | BGP (Redirect) IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop) --->| collector |+ | |---> +-----------+ +--------------+ +------------+ BGP (Redirect) IPFIX +------------+| BGP Flowspec (Drop) <---| Forwarding ||<--- | nodes || DDoS Attack | ++=====||================ | || ||x<==============[DNS Amp] | || |+x<==============[NTP Amp] +-----||-----+ || |/ +-----x------+ | DDoS | | mitigation | | system | +------------+* C is forC: DOTS client functionality* S is forS: DOTS server functionality*DNS Amp: DNS Amplification*NTP Amp: NTP AmplificationFigure 10: DDoS Mitigation Based on]]></artwork></figure> <figure anchor="attack_mappings"><name>Example of Message Body with AttackType ]]></artwork> </figure> <figure> <artwork><![CDATA[===============Mappings</name> <sourcecode name="" type="json"><![CDATA[=============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-dots-mapping:vendor-mapping": { "vendor": [ { "vendor-id": 32473, "vendor-name": "mitigator-c", "last-updated": "1629898958", "attack-mapping": [ { "attack-id": 77, "attack-description": "DNS amplification Attack: \ This attack is a type of reflection attack in which attackers \ spoof a target's IP address. The attackers abuse vulnerabilities \ in DNS servers to turn small queries into larger payloads." }, { "attack-id": 92, "attack-description":"NTP amplification Attack: \ This attack is a type of reflection attack in which attackers \ spoof a target's IP address. The attackers abuse vulnerabilities \ in NTP servers to turn small queries into larger payloads." } ] } ] } }Figure 11: Example]]></sourcecode> </figure> <figure anchor="attack_connection_type"><name>Example of Message Body with Total AttackMappings ]]></artwork> </figure> <figure> <artwork><![CDATA[Traffic, Total Attack Traffic Protocol, Total Attack Connection, and Attack Detail</name> <sourcecode name="" type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "total-attack-traffic": [ { "unit": "megabit-ps", "low-percentile-g": "600", "mid-percentile-g": "800", "high-percentile-g": "1000", "peak-g": "1100", "current-g": "700" } ], "total-attack-traffic-protocol": [ { "protocol": 17, "unit": "megabit-ps", "mid-percentile-g": "500" }, { "protocol": 15, "unit": "megabit-ps", "mid-percentile-g": "200" } ], "total-attack-connection": [ { "mid-percentile-l": [ { "protocol": 15, "connection": 200 } ], "high-percentile-l": [ { "protocol": 17, "connection": 300 } ] } ], "attack-detail": [ { "vendor-id": 32473, "attack-id": 77, "start-time": "1641169211", "attack-severity": "high" }, { "vendor-id": 32473, "attack-id": 92, "start-time": "1641172809", "attack-severity": "high" } ] } ] } }Figure 12: Example of Message Body with Total Attack Traffic, Total Attack Traffic Protocol, Total Attack Connection and Attack Type ]]></artwork> </figure></t>]]></sourcecode> </figure> <t>Attack mappings are sharedbyusing the DOTS data channel in advance(Section 8.1.6 of <xref target="RFC9244"></xref>).(<xref target="RFC9244" sectionFormat="of" section="8.1.6"/>). The forwarding nodes send traffic statistics to the flow collectors, e.g., using IPFIX. When DDoS attacks occur, the flow collectors identify attack traffic and send attack type information to the orchestratorbyusing the "vendor-id" and "attack-id" telemetry attributes. The orchestrator then resolves abused port numbers and orders relevant forwarding nodes to block the amplification attack traffic flow by dissemination of Flow Specifications using tools such asBorder Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec)BGP Flowspec <xreftarget="RFC8955"></xref>.target="RFC8955" format="default"/>. Also, the orchestrator orders relevant forwarding nodes to redirectothertraffic other than the amplification attack trafficbyusing a routing protocol, such as BGP <xreftarget="RFC4271"></xref>.</t>target="RFC4271" format="default"/>.</t> <t>The flow collector implements a DOTS client while the orchestrator implements a DOTS server.</t> </section> </section> <section anchor="section_ddos_detailed_mitigation_report"title="Detailednumbered="true" toc="default"> <name>Detailed DDoS MitigationReport">Report</name> <t>It is possible for the transit provider to add value to the DDoS mitigation service by reporting ongoing and detailed DDoS countermeasure status to the enterprise network. In addition, it is possible for the transit provider to know whether the DDoS countermeasure is effective or not by receiving reports from the enterprise network.</t> <t>This use case enables the mutual sharing of information about ongoing DDoS countermeasures between the transit provider and the enterprisenetwork mutually. Figure 13network. <xref target="mitigation_report"/> gives an overview of this use case.Figure 14<xref target="pipe_capacity"/> provides an example of a DOTS telemetry message body that is used to signal total pipe capacity from the enterprise network administrator to the orchestrator in the ISP.Figure 15<xref target="example_message"/> provides an example of a DOTS telemetry message body that is used to signalvariouspercentiles for total trafficpercentiles,and total attack trafficpercentiles, andas well as attack details from the orchestrator to thenetwork.</t> <t><figure align="center"> <artwork><![CDATA[network. </t> <figure anchor="mitigation_report"><name>Detailed DDoS Mitigation Report</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +------------------+ +------------------------+ | Enterprise | | Upstream | | Network | | Internet Transit | | +------------+ | | Provider | | | Network |C | | S+--------------+ | | | admini- |<-----DOTS---->| Orchestrator | | | | strator | | | +--------------+ | | +------------+ | | C ^ | | | | | DOTS | | | | S v | | | | +---------------+ DDoS Attack | | | | DMS |+======= | | | +---------------+ | | | | || Clean | | | | |/ Traffic | | +---------+ | | +---------------+ | | | DDoS | | | | Forwarding | Normal Traffic | | Target |<================| Node |======== | +---------+ | Link1 | +---------------+ | +------------------+ +------------------------+* C is forC: DOTS client functionality* S is forS: DOTS server functionalityFigure 13: Detailed DDoS Mitigation Report]]></artwork> </figure><figure> <artwork><![CDATA[<figure anchor="pipe_capacity"><name>Example of Message Body with Total Pipe Capacity</name> <sourcecode name="" type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry-setup": { "telemetry": [ { "total-pipe-capacity": [ { "link-id": "link1", "capacity": "1000", "unit": "megabit-ps" } ] } ] } }Figure 14: An Example]]></sourcecode> </figure> <figure anchor="example_message"> <name>Example of Message Body with TotalPipe Capacity ]]></artwork> </figure> <figure> <artwork><![CDATA[Traffic, Total Attack Traffic, and Attack Detail </name> <sourcecode name="" type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "tmid": 567, "target": { "target-prefix": [ "2001:db8::1/128" ] }, "target-protocol": [ 17 ], "total-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "800" } ], "total-attack-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "100" } ], "attack-detail": [ { "vendor-id": 32473, "attack-id": 77, "start-time": "1644819611", "attack-severity": "high" } ] } ] } }Figure 15: An Example of Message Body with Total Traffic, Total Attack Traffic Protocol, and Attack Detail ]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The network management system in the enterprise network reports limits of incoming traffic volume from the transit provider to the orchestrator in the transit provider in advance. It is reportedbyusing the "total-pipe-capacity" telemetry attribute in the DOTS telemetry setup.</t> <t>When DDoS attacks occur, DDoS mitigation orchestration <xreftarget="RFC8903"></xref>target="RFC8903" format="default"/> is carried out in the transit provider. Then, the DDoS mitigation systems report the status of DDoS countermeasures to the orchestrator by sending "attack-detail" telemetry attributes. After that, the orchestrator integrates the reports from the DDoS mitigation systems, while removing duplicate contents, and sends the integrated report to a network administratorbyusing DOTS telemetry periodically.</t> <t>During the DDoS mitigation, the orchestrator in the transit provider retrieves the link congestion status from the network manager in the enterprise networkbyusing the "total-traffic" telemetry attributes. Then, the orchestrator checks whether or not the DDoS countermeasures are effectiveor notby comparing the "total-traffic" and the "total-pipe-capacity" telemetry attributes.</t> <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 network administrator implements a DOTS client.</t> </section> <section anchor="section_use_cases_dms_tuning"title="Tuningnumbered="true" toc="default"> <name>Tuning MitigationResources">Resources</name> <section anchor="section_use_cases_ddos_detection_training"title="Supervisednumbered="true" toc="default"> <name>Supervised Machine Learning of FlowCollector">Collector</name> <t>DDoS detection based on tools, such as IPFIX, is alighter weightlighter-weight method of detecting DDoS attacksthancompared to DMSes in Internet transit provider networks. DDoS detection based on the DMSes is a more accurate method for detecting attack traffic than flow monitoring.</t> <t>The aim of this use case is to increase flow collectors' detection accuracy by carrying out supervised machine-learning techniques according to attack detail reported by the DMSes. To use such a technique, forwarding nodes, flow collectors, and a DMS should cooperate.Figure 16<xref target="training_supervised"/> gives an overview of this use case.Figure 17<xref target="message_body_attack"/> provides an example of a DOTS telemetry message body that is used to signalvarious total attack traffic percentiles andattackdetail.</t> <t><figure align="center"> <artwork><![CDATA[detail. </t> <figure anchor="training_supervised"> <name>Supervised Machine Learning of Flow Collector</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +-----------+ +-----------+| DOTS IPFIX | Flow ||S<--- --->| collector || +-----------++ +------------+ IPFIX +------------+| <---| Forwarding || | nodes || DDoS Attack [ Target ] | ++============================== | || ++=========================== | || || ++======================== +---||-|| ||-+ || || || |/ |/ |/ DOTS +---X--X--X--+ --->C| DDoS | | mitigation | | system | +------------+* C is forC: DOTS client functionality* S is forS: DOTS server functionalityFigure 16: Training Supervised Machine Learning of Flow Collectors]]></artwork> </figure><figure> <artwork><![CDATA[<figure anchor="message_body_attack"> <name>Example of Message Body with Attack Detail and Top Talkers</name> <sourcecode name="" type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "attack-detail": [ { "vendor-id": 32473, "attack-id": 77, "start-time": "1634192411", "attack-severity": "high", "top-talker": { "talker": [ { "source-prefix": "2001:db8::2/127" } ] } } ] } ] } }Figure 17: An Example of Message Body with Attack Type and top-talkers ]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The forwarding nodes send traffic statistics to the flow collectors, e.g., using IPFIX. When DDoS attacks occur, DDoS mitigation orchestration is carried out (as perSection 3.3 of<xreftarget="RFC8903"></xref>)target="RFC8903" sectionFormat="of" section="3.3"/>), and the DMS mitigates all attack traffic destined for a target. The DDoS mitigation system reports the "vendor-id", "attack-id", and "top-talker" telemetry attributes to a flow collector.</t> <t>After mitigating a DDoS attack, the flow collector attaches outputs of the DMS as labels to the statistics of the traffic flow oftop-talkers.top talkers. The outputs, for example, are the "attack-id" telemetry attributes. The flow collector then carries out supervised machine learning to increase its detection accuracy, setting the statistics as an explanatory variable and setting the labels as an objective variable.</t> <t>The DMS implements a DOTS client while the flow collector implements a DOTS server.</t> </section> <section anchor="section_use_cases_tuning_threshold"title="Unsupervisednumbered="true" toc="default"> <name>Unsupervised Machine Learning of FlowCollector">Collector</name> <t>DMSes can detect DDoS attack traffic, which means DMSes can also identify clean traffic. This use case supports unsupervisedmachine-learningmachine learning for anomaly detection according to a baseline reported by the DMSes. To use such a technique, forwarding nodes, flow collectors, and a DMS should cooperate.Figure 18<xref target="training_unsupervised"/> gives an overview of this use case.Figure 19<xref target="traffic_baseline"/> provides an example of a DOTS telemetry message body that is used to signal baseline.</t><t><figure align="center"> <artwork><![CDATA[<figure anchor="training_unsupervised"> <name>Unsupervised Machine Learning of Flow Collector</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +-----------+ +-----------+| DOTS | Flow || --->S| collector || +-----------++ +------------+ +------------+| | Forwarding || | nodes || Traffic [ Destination ] <== =============++============================== | || || | || |+ +---||-------+ || |/ DOTS +---X--------+ --->C| DDoS | | mitigation | | system | +------------+* C is forC: DOTS client functionality* S is forS: DOTS server functionalityFigure 18: Training Unsupervised Machine Learning of Flow Collectors]]></artwork> </figure><figure> <artwork><![CDATA[<figure anchor="traffic_baseline"> <name>Example of Message Body with Traffic Baseline</name> <sourcecode name="" type="json"><![CDATA[ { "ietf-dots-telemetry:telemetry-setup": { "telemetry": [ { "baseline": [ { "id": 1, "target-prefix": [ "2001:db8:6401::1/128" ], "target-port-range": [ { "lower-port": "53" } ], "target-protocol": [ 17 ], "total-traffic-normal": [ { "unit": "megabit-ps", "low-percentile-g": "30", "mid-percentile-g": "50", "high-percentile-g": "60", "peak-g": "70" } ] } ] } ] } }Figure 19: An Example of Message Body with Traffic Baseline ]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The forwarding nodes carry out traffic mirroring to copy the traffic destined to an IP address and to monitor the traffic by a DMS. The DMS then identifies"clean"clean traffic and reports the baseline telemetry attributes to the flow collectorbyusing DOTS telemetry.</t> <t>The flow collector then carries out unsupervised machine learning to be able to carry out anomaly detection.</t> <t>The DMS implements a DOTS client while the flow collector implements a DOTS server.</t> </section> </section> </section> <sectiontitle="Security Considerations"> <t>DOTS telemetry securitynumbered="true" toc="default"> <name>Security Considerations</name> <t>Security considerations for DOTS telemetry are discussed inSection 14 of<xreftarget="RFC9244"></xref>.target="RFC9244" sectionFormat="of" section="14"/>. These considerations applyforto the communication interfaces where DOTS is used. </t> <t>Some use cases involve controllers, orchestrators, and programmable interfaces. These interfaces can be misused by misbehaving nodes to further exacerbate DDoS attacks. The considerations are for end-to-end systems for DoS mitigation, so the mechanics are outside the scope of DOTS protocols.Section 5 of<xreftarget="RFC7149"></xref>target="RFC7149" sectionFormat="of" section="5"/> discusses some generic security considerations to take into account in such contexts (e.g., reliable access control). Specific security measures depend on the actual mechanism used to control underlying forwarding nodes and other controlled elements. For example,Section 13 of<xreftarget="RFC8955"></xref>target="RFC8955" sectionFormat="of" section="12"/> discusses security considerations that are relevant to BGP Flowspec. IPFIX-specific considerations are discussed inSection 11 of<xreftarget="RFC7011"></xref>.</t>target="RFC7011" sectionFormat="of" section="11"/>.</t> </section> <sectiontitle="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentdoes not require any action from IANA.</t> </section> <section title="Acknowledgement"> <t>The authors would like to thank Mohamed Boucadair and Valery Smyslov for 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>has no IANA actions.</t> </section> </middle><!-- ***** BACK MATTER ***** --><back><references title="Normative References"> <?rfc include="reference.RFC.9244"?><references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9244.xml"/> </references><references title="Informative References"> <?rfc include="reference.RFC.8903"?> <?rfc include="reference.RFC.4271"?> <?rfc include="reference.RFC.8955"?> <?rfc include="reference.RFC.8612"?> <?rfc include="reference.RFC.3413"?> <?rfc include="reference.RFC.7950"?> <?rfc include="reference.RFC.7011"?> <?rfc include="reference.RFC.9132"?> <?rfc include="reference.RFC.8783"?> <?rfc include='reference.RFC.8792'?> <?rfc include='reference.RFC.7149'?><references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8903.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8612.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3413.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9132.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7149.xml"/> <referenceanchor="DOTS Overview"anchor="DOTS_Overview" target="https://datatracker.ietf.org/meeting/108/materials/slides-108-saag-dots-overview-00"><!-- Manually added reference --><front><title>DOTS Overview (RFCs 8782, 8783)</title><title>DDoS Open Threat Signaling (DOTS)</title> <author initials="T." surname="Reddy"fullname="T.fullname="Tirumaleswar Reddy"> <organization/> </author> <author initials="M." surname="Boucadair"fullname="M.fullname="Mohamed Boucadair"> <organization/> </author> <date year="2020" month="July"/> </front> </reference> <referenceanchor="DNS Water Torture Attack"anchor="DNS_Water_Torture_Attack" target="https://dl.acm.org/doi/10.1145/3297156.3297272"><!-- Manually added reference --><front> <title>A Large Scale Analysis of DNS Water Torture Attack</title> <author initials="X." surname="Luo" fullname="Xi Luo"> <organization/> </author> <author initials="L."surname="Xi" fullname="L. Xi">surname="Wang" fullname="Liming Wang"> <organization/> </author> <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><!-- Appendix --></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> </back> </rfc>