<?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"?>
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- 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 category="info" docName="draft-hayashi-dots-dms-offload-00">
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="Mitigation Offload">DDoS Mitigation Offload: DOTS
    Applicability and Deployment Considerations</title>

    <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="Kaname Nishizuka" initials="K." surname="Nishizuka">
      <organization>NTT Communications</organization>

      <address>
        <postal>
          <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>

          <city>Tokyo</city>

          <code>108-8118</code>

          <country>Japan</country>
        </postal>

        <email>kaname@nttv6.jp</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <date day="20" month="July" year="2019" />

    <area>Security Area</area>

    <workgroup>DOTS</workgroup>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>This document describes a deployment scenario to assess the
      applicability of DOTS protocols together with a discussion on DOTS
      deployment considerations of such scenario. This scenario assumes that a
      DMS (DDoS Mitigation System) whose utilization rate is high sends its
      blocked traffic information to an orchestrator using DOTS protocols,
      then the orchestrator requests forwarding nodes such as routers to
      filter the traffic. Doing so enables service providers to mitigate the
      DDoS attack traffic automatically while ensuring interoperability and
      distributed filter enforcement.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="section_introduction" title="Introduction">
      <t>Volume-based distributed Denial-of-Service (DDoS) attacks such as DNS
      amplification attacks are critical threats to be handled by service
      providers. When such attacks occur, service providers have to mitigate
      them immediately to protect or recover their services.</t>

      <t>Therefore, for the service providers to immediately protect their
      network services from DDoS attacks, DDoS mitigation needs to be
      automated. To automate DDoS attack mitigation, it is desirable that
      multi-vendor elements involved in DDoS attack detection and mitigation
      collaborate and support standard interfaces to communicate.</t>

      <t>DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time
      signaling, threat-handling requests, and data filtering between the
      multi-vendor elements <xref
      target="I-D.ietf-dots-signal-channel"></xref> <xref
      target="I-D.ietf-dots-signal-call-home"></xref> <xref
      target="I-D.ietf-dots-signal-filter-control"></xref> <xref
      target="I-D.ietf-dots-data-channel"></xref>. This document describes an
      automated DDoS Mitigation offload scenario inherited from the DDoS
      orchestration scenario <xref target="I-D.ietf-dots-use-cases"></xref>,
      which ambitions to enable cost-effective DDoS Mitigation. Furthermore,
      this document describes deployment consideration for network operators
      who carry out this scenario using DOTS protocols in their network.</t>

      <t>This document aims to assess to what extent DOTS protocols can be
      used to provide the intended functionality and identify any gaps. </t>
    </section>

    <section anchor="section_terms" title="Terminology">
      <t>The readers should be familiar with the terms defined in <xref
      target="RFC8612"></xref> <xref
      target="I-D.ietf-dots-use-cases"></xref></t>

      <t>In addition, this document makes use of the following terms:</t>

      <t><list style="hanging">
          <t hangText="Mitigation offload:">Getting rid of a DMS's mitigation
          action and assigning the action to another entity when the
          utilization rate of the DMS reaches a given threshold. How such
          threshold is set is deployment-specific.</t>

          <t hangText="Utilization rate:">A scale to measure load of an entity
          such as link utilization rate or CPU utilization rate.</t>
        </list></t>
    </section>

    <section anchor="section_problems" title="The Problem">
      <t>In general, DDoS countermeasures are divided into detection and
      filtering. Detection is technically challenging given the dynamic of
      attacks and sophisticated attack strategies. DDoS Mitigation System
      (DMS) can detect attack traffic based on a specific technology (provided
      and supposed to be updated and maintained by vendors to detect complex
      attacks), so service providers can increase DDoS countermeasure level by
      deploying the DMS in their network.</t>

      <t>However, the number/capacity of DMS instances that can be deployed in
      a service providers network is limited due to equipment cost and
      dimensioning matters. Thus, DMS's utilization rate can reach its maximum
      capacity faster when the volume of DDoS attacks is enormous. When the
      rate reaches maximum capacity, the mitigation strategy needs to offload
      mitigation actions from the DMS to cost-effective forwarding nodes such
      as routers.</t>
    </section>

    <section anchor="section_scenario"
             title="DDoS Mitigation Offload Scenario">
      <t>This section describes offloading mitigation actions from DMS whose
      utilization rate is high to cost-effective forwarding node using DOTS
      protocols. This section does not consider deployments where the network
      orchestrator and DMS are co-located.</t>

      <t>Figures <xref format="counter"
      target="fig_Component-scenario"></xref> and <xref format="counter"
      target="fig_Sequence-scenario"></xref> show a sample component diagram
      and a sequence diagram of the deployment scenario, respectively.</t>

      <figure anchor="fig_Component-scenario"
              title="Component Diagram of DDoS Mitigation Offload Scenario">
        <artwork><![CDATA[
+--------------+        +-----------+
|              |        | DDoS      |+
| Orchestrator |<-------| mitigation||
|              |S DOTS C| systems   ||
+--------------+        +-----------+|
       |                  +----------+
       | e.g., BGP, BGP Flowspec
       |
       |  +------------------+
       +->| Forwarding nodes |+
          +------------------+|
            +-----------------+
    * C is for DOTS Client function
    * S is for DOTS Server function
          ]]></artwork>
      </figure>

      <t>The component diagram shown in <xref
      target="fig_Component-scenario"></xref> differs from that of DDoS
      Orchestration scenario in <xref target="I-D.ietf-dots-use-cases"></xref>
      in some respects. First, the DMS embeds a DOTS client to send DOTS
      requests to the orchestrator. Second, the orchestrator sends a request
      to underlying forwarding nodes to filter the attack traffic.</t>

      <figure anchor="fig_Sequence-scenario"
              title="Sequence Diagram of DDoS Mitigation Offload Scenario">
        <artwork><![CDATA[
+------------+          +----------+   +------------+
|            |          |DDoS      |+  | Forwarding |+
|Orchestrator|          |Mitigation||  | Nodes      ||
|            |          |Systems   ||  |            ||
+------------+          +----------+|  +------------+|
     |                   +----------+   +------------+
     |                         |              |
     | DOTS Request            |              |
     |S<----------------------C|              |
     |                         |              |
     | e.g., BGP, BGP Flowspec |              |
     | Filter Attack Traffic   |              |
     |-------------------------|------------->|
     |                         |              |
     * C is for DOTS Client function
     * S is for DOTS Server function
          ]]></artwork>
      </figure>

      <t>In this scenario, it is assumed that volume based attack already hits
      a network and attack traffic is detected and blocked by a DMS in the
      network. When the volume-based attack becomes intense, DMS's utilization
      rate can reach a certain threshold (e.g., maximum capacity). Then, the
      DMS sends a DOTS request as offload request to the orchestrator with the
      actions to enforce on the traffic. After that, the orchestrator requests
      the forwarding nodes to filter attack traffic by dissemination of flow
      specification rules protocols such as BGP Flowspec <xref
      target="RFC5575"></xref> on the basis of the blocked traffic
      information.</t>

      <t>This schenario is divided into two cases based on type of link between
      the DMS and the orchestrator: "out-of-band case" and "in-band case".</t>

      <t>"Out-of-band case" is that the DMS sends a DOTS request to the
      orchestrator with blocked traffic information by the DMS via out-of-band
      link. The link is not congested when it is under volume attack-time, so
      the link can convey a lot of information.</t>

      <t>On the other hand, "in-band case" is that the DMS sends a mitigation
      request to the orchestrator with blocked traffic information by the DMS
      via in-band channel. The link can be congested when it is under volume
      attack-time, so the link can convey limited information.</t>
    </section>

    <section title="DOTS Deployment Considerations">
      <t>This section describes deployment considerations: what type of DOTS
      protocol can be used and what type of information can be conveyed and effective by
      DOTS protocol in this scenario. <xref
      target="fig_DOTS_Signaling_Matrix"></xref> shows overview of the DOTS
      signaling method and conveyed information for the out-of-band case and
      in-band case.</t>

      <t>The volume of information should be considered carefully when DOTS
      protocol is used in the in-band case. What type of information can be
      conveyed by DMS relays on attack type detected by the DMS: reflection
      attack or non-reflection attack. When it is under non-reflection attack,
      src_ip and src_port information cannot be conveyed because attackers
      usually randomize the parameters so number of its become enormous. On
      the other hand, when it is under reflection attack, dst_port information
      cannot be conveyed because attackers usually randomize src_port so the
      number of dst_port of attack packets reached to victim become enormous.
      Furthermore, when it is under reflection attack, src_ip information
      cannot be conveyed when number of reflector is enormous.</t>

      <figure anchor="fig_DOTS_Signaling_Matrix"
              title="Signaling Method and Conveyed Information">
        <artwork><![CDATA[
+-------------+-----------------------------------+------------------+
|             |        Reflection Attack          |  Non-Reflection  |
|             |                                   |     Attack       |
+-------------+-----------------------------------+------------------+
| Out-of-band | Attack Time                                          |
|     case    | Method : Data Channel                                |
|             | Info : src_ip, src_port, dst_ip, dst_port, protocol  |
+-------------+-----------------------------------+------------------+
|   In-band   | Attack Time                       | Attack Time      |
|    case     | (Number of reflector is small)    | Method : Signal  |
|             | Method : Signal Channel with src  |          Channel |
|             | Info : src_ip, src_port,          | Info : dst_ip,   |
|             |        dst_ip, protocol           |        dst_port, |
|             +-----------------------------------+        protocol  |
|             | Attack Time                       |                  |
|             | (Number of reflector is enormous) |                  |
|             | Method : Signal Channel with src  |                  |
|             | Info : src_port, dst_ip, protocol |                  |
|             +-----------------------------------+------------------+
|             | Peace Time                        | Peace Time       |
|             | Method : Data Channel             | Method : Data    |
|             | Info : src_port,                  |          Channel |
|             |        dst_ip, protocol           | Info : dst_ip,   |
|             |                                   |        dst_port, |
|             |                                   |        protocol  |
|             |                                   |                  |
|             | Attack Time                       | Attack Time      |
|             | Method : Signal Channel           | Method : Signal  |
|             |          Control Filtering        |          Channel |
|             | Info : ACL name                   | Control Filtering|
|             |                                   | Info : ACL name  |
|-------------+------------------------------------------------------+

          ]]></artwork>
      </figure>

      <t>About offloading DMS against reflection attack, the current signal
      channel <xref target="I-D.ietf-dots-signal-channel"></xref> is
      insufficient in terms of conveying source information. On the other
      hand, both signal channel extensions defined in <xref
      target="I-D.ietf-dots-signal-call-home"></xref> (called, source-*
      clauses hereafter) and the filtering control extensions <xref
      target="I-D.ietf-dots-signal-filter-control"></xref> allow for sending
      source information.</t>

      <t>Using src-* attributes defined in <xref
      target="I-D.ietf-dots-signal-call-home"></xref> enables signal channel
      to convey src_ip information and src_port information in attack time. On
      the other hand, filtering control extensions can activate filtering rule
      configured in peacetime. Filtering rule for well-known port numbers
      abused for reflection attack can be configured to DOTS server in
      peacetime. However, filtering rule for reflector's IP address in attack
      time can't be known in peace time. So filtering control expansion can
      convey src_port information but can't send src_ip information against
      reflection attack. About sending source information in the DMS offload
      s scenario, the capability of the call home extension encompasses the
      capabilities of the filtering control extension.</t>

      <t>The following sub-sections describes example of use DOTS protocols in
      each case.</t>

      <section title="DOTS Signaling via Out-of-band Link">
        <t>In this case, the link is not congested when it is under volume
        attack-time, so DOTS data channel <xref
        target="I-D.ietf-dots-data-channel"></xref> is suitable because DOTS
        data channel has capability of conveying the drop-listed filtering
        rules including (src_ip, src_port, dst_ip, dst_port, protocol)
        information (and other actions such as 'rate-limit').</t>

        <section title="Example of using Data Channel">
          <t>The procedure to use DOTS Data Channel in such case is as
          follows:</t>

          <t><list style="symbols">
              <t>The DMS generates a list of flow (src_ip, src_port, dst_ip,
              dst_port, protocol) information which the DMS is
              blocking/rate-limiting and wants to offload.</t>

              <t>The DMS creates data-channel ACL such as shown figure <xref
              format="counter"
              target="fig_example_JSON_data_channel"></xref>.</t>

              <t>The DMS sends the data-channel ACL to the orchestrator.</t>
            </list></t>

          <figure anchor="fig_example_JSON_data_channel"
                  title="JSON Example of ACL including (src_ip, src_port, dst_ip, dst_port, protocol) information conveyed by DOTS data channel">
            <artwork><![CDATA[
    {
      "ietf-dots-data-channel:acls": {
        "acl": [
          {
            "name": "DMS_Offload_scenario_ACL",
            "type": "ipv4-acl-type",
            "activation-type": "immediate",
            "aces": {
              "ace": [
                {
                  "name": "DMS_Offload_scenario_ACE_00",
                  "matches": {
                    "ipv4": {
                      "destination-ipv4-network": "192.0.2.2/32",
                      "source-ipv4-network": "203.0.113.2/32",
                      "protocol":17
                    },
                    "udp": {
                      "source-port": {
                        "operator": "eq",
                        "port": 53
                      }
                    }
                  },
                  "actions": {
                    "forwarding": "drop"
                  }
                },
                {
                  "name": "DMS_Offload_scenario_ACE_01",
                  "matches": {
                    "ipv4": {
                      "destination-ipv4-network": "192.0.2.2/32",
                      "source-ipv4-network": "203.0.113.3/32",
                      "protocol":17
                    },
                    "udp": {
                      "source-port": {
                        "operator": "eq",
                        "port": 53
                      }
                    }
                  },
                  "actions": {
                    "forwarding": "drop"
                  }
                }
              ]
            }
          }
        ]
      }
    }
          ]]></artwork>
          </figure>
        </section>
      </section>

      <section title="DOTS Signaling via In-band Link">
        <t>In this case, the link can be congested when it is under volume
        attack-time, so DOTS data channel can't be used to convey the
        drop-listed filtering rules as blocked traffic information <xref
        target="Interop"></xref>. On the other hand, DOTS signal channel <xref
        target="I-D.ietf-dots-signal-channel"></xref>, the source-* clauses
        defined in <xref target="I-D.ietf-dots-signal-call-home"></xref> and
        filtering control <xref
        target="I-D.ietf-dots-signal-filter-control"></xref> can be used to
        communicate the policies to the orchestrator.</t>

        <section title="Example of using Signal Channel">
          <t>DOTS signal channel has capability to send (dst_ip, dst_port,
          protocol) information. The procedure to use DOTS Signal Channel in
          this case is as follows:</t>

          <t><list style="symbols">
              <t>The DMS generates a list of (dst_ip, dst_port, protocol)
              information which the DMS is blocking/rate-limiting and wants to
              offload.</t>

              <t>The DMS creates mitigation request such as shown figure <xref
              format="counter"
              target="fig_example_JSON_signal_channel"></xref>.</t>

              <t>The DMS sends the mitigation requests to the
              orchestrator.</t>
            </list></t>

          <figure anchor="fig_example_JSON_signal_channel"
                  title="JSON Example of offload request including (dst_ip, dst_port, protocol) information conveyed by DOTS signal channel">
            <artwork><![CDATA[
{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
        "192.0.2.2/32"
        ],
        "target-port-range": [
          {
           "lower-port": 80
          },
          {
           "lower-port": 443
          }
        ],
        "target-protocol": [
          6
        ],
        "lifetime": 3600
      },
      {
        "target-prefix": [
        "192.0.2.2/32"
        ],
        "target-port-range": [
          {
           "lower-port": 53
          },
          {
           "lower-port": 123
          }
        ],
        "target-protocol": [
          17
        ],
        "lifetime": 3600
      }
    ]
  }
}
              ]]></artwork>
          </figure>
        </section>

        <section title="Example of using Signal Channel Call Home">
          <t><xref target="I-D.ietf-dots-signal-call-home"></xref> extends the
          DOTS signal channel to convey (dst_ip, dst_port, src_ip, src_port,
          protocol) information in a mitigation request. A mitigation request
          can convey src_ip information when the number of reflectors detected
          by a DMS is small. The procedure to use DOTS src-* clauses is as
          follows:</t>

          <t><list style="symbols">
              <t>The DMS generates a list of (dst_ip, src_ip, src_port,
              protocol) information which the DMS is blocking/rate-limiting
              and wants to offload.</t>

              <t>The DMS creates mitigation request such as shown figure <xref
              format="counter"
              target="fig_example_JSON_signal_channel_call_home_1"></xref>.</t>

              <t>The DMS sends the mitigation requests to the
              orchestrator.</t>
            </list></t>

          <figure anchor="fig_example_JSON_signal_channel_call_home_1"
                  title="JSON Example of offload request including (dst_ip, src_ip, src_port, protocol) information conveyed by DOTS signal channel">
            <artwork><![CDATA[
{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
        "192.0.2.2/32"
        ],
        "target-protocol": [
          6
        ],
         "ietf-dots-call-home:source-prefix": [
           "203.0.113.2/32"
         ],
         "ietf-dots-call-home:source-port-range" : [
         {
           "ietf-dots-call-home:lower-port": 53
         },
         {
          "ietf-dots-call-home:lower-port": 123
         }
         ],
        "lifetime": 3600
      },
      {
        "target-prefix": [
        "192.0.2.2/32"
        ],
        "target-protocol": [
          6
        ],
         "ietf-dots-call-home:source-prefix": [
         "203.0.113.3/32"
         ],
         "ietf-dots-call-home:source-port-range" : [
         {
          "ietf-dots-call-home:lower-port": 19
         },
         {
          "ietf-dots-call-home:lower-port": 11211
         }
         ],
        "lifetime": 3600
      }
    ]
  }
}
              ]]></artwork>
          </figure>

          <t>On the other hand, a mitigation request cannot convey src_ip
          information when number of reflector detected by DMS exceeds a
          certain number (cannot fit within one single request). The procedure
          to use the DOTS signal channel in the situation is as follows:</t>

          <t><list style="symbols">
              <t>The DMS generates a list of (dst_ip, src_port, protocol)
              information which the DMS is blocking/rate-limiting and wants to
              offload.</t>

              <t>The DMS creates mitigation request such as shown in Figure
              <xref format="counter"
              target="fig_example_JSON_signal_channel_call_home_2"></xref>.</t>

              <t>The DMS sends the mitigation requests to the
              orchestrator.</t>
            </list></t>

          <figure anchor="fig_example_JSON_signal_channel_call_home_2"
                  title="JSON Example of offload request including (dst_ip, src_port, protocol) information conveyed by DOTS signal channel">
            <artwork><![CDATA[
{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
        "192.0.2.2/32"
        ],
        "target-protocol": [
          6
        ],
         "ietf-dots-call-home:source-port-range" : [
         {
          "ietf-dots-call-home:lower-port": 53
         },
         {
          "ietf-dots-call-home:lower-port": 123
         },
         {
          "ietf-dots-call-home:lower-port": 19
         },
         {
          "ietf-dots-call-home:lower-port": 11211
         }
         ],
        "lifetime": 3600
      }
    ]
  }
}
              ]]></artwork>
          </figure>
        </section>

        <section title="Data Channel and Signal Channel Controlling Filtering">
          <t>DOTS signal channel controlling filtering <xref
          target="I-D.ietf-dots-signal-filter-control"></xref> has capability
          to activate or deactivate ACL configured by Data Channel. Against
          reflection attack, DOTS client configures ACL including (dst_ip,
          src_port, protocol) information in peace time by Data Channel, and
          DOTS client activate the ACL in attack time by Signal Channel
          controlling filtering. Note that the src_port is well known port
          abused to carry out reflection attack by attacker. The procedure to
          use DOTS data channel and signal channel controlling filtering is as
          follows:</t>

          <t><list style="symbols">
              <t>In peace time, the DMS sends the ACL including (dst_ip,
              src_port, protocol) information such as figure <xref
              format="counter"
              target="fig_example_JSON_data_channel_contorlling_filtering"></xref>.</t>

              <t>In attack time, the DMS generates a list of (dst_ip,
              src_port, protocol) which the DMS is blocking/rate-limiting and
              wants to offload. After that, the DMS sends the mitigation
              requests to activate corresponding ACL configured to the
              orchestrator such as figure <xref format="counter"
              target="fig_example_JSON_signal_channel_contorlling_filtering"></xref>.</t>
            </list></t>

          <figure anchor="fig_example_JSON_data_channel_contorlling_filtering"
                  title="JSON Example of ACL including (dst_ip, src_port, protocol) information conveyed by DOTS data channel">
            <artwork><![CDATA[
{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "DMS_Offload_scenario_ACL",
        "type": "ipv4-acl-type",
        "activation-type": "activate-when-mitigating",
        "aces": {
          "ace": [
            {
              "name": "DMS_Offload_scenario_ACL_DNS_amp",
              "matches": {
                "ipv4": {
                  "destination-ipv4-network": "192.0.2.2/32",
                  "protocol":17
                },
                "udp": {
                  "source-port": {
                    "operator": "eq",
                    "port": 53
                  }
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            },
            {
              "name": "DMS_Offload_scenario_ACL_NTP_amp",
              "matches": {
                "ipv4": {
                  "destination-ipv4-network": "192.0.2.2/32",
                  "protocol":17
                },
                "udp": {
                  "source-port": {
                    "operator": "eq",
                    "port": 123
                  }
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]
        }
      }
    ]
  }
}
              ]]></artwork>
          </figure>

          <figure anchor="fig_example_JSON_signal_channel_contorlling_filtering"
                  title="JSON Example of including acl name conveyed by DOTS signal channel">
            <artwork><![CDATA[
{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
           "192.0.2.2/32"
         ],
         "target-protocol": [
           17
         ],
         "acl-list": [
           {
             "acl-name": "DMS_Offload_scenario_ACL_DNS_amp",
             "activation-type": "immediate"
           }
        "lifetime": 3600
      }
    ]
  }
}
              ]]></artwork>
          </figure>

          <t>Against non-reflection attack, DOTS client configures ACL
          including (dst_ip, dst_port, protocol) information in peace time by
          Data Channel, and DOTS client activate the 'acl' in attack time by
          Signal Channel. Note that the dst_port is well known port abused to
          carry out non-reclection attack by attacker. The procedure to use
          DOTS data channel and signal channel controlling filtering is as
          follows:</t>

          <t><list style="symbols">
              <t>In peace time, the DMS sends the ACL including (dst_ip,
              dst_port, protocol) information such as figure <xref
              format="counter"
              target="fig_example_JSON_data_channel_contorlling_filtering2"></xref>.</t>

              <t>In attack time, the DMS generates a list of (dst_ip,
              dst_port, protocol) which the DMS is blocking/rate-limiting and
              wants to offload. After that, the DMS sends the mitigation
              requests to activate corresponding ACL configured to the
              orchestrator such as figure <xref format="counter"
              target="fig_example_JSON_signal_channel_contorlling_filtering2"></xref>.</t>
            </list></t>

          <figure anchor="fig_example_JSON_data_channel_contorlling_filtering2"
                  title="JSON Example of ACL including (dst_ip, dst_port, protocol) information conveyed by DOTS data channel">
            <artwork><![CDATA[
{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "DMS_Offload_scenario_ACL",
        "type": "ipv4-acl-type",
        "activation-type": "activate-when-mitigating",
        "aces": {
          "ace": [
            {
              "name": "DMS_Offload_scenario_HTTP_GET_Flooding",
              "matches": {
                "ipv4": {
                  "destination-ipv4-network": "192.0.2.2/32",
                  "protocol":6
                },
                "tcp": {
                  "destination-port": {
                    "operator": "eq",
                    "port": 80
                  }
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            },
            {
              "name": "DMS_Offload_scenario_SYN_Flooding_FTP",
              "matches": {
                "ipv4": {
                  "destination-ipv4-network": "192.0.2.2/32",
                  "protocol":6
                },
                "tcp": {
                  "destination-port": {
                    "operator": "eq",
                    "port": 20
                  }
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]
        }
      }
    ]
  }
}
              ]]></artwork>
          </figure>

          <figure anchor="fig_example_JSON_signal_channel_contorlling_filtering2"
                  title="JSON Example of including ACL name conveyed by DOTS signal channel">
            <artwork><![CDATA[
{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
           "192.0.2.2/32"
         ],
         "target-protocol": [
           6
         ],
         "acl-list": [
           {
             "acl-name": "DMS_Offload_scenario_HTTP_GET_Flooding",
             "activation-type": "immediate"
           }
        "lifetime": 3600
      }
    ]
  }
}
              ]]></artwork>
          </figure>
        </section>
      </section>
    </section>

    <section title="Security Considerations">
      <t>Security considerations discussed in <xref
      target="I-D.ietf-dots-data-channel"></xref> and <xref
      target="I-D.ietf-dots-signal-channel"></xref> are to be taken into
      account.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section title="Acknowledgement">
      <t>Thanks to Tirumaleswar Reddy, Shunsuke Homma, Pan Wei, and Xia Liang
      for the comments. </t>

      <t>Thanks to Koichi Sakurada for demonstrating proof of concepts of this
      proposal .</t>
    </section>
  </middle>

  <!-- ***** BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="reference.I-D.ietf-dots-data-channel"?>

      <?rfc include="reference.I-D.ietf-dots-signal-channel"?>

      <?rfc include="reference.I-D.ietf-dots-signal-call-home"?>

      <?rfc include="reference.I-D.ietf-dots-signal-filter-control"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4271"?>

      <?rfc include="reference.RFC.5575"?>

      <?rfc include="reference.RFC.8612"?>

      <?rfc include="reference.I-D.ietf-dots-use-cases"?>

      <reference anchor="Interop"
                 target="https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00">
        <front>
          <title>DOTS Interop test report, IETF 103 Hackathon</title>

          <author fullname="Kaname Nishizuka" initials="K."
                  surname="Nishizuka">
            <organization>NTT Communications</organization>

            <address>
              <postal>
                <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>

                <city>Tokyo</city>

                <region></region>

                <code>108-8118</code>

                <country>Japan</country>
              </postal>

              <email>kaname@nttv6.jp</email>
            </address>
          </author>

          <author fullname="Jon Shallow" initials="J." surname=" Shallow">
            <organization>J.NCC Group</organization>

            <address>
              <postal>
                <street></street>

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <author fullname="Liang Xia" initials="L." surname="Xia ">
            <organization>Huawei</organization>

            <address>
              <postal>
                <street></street>

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <date month="November" year="2018" />
        </front>
      </reference>
    </references>

    <!-- Appendix -->
  </back>
</rfc>
