<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-dots-telemetry-use-cases-15" indexInclude="true" ipr="trust200902" number="9387" prepTime="2023-04-20T20:56:18" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry-use-cases-15" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9387" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="DOTS Telemetry Use Cases">Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry</title>
    <seriesInfo name="RFC" value="9387" stream="IETF"/>
    <author fullname="Yuhei Hayashi" initials="Y." surname="Hayashi">
      <organization abbrev="NTT" showOnFrontPage="true">NTT</organization>
      <address>
        <postal>
          <street>3-9-11, Midori-cho</street>
          <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">
      <organization abbrev="China Mobile" showOnFrontPage="true">China Mobile</organization>
      <address>
        <postal>
          <street>32, Xuanwumen West</street>
          <city>Beijing</city>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>chenmeiling@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Li Su" initials="L." surname="Su">
      <organization abbrev="China Mobile" showOnFrontPage="true">China Mobile</organization>
      <address>
        <postal>
          <street>32, Xuanwumen West</street>
          <city>Beijing</city>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>suli@chinamobile.com</email>
      </address>
    </author>
    <date month="04" year="2023"/>
    <area>sec</area>
    <workgroup>dots</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">DDoS Open Threat Signaling (DOTS) telemetry 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 DOTS 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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9387" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-telemetry-use-cases">Telemetry Use Cases</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mitigation-resources-assign">Mitigation Resources Assignment</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.1.2">
                  <li pn="section-toc.1-1.3.2.1.2.1">
                    <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.2.1.1"><xref derivedContent="3.1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mitigating-attack-flow-of-t">Mitigating Attack Flow of Top Talker Preferentially</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.2.1"><xref derivedContent="3.1.2" format="counter" sectionFormat="of" target="section-3.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dms-selection-for-mitigatio">DMS Selection for Mitigation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.3.1"><xref derivedContent="3.1.3" format="counter" sectionFormat="of" target="section-3.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-selection-for-redirect">Path Selection for Redirection</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.4.1"><xref derivedContent="3.1.4" format="counter" sectionFormat="of" target="section-3.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-short-but-extreme-volumetri">Short but Extreme Volumetric Attack Mitigation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.5.1"><xref derivedContent="3.1.5" format="counter" sectionFormat="of" target="section-3.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-selecting-mitigation-techni">Selecting Mitigation Technique Based on Attack Type</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-detailed-ddos-mitigation-re">Detailed DDoS Mitigation Report</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tuning-mitigation-resources">Tuning Mitigation Resources</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-supervised-machine-learning">Supervised Machine Learning of Flow Collector</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.2.1"><xref derivedContent="3.3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unsupervised-machine-learni">Unsupervised Machine Learning of Flow Collector</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="section_introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Distributed Denial-of-Service (DDoS) attacks, such as volumetric
      attacks and resource-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 indent="0" pn="section-1-2">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 indent="0" pn="section-1-3">DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time
      signaling, threat-handling requests, and data filtering between the
      multivendor elements <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/> <xref target="RFC8783" format="default" sectionFormat="of" derivedContent="RFC8783"/>. DOTS telemetry enriches the DOTS protocols
      with various telemetry attributes allowing optimal DDoS attack
      mitigation <xref target="RFC9244" format="default" sectionFormat="of" derivedContent="RFC9244"/>. 
This document presents sample use cases for DOTS telemetry to enhance the
overview and the purpose described in      
      <xref target="RFC9244" format="default" sectionFormat="of" derivedContent="RFC9244"/>.
      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" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">Readers should be familiar with the terms defined in <xref target="RFC8612" format="default" sectionFormat="of" derivedContent="RFC8612"/>, <xref target="RFC8903" format="default" sectionFormat="of" derivedContent="RFC8903"/>, and <xref target="RFC9244" format="default" sectionFormat="of" derivedContent="RFC9244"/>.</t>
      <t indent="0" pn="section-2-2">In addition, this document uses the following terms:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-3">
        <dt pn="section-2-3.1">Supervised Machine Learning:</dt>
        <dd pn="section-2-3.2">A machine-learning
          technique in which labeled data is used to train the algorithms (the
          input and output data are known).</dd>
        <dt pn="section-2-3.3">Unsupervised Machine Learning:</dt>
        <dd pn="section-2-3.4">A machine-learning
          technique in which unlabeled data is used to train the algorithms
          (the data has no historical labels).</dd>
      </dl>
    </section>
    <section anchor="section_use_cases" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-telemetry-use-cases">Telemetry Use Cases</name>
      <t indent="0" pn="section-3-1">This section describes DOTS telemetry use cases that use telemetry attributes
      included in the DOTS telemetry specification <xref target="RFC9244" format="default" sectionFormat="of" derivedContent="RFC9244"/>.</t>
      <t indent="0" pn="section-3-2">The following subsections assume that once the DOTS signal channel is
        established, DOTS clients will proceed with the telemetry setup configuration
        detailed in <xref target="RFC9244" sectionFormat="of" section="7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9244#section-7" derivedContent="RFC9244"/>.
        The following telemetry parameters are used:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-3">
        <li pn="section-3-3.1">"measurement-interval" defines the period during which percentiles
        are computed.</li>
        <li pn="section-3-3.2">"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" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-mitigation-resources-assign">Mitigation Resources Assignment</name>
        <section anchor="section_use_cases_ddos_mitigation_bandwidth_top-talker" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.1">
          <name slugifiedName="name-mitigating-attack-flow-of-t">Mitigating Attack Flow of Top Talker Preferentially</name>
          <t indent="0" pn="section-3.1.1-1">Some transit providers have to mitigate large-scale DDoS
          attacks using DDoS Mitigation Systems (DMSes) with limited
          resources that are already deployed in their network. For example,
          recently reported large DDoS attacks exceeded several Tbps
          <xref target="DOTS_Overview" format="default" sectionFormat="of" derivedContent="DOTS_Overview"/>.</t>
          <t indent="0" pn="section-3.1.1-2">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 of top talkers is redirected to the DMS
          preferentially by cooperation among forwarding nodes, flow
          collectors, and orchestrators. </t>
          <t indent="0" pn="section-3.1.1-3"><xref target="DDos_attack-flow" format="default" sectionFormat="of" derivedContent="Figure 1"/> gives an overview of this use case. <xref target="example_message_body" format="default" sectionFormat="of" derivedContent="Figure 2"/> provides an
          example of a DOTS telemetry message body that is used to signal
          top talkers (2001:db8:1::/48 and 2001:db8:2::/48).</t>
          <figure anchor="DDos_attack-flow" align="left" suppress-title="false" pn="figure-1">
            <name slugifiedName="name-mitigating-attack-flow-of-to">Mitigating Attack Flow of Top Talker Preferentially</name>
            <artwork type="" align="left" alt="" pn="section-3.1.1-4.1">
(Internet Transit Provider)

               +-----------+      +--------------+ SNMP or YANG/NETCONF
        IPFIX +-----------+| DOTS |              |&lt;---
          ---&gt;| Flow      ||C&lt;--&gt;S| Orchestrator | BGP Flowspec
              | collector |+      |              |---&gt;   (Redirect)
              +-----------+       +--------------+

                         +-------------+
                  IPFIX +-------------+| BGP Flowspec (Redirect)
                    &lt;---| Forwarding  ||&lt;---
                        |    nodes    ||
                        |             ||           DDoS Attack
[ Target(s) ]&lt;==========================================
                        |    ++=========================[top talker]
                        |    || ++======================[top talker]
                        +----|| ||----+
                             || ||
                             || ||
                             |/ |/
                        +----x--x----+
                        | DDoS       | SNMP or YANG/NETCONF
                        | mitigation |&lt;---
                        | system     |
                        +------------+

    C: DOTS client functionality
    S: DOTS server functionality
</artwork>
          </figure>
          <figure anchor="example_message_body" align="left" suppress-title="false" pn="figure-2">
            <name slugifiedName="name-example-of-message-body-to-">Example of Message Body to Signal Top Talkers</name>
            <sourcecode type="json" markers="false" pn="section-3.1.1-5.1">
{
  "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"
                    }
                  ]
                }
              ]
            }
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.1.1-6">The forwarding nodes send traffic statistics to the flow collectors, e.g.,
using IP Flow Information Export (IPFIX) <xref target="RFC7011" format="default" sectionFormat="of" derivedContent="RFC7011"/>.  When DDoS attacks occur, the flow collectors identify the
attack traffic and send information about the top talkers to the orchestrator
using the "target-prefix" and "top-talkers" DOTS telemetry attributes. The
orchestrator then checks the available capacity of the DMSes using a
network management protocol, such as the Simple Network Management Protocol
(SNMP) <xref target="RFC3413" format="default" sectionFormat="of" derivedContent="RFC3413"/> or YANG with the Network
Configuration Protocol (YANG/NETCONF) <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/>.  After that, the orchestrator orders the forwarding nodes
to redirect as much of the top talker's traffic to the DMSes as they can
handle by dissemination of Flow Specifications using tools such as Border
Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec)
<xref target="RFC8955" format="default" sectionFormat="of" derivedContent="RFC8955"/>. </t>
          <t indent="0" pn="section-3.1.1-7">The flow collector implements a DOTS client while the
          orchestrator implements a DOTS server.</t>
        </section>
        <section anchor="dms_selection" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.2">
          <name slugifiedName="name-dms-selection-for-mitigatio">DMS Selection for Mitigation</name>
          <t indent="0" pn="section-3.1.2-1">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 indent="0" pn="section-3.1.2-2">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 of the DMS. <xref target="DMS_selection" format="default" sectionFormat="of" derivedContent="Figure 3"/>
          gives an overview of this use case. <xref target="message_body" format="default" sectionFormat="of" derivedContent="Figure 4"/>
          provides an example of a DOTS telemetry message body that is used to
          signal percentiles for total attack traffic.
          </t>
          <figure anchor="DMS_selection" align="left" suppress-title="false" pn="figure-3">
            <name slugifiedName="name-dms-selection-for-mitigation">DMS Selection for Mitigation</name>
            <artwork name="" type="" align="left" alt="" pn="section-3.1.2-3.1">
(Internet Transit Provider)

               +-----------+      +--------------+ SNMP or YANG/NETCONF
        IPFIX +-----------+| DOTS |              |&lt;---
          ---&gt;| Flow      ||C&lt;--&gt;S| Orchestrator | BGP (Redirect)
              | collector |+      |              |---&gt;
              +-----------+       +--------------+

                         +------------+
                  IPFIX +------------+| BGP (Redirect)
                    &lt;---| Forwarding ||&lt;---
                        |    nodes   ||
                        |            ||     DDoS Attack
[Target A]              | ++=================== [Destined for Target A]
[Target B]              | ||  ++=============== [Destined for Target B]
                        +-||--||-----+
                          ||  ||
                    ++====++  ||  (congested DMS)
                    ||        ||  +-----------+
                    ||        |/  |      DMS3 |
                    ||  +-----x------+        |&lt;--- SNMP or YANG/NETCONF
                    |/  |       DMS2 |--------+
                 +--x---------+      |&lt;--- SNMP or YANG/NETCONF
                 |       DMS1 |------+
                 |            |&lt;--- SNMP or YANG/NETCONF
                 +------------+

    C: DOTS client functionality
    S: DOTS server functionality
</artwork>
          </figure>
          <figure anchor="message_body" align="left" suppress-title="false" pn="figure-4">
            <name slugifiedName="name-example-of-message-body-wit">Example of Message Body with Total Attack Traffic</name>
            <sourcecode name="" type="json" markers="false" pn="section-3.1.2-4.1">
{
  "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"
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.1.2-5">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 orchestrator using the
          "target-prefix" and "total-attack-traffic" DOTS telemetry
          attributes. The orchestrator then checks the available capacity of
          the DMSes using a network management protocol, such as the Simple
          Network Management Protocol (SNMP) <xref target="RFC3413" format="default" sectionFormat="of" derivedContent="RFC3413"/> or YANG with the Network Configuration Protocol
          (YANG/NETCONF) <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/>.  After
          that, the orchestrator selects a DMS with sufficient capacity to
          which attack traffic should be redirected.  For example, a simple
          DMS selection algorithm can 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 <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/>. </t>
          <t indent="0" pn="section-3.1.2-6">The detailed DMS selection algorithm is out of the scope of this
          document.</t>
          <t indent="0" pn="section-3.1.2-7">The flow collector implements a DOTS client while the
          orchestrator implements a DOTS server.</t>
        </section>
        <section anchor="redirection_path_selection" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.3">
          <name slugifiedName="name-path-selection-for-redirect">Path Selection for Redirection</name>
          <t indent="0" pn="section-3.1.3-1">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 indent="0" pn="section-3.1.3-2">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" format="default" sectionFormat="of" derivedContent="Figure 5"/> gives an overview of this
          use case. <xref target="message_total_attack" format="default" sectionFormat="of" derivedContent="Figure 6"/> provides an example
          of a DOTS telemetry message body that is used to signal percentiles
          for total traffic and total attack traffic.
          </t>
          <figure anchor="path_selection" align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-path-selection-for-redirecti">Path Selection for Redirection</name>
            <artwork name="" type="" align="left" alt="" pn="section-3.1.3-3.1">
(Internet Transit Provider)

          +-----------+      +--------------+ DOTS
         +-----------+|      |              |S&lt;---
   IPFIX | Flow      || DOTS | Orchestrator |
      --&gt;| collector ||C&lt;--&gt;S|              | BGP Flowspec (Redirect)
         |           |+      |              |---&gt;
         +-----------+       +--------------+

               DOTS +------------+  DOTS +------------+ IPFIX
               ---&gt;C| Forwarding |  ---&gt;C| Forwarding |---&gt;
       BGP Flowspec |   node     |       |   node     |
     (Redirect) ---&gt;|            |       |            |  DDoS Attack
[Target]            |       ++====================================
                    +-------||---+       +------------+
                            ||              /
                            ||             / (congested link)
                            ||            /
                    DOTS  +-||----------------+ BGP Flowspec (Redirect)
                     ---&gt;C| ||  Forwarding    |&lt;---
                          | ++===  node       |
                          +----||-------------+
                               |/
                            +--x-----------+
                            |     DMS      |
                            +--------------+

    C: DOTS client functionality
    S: DOTS server functionality
</artwork>
          </figure>
          <figure anchor="message_total_attack" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-example-of-message-body-with">Example of Message Body with Total Attack Traffic and Total Traffic</name>
            <sourcecode name="" type="json" markers="false" pn="section-3.1.3-4.1">
{
  "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"
           }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.1.3-5">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
orchestrator using the "target-prefix" and "total-attack-traffic" DOTS
telemetry attributes.  The underlying forwarding nodes send the volume of the
total traffic passing the node to the orchestrator using the
"total-traffic" telemetry attributes.  The orchestrator then selects a path
with sufficient bandwidth to which the flow of attack traffic should be
redirected.  For example, a simple selection algorithm 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 as BGP Flowspec
<xref target="RFC8955" format="default" sectionFormat="of" derivedContent="RFC8955"/>.</t>
          <t indent="0" pn="section-3.1.3-6">The detailed path selection algorithm is out of the scope of this
          document.</t>
          <t indent="0" pn="section-3.1.3-7">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" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.4">
          <name slugifiedName="name-short-but-extreme-volumetri">Short but Extreme Volumetric Attack Mitigation</name>
          <t indent="0" pn="section-3.1.4-1">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
          time span. The attacks go back to zero and then back to maximum
          values, repeating in continuous cycles at short intervals.  It is
          difficult for transit providers to mitigate such an attack with
          their DMSes by 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 indent="0" pn="section-3.1.4-2">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. <xref target="attack_mitigation" format="default" sectionFormat="of" derivedContent="Figure 7"/> gives an overview of
          this use case. <xref target="total_pipe_capacity" format="default" sectionFormat="of" derivedContent="Figure 8"/> provides an
          example of a DOTS telemetry message body that is used to signal
          total pipe capacity. <xref target="total_attack_traffic" format="default" sectionFormat="of" derivedContent="Figure 9"/> provides
          an example of a DOTS telemetry message body that is used to signal
          various percentiles for total traffic and total attack traffic.

          </t>
          <figure anchor="attack_mitigation" align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-short-but-extreme-volumetric">Short but Extreme Volumetric Attack Mitigation</name>
            <artwork name="" type="" align="left" alt="" pn="section-3.1.4-3.1">
(Internet Transit Provider)

           +------------+       +----------------+
           | Network    |  DOTS | Administrative | BGP Flowspec
Alert-----&gt;| Management |C&lt;---&gt;S| System         | (Rate-Limit)
           | System     |       |                |---&gt;
           +------------+       +----------------+
                                               BGP Flowspec
             +------------+     +------------+ (Rate-Limit X bps)
             | Forwarding |     | Forwarding |&lt;---
             |   node     |     |   node     |
       Link1 |            |     |            | DDoS &amp; Normal traffic
[Target]&lt;------------------------------------================
Pipe         +------------+     +------------+  Attack Traffic
Capability                                      Bandwidth
 X bps                                          Y bps

                    Network-access success rate
                           X / (X + Y)

    C: DOTS client functionality
    S: DOTS server functionality
</artwork>
          </figure>
          <figure anchor="total_pipe_capacity" align="left" suppress-title="false" pn="figure-8">
            <name slugifiedName="name-example-of-message-body-with-">Example of Message Body with Total Pipe Capacity</name>
            <sourcecode name="" type="json" markers="false" pn="section-3.1.4-4.1">
  {
    "ietf-dots-telemetry:telemetry-setup": {
      "telemetry": [
        {
          "total-pipe-capacity": [
            {
              "link-id": "link1",
              "capacity": "1000",
              "unit": "megabit-ps"
            }
          ]
        }
      ]
    }
  }
</sourcecode>
          </figure>
          <figure anchor="total_attack_traffic" align="left" suppress-title="false" pn="figure-9">
            <name slugifiedName="name-example-of-message-body-with-t">Example of Message Body with Total Attack Traffic and Total Traffic</name>
            <sourcecode name="" type="json" markers="false" pn="section-3.1.4-5.1">
{
  "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"
          }
        ]
       }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.1.4-6">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 system using 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 as BGP Flowspec <xref target="RFC8955" format="default" sectionFormat="of" derivedContent="RFC8955"/>.  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 indent="0" pn="section-3.1.4-7">Note that total pipe capability information can be gathered by
          telemetry setup in advance (<xref target="RFC9244" sectionFormat="of" section="7.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9244#section-7.2" derivedContent="RFC9244"/>).</t>
          <t indent="0" pn="section-3.1.4-8">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" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.5">
          <name slugifiedName="name-selecting-mitigation-techni">Selecting Mitigation Technique Based on Attack Type</name>
          <t indent="0" pn="section-3.1.5-1">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
          collectors using IPFIX. It may also be necessary to inspect the Layer 7
          information of suspicious packets to detect attacks such as DNS
          water torture attacks <xref target="DNS_Water_Torture_Attack" format="default" sectionFormat="of" derivedContent="DNS_Water_Torture_Attack"/>.
          To carry out the DNS water torture attack,
          an attacker commands a botnet to make thousands of DNS requests
          for fake subdomains against an authoritative name server.
          Such attack traffic should be detected and mitigated at the DMS.</t>
          <t indent="0" pn="section-3.1.5-2">This use case enables transit providers to select
          a mitigation technique based on the type of attack 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 indent="0" pn="section-3.1.5-3"><xref target="mitigation_attack_type" format="default" sectionFormat="of" derivedContent="Figure 10"/> gives an overview of this
          use case. <xref target="attack_mappings" format="default" sectionFormat="of" derivedContent="Figure 11"/> provides an example of
          attack mappings that are shared using the DOTS data channel in
          advance. <xref target="attack_connection_type" format="default" sectionFormat="of" derivedContent="Figure 12"/> provides an example
          of a DOTS telemetry message body that is used to signal percentiles
          for total attack traffic, total attack traffic protocol, and total
          attack connection; it also shows attack details.
          </t>
          <t indent="0" pn="section-3.1.5-4">The example in <xref target="attack_mappings" format="default" sectionFormat="of" derivedContent="Figure 11"/> uses the folding defined in 
<xref target="RFC8792" format="default" sectionFormat="of" derivedContent="RFC8792"/> for long lines. </t>
          <figure anchor="mitigation_attack_type" align="left" suppress-title="false" pn="figure-10">
            <name slugifiedName="name-selecting-mitigation-techniq">Selecting Mitigation Technique Based on Attack Type</name>
            <artwork name="" type="" align="left" alt="" pn="section-3.1.5-5.1">
(Internet Transit Provider)

           +-----------+ DOTS +--------------+
          +-----------+|&lt;----&gt;|              | BGP (Redirect)
    IPFIX | Flow      ||C    S| Orchestrator | BGP Flowspec (Drop)
      ---&gt;| collector |+      |              |---&gt;
          +-----------+       +--------------+

                      +------------+ BGP (Redirect)
               IPFIX +------------+| BGP Flowspec (Drop)
                 &lt;---| Forwarding ||&lt;---
                     |    nodes   ||              DDoS Attack
                     |     ++=====||================
                     |     ||     ||x&lt;==============[DNS Amp]
                     |     ||     |+x&lt;==============[NTP Amp]
                     +-----||-----+
                           ||
                           |/
                     +-----x------+
                     | DDoS       |
                     | mitigation |
                     | system     |
                     +------------+

    C: DOTS client functionality
    S: DOTS server functionality
    DNS Amp: DNS Amplification
    NTP Amp: NTP Amplification
</artwork>
          </figure>
          <figure anchor="attack_mappings" align="left" suppress-title="false" pn="figure-11">
            <name slugifiedName="name-example-of-message-body-with-a">Example of Message Body with Attack Mappings</name>
            <sourcecode name="" type="json" markers="false" pn="section-3.1.5-6.1">=============== 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."
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <figure anchor="attack_connection_type" align="left" suppress-title="false" pn="figure-12">
            <name slugifiedName="name-example-of-message-body-with-to">Example of Message Body with Total Attack Traffic, Total Attack Traffic Protocol, Total Attack Connection, and Attack Detail</name>
            <sourcecode name="" type="json" markers="false" pn="section-3.1.5-7.1">
{
  "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"
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.1.5-8">Attack mappings are shared using the DOTS data channel in
          advance (<xref target="RFC9244" sectionFormat="of" section="8.1.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9244#section-8.1.6" derivedContent="RFC9244"/>).  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 orchestrator using 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 as BGP Flowspec <xref target="RFC8955" format="default" sectionFormat="of" derivedContent="RFC8955"/>.  Also, the orchestrator orders
          relevant forwarding nodes to redirect traffic other than the
          amplification attack traffic using a routing protocol, such as
          BGP <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/>.</t>
          <t indent="0" pn="section-3.1.5-9">The flow collector implements a DOTS client while the
          orchestrator implements a DOTS server.</t>
        </section>
      </section>
      <section anchor="section_ddos_detailed_mitigation_report" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-detailed-ddos-mitigation-re">Detailed DDoS Mitigation Report</name>
        <t indent="0" pn="section-3.2-1">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 indent="0" pn="section-3.2-2">This use case enables the mutual sharing of information about ongoing DDoS
countermeasures between the transit provider and the enterprise network.
<xref target="mitigation_report" format="default" sectionFormat="of" derivedContent="Figure 13"/> gives an overview of this use case.  <xref target="pipe_capacity" format="default" sectionFormat="of" derivedContent="Figure 14"/> 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. <xref target="example_message" format="default" sectionFormat="of" derivedContent="Figure 15"/>
provides an example of a DOTS telemetry message body that is used to signal
percentiles for total traffic and total attack traffic as well as attack
details from the orchestrator to the network.
</t>
        <figure anchor="mitigation_report" align="left" suppress-title="false" pn="figure-13">
          <name slugifiedName="name-detailed-ddos-mitigation-rep">Detailed DDoS Mitigation Report</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.2-3.1">
  +------------------+       +------------------------+
  | Enterprise       |       |    Upstream            |
  | Network          |       |    Internet Transit    |
  |  +------------+  |       |    Provider            |
  |  | Network    |C |       |   S+--------------+    |
  |  | admini-    |&lt;-----DOTS----&gt;| Orchestrator |    |
  |  | strator    |  |       |    +--------------+    |
  |  +------------+  |       |         C ^            |
  |                  |       |           | DOTS       |
  |                  |       |         S v            |
  |                  |       |    +---------------+ DDoS Attack
  |                  |       |    |      DMS      |+=======
  |                  |       |    +---------------+   |
  |                  |       |           || Clean     |
  |                  |       |           |/ Traffic   |
  |  +---------+     |       |   +---------------+    |
  |  | DDoS    |     |       |   | Forwarding    | Normal Traffic
  |  | Target  |&lt;================| Node          |========
  |  +---------+     | Link1 |   +---------------+    |
  +------------------+       +------------------------+

    C: DOTS client functionality
    S: DOTS server functionality
</artwork>
        </figure>
        <figure anchor="pipe_capacity" align="left" suppress-title="false" pn="figure-14">
          <name slugifiedName="name-example-of-message-body-with-tot">Example of Message Body with Total Pipe Capacity</name>
          <sourcecode name="" type="json" markers="false" pn="section-3.2-4.1">
{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "total-pipe-capacity": [
          {
            "link-id": "link1",
            "capacity": "1000",
            "unit": "megabit-ps"
          }
        ]
      }
    ]
  }
}
</sourcecode>
        </figure>
        <figure anchor="example_message" align="left" suppress-title="false" pn="figure-15">
          <name slugifiedName="name-example-of-message-body-with-tota">Example of Message Body with Total Traffic, Total Attack Traffic, and Attack Detail
          </name>
          <sourcecode name="" type="json" markers="false" pn="section-3.2-5.1">
{
  "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"
          }
        ]
      }
    ]
  }
}
</sourcecode>
        </figure>
        <t indent="0" pn="section-3.2-6">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 reported
        using the "total-pipe-capacity" telemetry attribute in the DOTS telemetry
        setup.</t>
        <t indent="0" pn="section-3.2-7">When DDoS attacks occur, DDoS mitigation orchestration <xref target="RFC8903" format="default" sectionFormat="of" derivedContent="RFC8903"/> 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 administrator using DOTS telemetry periodically.</t>
        <t indent="0" pn="section-3.2-8">During the DDoS mitigation, the orchestrator in the transit
        provider retrieves the link congestion status from the network manager in
        the enterprise network using the "total-traffic" telemetry attributes.
        Then, the orchestrator checks whether or not the DDoS countermeasures are
        effective by comparing the "total-traffic" and the
        "total-pipe-capacity" telemetry attributes.</t>
        <t indent="0" pn="section-3.2-9">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" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-tuning-mitigation-resources">Tuning Mitigation Resources</name>
        <section anchor="section_use_cases_ddos_detection_training" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.1">
          <name slugifiedName="name-supervised-machine-learning">Supervised Machine Learning of Flow Collector</name>
          <t indent="0" pn="section-3.3.1-1">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
          DMSes is a more accurate method for detecting attack traffic
          than flow monitoring.</t>
          <t indent="0" pn="section-3.3.1-2">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. <xref target="training_supervised" format="default" sectionFormat="of" derivedContent="Figure 16"/> gives an
          overview of this use case.  <xref target="message_body_attack" format="default" sectionFormat="of" derivedContent="Figure 17"/>
          provides an example of a DOTS telemetry message body that is used to
          signal attack detail.
          </t>
          <figure anchor="training_supervised" align="left" suppress-title="false" pn="figure-16">
            <name slugifiedName="name-supervised-machine-learning-">Supervised Machine Learning of Flow Collector</name>
            <artwork name="" type="" align="left" alt="" pn="section-3.3.1-3.1">
                                +-----------+
                               +-----------+| DOTS
                         IPFIX | Flow      ||S&lt;---
                           ---&gt;| collector ||
                               +-----------++

                                +------------+
                         IPFIX +------------+|
                           &lt;---| Forwarding ||
                               |    nodes   ||           DDoS Attack
 [ Target ]                    |   ++==============================
                               |   || ++===========================
                               |   || || ++========================
                               +---||-|| ||-+
                                   || || ||
                                   |/ |/ |/
                         DOTS  +---X--X--X--+
                          ---&gt;C| DDoS       |
                               | mitigation |
                               | system     |
                               +------------+

    C: DOTS client functionality
    S: DOTS server functionality
</artwork>
          </figure>
          <figure anchor="message_body_attack" align="left" suppress-title="false" pn="figure-17">
            <name slugifiedName="name-example-of-message-body-with-at">Example of Message Body with Attack Detail and Top Talkers</name>
            <sourcecode name="" type="json" markers="false" pn="section-3.3.1-4.1">
{
  "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"
                }
              ]
            }
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.3.1-5">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 per <xref target="RFC8903" sectionFormat="of" section="3.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8903#section-3.3" derivedContent="RFC8903"/>), 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 indent="0" pn="section-3.3.1-6">After mitigating a DDoS attack, the flow collector attaches
          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 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 indent="0" pn="section-3.3.1-7">The DMS implements a DOTS client while the flow collector
          implements a DOTS server.</t>
        </section>
        <section anchor="section_use_cases_tuning_threshold" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.2">
          <name slugifiedName="name-unsupervised-machine-learni">Unsupervised Machine Learning of Flow Collector</name>
          <t indent="0" pn="section-3.3.2-1">DMSes can detect DDoS attack traffic, which means DMSes can also
          identify clean traffic. This use case supports unsupervised
          machine 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. <xref target="training_unsupervised" format="default" sectionFormat="of" derivedContent="Figure 18"/> gives an overview of this use
          case. <xref target="traffic_baseline" format="default" sectionFormat="of" derivedContent="Figure 19"/> provides an example of a DOTS telemetry message body
          that is used to signal baseline.</t>
          <figure anchor="training_unsupervised" align="left" suppress-title="false" pn="figure-18">
            <name slugifiedName="name-unsupervised-machine-learnin">Unsupervised Machine Learning of Flow Collector</name>
            <artwork name="" type="" align="left" alt="" pn="section-3.3.2-2.1">
                              +-----------+
                             +-----------+|
                        DOTS | Flow      ||
                        ---&gt;S| collector ||
                             +-----------++

                              +------------+
                             +------------+|
                             | Forwarding ||
                             |    nodes   ||             Traffic
[ Destination ] &lt;== =============++==============================
                             |   ||       ||
                             |   ||       |+
                             +---||-------+
                                 ||
                                 |/
                       DOTS  +---X--------+
                        ---&gt;C| DDoS       |
                             | mitigation |
                             | system     |
                             +------------+

    C: DOTS client functionality
    S: DOTS server functionality
</artwork>
          </figure>
          <figure anchor="traffic_baseline" align="left" suppress-title="false" pn="figure-19">
            <name slugifiedName="name-example-of-message-body-with-tr">Example of Message Body with Traffic Baseline</name>
            <sourcecode name="" type="json" markers="false" pn="section-3.3.2-3.1">
  {
    "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"
                }
              ]
            }
          ]
        }
      ]
    }
  }
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.3.2-4">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 traffic and reports the baseline telemetry attributes to the
flow collector using DOTS telemetry.</t>
          <t indent="0" pn="section-3.3.2-5">The flow collector then carries out unsupervised machine
          learning to be able to carry out anomaly detection.</t>
          <t indent="0" pn="section-3.3.2-6">The DMS implements a DOTS client while the flow collector
          implements a DOTS server.</t>
        </section>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-4-1">Security considerations for DOTS telemetry are discussed in <xref target="RFC9244" sectionFormat="of" section="14" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9244#section-14" derivedContent="RFC9244"/>. These considerations
      apply to the communication interfaces where DOTS is used. </t>
      <t indent="0" pn="section-4-2">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.  <xref target="RFC7149" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7149#section-5" derivedContent="RFC7149"/>
      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, <xref target="RFC8955" sectionFormat="of" section="12" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8955#section-12" derivedContent="RFC8955"/> discusses security
      considerations that are relevant to BGP Flowspec.  IPFIX-specific
      considerations are discussed in <xref target="RFC7011" sectionFormat="of" section="11" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7011#section-11" derivedContent="RFC7011"/>.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC9244" target="https://www.rfc-editor.org/info/rfc9244" quoteTitle="true" derivedAnchor="RFC9244">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.K"/>
            <author fullname="E. Doron" initials="E." surname="Doron"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <author fullname="J. Shallow" initials="J." surname="Shallow"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This document aims to enrich the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.</t>
              <t indent="0">This document specifies two YANG modules: one for representing DOTS telemetry message types and one for sharing the attack mapping details over the DOTS data channel.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9244"/>
          <seriesInfo name="DOI" value="10.17487/RFC9244"/>
        </reference>
      </references>
      <references pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="DNS_Water_Torture_Attack" target="https://dl.acm.org/doi/10.1145/3297156.3297272" quoteTitle="true" derivedAnchor="DNS_Water_Torture_Attack">
          <front>
            <title>A Large Scale Analysis of DNS Water Torture Attack</title>
            <author initials="X." surname="Luo" fullname="Xi Luo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Wang" fullname="Liming Wang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Z." surname="Xu" fullname="Zhen Xu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Chen" fullname="Kai Chen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Yang" fullname="Jing Yang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Tian" fullname="Tian Tian">
              <organization showOnFrontPage="true"/>
            </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>
        <reference anchor="DOTS_Overview" target="https://datatracker.ietf.org/meeting/108/materials/slides-108-saag-dots-overview-00" quoteTitle="true" derivedAnchor="DOTS_Overview">
          <front>
            <title>DDoS Open Threat Signaling (DOTS)</title>
            <author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="July"/>
          </front>
        </reference>
        <reference anchor="RFC3413" target="https://www.rfc-editor.org/info/rfc3413" quoteTitle="true" derivedAnchor="RFC3413">
          <front>
            <title>Simple Network Management Protocol (SNMP) Applications</title>
            <author fullname="D. Levi" initials="D." surname="Levi"/>
            <author fullname="P. Meyer" initials="P." surname="Meyer"/>
            <author fullname="B. Stewart" initials="B." surname="Stewart"/>
            <date month="December" year="2002"/>
            <abstract>
              <t indent="0">This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411.  The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.  This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding.  This document obsoletes RFC 2573. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="62"/>
          <seriesInfo name="RFC" value="3413"/>
          <seriesInfo name="DOI" value="10.17487/RFC3413"/>
        </reference>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" quoteTitle="true" derivedAnchor="RFC4271">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t indent="0">The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t indent="0">BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t indent="0">This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="RFC7011" target="https://www.rfc-editor.org/info/rfc7011" quoteTitle="true" derivedAnchor="RFC7011">
          <front>
            <title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information</title>
            <author fullname="B. Claise" initials="B." role="editor" surname="Claise"/>
            <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell"/>
            <author fullname="P. Aitken" initials="P." surname="Aitken"/>
            <date month="September" year="2013"/>
            <abstract>
              <t indent="0">This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network.  In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.  This document obsoletes RFC 5101.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="77"/>
          <seriesInfo name="RFC" value="7011"/>
          <seriesInfo name="DOI" value="10.17487/RFC7011"/>
        </reference>
        <reference anchor="RFC7149" target="https://www.rfc-editor.org/info/rfc7149" quoteTitle="true" derivedAnchor="RFC7149">
          <front>
            <title>Software-Defined Networking: A Perspective from within a Service Provider Environment</title>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <author fullname="C. Jacquenet" initials="C." surname="Jacquenet"/>
            <date month="March" year="2014"/>
            <abstract>
              <t indent="0">Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.</t>
              <t indent="0">It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7149"/>
          <seriesInfo name="DOI" value="10.17487/RFC7149"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" quoteTitle="true" derivedAnchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC8612" target="https://www.rfc-editor.org/info/rfc8612" quoteTitle="true" derivedAnchor="RFC8612">
          <front>
            <title>DDoS Open Threat Signaling (DOTS) Requirements</title>
            <author fullname="A. Mortensen" initials="A." surname="Mortensen"/>
            <author fullname="T. Reddy" initials="T." surname="Reddy"/>
            <author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/>
            <date month="May" year="2019"/>
            <abstract>
              <t indent="0">This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8612"/>
          <seriesInfo name="DOI" value="10.17487/RFC8612"/>
        </reference>
        <reference anchor="RFC8783" target="https://www.rfc-editor.org/info/rfc8783" quoteTitle="true" derivedAnchor="RFC8783">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.K"/>
            <date month="May" year="2020"/>
            <abstract>
              <t indent="0">The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.</t>
              <t indent="0">This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8783"/>
          <seriesInfo name="DOI" value="10.17487/RFC8783"/>
        </reference>
        <reference anchor="RFC8792" target="https://www.rfc-editor.org/info/rfc8792" quoteTitle="true" derivedAnchor="RFC8792">
          <front>
            <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="June" year="2020"/>
            <abstract>
              <t indent="0">This document defines two strategies for handling long lines in width-bounded text content.  One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line.  The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy.  Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8792"/>
          <seriesInfo name="DOI" value="10.17487/RFC8792"/>
        </reference>
        <reference anchor="RFC8903" target="https://www.rfc-editor.org/info/rfc8903" quoteTitle="true" derivedAnchor="RFC8903">
          <front>
            <title>Use Cases for DDoS Open Threat Signaling</title>
            <author fullname="R. Dobbins" initials="R." surname="Dobbins"/>
            <author fullname="D. Migault" initials="D." surname="Migault"/>
            <author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/>
            <author fullname="N. Teague" initials="N." surname="Teague"/>
            <author fullname="L. Xia" initials="L." surname="Xia"/>
            <author fullname="K. Nishizuka" initials="K." surname="Nishizuka"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS Mitigation solutions.  This document presents sample use cases that describe the interactions expected between the DOTS components as well as DOTS messaging exchanges.  These use cases are meant to identify the interacting DOTS components, how they collaborate, and what the typical information to be exchanged is.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8903"/>
          <seriesInfo name="DOI" value="10.17487/RFC8903"/>
        </reference>
        <reference anchor="RFC8955" target="https://www.rfc-editor.org/info/rfc8955" quoteTitle="true" derivedAnchor="RFC8955">
          <front>
            <title>Dissemination of Flow Specification Rules</title>
            <author fullname="C. Loibl" initials="C." surname="Loibl"/>
            <author fullname="S. Hares" initials="S." surname="Hares"/>
            <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <author fullname="M. Bacher" initials="M." surname="Bacher"/>
            <date month="December" year="2020"/>
            <abstract>
              <t indent="0">This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.</t>
              <t indent="0">It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.</t>
              <t indent="0">This document obsoletes both RFC 5575 and RFC 7674.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8955"/>
          <seriesInfo name="DOI" value="10.17487/RFC8955"/>
        </reference>
        <reference anchor="RFC9132" target="https://www.rfc-editor.org/info/rfc9132" quoteTitle="true" derivedAnchor="RFC9132">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="J. Shallow" initials="J." surname="Shallow"/>
            <author fullname="T. Reddy.K" initials="T." surname="Reddy.K"/>
            <date month="September" year="2021"/>
            <abstract>
              <t indent="0">This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.</t>
              <t indent="0">A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.</t>
              <t indent="0">This document obsoletes RFC 8782.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9132"/>
          <seriesInfo name="DOI" value="10.17487/RFC9132"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Mohamed       Boucadair"/> and <contact fullname="Valery Smyslov"/> for their valuable
      feedback.</t>
      <t indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Paul Wouters"/> for the detailed AD
      review.</t>
      <t indent="0" pn="section-appendix.a-3">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 indent="0" pn="section-appendix.a-4">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>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Yuhei Hayashi" initials="Y." surname="Hayashi">
        <organization abbrev="NTT" showOnFrontPage="true">NTT</organization>
        <address>
          <postal>
            <street>3-9-11, Midori-cho</street>
            <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">
        <organization abbrev="China Mobile" showOnFrontPage="true">China Mobile</organization>
        <address>
          <postal>
            <street>32, Xuanwumen West</street>
            <city>Beijing</city>
            <code>100053</code>
            <country>China</country>
          </postal>
          <email>chenmeiling@chinamobile.com</email>
        </address>
      </author>
      <author fullname="Li Su" initials="L." surname="Su">
        <organization abbrev="China Mobile" showOnFrontPage="true">China Mobile</organization>
        <address>
          <postal>
            <street>32, Xuanwumen West</street>
            <city>Beijing</city>
            <code>100053</code>
            <country>China</country>
          </postal>
          <email>suli@chinamobile.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
