<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!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"?> "rfc2629-xhtml.ent">
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
consensus="true"
docName="draft-ietf-dots-data-channel-31"
     ipr="trust200902">
number="8783"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
tocInclude="true"
tocDepth="3"
symRefs="true"
sortRefs="true"
version="3">
  <!-- xml2rfc v2v3 conversion 2.40.0 -->
  <front>
    <title abbrev="DOTS Data Channel Protocol">Distributed Denial-of-Service
    Open Threat Signaling (DOTS) Data Channel Specification</title>
    <seriesInfo name="RFC" value="8783"/>
    <author fullname="Mohamed Boucadair" initials="M." role="editor" 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>
    <author fullname="Tirumaleswar Reddy" Reddy.K" initials="T." role="editor"
            surname="Reddy"> surname="Reddy.K">
      <organization abbrev="McAfee">McAfee, Inc.</organization>
      <address>
        <postal>
          <street>Embassy Golf Link Business Park</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560071</code>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <date day="22" month="July" year="2019" />  month="May" year="2020"/>
    <workgroup>DOTS</workgroup>
    <keyword>Automation</keyword>
    <keyword>Security</keyword>
    <keyword>Mitigation</keyword>
    <keyword>Scrubbing</keyword>
    <keyword>Anti-DDoS</keyword>
    <keyword>Mitigator</keyword>
    <keyword>Security Center</keyword>
    <keyword>Filtering</keyword>
    <keyword>Resilience</keyword>
    <keyword>RESTCONF</keyword>
    <abstract>
      <t>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>This is a companion document to the DOTS signal channel
      specification.</t>
    </abstract>

    <note title="Editorial Note (To be removed by RFC Editor)">
      <t>Please update these statements within the document with the RFC
      number to be assigned to this document:<list style="symbols">
          <t>"This version of this YANG module is part of RFC XXXX;"</t>

          <t>"RFC XXXX: Distributed "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Signal Channel Specification";</t>

          <t>reference: RFC XXXX</t>
        </list></t>

      <t>Please update the "revision" date of the YANG module.</t>
    </note> Specification" (RFC 8782).</t>
    </abstract>

  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>A distributed denial-of-service (DDoS) attack is an attempt to make
      machines or network resources unavailable to their intended users. In
      most cases, sufficient scale can be achieved by compromising enough
      end-hosts
      end hosts and using those infected hosts to perpetrate and amplify the
      attack. The victim of such an attack can be an application server, a
      router, a firewall, an entire network, etc.</t>
      <t>As discussed in <xref target="RFC8612"></xref>, target="RFC8612" format="default"/>, the lack of a common
      method to coordinate a real-time response among involved actors and
      network domains inhibits the speed and effectiveness of DDoS attack
      mitigation. From that standpoint, DDoS Open Threat Signaling (DOTS)
      defines an architecture that allows a DOTS client to send requests to a
      DOTS server for DDoS attack mitigation
      <xref
      target="I-D.ietf-dots-architecture"></xref>. target="I-D.ietf-dots-architecture" format="default"/>. The DOTS approach is thus
      meant to minimize the impact of DDoS attacks, thereby contributing to
      the enforcement of more efficient defensive if not proactive security
      strategies. To that aim, DOTS defines two channels: the signal channel and the
      data channels channel (<xref target="channels"></xref>). target="channels" format="default"/>). </t>
      <figure align="center"
          anchor="channels" title="DOTS Channels">
          <artwork><![CDATA[+---------------+ anchor="channels">
        <name>DOTS Channels</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+---------------+                                 +---------------+
|               | <------- Signal Channel ------> |               |
|  DOTS Client  |                                 |  DOTS Server  |
|               | <=======  Data Channel  ======> |               |
+---------------+                                 +---------------+]]></artwork>
        </figure></t>                                 +---------------+
]]></artwork>
      </figure>
      <t>The DOTS signal channel is used to carry information about a device
      or a network (or a part thereof) that is under a DDoS attack. Such
      information is sent by a DOTS client to an upstream DOTS server so that
      appropriate mitigation actions are undertaken on traffic deemed
      suspicious. The DOTS signal channel is further elaborated in <xref
      target="I-D.ietf-dots-signal-channel"></xref>.</t>

      <t>As for the target="RFC8782" format="default"/>.</t>
      <t>The DOTS data channel, it channel is used for infrequent bulk data
      exchange between DOTS agents to significantly improve the coordination
      of all the parties involved in the response to the attack. Section 2 of
      <xref target="I-D.ietf-dots-architecture"></xref> target="I-D.ietf-dots-architecture" section="2" sectionFormat="of" format="default"/> mentions that the DOTS
      data channel is used to perform the following tasks:</t>

      <t><list style="symbols">
          <t>Creating
      <ul spacing="normal">
        <li>
          <t>Creation of aliases for resources for which mitigation may be
          requested.<vspace blankLines="1" />A
          requested.</t>
          <t>A DOTS client may submit to its
          DOTS server a collection of prefixes to which it would like to refer to
          by an alias when requesting mitigation. The DOTS server can respond
          to this request with either a success or failure response (see
          Section 2 in
          <xref
          target="I-D.ietf-dots-architecture"></xref>).<vspace
          blankLines="1" />Refer target="I-D.ietf-dots-architecture" section="2" sectionFormat="of" format="default"/>).</t>
          <t>Refer to <xref target="identifier"></xref> target="identifier" format="default"/> for more
          details.</t>
        </li>
        <li>
          <t>Policy management, which enables a DOTS client to request the
          installation or withdrawal of traffic filters, the dropping or
          rate-limiting of unwanted traffic, and the permitting of accept-listed
          traffic. A DOTS client is entitled to instruct filtering rules only
          on IP resources that belong to its domain.<vspace
          blankLines="1" />Sample domain.</t>
          <t>Sample use cases for populating drop- or
          accept-list filtering rules are detailed hereafter: <list
              style="symbols"> </t>
          <ul spacing="normal">
            <li>
              <t>If a network resource (DOTS client) is informed about a
              potential DDoS attack from a set of IP addresses, the DOTS
              client informs its servicing DOTS gateway of all suspect IP
              addresses that need to be drop-listed for further investigation.
              The DOTS client could also specify a list of protocols and port
              numbers in the drop-list rule. <vspace blankLines="1" />The </t>
              <t>The DOTS
              gateway then propagates the drop-listed IP addresses to a DOTS
              server
              server, which will undertake appropriate actions so that traffic
              originated by these IP addresses to the target network
              (specified by the DOTS client) is blocked.</t>
            </li>
            <li>
              <t>A network, network that has partner sites from which only legitimate
              traffic arrives, arrives may want to ensure that the traffic from these
              sites is not subjected to DDoS attack mitigation. The DOTS
              client uses the DOTS data channel to convey the accept-listed IP
              prefixes of the partner sites to its DOTS server. <vspace
              blankLines="1" />The </t>
              <t>The DOTS server uses this information to
              accept-list flows originated by such IP prefixes and which reach
              the network.</t>
            </list>Refer
            </li>
          </ul>
          <t>Refer to <xref target="filter"></xref> target="filter" format="default"/> for more
          details.</t>
        </list></t>
        </li>
      </ul>
    </section>
    <section anchor="notation" title="Terminology">
      <t>The numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref
      target="RFC2119"></xref> target="RFC2119"/> <xref target="RFC8174"></xref> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      <t>The reader should be familiar with the terms defined in <xref
      target="RFC8612"></xref>.</t> target="RFC8612" format="default"/>.</t>
      <t>The terminology for describing YANG modules is defined in
      <xref
      target="RFC7950"></xref>. target="RFC7950" format="default"/>. The meaning of the symbols in the tree
      diagrams is defined in <xref target="RFC8340"></xref>.</t> target="RFC8340" format="default"/>.</t>
      <t>This document generalizes the notion of Access Control List (ACL) so
      that it is not device-specific device specific <xref target="RFC8519"></xref>. target="RFC8519" format="default"/>. As such,
      this document defines an ACL as an ordered set of rules that is used to
      filter traffic. Each rule is represented by an Access Control Entry
      (ACE). ACLs communicated via the DOTS data channel are not bound to a
      device interface.</t>
      <t>For the sake of simplicity, all of the examples in this document use
      "/restconf" as the discovered RESTCONF API root path. Many Within the examples, many protocol
      header lines and message-body text within examples throughout the
      document are split into multiple lines for display purposes only. When a
      line ends with backslash ('\') as the last character, the line is
      wrapped for display purposes. It is to be considered to be joined to the
      next line by deleting the backslash, the following line break, and the
      leading whitespace of the next line.</t>
    </section>
    <section title="DOTS numbered="true" toc="default">
      <name>DOTS Data Channel"> Channel</name>
      <section title="Design Overview"> numbered="true" toc="default">
        <name>Design Overview</name>
        <t>Unlike the DOTS signal channel, which must remain operational even
        when confronted with signal degradation due to packets packet loss, the DOTS
        data channel is not expected to be fully operational at all times,
        especially when a DDoS attack is underway. The requirements for a DOTS
        data channel protocol are documented in <xref
        target="RFC8612"></xref>.</t> target="RFC8612" format="default"/>.</t>
        <t>This specification does not require an order of DOTS signal and
        data channel creations creation nor mandates does it mandate a time interval between them.
        These considerations are implementation- implementation and deployment-specific.</t> deployment specific.</t>
        <t>As the primary function of the data channel is data exchange, a
        reliable transport mode is required in order for DOTS agents to detect
        data delivery success or failure. This document uses RESTCONF <xref
        target="RFC8040"></xref> target="RFC8040" format="default"/> over TLS over TCP as the DOTS data channel
        protocol. The abstract layering of the DOTS data channel is shown in <xref
        target="fig_dots2"></xref>.</t>

        <t><figure anchor="fig_dots2"
            title="Abstract target="fig_dots2" format="default"/>.</t>
        <figure anchor="fig_dots2">
          <name>Abstract Layering of DOTS Data Channel"> Channel</name>
          <artwork align="center"><![CDATA[+-------------------+ align="center" name="" type="" alt=""><![CDATA[
+-------------------+
| DOTS Data Channel |
+-------------------+
|      RESTCONF     |
+-------------------+
|        TLS        |
+-------------------+
|        TCP        |
+-------------------+
|        IP         |
+-------------------+
]]></artwork>
          </figure></t>
        </figure>
        <t>The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data
        resources represented by DOTS data channel YANG modules. These basic
        edit operations allow the a DOTS data channel client to alter the running configuration to
        be altered by a
        of the DOTS client. data channel. Rules for generating and processing
        RESTCONF methods are defined in Section 4 of <xref
        target="RFC8040"></xref>.</t> target="RFC8040" section="4" sectionFormat="of" format="default"/>.</t>
        <t>DOTS data channel configuration information as well as state
        information can be retrieved with the GET method. An HTTP status-line
        is returned for each request to report success or failure for RESTCONF
        operations (Section 5.4 of <xref target="RFC8040"></xref>). (<xref target="RFC8040" section="5.4" sectionFormat="of" format="default"/>). The
        "error-tag"
        error-tag provides more information about encountered errors
        (Section 7 of <xref target="RFC8040"></xref>).</t>
        (<xref target="RFC8040" section="7" sectionFormat="of" format="default"/>).</t>
        <t>DOTS clients perform the root resource discovery procedure
        discussed in Section 3.1 of <xref target="RFC8040"></xref> target="RFC8040" section="3.1" sectionFormat="of" format="default"/> to
        determine the root of the RESTCONF API. After discovering the RESTCONF
        API root, a DOTS client uses this value as the initial part of the
        path in the request URI in any subsequent request to the DOTS server.
        The DOTS server may support the retrieval of the YANG modules it
        supports (Section 3.7 in <xref target="RFC8040"></xref>). (<xref target="RFC8040" section="3.7" sectionFormat="of" format="default"/>). For example,
        a DOTS client may use RESTCONF to retrieve the vendor-specific YANG
        modules supported by its DOTS server.</t>
        <t>JavaScript Object Notation (JSON) <xref target="RFC8259"> target="RFC8259" format="default"> </xref>
        payloads are used to propagate the DOTS data-channel-specific payload
        messages that carry request parameters and response information, such
        as errors. This specification uses the encoding rules defined in
        <xref
        target="RFC7951"></xref> target="RFC7951" format="default"/> for representing DOTS data channel
        configuration data using YANG (<xref target="YANG"></xref>) target="YANG" format="default"/>) as JSON
        text.</t>
        <t>A DOTS client registers itself to with its DOTS server(s) in order to
        set up DOTS data channel-related configuration data and to receive state
        data (i.e., non-configuration data) from the DOTS server(s) (<xref
        target="registering"></xref>). target="registering" format="default"/>).
        Mutual authentication considerations are specified in Section 8 of
        <xref
        target="I-D.ietf-dots-signal-channel"></xref>. target="RFC8782" section="8" sectionFormat="of" format="default"/>.
        The coupling of signal and data channels is discussed in Section 4.4.1 of
        <xref
        target="I-D.ietf-dots-signal-channel"></xref>.</t> target="RFC8782" section="4.4.1" sectionFormat="of" format="default"/>.</t>
        <t>A DOTS client can either maintain a persistent connection or initiate
        periodic connections with its DOTS server(s). If the DOTS client needs
        to frequently update the drop-list or accept-list filtering rules or
        aliases, it maintains a persistent connection with the DOTS server.
        For example, CAPTCHA and cryptographic puzzles can be used by the
        mitigation service in the DOTS client domain to determine
	whether or not the
        IP address is used for legitimate purpose or not, purpose, and the DOTS client
        can frequently update the drop-list filtering rules. A persistent
        connection is also useful if the DOTS client subscribes to event
        notifications (Section 6.3 of <xref target="RFC8040"></xref>). (<xref target="RFC8040" section="6.3" sectionFormat="of" format="default"/>).
        Additional considerations related to RESTCONF connection management
        (including, configuring the connection type or the reconnect strategy)
        can be found in <xref
        target="I-D.ietf-netconf-restconf-client-server"></xref>.</t> target="I-D.ietf-netconf-restconf-client-server" format="default"/>.</t>
        <t>A single DOTS data channel between DOTS agents can be used to
        exchange multiple requests and multiple responses. To reduce DOTS
        client and DOTS server workload, DOTS clients SHOULD re-use <bcp14>SHOULD</bcp14> reuse the same
        TLS session. While the communication to the DOTS server is quiescent,
        the DOTS client MAY <bcp14>MAY</bcp14> probe the server to ensure it has maintained
        cryptographic state. Such probes can also keep alive firewall and/or
        NAT bindings. A TLS heartbeat <xref target="RFC6520"></xref> target="RFC6520" format="default"/> verifies
        that the DOTS server still has TLS state by returning a TLS
        message.</t>
        <t>A DOTS server may detect conflicting filtering requests from
        distinct DOTS clients which that belong to the same domain. For example, a
        DOTS client could request to drop-list a prefix by specifying the
        source prefix, while another DOTS client could request to accept-list
        that same source prefix, but both having the same destination prefix.
        DOTS servers SHOULD <bcp14>SHOULD</bcp14> support a configuration parameter to indicate the
        behavior to follow when a conflict is detected (e.g., reject all,
        reject the new request, notify an administrator for validation).
        <xref
        target="install"></xref> target="install" format="default"/> specifies a default behavior when no
        instruction is supplied to a DOTS server.</t>
        <t>How a DOTS client synchronizes its configuration with the one
        maintained by its DOTS server(s) is implementation-specific. implementation specific. For
        example: <list style="symbols">
            <t>a </t>
        <ul spacing="normal">
          <li>A DOTS client can systematically send a GET message before
            and/or after a configuration change request.</t>

            <t>a request.</li>
<li>A DOTS client can re-establish reestablish the disconnected DOTS session
after an attack is mitigated and mitigated. Then, it sends a GET message before a
configuration change request.</t>
          </list></t> request. </li>
        </ul>
        <t>NAT considerations for the DOTS data channel are similar to those
        discussed in Section 3 of <xref
        target="I-D.ietf-dots-signal-channel"></xref>.</t>

        <t>How target="RFC8782" section="3" sectionFormat="of" format="default"/>.</t>
        <t>The translation of filtering rules that are instantiated on a DOTS server are
        translated
        into network configurations configuration actions is out of scope of this
        specification.</t>
        <t>Some of the fields introduced in <xref target="YANG"></xref> target="YANG" format="default"/> are
        also discussed in Sections <xref format="counter"
        target="registering"></xref>, target="registering"/>,
        <xref format="counter"
        target="identifier"></xref>, target="identifier"/>, and <xref format="counter"
        target="filter"></xref>. target="filter"/>.
        These sections are authoritative for these fields.</t>
      </section>
      <section title="DOTS numbered="true" toc="default">
        <name>DOTS Server(s) Discovery"> Discovery</name>
        <t>This document assumes that DOTS clients are provisioned with a way
        to know the
        knowledge of how to reach their DOTS server(s), which could occur by a
        variety of means (e.g., local configuration, configuration or dynamic means such as
        DHCP <xref target="I-D.ietf-dots-server-discovery"></xref>). target="I-D.ietf-dots-server-discovery" format="default"/>). The
        specification of such means are out of scope of this document.</t>
        <t>Likewise, it is out of scope of this document to specify the
        behavior to be followed by a DOTS client to send DOTS requests when
        multiple DOTS servers are provisioned (e.g., contact all DOTS servers,
        select one DOTS server among the list).</t>
      </section>
      <section title="DOTS Gateways"> numbered="true" toc="default">
        <name>DOTS Gateways</name>
        <t>When a server-domain DOTS gateway is involved in DOTS data channel
        exchanges, the same considerations for manipulating the 'cdid' (client
        domain identifier) parameter specified in <xref
        target="I-D.ietf-dots-signal-channel"></xref> MUST target="RFC8782" format="default"/> <bcp14>MUST</bcp14> be followed by DOTS
        agents. As a reminder, 'cdid' is meant to assist the DOTS server to
        enforce in
        enforcing some policies (e.g., limit the number of filtering rules per
        DOTS client or per DOTS client domain). A loop detect detection mechanism for
        DOTS gateways is specified in <xref target="loops"></xref>.</t> target="loops" format="default"/>.</t>
        <t>If a DOTS gateway is involved, the DOTS gateway verifies that the
        DOTS client is authorized to undertake a data channel action (e.g.,
        instantiate filtering rules). If the DOTS client is authorized, it
        propagates the rules to the upstream DOTS server. Likewise, the DOTS
        server verifies that the DOTS gateway is authorized to relay data
        channel actions. For example, to create or purge filters, a DOTS
        client sends its request to its DOTS gateway. The DOTS gateway
        validates the rules in the request and proxies the requests containing
        the filtering rules to its DOTS server. When the DOTS gateway receives
        the associated response from the DOTS server, it propagates the
        response back to the DOTS client.</t>
      </section>
      <section anchor="loops" title="Detect numbered="true" toc="default">
        <name>Detecting and Prevent Preventing Infinite Loops"> Loops</name>
        <t>In order to detect and prevent infinite loops, DOTS gateways MUST <bcp14>MUST</bcp14>
        support the procedure defined in Section 5.7.1 of <xref
        target="RFC7230"></xref>. target="RFC7230" section="5.7.1" sectionFormat="of" format="default"/>.
        In particular, each intermediate DOTS
        gateway MUST <bcp14>MUST</bcp14> check that none of its own information (e.g., server
        names, literal IP addresses) is present in the "Via" Via header field of a
        DOTS message it receives:<list style="symbols"> receives:</t>
        <ul spacing="normal">
          <li>
            <t>If it detects that its own information is present in the "Via" Via
            header field, the DOTS gateway MUST NOT <bcp14>MUST NOT</bcp14> forward the DOTS message.
            Messages that cannot be forwarded because of a loop SHOULD <bcp14>SHOULD</bcp14> be
            logged with a "508 Loop Detected" status-line returned sent back
            to the DOTS peer. The structure of the reported error is depicted
            in <xref target="looperr"></xref>.<vspace blankLines="1" /><figure
                align="center" anchor="looperr" title="Loop target="looperr" format="default"/>.</t>
            <figure anchor="looperr">
              <name>Loop Detected Error">
                <artwork><![CDATA[error-app-tag: Error</name>
              <sourcecode type=""><![CDATA[
error-app-tag:  loop-detected
error-tag:      operation-failed
error-type:     transport, application
error-info:     <via-header> : A copy of the Via header field when
                the loop was detected.
Description:    An infinite loop has been detected when forwarding
                a requests via a proxy.
]]></artwork>
              </figure><vspace blankLines="1" />It
]]></sourcecode>
            </figure>
            <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that DOTS
            clients and gateways support methods to alert administrators about
            loop errors so that appropriate actions are undertaken.</t>

            <t>Otherwise,
          </li>
          <li>Otherwise, the DOTS agent MUST <bcp14>MUST</bcp14> update or insert the "Via" Via
            header field by appending its own information.</t>
          </list></t> information.</li>
        </ul>
        <t>Unless configured otherwise, DOTS gateways at the boundaries of a
        DOTS client domain SHOULD <bcp14>SHOULD</bcp14> remove the previous "Via" Via header field
        information after checking for a loop before forwarding. This behavior
        is required for topology hiding purposes but can also serve to
        minimize potential conflicts that may arise if overlapping information
        is used in distinct DOTS domains (e.g., private IPv4 addresses, non
        aliases that are not globally unique aliases).</t> unique).</t>
      </section>
      <section title="Stale Entries"> numbered="true" toc="default">
        <name>Preventing Stale Entries</name>
        <t>In order to avoid stale entries, a lifetime is associated with
        alias and filtering entries created by DOTS clients. Also, DOTS
        servers may track the inactivity timeout of DOTS clients to detect
        stale entries.</t>
      </section>
    </section>
    <section anchor="YANG" title="DOTS numbered="true" toc="default">
      <name>DOTS Data Channel YANG Module"> Module</name>
      <section anchor="tree" title="Generic numbered="true" toc="default">

        <name>Generic Tree Structure"> Structure</name>
        <t>The DOTS data channel YANG module (ietf-dots-data-channel) 'ietf-dots-data-channel' provides
        a method for DOTS clients to manage aliases for resources for which
        mitigation may be requested. Such aliases may be used in subsequent
        DOTS signal channel exchanges to refer more efficiently to the
        resources under attack.</t>
        <t>Note that the full module's tree has been split across several
        figures to aid the exposition of the various sub-trees.</t> subtrees.</t>
        <t>The tree structure for the DOTS alias is depicted in <xref
        target="talias"></xref>.</t>

        <t><figure align="center" anchor="talias" title="DOTS target="talias" format="default"/>.</t>
        <figure anchor="talias">
          <name>DOTS Alias Subtree">
            <artwork><![CDATA[module: Subtree</name>
          <sourcecode type="yangtree"><![CDATA[
module: ietf-dots-data-channel
  +--rw dots-data
     +--rw dots-client* [cuid]
     |  +--rw cuid            string
     |  +--rw cdid?           string
     |  +--rw aliases
     |  |  +--rw alias* [name]
     |  |     +--rw name                 string
     |  |     +--rw target-prefix*       inet:ip-prefix
     |  |     +--rw target-port-range* [lower-port]
     |  |     |  +--rw lower-port    inet:port-number
     |  |     |  +--rw upper-port?   inet:port-number
     |  |     +--rw target-protocol*     uint8
     |  |     +--rw target-fqdn*         inet:domain-name
     |  |     +--rw target-uri*          inet:uri
     |  |     +--ro pending-lifetime?    int32
     |  +--rw acls
     |     ...
     +--ro capabilities
        ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>Also, the 'ietf-dots-data-channel' YANG module provides a method for
        DOTS clients to manage filtering rules. Examples of filtering
        management in a DOTS context include, but are not limited to:</t>

        <t><list style="symbols">
            <t>Drop-list
        <ul spacing="normal">
          <li>Drop-list management, which enables a DOTS client to inform a
            DOTS server about sources from which traffic should be
            discarded.</t>

            <t>Accept-list
            discarded.</li>
          <li>Accept-list management, which enables a DOTS client to inform a
            DOTS server about sources from which traffic should always be
            accepted.</t>

            <t>Policy
            accepted.</li>
          <li>Policy management, which enables a DOTS client to request the
            installation or withdrawal of traffic filters, the dropping or
            rate-limiting of unwanted traffic traffic, and permitting the allowance of accept-listed
            traffic.</t>
          </list></t>
            traffic.</li>
        </ul>
        <t>The tree structure for the DOTS filtering entries is depicted in
        <xref target="tacl"></xref>.</t> target="tacl" format="default"/>.</t>
        <t>Investigations into the prospect of augmenting
        'ietf-access-control-list' to meet DOTS requirements concluded that
        such a design approach did not support many of the DOTS requirements,
        e.g.,</t>

        <t><list style="symbols">
            <t>Retrieve
        for example:</t>
        <ul spacing="normal">
          <li>Retrieve a filtering entry (or all entries) created by a DOTS
            client.</t>

            <t>Delete
            client.</li>
          <li>Delete a filtering entry that was instantiated by a DOTS
            client.</t>
          </list></t>
            client.</li>
        </ul>
        <t>Accordingly, new DOTS filtering entries (i.e., Access Control List
        (ACL)) ACL) are defined that mimic the structure specified in
        <xref
        target="RFC8519"></xref>. target="RFC8519" format="default"/>. Concretely, DOTS agents are assumed to
        manipulate an ordered list of ACLs; each ACL contains a separately
        ordered list of Access Control Entries (ACEs). ACEs. Each ACE has a group of
        match and a group of action criteria.</t>
        <t>Once all of the ACE entries have been iterated though with no match,
        then all of the following ACL's ACE entries are iterated through until
        the first match match, at which point the specified action is applied. If
        there is no match during 'idle' time (i.e., no mitigation is active),
        then there is no further action to be taken against the packet. If
        there is no match during active mitigation, then the packet will still
        be scrubbed by the DDoS mitigator.</t>

        <t><figure align="center" anchor="tacl" title="DOTS
        <figure anchor="tacl">
          <name>DOTS ACLs Subtree">
            <artwork><![CDATA[module: Subtree</name>
          <sourcecode type="yangtree"><![CDATA[
module: ietf-dots-data-channel
  +--rw dots-data
     +--rw dots-client* [cuid]
     |  +--rw cuid            string
     |  +--rw cdid?           string
     |  +--rw aliases
     |  |  ...
     |  +--rw acls
     |     +--rw acl* [name]
     |        +--rw name                string
     |        +--rw type?               ietf-acl:acl-type
     |        +--rw activation-type?    activation-type
     |        +--ro pending-lifetime?   int32
     |        +--rw aces
     |           +--rw ace* [name]
     |              +--rw name          string
     |              +--rw matches
     |              |  +--rw (l3)?
     |              |  |  +--:(ipv4)
     |              |  |  |  ...
     |              |  |  +--:(ipv6)
     |              |  |     ...
     |              |  +--rw (l4)?
     |              |     +--:(tcp)
     |              |     |  ...
     |              |     +--:(udp)
     |              |     |  ...
     |              |     +--:(icmp)
     |              |        ...
     |              +--rw actions
     |              |  +--rw forwarding    identityref
     |              |  +--rw rate-limit?   decimal64
     |              +--ro statistics
     |                 +--ro matched-packets?   yang:counter64
     |                 +--ro matched-octets?    yang:counter64
     +--ro capabilities
        ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>Filtering rules instructed by a DOTS client assumes assume a default
        direction: the destination is the DOTS client domain.</t>
        <t>DOTS forwarding actions can be 'accept' (i.e., accept matching
        traffic) or 'drop' (i.e., drop matching traffic without sending any
        ICMP error message). Accepted traffic can be subject to rate-limiting
        'rate-limit'. Note that 'reject' action (i.e., drop matching traffic
        and send an ICMP error message to the source) is not supported in
        'ietf-dots-data-channel' because it is not appropriate in the context
        of DDoS mitigation. Generating ICMP messages to notify of drops when
        mitigating a DDoS attack will exacerbate the DDoS attack. Furthermore,
        these ICMP messages will be used by an attacker as an explicit signal
        that the traffic is being blocked.</t>
      </section>
      <section anchor="filf" title="Filtering Fields"> numbered="true" toc="default">
        <name>Filtering Fields</name>
        <t>The 'ietf-dots-data-channel' module reuses the packet fields module
        'ietf-packet-fields' <xref target="RFC8519"></xref> target="RFC8519" format="default"/>, which defines
        matching on fields in the packet including IPv4, IPv6, and transport
        layer fields. The 'ietf-dots-data-channel' module can be augmented,
        for example, to support additional protocol-specific matching
        fields.</t>
        <t>This specification defines a new IPv4/IPv6 matching field called
        'fragment' to efficiently handle fragment-related filtering rules.
        Indeed, <xref target="RFC8519"></xref> target="RFC8519" format="default"/> does not support such
        capability for IPv6 but offers a partial support for IPv4 by means of
        'flags'. Nevertheless, the use of 'flags' is problematic since it does
        not allow to define a bitmask. bitmask to be defined. For example, setting other bits not
        covered by the 'flags' filtering clause in a packet will allow that
        packet to get through (because it won't match the ACE). Sample
        examples
        Examples to illustrate how 'fragment' can be used are provided in
        <xref target="frag"></xref>.</t> target="frag" format="default"/>.</t>
        <t><xref target="tipv4"></xref> target="tipv4" format="default"/> shows the IPv4 match subtree.</t>

        <t><figure align="center" anchor="tipv4"
            title="DOTS
        <figure anchor="tipv4">
          <name>DOTS ACLs Subtree (IPv4 Match)">
            <artwork><![CDATA[ Match)</name>
          <sourcecode type="yangtree"><![CDATA[
module: ietf-dots-data-channel
  +--rw dots-data
     +--rw dots-client* [cuid]
     |  ...
     |  +--rw acls
     |     +--rw acl* [name]
     |        ...
     |        +--rw aces
     |           +--rw ace* [name]
     |              +--rw name          string
     |              +--rw matches
     |              |  +--rw (l3)?
     |              |  |  +--:(ipv4)
     |              |  |  |  +--rw ipv4
     |              |  |  |     +--rw dscp?                 inet:dscp
     |              |  |  |     +--rw ecn?                  uint8
     |              |  |  |     +--rw length?               uint16
     |              |  |  |     +--rw ttl?                  uint8
     |              |  |  |     +--rw protocol?             uint8
     |              |  |  |     +--rw ihl?                  uint8
     |              |  |  |     +--rw flags?                bits
     |              |  |  |     +--rw offset?               uint16
     |              |  |  |     +--rw identification?       uint16
     |              |  |  |     +--rw (destination-network)?
     |              |  |  |     |  +--:(destination-ipv4-network)
     |              |  |  |     |     +--rw destination-ipv4-network?
     |              |  |  |     |             inet:ipv4-prefix
     |              |  |  |     +--rw (source-network)?
     |              |  |  |     |  +--:(source-ipv4-network)
     |              |  |  |     |     +--rw source-ipv4-network?
     |              |  |  |     |             inet:ipv4-prefix
     |              |  |  |     +--rw fragment
     |              |  |  |        +--rw operator?        operator
     |              |  |  |        +--rw type        fragment-type
     |              |  |  +--:(ipv6)
     |              |  |     ...
     |              |  +--rw (l4)?
     |              |     ...
     |              +--rw actions
     |              |  ...
     |              +--ro statistics
     |                 ...
     +--ro capabilities
        ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t><xref target="tipv6"></xref> target="tipv6" format="default"/> shows the IPv6 match subtree.</t>

        <t><figure align="center" anchor="tipv6"
            title="DOTS
        <figure anchor="tipv6">
          <name>DOTS ACLs Subtree (IPv6 Match)">
            <artwork><![CDATA[ Match)</name>
          <sourcecode type="yangtree"><![CDATA[
module: ietf-dots-data-channel
  +--rw dots-data
     +--rw dots-client* [cuid]
     |  ...
     |  +--rw acls
     |     +--rw acl* [name]
     |        ...
     |        +--rw aces
     |           +--rw ace* [name]
     |              +--rw name          string
     |              +--rw matches
     |              |  +--rw (l3)?
     |              |  |  +--:(ipv4)
     |              |  |  |  ...
     |              |  |  +--:(ipv6)
     |              |  |     +--rw ipv6
     |              |  |        +--rw dscp?                 inet:dscp
     |              |  |        +--rw ecn?                  uint8
     |              |  |        +--rw length?               uint16
     |              |  |        +--rw ttl?                  uint8
     |              |  |        +--rw protocol?             uint8
     |              |  |        +--rw (destination-network)?
     |              |  |        |  +--:(destination-ipv6-network)
     |              |  |        |     +--rw destination-ipv6-network?
     |              |  |        |             inet:ipv6-prefix
     |              |  |        +--rw (source-network)?
     |              |  |        |  +--:(source-ipv6-network)
     |              |  |        |     +--rw source-ipv6-network?
     |              |  |        |             inet:ipv6-prefix
     |              |  |        +--rw flow-label?
     |              |  |        |       inet:ipv6-flow-label
     |              |  |        +--rw fragment
     |              |  |           +--rw operator?       operator
     |              |  |           +--rw type       fragment-type
     |              |  +--rw (l4)?
     |              |     ...
     |              +--rw actions
     |              |  ...
     |              +--ro statistics
     |                 ...
     +--ro capabilities
        ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>

        <t><xref target="ttcp"></xref> target="ttcp" format="default"/> shows the TCP match subtree. In
        addition to the fields defined in <xref target="RFC8519"></xref>, target="RFC8519" format="default"/>, this
        specification defines a new TCP matching field, called
        'flags-bitmask', to efficiently handle TCP flags filtering rules. Some
        examples are provided in <xref target="flags"></xref>.</t>

        <t><figure align="center" anchor="ttcp"
            title="DOTS target="flags" format="default"/>.</t>
        <figure anchor="ttcp">
          <name>DOTS ACLs Subtree (TCP Match)">
            <artwork><![CDATA[module: ietf-dots-data-channel Match)</name>

          <sourcecode type="yangtree"><![CDATA[
   +--rw dots-data
   +-rw dots-client* [cuid] matches
   | ...
   | +-rw acls
   |   +-rw acl* [name]
   |    ...
   |     +-rw aces
   |       +-rw ace* [name]
   |         +-rw name          string
   |           +-rw matches
   |           | +-rw  +--rw (l3)?
   |  | |  ...
   |           | +-rw  +--rw (l4)?
   |           |   +-:(tcp)
   |     +--:(tcp)
   |     | +-rw  +--rw tcp
   |     |   |     +--rw sequence-number?          uint32
   |     |   |     +--rw acknowledgement-number?   uint32
   |     |   |     +--rw data-offset?              uint8
   |     |   |     +--rw reserved?                 uint8
   |     |   |     +--rw flags?                    bits
   |     |   |     +--rw window-size?              uint16
   |     |   |     +--rw urgent-pointer?           uint16
   |     |   |     +--rw options?                  binary
   |     |   |     +--rw flags-bitmask
   |     |     |   |  +--rw operator?            operator
   |     |     |   |  +--rw bitmask                uint16
   |     |   |     +--rw (source-port)?
   |     |     |   |  +--:(source-port-range-or-operator)
   |     |     |   |     +--rw source-port-range-or-operator
   |     |     |   |        +--rw (port-range-or-operator)?
   |     |     |   |           +--:(range)
   |     |     |           |           |  +--rw lower-port
   |     |     |           |  |  |       inet:port-number
   |     |     |           |           |  +--rw upper-port
   |     |     |           |           |          inet:port-number
   |     |     |   |           +--:(operator)
   |     |     |   |              +--rw operator?
   |     |     |              |              |       operator
   |     |     |   |              +--rw port
   |     |     |   |                      inet:port-number
   |     |   |     +--rw (destination-port)?
   |     |   |        +--:(destination-port-range-or-operator)
   |     |   |           +--rw destination-port-range-or-operator
   |     |   |              +--rw (port-range-or-operator)?
   |     |   |                 +--:(range)
   |     |                 |               |  +--rw lower-port
   |     |                 |  |  |       inet:port-number
   |     |                 |               |  +--rw upper-port
   |     |                 |               |          inet:port-number
   |     |   |                 +--:(operator)
   |     |   |                    +--rw operator?
   |     |                    |                  |       operator
   |     |   |                    +--rw port
   |     |   |                            inet:port-number
   |           |   +-:(udp)
   |     +--:(udp)
   |     |  ...
   |           |   +-:(icmp)
   |     +--:(icmp)
   |        ...
   |           +-rw
   +--rw actions
   |           | ...
   |           +-ro statistics
   |             ...
   +-ro capabilities  ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t><xref target="ttransport"></xref> target="ttransport" format="default"/> shows the UDP and ICMP match
        subtrees. The same structure is used for both ICMP and ICMPv6. The
        indication whether an ACL is about ICMP or ICMPv6 is governed by the
        'l3' match or the ACL type.</t>

        <t><figure align="center" anchor="ttransport"
            title="DOTS
        <figure anchor="ttransport">
          <name>DOTS ACLs Subtree (UDP and ICMP Match)">
            <artwork><![CDATA[module: ietf-dots-data-channel
 +-rw dots-data
   +-rw dots-client* [cuid]
   | ...
   | +-rw acls
   |   +-rw acl* [name]
   |     ...
   |     +-rw aces
   |       +-rw ace* [name]
   |         +--rw name          string
   | Match)</name>

          <sourcecode type="yangtree"><![CDATA[
   +--rw matches
   |         |  +--rw (l3)?
   |  |  |  ...
   |         |  +--rw (l4)?
   |         |     +--:(tcp)
   |     |     |  ...
   |         |     +--:(udp)
   |     |     |  +--rw udp
   |     |     |     +--rw length?          uint16
   |     |     |     +--rw (source-port)?
   |     |     |     |  +--:(source-port-range-or-operator)
   |     |     |     |     +--rw source-port-range-or-operator
   |     |     |     |        +--rw (port-range-or-operator)?
   |     |     |     |           +--:(range)
   |     |     |           |           |  +--rw lower-port
   |     |     |           |  |  |       inet:port-number
   |     |     |           |           |  +--rw upper-port
   |     |     |           |           |          inet:port-number
   |     |     |     |           +--:(operator)
   |     |     |     |              +--rw operator?
   |     |     |              |              |       operator
   |     |     |     |              +--rw port
   |     |     |     |                      inet:port-number
   |     |     |     +--rw (destination-port)?
   |     |     |        +--:(destination-port-range-or-operator)
   |     |     |           +--rw destination-port-range-or-operator
   |     |     |              +--rw (port-range-or-operator)?
   |     |     |                 +--:(range)
   |     |                 |                 |  +--rw lower-port
   |     |                 |  |  |       inet:port-number
   |     |                 |                 |  +--rw upper-port
   |     |                 |                 |          inet:port-number
   |     |     |                 +--:(operator)
   |     |     |                    +--rw operator?
   |     |                    |                    |       operator
   |     |     |                    +--rw port
   |     |     |                            inet:port-number
   |         |     +--:(icmp)
   |         |        +--rw icmp
   |         |           +--rw type?             uint8
   |         |           +--rw code?             uint8
   |         |           +--rw rest-of-header?   binary
   |
   +--rw actions
   |         |  ...
   |         +--ro statistics
   |  ...
   +-ro capabilities
     ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>DOTS implementations MUST <bcp14>MUST</bcp14> support the following matching
        criteria:<list style="empty">
            <t>match
        criteria:</t>
        <ul empty="true" spacing="normal">
          <li>Match based on the IP header (IPv4 and IPv6), match based on
            the transport header (TCP, UDP, and ICMP), and match based
	    on any combination
            thereof. The same matching fields are used for both ICMP and
            ICMPv6.</t>
          </list></t>
            ICMPv6.</li>
        </ul>
        <t>The following match fields MUST <bcp14>MUST</bcp14> be supported by DOTS
        implementations (<xref target="mf"></xref>):</t>

        <texttable target="mf" format="default"/>):</t>
        <table align="center" anchor="mf" style="headers"
                   title="Mandatory anchor="mf">
          <name>Mandatory DOTS Channel Match Fields">
          <ttcol>ACL Match</ttcol>

          <ttcol>Mandatory Fields</ttcol>

          <c>ipv4</c>

          <c>length, Fields</name>
          <thead>
            <tr>
              <th align="left">ACL Match</th>
              <th align="left">Mandatory Fields</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">ipv4</td>
              <td align="left">length, protocol, destination-ipv4-network, source-ipv4-network,
          and fragment</c>

          <c>ipv6</c>

          <c>length, fragment</td>
            </tr>
            <tr>
              <td align="left">ipv6</td>
              <td align="left">length, protocol, destination-ipv6-network, source-ipv6-network,
          and fragment</c>

          <c>tcp</c>

          <c>flags-bitmask, fragment</td>
            </tr>
            <tr>
              <td align="left">tcp</td>
              <td align="left">flags-bitmask, source-port-range-or-operator, and
          destination-port-range-or-operator</c>

          <c>udp</c>

          <c>length,
          destination-port-range-or-operator</td>
            </tr>
            <tr>
              <td align="left">udp</td>
              <td align="left">length, source-port-range-or-operator, and
          destination-port-range-or-operator</c>

          <c>icmp</c>

          <c>type and code</c>
        </texttable>
          destination-port-range-or-operator</td>
            </tr>
            <tr>
              <td align="left">icmp</td>
              <td align="left">type and code</td>
            </tr>
          </tbody>
        </table>
        <t>Implementations MAY <bcp14>MAY</bcp14> support other filtering match fields and
        actions. The 'ietf-dots-data-channel' YANG module provides a method for an
        implementation to expose its filtering capabilities. The tree
        structure of the 'capabilities' is shown in <xref
        target="tcap"></xref>. target="tcap" format="default"/>.
        DOTS clients that support both 'fragment' and
        'flags' (or 'flags-bitmask' and 'flags') matching fields MUST NOT <bcp14>MUST NOT</bcp14> set
        these fields in the same request.</t>

        <t><figure anchor="tcap" title="Filtering
        <figure anchor="tcap">
          <name>Filtering Capabilities Subtree">
            <artwork align="left"><![CDATA[module: Subtree</name>
          <sourcecode type="yangtree"><![CDATA[
module: ietf-dots-data-channel
  +--rw dots-data
     ...
     +--ro capabilities
        +--ro address-family*        enumeration
        +--ro forwarding-actions*    identityref
        +--ro rate-limit?            boolean
        +--ro transport-protocols*   uint8
        +--ro ipv4
        |  +--ro dscp?                 boolean
        |  +--ro ecn?                  boolean
        |  +--ro length?               boolean
        |  +--ro ttl?                  boolean
        |  +--ro protocol?             boolean
        |  +--ro ihl?                  boolean
        |  +--ro flags?                boolean
        |  +--ro offset?               boolean
        |  +--ro identification?       boolean
        |  +--ro source-prefix?        boolean
        |  +--ro destination-prefix?   boolean
        |  +--ro fragment?             boolean
        +--ro ipv6
        |  +--ro dscp?                 boolean
        |  +--ro ecn?                  boolean
        |  +--ro length?               boolean
        |  +--ro hoplimit?             boolean
        |  +--ro protocol?             boolean
        |  +--ro destination-prefix?   boolean
        |  +--ro source-prefix?        boolean
        |  +--ro flow-label?           boolean
        |  +--ro fragment?             boolean
        +--ro tcp
        |  +--ro sequence-number?          boolean
        |  +--ro acknowledgement-number?   boolean
        |  +--ro data-offset?              boolean
        |  +--ro reserved?                 boolean
        |  +--ro flags?                    boolean
        |  +--ro window-size?              boolean
        |  +--ro urgent-pointer?           boolean
        |  +--ro options?                  boolean
        |  +--ro flags-bitmask?            boolean
        |  +--ro source-port?              boolean
        |  +--ro destination-port?         boolean
        |  +--ro port-range?               boolean
        +--ro udp
        |  +--ro length?             boolean
        |  +--ro source-port?        boolean
        |  +--ro destination-port?   boolean
        |  +--ro port-range?         boolean
        +--ro icmp
           +--ro type?             boolean
           +--ro code?             boolean
           +--ro rest-of-header?   boolean
]]></artwork>
          </figure></t>

        <t></t>
]]></sourcecode>
        </figure>
        <t/>
      </section>
      <section title="YANG Module"> numbered="true" toc="default">
        <name>YANG Module</name>
        <t>This module uses the common YANG types defined in <xref
        target="RFC6991"></xref> target="RFC6991" format="default"/> and types defined in <xref
        target="RFC8519"></xref>. <figure>
            <artwork><![CDATA[<CODE BEGINS> file "ietf-dots-data-channel@2019-05-09.yang" target="RFC8519" format="default"/>. </t>

        <sourcecode name="ietf-dots-data-channel@2020-05-28.yang" type="yang" markers="true"><![CDATA[
module ietf-dots-data-channel {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-dots-data-channel";
  prefix data-channel;

  import ietf-inet-types {
    prefix inet;
    reference
      "Section 4 of RFC 6991";
  }
  import ietf-access-control-list {
    prefix ietf-acl;
    reference
      "RFC 8519: YANG Data Model for Network Access
                 Control Lists (ACLs)";
  }
  import ietf-packet-fields {
    prefix packet-fields;
    reference
      "RFC 8519: YANG Data Model for Network Access
                 Control Lists (ACLs)";
  }

  organization
    "IETF DDoS Open Threat Signaling (DOTS) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/dots/>
     WG List:  <mailto:dots@ietf.org>

     Editor:  Mohamed Boucadair
              <mailto:mohamed.boucadair@orange.com>

     Editor:  Konda, Tirumaleswar Reddy Reddy.K
              <mailto:TirumaleswarReddy_Konda@McAfee.com>

     Author:  Jon Shallow
              <mailto:jon.shallow@nccgroup.com>

     Author:  Kaname Nishizuka
              <mailto:kaname@nttv6.jp>

     Author:  Liang Xia
              <mailto:frank.xialiang@huawei.com>

     Author:  Prashanth Patil
              <mailto:praspati@cisco.com>

     Author:  Andrew Mortensen
              <mailto:amortensen@arbor.net>

     Author:  Nik Teague
              <mailto:nteague@verisign.com>";
              <mailto:nteague@ironmountain.co.uk>";
  description
    "This module contains YANG definition for configuring
     aliases for resources and filtering rules using DOTS
     data channel.

     Copyright (c) 2019 2020 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; 8783; see
     the RFC itself for full legal notices.";

  revision 2019-05-09 2020-05-28 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: 8783: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Data Channel Specification";
  }

  typedef activation-type {
    type enumeration {
      enum "activate-when-mitigating" activate-when-mitigating {
        value 1;
        description
          "The Access Control List (ACL) is installed only when
           a mitigation is active for the DOTS client.";
      }
      enum "immediate" immediate {
        value 2;
        description
          "The ACL is immediately activated.";
      }
      enum "deactivate" deactivate {
        value 3;
        description
          "The ACL is maintained by the DOTS server, but it is
           deactivated.";
      }
    }
    description
      "Indicates the activation type of an ACL.";
  }

  typedef operator {
    type bits {
      bit not {
        position 0;
        description
          "If set, logical negation of operation.";
      }
      bit match {
        position 1;
        description
          "Match bit.  This is a bitwise match operation
           defined as '(data & value) == value'.";
      }
      bit any {
        position 3;
        description
          "Any bit.  This is a match on any of the bits in
           bitmask.  It evaluates to 'true' if any of the bits
           in the value mask are set in the data,
           i.e., '(data & value) != 0'.";
      }
    }
    description
      "Specifies how to apply the defined bitmask."; bitmask.
       'any' and 'match' bits must not be set simultaneously.";
  }

  grouping tcp-flags {
    leaf operator {
      type operator;
      default "match";
      description
        "Specifies how to interpret the TCP flags.";
    }
    leaf bitmask {
      type uint16;
      mandatory true;
      description
        "The bitmask matches the last 4 bits of byte 12
         and byte 13 of the TCP header.  For clarity, the 4 bits
         of byte 12 corresponding to the TCP data offset field
         are not included in any matching.";
    }
    description
      "Operations on TCP flags.";
  }

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment bit for IPv4.
           Must be set to 0 when it appears in an IPv6 filter.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description
      "Different fragment types to match against.";
  }

  grouping target {
    description
      "Specifies the targets of the mitigation request.";
    leaf-list target-prefix {
      type inet:ip-prefix;
      description
        "IPv4 or IPv6 prefix identifying the target.";
    }
    list target-port-range {
      key "lower-port";
      description
        "Port range.  When only lower-port is
         present, it represents a single port number.";
      leaf lower-port {
        type inet:port-number;
        mandatory true;
        description
          "Lower port number of the port range.";
      }
      leaf upper-port {
        type inet:port-number;
        must '. >= ../lower-port' {
          error-message
            "The upper port upper-port number must be greater than
             or equal to the lower-port number.";
        }
        description
          "Upper port number of the port range.";
      }
    }
    leaf-list target-protocol {
      type uint8;
      description
        "Identifies the target protocol number.

         Values are taken from the IANA protocol registry:
         https://www.iana.org/assignments/protocol-numbers/
         protocol-numbers.xhtml

         For example, 6 for TCP or 17 for UDP.";
    }
    leaf-list target-fqdn {
      type inet:domain-name;
      description
        "FQDN identifying the target.";
    }
    leaf-list target-uri {
      type inet:uri;
      description
        "URI identifying the target.";
    }
  }

  grouping fragment-fields {
    leaf operator {
      type operator;
      default "match";
      description
        "Specifies how to interpret the fragment type.";
    }
    leaf type {
      type fragment-type;
      mandatory true;
      description
        "Indicates what fragment type to look for.";
    }
    description
      "Operations on fragment types.";
  }

  grouping aliases {
    description
      "Top level
      "Top-level container for aliases.";
    list alias {
      key "name";
      description
        "List of aliases.";
      leaf name {
        type string;
        description
          "The name of the alias.";
      }
      uses target;
      leaf pending-lifetime {
        type int32;
        units "minutes";
        config false;
        description
          "Indicates the pending validity lifetime of the alias
           entry.";
      }
    }
  }

  grouping ports {
    choice source-port {
      container source-port-range-or-operator {
        uses packet-fields:port-range-or-operator;
        description
          "Source port definition.";
      }
      description
        "Choice of specifying the source port or referring to
         a group of source port numbers.";
    }
    choice destination-port {
      container destination-port-range-or-operator {
        uses packet-fields:port-range-or-operator;
        description
          "Destination port definition.";
      }
      description
        "Choice of specifying a destination port or referring
         to a group of destination port numbers.";
    }
    description
      "Choice of specifying a source or destination port numbers.";
  }

  grouping access-lists {
    description
      "Specifies the ordered set of Access Control Lists.";
    list acl {
      key "name";
      ordered-by user;
      description
        "An ACL is an ordered list of Access Control Entries (ACE).
         Each ACE has a list of match criteria and a list of
         actions.";
      leaf name {
        type string {
          length "1..64";
        }
        description
          "The name of the access list.";
        reference
          "RFC 8519: YANG Data Model for Network Access
                     Control Lists (ACLs)";
      }
      leaf type {
        type ietf-acl:acl-type;
        description
          "Type of access control list.  Indicates the primary
           intended type of match criteria (e.g., IPv4, IPv6)
           used in the list instance.";
        reference
          "RFC 8519: YANG Data Model for Network Access
                     Control Lists (ACLs)";
      }
      leaf activation-type {
        type activation-type;
        default "activate-when-mitigating";
        description
          "Indicates the activation type of an ACL.  An ACL can be
           deactivated, installed immediately, or installed when
           a mitigation is active.";
      }
      leaf pending-lifetime {
        type int32;
        units "minutes";
        config false;
        description
          "Indicates the pending validity lifetime of the ACL
           entry.";
      }
      container aces {
        description
          "The Access Control Entries container contains
           a list of ACEs.";
        list ace {
          key "name";
          ordered-by user;
          description
            "List of access list entries.";
          leaf name {
            type string {
              length "1..64";
            }
            description
              "A unique name identifying this ACE.";
            reference
              "RFC 8519: YANG Data Model for Network Access
                         Control Lists (ACLs)";
          }
          container matches {
            description
              "The rules in this set determine what fields will be
               matched upon before any action is taken on them.

               If no matches are defined in a particular container,
               then any packet will match that container.

               If no matches are specified at all in an ACE, then any
               packet will match the ACE.";
            reference
              "RFC 8519: YANG Data Model for Network Access
                         Control Lists (ACLs)";
            choice l3 {
              container ipv4 {
                when "derived-from(../../../../type, "
                   + "'ietf-acl:ipv4-acl-type')";
                uses packet-fields:acl-ip-header-fields;
                uses packet-fields:acl-ipv4-header-fields;
                container fragment {
                  description
                    "Indicates how to handle IPv4 fragments.";
                  uses fragment-fields;
                }
                description
                  "Rule set that matches IPv4 header.";
              }
              container ipv6 {
                when "derived-from(../../../../type, "
                   + "'ietf-acl:ipv6-acl-type')";
                uses packet-fields:acl-ip-header-fields;
                uses packet-fields:acl-ipv6-header-fields;
                container fragment {
                  description
                    "Indicates how to handle IPv6 fragments.";
                  uses fragment-fields;
                }
                description
                  "Rule set that matches IPv6 header.";
              }
              description
                "Either IPv4 or IPv6.";
            }
            choice l4 {
              container tcp {
                uses packet-fields:acl-tcp-header-fields;
                container flags-bitmask {
                  description
                    "Indicates how to handle TCP flags.";
                  uses tcp-flags;
                }
                uses ports;
                description
                  "Rule set that matches TCP header.";
              }
              container udp {
                uses packet-fields:acl-udp-header-fields;
                uses ports;
                description
                  "Rule set that matches UDP header.";
              }
              container icmp {
                uses packet-fields:acl-icmp-header-fields;
                description
                  "Rule set that matches ICMP/ICMPv6 header.";
              }
              description
                "Can be TCP, UDP, or ICMP/ICMPv6";
            }
          }
          container actions {
            description
              "Definitions of action for this ACE.";
            leaf forwarding {
              type identityref {
                base ietf-acl:forwarding-action;
              }
              mandatory true;
              description
                "Specifies the forwarding action per ACE.";
              reference
                "RFC 8519: YANG Data Model for Network Access
                           Control Lists (ACLs)";
            }
            leaf rate-limit {
              when "../forwarding = 'ietf-acl:accept'" {
                description
                  "Rate-limit is valid only when accept action is
                   used.";
              }
              type decimal64 {
                fraction-digits 2;
              }
              units "bytes per second";
              description
                "Specifies how to rate-limit the traffic.";
            }
          }
          container statistics {
            config false;
            description
              "Aggregate statistics.";
            uses ietf-acl:acl-counters;
          }
        }
      }
    }
  }

  container dots-data {
    description
      "Main container for DOTS data channel.";
    list dots-client {
      key "cuid";
      description
        "List of DOTS clients.";
      leaf cuid {
        type string;
        description
          "A unique identifier that is generated by a DOTS client
           to prevent request collisions.";
        reference
          "RFC YYYY: 8782: Distributed Denial-of-Service Open Threat
                  Signaling (DOTS) Signal Channel Specification";
      }
      leaf cdid {
        type string;
        description
          "A client domain identifier conveyed by a
           server-domain DOTS gateway to a remote DOTS server.";
        reference
          "RFC YYYY: 8782: Distributed Denial-of-Service Open Threat
                  Signaling (DOTS) Signal Channel Specification";
      }
      container aliases {
        description
          "Set of aliases that are bound to a DOTS client.";
        uses aliases;
      }
      container acls {
        description
          "Access lists that are bound to a DOTS client.";
        uses access-lists;
      }
    }
    container capabilities {
      config false;
      description
        "Match capabilities";
      leaf-list address-family {
        type enumeration {
          enum "ipv4" ipv4 {
            description
              "IPv4 is supported.";
          }
          enum "ipv6" ipv6 {
            description
              "IPv6 is supported.";
          }
        }
        description
          "Indicates the IP address families supported by
           the DOTS server.";
      }
      leaf-list forwarding-actions {
        type identityref {
          base ietf-acl:forwarding-action;
        }
        description
          "Supported forwarding action(s).";
      }
      leaf rate-limit {
        type boolean;
        description
          "Support of rate-limit action.";
      }
      leaf-list transport-protocols {
        type uint8;
        description
          "Upper-layer protocol associated with a filtering rule.

           Values are taken from the IANA protocol registry:
           https://www.iana.org/assignments/protocol-numbers/
           protocol-numbers.xhtml

           For example, this field contains 1 for ICMP, 6 for TCP
           17 for UDP, or 58 for ICMPv6.";
      }
      container ipv4 {
        description
          "Indicates IPv4 header fields that are supported to enforce
           ACLs.";
        leaf dscp {
          type boolean;
          description
            "Support of filtering based on Differentiated Services
             Code Point (DSCP).";
        }
        leaf ecn {
          type boolean;
          description
            "Support of filtering based on Explicit Congestion
             Notification (ECN).";
        }
        leaf length {
          type boolean;
          description
            "Support of filtering based on the Total Length.";
        }
        leaf ttl {
          type boolean;
          description
            "Support of filtering based on the Time to Live (TTL).";
        }
        leaf protocol {
          type boolean;
          description
            "Support of filtering based on protocol field.";
        }
        leaf ihl {
          type boolean;
          description
            "Support of filtering based on the Internet Header
             Length (IHL).";
        }
        leaf flags {
          type boolean;
          description
            "Support of filtering based on the 'flags'.";
        }
        leaf offset {
          type boolean;
          description
            "Support of filtering based on the 'offset'.";
        }
        leaf identification {
          type boolean;
          description
            "Support of filtering based on the 'identification'.";
        }
        leaf source-prefix {
          type boolean;
          description
            "Support of filtering based on the source prefix.";
        }
        leaf destination-prefix {
          type boolean;
          description
            "Support of filtering based on the destination prefix.";
        }
        leaf fragment {
          type boolean;
          description
            "Indicates the capability of a DOTS server to
             enforce filters on IPv4 fragments.  That is, the match
             functionality based on the Layer 3 'fragment' clause
             is supported.";
        }
      }
      container ipv6 {
        description
          "Indicates IPv6 header fields that are supported to enforce
           ACLs.";
        leaf dscp {
          type boolean;
          description
            "Support of filtering based on DSCP.";
        }
        leaf ecn {
          type boolean;
          description
            "Support of filtering based on ECN.";
        }
        leaf length {
          type boolean;
          description
            "Support of filtering based on the Payload Length.";
        }
        leaf hoplimit {
          type boolean;
          description
            "Support of filtering based on the Hop Limit.";
        }
        leaf protocol {
          type boolean;
          description
            "Support of filtering based on the Next Header field.";
        }
        leaf destination-prefix {
          type boolean;
          description
            "Support of filtering based on the destination prefix.";
        }
        leaf source-prefix {
          type boolean;
          description
            "Support of filtering based on the source prefix.";
        }
        leaf flow-label {
          type boolean;
          description
            "Support of filtering based on the Flow label."; Label.";
        }
        leaf fragment {
          type boolean;
          description
            "Indicates the capability of a DOTS server to
             enforce filters on IPv6 fragments.";
        }
      }
      container tcp {
        description
          "Set of TCP fields that are supported by the DOTS server
           to enforce filters.";
        leaf sequence-number {
          type boolean;
          description
            "Support of filtering based on the TCP sequence number.";
        }
        leaf acknowledgement-number {
          type boolean;
          description
            "Support of filtering based on the TCP acknowledgement
             number.";
        }
        leaf data-offset {
          type boolean;
          description
            "Support of filtering based on the TCP data-offset.";
        }
        leaf reserved {
          type boolean;
          description
            "Support of filtering based on the TCP reserved field.";
        }
        leaf flags {
          type boolean;
          description
            "Support of filtering, as defined in RFC 8519, based
             on the TCP flags.";
        }
        leaf window-size {
          type boolean;
          description
            "Support of filtering based on the TCP window size.";
        }
        leaf urgent-pointer {
          type boolean;
          description
            "Support of filtering based on the TCP urgent pointer.";
        }
        leaf options {
          type boolean;
          description
            "Support of filtering based on the TCP options.";
        }
        leaf flags-bitmask {
          type boolean;
          description
            "Support of filtering based on the TCP flags bitmask.";
        }
        leaf source-port {
          type boolean;
          description
            "Support of filtering based on the source port number.";
        }
        leaf destination-port {
          type boolean;
          description
            "Support of filtering based on the destination port
             number.";
        }
        leaf port-range {
          type boolean;
          description
            "Support of filtering based on a port range.

             This includes filtering based on a source port range,
             destination port range, or both.  All operators
             (i.e, less than or equal to, greater than or equal to,
             equal to, and not equal to) are supported."; supported.

             In particular, this means that the implementation
             supports filtering based on
             source-port-range-or-operator and
             destination-port-range-or-operator.";
        }
      }
      container udp {
        description
          "Set of UDP fields that are supported by the DOTS server
           to enforce filters.";
        leaf length {
          type boolean;
          description
            "Support of filtering based on the UDP length.";
        }
        leaf source-port {
          type boolean;
          description
            "Support of filtering based on the source port number.";
        }
        leaf destination-port {
          type boolean;
          description
            "Support of filtering based on the destination port
             number.";
        }
        leaf port-range {
          type boolean;
          description
            "Support of filtering based on a port range.

             This includes filtering based on a source port range,
             destination port range, or both.  All operators
             (i.e, less than or equal, greater than or equal,
             equal to, and not equal to) are supported."; supported.

             In particular, this means that the implementation
             supports filtering based on
             source-port-range-or-operator and
             destination-port-range-or-operator.";
        }
      }
      container icmp {
        description
          "Set of ICMP/ICMPv6 fields that are supported by the DOTS
           server to enforce filters.";
        leaf type {
          type boolean;
          description
            "Support of filtering based on the ICMP/ICMPv6 type.";
        }
        leaf code {
          type boolean;
          description
            "Support of filtering based on the ICMP/ICMPv6 code.";
        }
        leaf rest-of-header {
          type boolean;
          description
            "Support of filtering based on the ICMP four-bytes four-byte
             field / the ICMPv6 message body.";
        }
      }
    }
  }
}
<CODE ENDS>
]]></artwork>
          </figure></t>
]]></sourcecode>
      </section>
    </section>
    <section anchor="registering" title="Managing numbered="true" toc="default">
      <name>Managing DOTS Clients"> Clients</name>
      <section anchor="registe" title="Registering numbered="true" toc="default">
        <name>Registering DOTS Clients"> Clients</name>
        <t>In order to make use of the DOTS data channel, a DOTS client MUST <bcp14>MUST</bcp14>
        register to with its DOTS server(s) by creating a DOTS client
        ('dots-client') resource. To that aim, DOTS clients SHOULD <bcp14>SHOULD</bcp14> send a POST
        request (shown in <xref target="register"></xref>).</t>

        <t><figure anchor="register" title="POST target="register" format="default"/>).</t>
        <figure anchor="register">
          <name>POST to Register Schema">
            <artwork align="left"><![CDATA[ Schema</name>
          <sourcecode type=""><![CDATA[
 POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1
 Host: {host}:{port}
 Content-Type: application/yang-data+json

 {
   "ietf-dots-data-channel:dots-client": [
     {
       "cuid": "string"
     }
   ]
 }]]></artwork>
          </figure></t>
 }]]></sourcecode>
        </figure>
        <t>The 'cuid' (client unique identifier) parameter is described
        below:<list style="hanging">
            <t hangText="cuid:">A
        below:</t>
        <dl newline="false" spacing="normal">
          <dt>cuid:</dt>
          <dd>
            <t>A globally unique identifier that is meant to
            prevent collisions among DOTS clients. This attribute has the same
            meaning, syntax, and processing rules as the 'cuid' attribute
            defined in <xref
            target="I-D.ietf-dots-signal-channel"></xref>.<vspace
            blankLines="1" />DOTS target="RFC8782" format="default"/>.</t>
            <t>DOTS clients MUST <bcp14>MUST</bcp14> use the same 'cuid' for both
            signal and data channels.<vspace blankLines="1" />This channels.</t>
            <t>This is a
            mandatory attribute.</t>
          </list></t>
          </dd>
        </dl>
        <t>In deployments where server-domain DOTS gateways are enabled,
        identity information about the origin source client domain SHOULD <bcp14>SHOULD</bcp14> be
        supplied to the DOTS server. That information is meant to assist the
        DOTS server to enforce some policies. These policies can be enforced
        per-client, per-client
        per client, per client domain, or both. <xref
        target="register-relayed"></xref> target="register-relayed" format="default"/>
shows a schema example of a register request relayed by a server-domain DOTS gateway.<figure
            anchor="register-relayed"
            title="POST
   gateway.</t>
        <figure anchor="register-relayed">
          <name>POST to Register Schema (via a Server-Domain DOTS Gateway)">
            <artwork align="left"><![CDATA[ Gateway)</name>
          <sourcecode type=""><![CDATA[
 POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1
 Host: {host}:{port}
 Content-Type: application/yang-data+json

 {
   "ietf-dots-data-channel:dots-client": [
     {
       "cuid": "string",
       "cdid": "string"
     }
   ]
 }]]></artwork>
          </figure>A
 }
]]></sourcecode>
        </figure>
        <t>A server-domain DOTS gateway SHOULD <bcp14>SHOULD</bcp14> add the following
        attribute:</t>

        <t><list style="hanging">
            <t hangText="cdid:">This
        <dl newline="false" spacing="normal">
          <dt>cdid:</dt>
          <dd>
            <t>This attribute has the same meaning, syntax,
            and processing rules as the 'cdid' attribute defined in
            <xref
            target="I-D.ietf-dots-signal-channel"></xref>. <vspace
            blankLines="1" /> target="RFC8782" format="default"/>. </t>
            <t> In deployments where server-domain DOTS gateways
            are enabled, 'cdid' does not need to be inserted when relaying
            DOTS methods to manage aliases (<xref target="identifier"></xref>) target="identifier" format="default"/>)
            or filtering rules (<xref target="filter"></xref>). target="filter" format="default"/>). DOTS servers
            are responsible for maintaining the association between 'cdid' and
            'cuid' for policy enforcement purposes.<vspace
            blankLines="1" />This purposes.</t>
            <t>This is an optional attribute.</t>
          </list></t>

        <t>A request
          </dd>
        </dl>
        <t>An example request to create a 'dots-client' resource is depicted in
        <xref target="register-example"></xref>. target="register-example" format="default"/>. This request is relayed by a
        server-domain DOTS gateway as hinted by the presence of the 'cdid'
        attribute.</t>

        <t><figure anchor="register-example"
            title="POST
        <figure anchor="register-example">
          <name>POST to Register (DOTS gateway)">
            <artwork align="left"><![CDATA[ gateway)</name>
          <sourcecode type=""><![CDATA[
 POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1
 Host: example.com
 Content-Type: application/yang-data+json

 {
   "ietf-dots-data-channel:dots-client": [
     {
       "cuid": "dz6pHjaADkaFTbjr0JGBpw",
       "cdid": "7eeaf349529eb55ed50113"
     }
   ]
 }
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>As a reminder, DOTS gateways may rewrite the 'cuid' used by peer
        DOTS clients (Section 4.4.1 of <xref
        target="I-D.ietf-dots-signal-channel"></xref>).</t> (<xref target="RFC8782" section="4.4.1" sectionFormat="of" format="default"/>).</t>
        <t>DOTS servers can identify the DOTS client domain using the 'cdid'
        parameter or using the client's DNS name specified in the Subject
        Alternative Name extension's dNSName type in the client certificate
        <xref target="RFC6125"></xref>.</t> target="RFC6125" format="default"/>.</t>
        <t>DOTS servers MUST <bcp14>MUST</bcp14> limit the number of 'dots-client' resources to be
        created by the same DOTS client to 1 per request. Requests with
        multiple 'dots-client' resources MUST <bcp14>MUST</bcp14> be rejected by DOTS servers. To
        that aim, the DOTS server MUST <bcp14>MUST</bcp14> rely on the same procedure to
        unambiguously identify a DOTS client as discussed in Section 4.4.1 of
        <xref target="I-D.ietf-dots-signal-channel"></xref>.</t> target="RFC8782" section="4.4.1" sectionFormat="of" format="default"/>.</t>
        <t>The DOTS server indicates the result of processing the POST request
        using status-line codes. Status codes in the range "2xx" codes range are
        success, "4xx" codes are some sort of invalid requests and "5xx" codes
        are returned if the DOTS server has erred or is incapable of accepting
        the creation of the 'dots-client' resource. In particular, <list
            style="symbols">
            <t>"201 </t>
        <ul spacing="normal">
          <li>"201 Created" status-line is returned in the response, response if the
            DOTS server has accepted the request.</t>

            <t>"400 request.</li>
          <li>"400 Bad Request" status-line is returned by the DOTS server, server
            if the request does not include a 'cuid' parameter. The error-tag
            "missing-attribute" is used in this case.</t>

            <t>"409 case.</li>
          <li>"409 Conflict" status-line is returned to the requesting DOTS
            client,
            client if the data resource already exists. The error-tag
            "resource-denied" is used in this case.</t>
          </list></t> case.</li>
        </ul>
        <t>Once a DOTS client registers itself to with a DOTS server, it can
        create/delete/retrieve aliases (<xref target="identifier"></xref>) target="identifier" format="default"/>) and
        filtering rules (<xref target="filter"></xref>).</t> target="filter" format="default"/>).</t>
        <t>A DOTS client MAY <bcp14>MAY</bcp14> use the PUT request (Section 4.5 in <xref
        target="RFC8040"></xref>)
        (<xref target="RFC8040" section="4.5" sectionFormat="of" format="default"/>)
        to register a DOTS client within the DOTS
        server. An example is shown in <xref target="putregister"></xref>.</t>

        <t><figure anchor="putregister" title="PUT target="putregister" format="default"/>.</t>
        <figure anchor="putregister">
          <name>PUT to Register">
            <artwork align="center"><![CDATA[ Register</name>
          <sourcecode type=""><![CDATA[
 PUT /restconf/data/ietf-dots-data-channel:dots-data\
     /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
 Host: example.com
 Content-Type: application/yang-data+json

 {
   "ietf-dots-data-channel:dots-client": [
     {
       "cuid": "dz6pHjaADkaFTbjr0JGBpw"
     }
   ]
 }]]></artwork>
          </figure></t>
 }
]]></sourcecode>
        </figure>
        <t>The DOTS gateway that inserted a 'cdid' in a PUT request MUST <bcp14>MUST</bcp14> strip
        the 'cdid' parameter in the corresponding response before forwarding
        the response to the DOTS client.</t>
      </section>
      <section anchor="unregistering" title="Unregistering numbered="true" toc="default">
        <name>De-registering DOTS Clients"> Clients</name>
        <t>A DOTS client de-registers from its DOTS server(s) by deleting the
        'cuid' resource(s). Resources bound to this DOTS client will be
        deleted by the DOTS server. An example of a de-register request is
        shown in <xref target="derigister"></xref>.</t>

        <t><figure align="center" anchor="derigister"
            title="De-register target="derigister" format="default"/>.</t>
        <figure anchor="derigister">
          <name>De-register a DOTS Client">
            <artwork><![CDATA[ Client</name>
          <sourcecode type=""><![CDATA[
 DELETE /restconf/data/ietf-dots-data-channel:dots-data\
        /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
 Host: example.com
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="identifier" title="Managing numbered="true" toc="default">
      <name>Managing DOTS Aliases"> Aliases</name>
      <t>The following sub-sections subsections define the means for a DOTS client to create
      aliases (<xref target="calias"></xref>), target="calias" format="default"/>), to retrieve one or a list of
      aliases (<xref target="ralias"></xref>), target="ralias" format="default"/>), and to delete an alias (<xref
      target="dalias"></xref>).</t> target="dalias" format="default"/>).</t>
      <section anchor="calias" title="Create Aliases"> numbered="true" toc="default">
        <name>Creating Aliases</name>
        <t>A POST or PUT request is used by a DOTS client to create aliases, aliases
        for resources for which a mitigation may be requested. Such aliases
        may be used in subsequent DOTS signal channel exchanges to refer more
        efficiently to the resources under attack.</t>
        <t>DOTS clients within the same domain can create different aliases
        for the same resource.</t>
        <t>The structure of POST requests used to create aliases is shown in
        <xref target="createalias"></xref>.</t>

        <t><figure anchor="createalias"
            title="POST target="createalias" format="default"/>.</t>
        <figure anchor="createalias">
          <name>POST to Create Aliases (Request Schema)">
            <artwork align="left"><![CDATA[ Schema)</name>
          <sourcecode type=""><![CDATA[
 POST /restconf/data/ietf-dots-data-channel:dots-data\
      /dots-client=cuid HTTP/1.1
 Host: {host}:{port}
 Content-Type: application/yang-data+json

 {
  "ietf-dots-data-channel:aliases": {
    "alias": [
      {
        "name": "string",
        "target-prefix": [
          "string"
        ],
        "target-port-range": [
          {
            "lower-port": integer,
            "upper-port": integer
          }
        ],
        "target-protocol": [
          integer
        ],
        "target-fqdn": [
          "string"
        ],
        "target-uri": [
          "string"
        ]
      }
    ]
  }
}]]></artwork>
          </figure></t>
}
]]></sourcecode>
        </figure>
        <t>The parameters are described below:</t>

        <t><list style="hanging">
            <t hangText="name:">Name
        <dl newline="false" spacing="normal">
          <dt>name:</dt>
          <dd>
            <t>Name of the alias. <vspace
            blankLines="1" />This </t>
            <t>This is a mandatory attribute.</t>

            <t hangText="target-prefix: ">Prefixes
          </dd>
          <dt>target-prefix: </dt>
          <dd>
            <t>Prefixes are separated by commas.
            Prefixes are represented using Classless Inter-domain Routing
            (CIDR) notation <xref target="RFC4632"></xref>. target="RFC4632" format="default"/>. As a reminder, the
            prefix length must be less than or equal to 32 (resp. 128) for
            IPv4 (resp. IPv6).<vspace blankLines="1" />The or 128 for IPv6.</t>
            <t>The prefix list MUST
            NOT <bcp14>MUST
            NOT</bcp14> include broadcast, loopback, or multicast addresses. These
            addresses are considered as invalid values. In addition, the DOTS
            server MUST <bcp14>MUST</bcp14> validate that these prefixes are within the scope of
            the DOTS client domain. Other validation checks may be supported
            by DOTS servers.<vspace blankLines="1" />This servers.</t>
            <t>This is an optional
            attribute.</t>

            <t hangText="target-port-range: ">A
          </dd>
          <dt>target-port-range: </dt>
          <dd>
            <t>A range of port numbers. <vspace
            blankLines="1" />The </t>
            <t>The port range is defined by two bounds, a lower
            port number (lower-port) ('lower-port') and an upper port number (upper-port). ('upper-port').
            The range is considered to include both the lower and upper
            bounds.<vspace blankLines="1" />When
            bounds.</t>
            <t>When only 'lower-port' is present,
            it represents a single port number. <vspace blankLines="1" />For </t>
            <t>For TCP, UDP, Stream Control Transmission Protocol (SCTP) <xref
            target="RFC4960"></xref>, target="RFC4960" format="default"/>,
            or Datagram Congestion Control Protocol (DCCP) <xref target="RFC4340"></xref>, target="RFC4340" format="default"/>,
            the range of port numbers can be, for example, 1024-65535. <vspace blankLines="1" />This </t>
            <t>This is an optional attribute.</t>

            <t hangText="target-protocol: ">A
          </dd>
          <dt>target-protocol: </dt>
          <dd>
            <t>A list of protocols. Values are
            taken from the IANA protocol registry <xref
            target="proto_numbers"></xref>. <vspace blankLines="1" />If target="IANA-PROTO" format="default"/>. </t>
            <t>If
            'target-protocol' is not specified, then the request applies to
            any protocol. <vspace blankLines="1" />This </t>
            <t>This is an optional
            attribute.</t>

            <t hangText="target-fqdn: ">A
          </dd>
          <dt>target-fqdn: </dt>
          <dd>
            <t>A list of Fully Qualified Domain Names
            (FQDNs) identifying resources under attack <xref
            target="RFC8499"></xref>.<vspace blankLines="1" />How target="RFC8499" format="default"/>.</t>
            <t>How a name is
            passed to an underlying name resolution library is implementation-
	    implementation and deployment-specific. deployment specific. Nevertheless, once the name is resolved
            into one or multiple IP addresses, DOTS servers MUST <bcp14>MUST</bcp14> apply the
            same validation checks as those for 'target-prefix'.<vspace
            blankLines="1" />The 'target-prefix'.</t>
            <t>The use of FQDNs may be suboptimal because it
            does not guarantee that the DOTS server will resolve a name to the
            same IP addresses that the DOTS client does.<vspace
            blankLines="1" />This does.</t>
            <t>This is an optional attribute.</t>

            <t hangText="target-uri: ">A
          </dd>
          <dt>target-uri: </dt>
          <dd>
            <t>A list of Uniform Resource Identifiers
            (URIs) <xref target="RFC3986"></xref>. <vspace
            blankLines="1" />The target="RFC3986" format="default"/>. </t>
            <t>The same validation checks used for 'target-fqdn'
            MUST
            <bcp14>MUST</bcp14> be followed by DOTS servers to validate a target URI. <vspace
            blankLines="1" />This </t>
            <t>This is an optional attribute.</t>
          </list></t>
          </dd>
        </dl>
        <t>In POST or PUT requests, at least one of the 'target-prefix',
        'target-fqdn', or 'target-uri' attributes MUST <bcp14>MUST</bcp14> be present. DOTS agents
        can safely ignore Vendor-Specific vendor-specific parameters they don't
        understand.</t>
        <t>If more than one 'target-*' scope types (e.g., 'target-prefix' and
        'target-fqdn' or 'target-fqdn' and 'target-uri') are included in a
        POST or PUT request, the DOTS server binds all resulting IP
        addresses/prefixes to the same resource.</t>
        <t><xref target="Figure2"></xref> target="Figure2" format="default"/> shows a POST request to create an
        alias called "https1" for HTTPS servers with IP addresses
        2001:db8:6401::1 and 2001:db8:6401::2 listening on TCP port number
        443.</t>

        <t><figure anchor="Figure2"
            title="Example
        <figure anchor="Figure2">
          <name>Example of a POST to Create an Alias">
            <artwork align="left"><![CDATA[POST Alias</name>
          <sourcecode type=""><![CDATA[
POST /restconf/data/ietf-dots-data-channel:dots-data\
     /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: www.example.com example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:aliases": {
    "alias": [
      {
        "name": "https1",
        "target-protocol": [
          6
        ],
        "target-prefix": [
          "2001:db8:6401::1/128",
          "2001:db8:6401::2/128"
        ],
        "target-port-range": [
          {
            "lower-port": 443
          }
        ]
      }
    ]
  }
}]]></artwork>
          </figure></t>

        <t>"201
}
]]></sourcecode>
        </figure>
        <t>A "201 Created" status-line MUST <bcp14>MUST</bcp14> be returned in the response if the
        DOTS server has accepted the alias.</t>

        <t>"409
        <t>A "409 Conflict" status-line MUST <bcp14>MUST</bcp14> be returned to the requesting DOTS
        client, if the request is conflicting with an existing alias name. The
        error-tag "resource-denied" is used in this case.</t>
        <t>If the request is missing a mandatory attribute or it contains an
        invalid or unknown parameter, a "400 Bad Request" status-line MUST <bcp14>MUST</bcp14> be
        returned by the DOTS server. The error-tag is set to
        "missing-attribute", "invalid-value", or "unknown-element" as a
        function of the encountered error.</t>
        <t>If the request is received via a server-domain DOTS gateway, but
        the DOTS server does not maintain a 'cdid' for this 'cuid' while a
        'cdid' is expected to be supplied, the DOTS server MUST <bcp14>MUST</bcp14> reply with
        a "403 Forbidden" status-line and the error-tag "access-denied". Upon
        receipt of this message, the DOTS client MUST <bcp14>MUST</bcp14> register (<xref
        target="registering"></xref>).</t> target="registering" format="default"/>).</t>
        <t>A DOTS client uses the PUT request to modify the aliases in the
        DOTS server. In particular, a DOTS client MUST <bcp14>MUST</bcp14> update its alias
        entries upon change of the prefix indicated in the
        'target-prefix'.</t>
        <t>A DOTS server MUST <bcp14>MUST</bcp14> maintain an alias for at least 10080 minutes (1
        week). If no refresh request is seen from the DOTS client, the DOTS
        server removes expired entries.</t>
      </section>
      <section anchor="ralias" title="Retrieve numbered="true" toc="default">
        <name>Retrieving Installed Aliases"> Aliases</name>
        <t>A GET request is used to retrieve one or all installed aliases by a
        DOTS client from a DOTS server (Section 3.3.1 in <xref
        target="RFC8040"></xref>). (<xref target="RFC8040" section="3.3.1" sectionFormat="of" format="default"/>). If no 'name' is included in the request,
        this is an indication indicates that the request is about retrieving all aliases
        instantiated by the DOTS client.</t>
        <t><xref target="Figure4"></xref> target="Figure4" format="default"/> shows an example to retrieve all the
        aliases that were instantiated by the requesting DOTS client. The
        "content" query parameter and its permitted values are defined in
        Section 4.8.1 of
        <xref target="RFC8040"></xref>.</t> target="RFC8040" section="4.8.1" sectionFormat="of" format="default"/>.</t>
        <figure anchor="Figure4" title="GET anchor="Figure4">
          <name>GET to Retrieve All Installed Aliases">
          <artwork align="left"><![CDATA[ Aliases</name>
          <sourcecode type=""><![CDATA[
  GET /restconf/data/ietf-dots-data-channel:dots-data\
      /dots-client=dz6pHjaADkaFTbjr0JGBpw\
      /aliases?content=all HTTP/1.1
  Host: example.com
  Accept: application/yang-data+json
]]></artwork>
]]></sourcecode>
        </figure>

        <t></t>
        <t><xref target="Figure6"></xref> target="Figure6" format="default"/> shows an example of the response
        message body that includes all the aliases that are maintained by the
        DOTS server for the DOTS client identified by the 'cuid'
        parameter.</t>

        <t><figure anchor="Figure6"
            title="An
        <figure anchor="Figure6">
          <name>An Example of a Response Body Listing All Installed Aliases">
            <artwork align="left"><![CDATA[{ Aliases</name>
          <sourcecode type=""><![CDATA[
{
  "ietf-dots-data-channel:aliases": {
    "alias": [
      {
        "name": "Server1",
        "target-protocol": [
          6
        ],
        "target-prefix": [
          "2001:db8:6401::1/128",
          "2001:db8:6401::2/128"
        ],
        "target-port-range": [
          {
            "lower-port": 443
          }
        ],
        "pending-lifetime": 3596
      },
      {
        "name": "Server2",
        "target-protocol": [
          6
        ],
        "target-prefix": [
          "2001:db8:6401::10/128",
          "2001:db8:6401::20/128"
        ],
        "target-port-range": [
          {
            "lower-port": 80
          }
        ],
        "pending-lifetime": 9869
      }
    ]
  }
}]]></artwork>
          </figure></t>
}
]]></sourcecode>
        </figure>
        <t><xref target="analias"></xref> target="analias" format="default"/> shows an example of a GET request to
        retrieve the alias "Server2" that was instantiated by the DOTS client.
        </t>
        <figure anchor="analias" title="GET anchor="analias">
          <name>GET to Retrieve an Alias">
            <artwork align="left"><![CDATA[ Alias</name>
          <sourcecode type=""><![CDATA[
  GET /restconf/data/ietf-dots-data-channel:dots-data\
      /dots-client=dz6pHjaADkaFTbjr0JGBpw\
      /aliases/alias=Server2?content=all HTTP/1.1
  Host: example.com
  Accept: application/yang-data+json]]></artwork>
          </figure></t> application/yang-data+json
]]></sourcecode>
        </figure>
        <t>If an alias name ('name') is included in the request, but the DOTS
        server does not find that alias name for this DOTS client in its
        configuration data, it MUST <bcp14>MUST</bcp14> respond with a "404 Not Found"
        status-line.</t>
      </section>
      <section anchor="dalias" title="Delete Aliases"> numbered="true" toc="default">
        <name>Deleting Aliases</name>
        <t>A DELETE request is used to delete an alias maintained by a DOTS
        server.</t>
        <t>If the DOTS server does not find the alias name, name that was conveyed in the
        DELETE request, request in its configuration data for this DOTS client, it
        MUST
        <bcp14>MUST</bcp14> respond with a "404 Not Found" status-line.</t>
        <t>The DOTS server successfully acknowledges a DOTS client's request
        to remove the alias using "204 No Content" status-line in the
        response.</t>
        <t><xref target="Figure3"></xref> target="Figure3" format="default"/> shows an example of a request to
        delete an alias.</t>

        <t><figure anchor="Figure3" title="Delete
        <figure anchor="Figure3">
          <name>Delete an Alias">
            <artwork align="left"><![CDATA[ Alias</name>
          <sourcecode type=""><![CDATA[
  DELETE /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=dz6pHjaADkaFTbjr0JGBpw\
         /aliases/alias=Server1 HTTP/1.1
  Host: example.com]]></artwork>
          </figure></t> example.com
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="filter" title="Managing numbered="true" toc="default">
      <name>Managing DOTS Filtering Rules"> Rules</name>
      <t>The following sub-sections subsections define the means for a DOTS client to retrieve
      DOTS filtering capabilities (<xref target="rcap"></xref>), target="rcap" format="default"/>), to create
      filtering rules (<xref target="install"></xref>), target="install" format="default"/>), to retrieve active
      filtering rules (<xref target="rfilter"></xref>), target="rfilter" format="default"/>), and to delete a filtering
      rule (<xref target="dfilter"></xref>).</t> target="dfilter" format="default"/>).</t>
      <section anchor="rcap" title="Retrieve numbered="true" toc="default">
        <name>Retrieving DOTS Filtering Capabilities"> Capabilities</name>
        <t>A DOTS client MAY <bcp14>MAY</bcp14> send a GET request to retrieve the filtering
        capabilities supported by a DOTS server. <xref target="cap"></xref> target="cap" format="default"/>
        shows an example of such request.</t>

        <t><figure anchor="cap"
            title="GET
        <figure anchor="cap">
          <name>GET to Retrieve the Capabilities of a DOTS Server">
            <artwork align="left"><![CDATA[ Server</name>
          <sourcecode type=""><![CDATA[
  GET /restconf/data/ietf-dots-data-channel:dots-data\
      /capabilities HTTP/1.1
  Host: example.com
  Accept: application/yang-data+json
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>A DOTS client client, which issued a GET request to retrieve the filtering
        capabilities supported by its DOTS server, SHOULD NOT <bcp14>SHOULD NOT</bcp14> request for
        filtering actions that are not supported by that DOTS server.</t>
        <t><xref target="capex"></xref> target="capex" format="default"/> shows an example of a response body
        received from a DOTS server which supports:<list style="symbols">
            <t>IPv4, supports:</t>
        <ul spacing="normal">
          <li>IPv4, IPv6, TCP, UDP, ICMP, and ICMPv6 mandatory match criteria
            listed in <xref target="filf"></xref>.</t>

            <t>'accept', target="filf" format="default"/>.</li>
          <li>'accept', 'drop', and 'rate-limit' actions.</t>
          </list></t>

        <t><figure anchor="capex"
            title="Reply actions.</li>
        </ul>
        <figure anchor="capex">
          <name>Reply to a GET Request with Filtering Capabilities (Message Body)">
            <artwork align="left"><![CDATA[ Body)</name>
          <sourcecode type=""><![CDATA[
 {
  "ietf-dots-data-channel:capabilities": {
    "address-family": ["ipv4", "ipv6"],
    "forwarding-actions": ["drop", "accept"],
    "rate-limit": true,
    "transport-protocols": [1, 6, 17, 58],
    "ipv4": {
      "length": true,
      "protocol": true,
      "destination-prefix": true,
      "source-prefix": true,
      "fragment": true
    },
    "ipv6": {
      "length": true,
      "protocol": true,
      "destination-prefix": true,
      "source-prefix": true,
      "fragment": true
    },
    "tcp": {
      "flags-bitmask": true,
      "source-port": true,
      "destination-port": true,
      "port-range": true
    },
    "udp": {
      "length": true,
      "source-port": true,
      "destination-port": true,
      "port-range": true
    },
    "icmp": {
      "type": true,
      "code": true
    }
  }
}]]></artwork>
          </figure></t>
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="install" title="Install numbered="true" toc="default">
        <name>Installing Filtering Rules"> Rules</name>
        <t>A POST or PUT request is used by a DOTS client to communicate
        filtering rules to a DOTS server.</t>
        <t><xref target="Figure7"></xref> target="Figure7" format="default"/> shows an example of a POST request example to
        block traffic from 192.0.2.0/24 and destined to 198.51.100.0/24. Other
        examples are discussed in <xref target="frag"></xref>.</t>

        <t><figure anchor="Figure7" title="POST target="frag" format="default"/>.</t>
        <figure anchor="Figure7">
          <name>POST to Install Filtering Rules">
            <artwork align="left"><![CDATA[ Rules</name>
          <sourcecode type=""><![CDATA[
 POST /restconf/data/ietf-dots-data-channel:dots-data\
      /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
 Host: example.com
 Content-Type: application/yang-data+json

 {
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "sample-ipv4-acl",
        "type": "ipv4-acl-type",
        "activation-type": "activate-when-mitigating",
        "aces": {
          "ace": [
            {
              "name": "rule1",
              "matches": {
                "ipv4": {
                  "destination-ipv4-network": "198.51.100.0/24",
                  "source-ipv4-network": "192.0.2.0/24"
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]
        }
      }
    ]
  }
 }]]></artwork>
          </figure></t>
 }
]]></sourcecode>
        </figure>
        <t>The meaning of these parameters is as follows:</t>

        <t><list style="hanging">
            <t hangText="name:">The
        <dl newline="false" spacing="normal">
          <dt>name:</dt>
          <dd>
            <t>The name of the access list. <vspace
            blankLines="1" />This </t>
            <t>This is a mandatory attribute.</t>

            <t hangText="type:">Indicates
          </dd>
          <dt>type:</dt>
          <dd>
            <t>Indicates the primary intended type of match
            criteria (e.g., IPv4, IPv6). It is set to 'ipv4-acl-type' in the
            example of <xref target="Figure7"></xref>. <vspace
            blankLines="1" />This target="Figure7" format="default"/>. </t>
            <t>This is an optional attribute.</t>

            <t hangText="activation-type:">Indicates
          </dd>
          <dt>activation-type:</dt>
          <dd>
            <t>Indicates whether an ACL has to be
            activated (immediately or during mitigation time) or instantiated
            without being activated (deactivated). Deactivated ACLs can be
            activated using a variety of means means, such as manual configuration on
            a DOTS server or by using the DOTS data channel. <vspace
            blankLines="1" />If </t>
            <t>If this attribute is not provided, the DOTS
            server MUST <bcp14>MUST</bcp14> use 'activate-when-mitigating' as the default
            value.<vspace blankLines="1" />When
            value.</t>
            <t>When a mitigation is in progress,
            the DOTS server MUST <bcp14>MUST</bcp14> only activate 'activate-when-mitigating'
            filters that are bound to the DOTS client that triggered the
            mitigation. <vspace blankLines="1" />This </t>
            <t>This is an optional
            attribute.</t>

            <t hangText="matches:">Define
          </dd>
          <dt>matches:</dt>
          <dd>
            <t>Defines criteria used to identify a flow on
            which to apply the rule. It can be "l3" (IPv4, IPv6) or "l4" (TCP,
            UDP, ..). ICMP). The detailed match parameters are specified in <xref
            target="YANG"></xref>.<vspace blankLines="1" />In target="YANG" format="default"/>.</t>
            <t>In the example
            depicted in <xref target="Figure7"></xref>, target="Figure7" format="default"/>, an IPv4 matching
            criteria is used.<vspace blankLines="1" />This used.</t>
            <t>This is an optional
            attribute.</t>

            <t hangText="destination-ipv4-network:">The
          </dd>
          <dt>destination-ipv4-network:</dt>
          <dd>
            <t>The destination IPv4
            prefix. DOTS servers MUST <bcp14>MUST</bcp14> validate that these prefixes are within
            the scope of the DOTS client domain. Other validation checks may
            be supported by DOTS servers. If this attribute is not provided,
            the DOTS server enforces the ACL on any destination IP address
            that belong belongs to the DOTS client domain. <vspace
            blankLines="1" />This </t>
            <t>This is a mandatory attribute in requests with an
            'activation-type' set to 'immediate'.</t>

            <t hangText="source-ipv4-network:">The
          </dd>
          <dt>source-ipv4-network:</dt>
          <dd>
            <t>The source IPv4 prefix. <vspace
            blankLines="1" />This </t>
            <t>This is an optional attribute.</t>

            <t hangText="actions: ">Actions
          </dd>
          <dt>actions: </dt>
          <dd>
            <t>Actions in the forwarding ACL category can
            be "drop" 'drop' or "accept". 'accept'. The "accept" 'accept' action is used to accept-list
            traffic. The "drop" action is used to drop-list traffic. <vspace
            blankLines="1" />Accepted </t>
            <t>Accepted traffic may be subject to "rate-limit"; 'rate-limit';
            the allowed traffic rate is represented in bytes per second. This
            unit is the same as the one used for "traffic-rate" in <xref
            target="RFC5575"></xref>.<vspace blankLines="1" />This target="RFC5575" format="default"/>.</t>
            <t>This is a
            mandatory attribute.</t>
          </list></t>
          </dd>
        </dl>
        <t>The DOTS server indicates the result of processing the POST request
        using the status-line. Concretely, a "201 Created" status-line MUST <bcp14>MUST</bcp14> be
        returned in the response if the DOTS server has accepted the filtering
        rules. If the request is missing a mandatory attribute or contains an
        invalid or unknown parameter (e.g., a match field not supported by the
        DOTS server), a "400 Bad Request" status-line MUST <bcp14>MUST</bcp14> be returned by the
        DOTS server in the response. The error-tag is set to
        "missing-attribute", "invalid-value", or "unknown-element" as a
        function of the encountered error.</t>
        <t>If the request is received via a server-domain DOTS gateway, but
        the DOTS server does not maintain a 'cdid' for this 'cuid' while a
        'cdid' is expected to be supplied, the DOTS server MUST <bcp14>MUST</bcp14> reply with
        a "403 Forbidden" status-line and the error-tag "access-denied". Upon
        receipt of this message, the DOTS client MUST <bcp14>MUST</bcp14> register (<xref
        target="register"></xref>).</t> target="register" format="default"/>).</t>
        <t>If the request is conflicting with an existing filtering installed
        by another DOTS client of the domain, absent any local policy, the
        DOTS server returns a "409 Conflict" status-line to the requesting DOTS
        client. The error-tag "resource-denied" is used in this case.</t>
        <t>The "insert" query parameter (Section 4.8.5 of <xref
        target="RFC8040"></xref>) MAY (<xref target="RFC8040" section="4.8.5" sectionFormat="of" format="default"/>)
        <bcp14>MAY</bcp14> be used to specify how an access control
        entry is inserted within an ACL and how an ACL is inserted within an
        ACL set.</t>
        <t>The DOTS client uses the PUT request to modify its filtering rules
        maintained by the DOTS server. In particular, a DOTS client MUST <bcp14>MUST</bcp14>
        update its filtering entries upon change of the destination-prefix. destination prefix.
        How such change is detected is out of scope.</t>
        <t>A DOTS server MUST <bcp14>MUST</bcp14> maintain a filtering rule for at least 10080
        minutes (1 week). If no refresh request is seen from the DOTS client,
        the DOTS server removes expired entries. Typically, a refresh request
        is a PUT request which that echoes the content of a response to a GET
        request with all of the read-only parameters stripped out (e.g.,
        pending-lifetime).</t>
        'pending-lifetime').</t>
      </section>
      <section anchor="rfilter" title="Retrieve numbered="true" toc="default">
        <name>Retrieving Installed Filtering Rules  "> Rules</name>
        <t>A DOTS client periodically queries its DOTS server to check the
        counters for installed filtering rules. A GET request is used to
        retrieve filtering rules from a DOTS server. In order to indicate
        which type of data is requested in a GET request, the DOTS client sets
        adequately the "content" query parameter.</t>
        <t>If the DOTS server does not find the access list name conveyed in
        the GET request in its configuration data for this DOTS client, it
        responds with a "404 Not Found" status-line.</t>
        <t>In order to illustrate the intended behavior, consider the example
        depicted in <xref target="PUTv6"></xref>. target="PUTv6" format="default"/>. In reference to this
        example, the DOTS client requests the creation of an immediate ACL
        called "test-acl-ipv6-udp".</t>

        <t><figure anchor="PUTv6"
            title="Example
        <figure anchor="PUTv6">
          <name>Example of a PUT Request to Create a Filtering">
            <artwork align="left"><![CDATA[PUT Filtering</name>
          <sourcecode type=""><![CDATA[
PUT /restconf/data/ietf-dots-data-channel:dots-data\
    /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
    /acl=test-acl-ipv6-udp HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "test-acl-ipv6-udp",
        "type": "ipv6-acl-type",
        "activation-type": "immediate",
        "aces": {
          "ace": [
            {
              "name": "my-test-ace",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8:6401::2/127",
                  "source-ipv6-network": "2001:db8:1234::/96",
                  "protocol": 17,
                  "flow-label": 10000
                },
                "udp": {
                  "source-port":
                  "source-port-range-or-operator": {
                    "operator": "lte",
                    "port": 80
                  },
                  "destination-port":
                  "destination-port-range-or-operator": {
                    "operator": "neq",
                    "port": 1010
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}]]></artwork>
          </figure></t>
}
]]></sourcecode>
        </figure>
        <t>The peer DOTS server follows the procedure specified in
        <xref
        target="install"></xref> target="install" format="default"/> to process the request. We consider in the
        following that a positive response is sent back to the requesting DOTS
        client to confirm that the "test-acl-ipv6-udp" ACL is successfully
        installed by the DOTS server.</t>
        <t>The DOTS client can issue a GET request to retrieve all its
        filtering rules and the number of matches for the installed filtering
        rules as illustrated in <xref target="Get"></xref>. target="Get" format="default"/>. The "content"
        query parameter is set to 'all'. The message body of the response to
        this GET request is shown in <xref target="Getr"></xref>.</t> target="Getr" format="default"/>.</t>
        <figure anchor="Get"
                title="Retrieve anchor="Get">
          <name>Retrieve the Configuration Data and State Data for the Filtering Rules (GET Request)">
          <artwork align="left"><![CDATA[ Request)</name>
          <sourcecode type=""><![CDATA[
  GET /restconf/data/ietf-dots-data-channel:dots-data\
      /dots-client=dz6pHjaADkaFTbjr0JGBpw\
      /acls?content=all HTTP/1.1
  Host: example.com
  Accept: application/yang-data+json
]]></artwork>
]]></sourcecode>
        </figure>

        <t></t>

        <t><figure anchor="Getr"
            title="Retrieve
        <figure anchor="Getr">
          <name>Retrieve the Configuration Data and State Data for the Filtering Rules (Response Message Body)">
            <artwork align="left"><![CDATA[{ Body)</name>
          <sourcecode type=""><![CDATA[
{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "test-acl-ipv6-udp",
        "type": "ipv6-acl-type",
        "activation-type": "immediate",
        "pending-lifetime":9080,
        "aces": {
          "ace": [
            {
              "name": "my-test-ace",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8:6401::2/127",
                  "source-ipv6-network": "2001:db8:1234::/96",
                  "protocol": 17,
                  "flow-label": 10000
                },
                "udp": {
                  "source-port":
                  "source-port-range-or-operator": {
                    "operator": "lte",
                    "port": 80
                  },
                  "destination-port":
                  "destination-port-range-or-operator": {
                    "operator": "neq",
                    "port": 1010
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}]]></artwork>
          </figure></t>
}
]]></sourcecode>
        </figure>
        <t>Also, a DOTS client can issue a GET request to retrieve only
        configuration data related to an ACL as shown in <xref
        target="GEtc"></xref>. target="GEtc" format="default"/>. It does so by setting the "content" query
        parameter to 'config'.</t>

        <t><figure anchor="GEtc"
            title="Retrieve
        <figure anchor="GEtc">
          <name>Retrieve the Configuration Data for a Filtering Rule (GET Request)">
            <artwork align="left"><![CDATA[ Request)</name>
          <sourcecode type=""><![CDATA[
  GET /restconf/data/ietf-dots-data-channel:dots-data\
      /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
      /acl=test-acl-ipv6-udp?content=config HTTP/1.1
  Host: example.com
  Accept: application/yang-data+json]]></artwork>
          </figure></t> application/yang-data+json
]]></sourcecode>
        </figure>
        <t>A response to this GET request is shown in <xref
        target="GEtcr"></xref>.</t>

        <t><figure anchor="GEtcr"
            title="Retrieve target="GEtcr" format="default"/>.</t>
        <figure anchor="GEtcr">
          <name>Retrieve the Configuration Data for a Filtering Rule (Response Message Body)">
            <artwork align="left"><![CDATA[{ Body)</name>
          <sourcecode type=""><![CDATA[
{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "test-acl-ipv6-udp",
        "type": "ipv6-acl-type",
        "activation-type": "immediate",
        "aces": {
          "ace": [
            {
              "name": "my-test-ace",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8:6401::2/127",
                  "source-ipv6-network": "2001:db8:1234::/96",
                  "protocol": 17,
                  "flow-label": 10000
                },
                "udp": {
                  "source-port":
                  "source-port-range-or-operator": {
                    "operator": "lte",
                    "port": 80
                  },
                  "destination-port":
                  "destination-port-range-or-operator": {
                    "operator": "neq",
                    "port": 1010
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}]]></artwork>
          </figure></t>
}
]]></sourcecode>
        </figure>
        <t>A DOTS client can also issue a GET request with a "content" query
        parameter set to 'non-config' to exclusively retrieve
        non-configuration data bound to a given ACL as shown in <xref
        target="GEtnc"></xref>. target="GEtnc" format="default"/>. A response to this GET request is shown in
        <xref target="GEtncr"></xref>.</t>

        <t><figure anchor="GEtnc"
            title="Retrieve target="GEtncr" format="default"/>.</t>
        <figure anchor="GEtnc">
          <name>Retrieve the Non-Configuration Data for a Filtering Rule (GET Request)">
            <artwork align="left"><![CDATA[ Request)</name>
          <sourcecode type=""><![CDATA[
  GET /restconf/data/ietf-dots-data-channel:dots-data\
      /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
      /acl=test-acl-ipv6-udp?content=non-config HTTP/1.1
  Host: example.com
  Accept: application/yang-data+json]]></artwork>
          </figure></t>

        <t><figure anchor="GEtncr"
            title="Retrieve application/yang-data+json
]]></sourcecode>
        </figure>
        <figure anchor="GEtncr">
          <name>Retrieve the Non-Configuration Data for a Filtering Rule (Response Message Body)">
            <artwork align="left"><![CDATA[{ Body)</name>
          <sourcecode type=""><![CDATA[
{
  "ietf-dots-data-channel:acls":  {
    "acl": [
      {
        "name": "test-acl-ipv6-udp",
        "pending-lifetime": 8000,
        "aces": {
          "ace": [
            {
              "name": "my-test-ace"
            }
          ]
        }
      }
    ]
  }
}
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
      </section>
      <section anchor="dfilter" title="Remove numbered="true" toc="default">
        <name>Removing Filtering Rules"> Rules</name>
        <t>A DELETE request is used by a DOTS client to delete filtering rules
        from a DOTS server.</t>
        <t>If the DOTS server does not find the access list name carried in
        the DELETE request in its configuration data for this DOTS client, it
        MUST
        <bcp14>MUST</bcp14> respond with a "404 Not Found" status-line. The DOTS server
        successfully acknowledges a DOTS client's request to withdraw the
        filtering rules using a "204 No Content" status-line, and removes the
        filtering rules accordingly.</t>
        <t><xref target="Figure9"></xref> target="Figure9" format="default"/> shows an example of a request to
        remove the IPv4 ACL "sample-ipv4-acl" created in <xref
        target="install"></xref>.</t> target="install" format="default"/>.</t>
        <figure anchor="Figure9"
                title="Remove anchor="Figure9">
          <name>Remove a Filtering Rule (DELETE Request)">
          <artwork align="left"><![CDATA[ Request)</name>
          <sourcecode type=""><![CDATA[
  DELETE  /restconf/data/ietf-dots-data-channel:dots-data\
          /dots-client=dz6pHjaADkaFTbjr0JGBpw/acls\
          /acl=sample-ipv4-acl HTTP/1.1
  Host: example.com]]></artwork> example.com]]>
</sourcecode>
        </figure>

        <t></t>
        <t/>
        <t><xref target="Figure9a"></xref> target="Figure9a" format="default"/> shows an example of a response
        received from the DOTS server to confirm the deletion of
        "sample-ipv4-acl".</t>

        <t><figure anchor="Figure9a"
            title="Remove
        <figure anchor="Figure9a">
          <name>Remove a Filtering Rule (Response)">
            <artwork align="left"><![CDATA[ (Response)</name>
          <sourcecode type=""><![CDATA[
 HTTP/1.1 204 No Content
 Server: Apache
 Date: Fri, 27 Jul 2018 10:05:15 GMT
 Cache-Control: no-cache
 Content-Type: application/yang-data+json
 Content-Length: 0
 Connection: Keep-Alive]]></artwork>
          </figure></t> Keep-Alive
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="operational" title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>The following operational considerations should be taken into
      account:</t>

      <t><list style="symbols">
          <t>DOTS
      <ul spacing="normal">
        <li>DOTS servers MUST NOT <bcp14>MUST NOT</bcp14> enable both DOTS data channel and direct
          configuration, to avoid race conditions and inconsistent
          configurations arising from simultaneous updates from multiple
          sources.</t>

          <t>DOTS
          sources.</li>
        <li>DOTS agents SHOULD <bcp14>SHOULD</bcp14> enable the DOTS data channel to configure
          aliases and ACLs, and only use direct configuration as a stop-gap
          mechanism to test DOTS signal channel with aliases and ACLs.
          Further, direct configuration SHOULD <bcp14>SHOULD</bcp14> only be used when the on-path
          DOTS agents are within the same domain.</t>

          <t>If domain.</li>
        <li>If a DOTS server has enabled direct configuration, it can reject
          the DOTS data channel connection using hard ICMP error <xref
          target="RFC1122"></xref> target="RFC1122" format="default"/> or RST (Reset) bit in the TCP header or
          reject the RESTCONF request using an error response containing a
          "503 Service Unavailable" status-line.</t>
        </list></t> status-line.</li>
      </ul>
    </section>

    <section title="IANA Considerations">
      <t>This document requests IANA to register numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has registered the following URI in the "ns"
      subregistry within the "IETF XML Registry" <xref
      target="RFC3688"></xref>: <figure>
          <artwork><![CDATA[         URI: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel
         Registrant Contact: The IESG.
         XML: N/A; target="RFC3688" format="default"/>: </t>
           <dl newline="false" spacing="compact">
                <dt>ID:</dt> <dd>yang:ietf-dots-data-channel</dd>
                <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-dots-data-channel</dd>
                <dt>Registrant Contact:</dt> <dd>The IESG.</dd>
                <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.
]]></artwork>
        </figure> This document requests IANA to register namespace.</dd>
                <dt>Reference: </dt><dd>RFC 8783</dd>
           </dl>
      <t>IANA has registered the following YANG
      module in the "YANG Module Names" subregistry <xref
      target="RFC7950"></xref> target="RFC7950" format="default"/>
      within the "YANG Parameters" registry.<figure>
          <artwork><![CDATA[         Name: ietf-dots-data-channel
         Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel
         Prefix: data-channel
         Reference: RFC XXXX]]></artwork>
        </figure></t> registry.</t>
           <dl newline="false" spacing="compact">
   <dt>Name:</dt><dd>ietf-dots-data-channel</dd>
   <dt>Namespace: </dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-data-channel</dd>
   <dt>Prefix: </dt><dd>data-channel</dd>
   <dt>Reference: </dt><dd>RFC 8783</dd>
</dl>
      <t>This module is not maintained by IANA.</t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>RESTCONF security considerations are discussed in <xref
      target="RFC8040"></xref>. target="RFC8040" format="default"/>.
      In particular, DOTS agents MUST <bcp14>MUST</bcp14> follow the
      security recommendations in Sections 2 <xref target="RFC8040" section="2" sectionFormat="bare" format="default"/> and 12
      <xref target="RFC8040" section="12" sectionFormat="bare" format="default"/>
      of <xref
      target="RFC8040"></xref>. target="RFC8040" format="default"/>.
      Also, DOTS agents MUST <bcp14>MUST</bcp14> support the mutual
      authentication TLS profile discussed in
      Sections 7.1 <xref target="RFC8782" section="7.1" sectionFormat="bare" format="default"/> and 8
      <xref target="RFC8782" section="8" sectionFormat="bare" format="default"/>
      of <xref
      target="I-D.ietf-dots-signal-channel"></xref>.</t> target="RFC8782" format="default"/>.</t>
      <t>Authenticated encryption MUST <bcp14>MUST</bcp14> be used for data confidentiality and
      message integrity. The interaction between the DOTS agents requires
      Transport Layer Security (TLS) with a cipher suite offering
      confidentiality protection protection, and the guidance given in <xref
      target="RFC7525"></xref> MUST target="RFC7525" format="default"/>
      <bcp14>MUST</bcp14> be followed to avoid attacks on TLS.</t>
      <t>The installation of drop- drop-list or accept-list rules using RESTCONF over
      TLS reveals the attacker IP addresses and legitimate IP addresses only
      to the DOTS server trusted by the DOTS client. The secure communication
      channel between DOTS agents provides privacy and prevents a network
      eavesdropper from directly gaining access to the drop- drop-listed and accept-listed
      IP addresses.</t>
      <t>An attacker may be able to inject RST packets, bogus application
      segments, etc., regardless of whether TLS authentication is used.
      Because the application data is TLS protected, this will not result in
      the application receiving bogus data, but it will constitute a DoS on
      the connection. This attack can be countered by using TCP-AO
      TCP Authentication Option (TCP-AO) <xref
      target="RFC5925"></xref>. target="RFC5925" format="default"/>. If TCP-AO is used, then any bogus packets
      injected by an attacker will be rejected by the TCP-AO integrity check
      and therefore will never reach the TLS layer.</t>
      <t>In order to prevent leaking internal information outside a
      client-domain,
      client domain, client-side DOTS gateways SHOULD NOT <bcp14>SHOULD NOT</bcp14> reveal the identity
      of internal DOTS clients (e.g., source IP address, client's hostname)
      unless explicitly configured to do so.</t>
      <t>DOTS servers MUST <bcp14>MUST</bcp14> verify that requesting DOTS clients are entitled to
      enforce filtering rules on a given IP prefix. That is, only filtering
      rules on IP resources that belong to the DOTS client domain can be
      authorized by a DOTS server. The exact mechanism for the DOTS servers to
      validate that the target prefixes are within the scope of the DOTS
      client domain is deployment-specific.</t> deployment specific.</t>
      <t>Rate-limiting DOTS requests, including those with new 'cuid' values,
      from the same DOTS client defends against DoS attacks that would result
      from varying the 'cuid' to exhaust DOTS server resources. Rate-limit
      policies SHOULD <bcp14>SHOULD</bcp14> be enforced on DOTS gateways (if deployed) and DOTS
      servers.</t>
      <t>Applying resources quota per DOTS client and/or per DOTS client
      domain (e.g., limit limiting the number of aliases and filters to be installed by
      DOTS clients) prevents DOTS server resources to be from being aggressively used by
      some DOTS clients and ensures, therefore, therefore ensures DDoS mitigation usage
      fairness. Additionally, DOTS servers may limit the number of DOTS
      clients that can be enabled per domain.</t>
      <t>When FQDNs are used as targets, the DOTS server MUST <bcp14>MUST</bcp14> rely upon DNS
      privacy enabling protocols (e.g., DNS over TLS <xref
      target="RFC7858"></xref> target="RFC7858" format="default"/>
      or DoH DNS over HTTPS (DoH) <xref target="RFC8484"></xref>) target="RFC8484" format="default"/>) to
      prevent eavesdroppers from possibly identifying the target resources
      protected by the DDoS mitigation service, and means to ensure the target
      FQDN resolution is authentic (e.g., DNSSEC <xref
      target="RFC4034"></xref>).</t> target="RFC4034" format="default"/>).</t>
      <t>The presence of DOTS gateways may lead to infinite forwarding loops,
      which is undesirable. To prevent and detect such loops, a mechanism is
      defined in <xref target="loops"></xref>.</t>

      <t>All data nodes defined in the target="loops" format="default"/>.</t>
<t>
The YANG module which can be created,
      modified, and deleted (i.e., config true, which is the default) are
      considered sensitive. specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH)
<xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.
</t>
<t>
The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/>
provides the means to restrict access for particular NETCONF or RESTCONF users
to a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
</t>

<t>
  There are a number of data nodes defined in this YANG module that are
  writable/creatable/deletable (i.e., config true, which is the default).
  These data nodes may be considered sensitive or vulnerable in some network
  environments. Write operations applied (e.g., edit-config) to these data nodes
  without proper protection can negatively affect have a negative effect on network operations. This
      module reuses YANG structures from <xref target="RFC8519"></xref>, and
      the security considerations for those nodes continue to apply
  The DOTS data channel is responsible for this
      usage. exchanging configuration data
  that affect traffic filtering during DDoS attack mitigation, in particular.
  Appropriate security measures are recommended to prevent illegitimate users from
  invoking DOTS data channel primitives. primitives on writable data nodes.
  Nevertheless, an attacker who can access a DOTS client is technically
  capable of launching various attacks, such as:<list style="symbols">
          <t>Setting as:
</t>
      <ul spacing="normal">
        <li>Setting an arbitrarily low rate-limit, which may prevent
          legitimate traffic from being forwarded (rate-limit).</t>

          <t>Setting (rate-limit).</li>
        <li>Setting an arbitrarily high rate-limit, which may lead to the
          forwarding of illegitimate DDoS traffic (rate-limit).</t>

          <t>Communicating (rate-limit).</li>
        <li>Communicating invalid aliases to the server (alias), which will
          cause the failure of associating both data and signal channels.</t>

          <t>Setting channels.</li>
        <li>Setting invalid ACL entries, which may prevent legitimate traffic
          from being forwarded. Likewise, invalid ACL entries may lead to
          forward DDoS traffic.</t>
        </list></t>
    </section>

    <section title="Contributing Authors">
      <t>The following individuals co-authored this document:</t>

      <t><figure>
          <artwork><![CDATA[   Kaname Nishizuka
   NTT Communications
   GranPark 16F 3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan

   Email: kaname@nttv6.jp

   Liang Xia
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Email: frank.xialiang@huawei.com

   Prashanth Patil
   Cisco Systems, Inc.

   Email: praspati@cisco.com

   Andrew Mortensen
   Arbor Networks, Inc.
   2727 S. State St
   Ann Arbor, MI  48104
   United States

   Email: andrew.mortensen@netscout.com

   Nik Teague
   Iron Mountain Data Centers
   United Kingdom

   Email: nteague@ironmountain.co.uk]]></artwork>
        </figure></t>
    </section>

    <section anchor="contr" title="Contributors">
      <t>The following individuals have contributed to this document:<list
          style="symbols">
          <t>Dan Wing, Email: dwing-ietf@fuggles.com</t>

          <t>Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.com</t>
        </list></t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Ehud
      Doron, Russ White, Gilbert Clark, Kathleen Moriarty, Nesredien Suleiman,
      Roni Even, and Brian Trammel for the discussion and comments.</t>

      <t>The authors would like to give special thanks to Kaname Nishizuka and
      Jon Shallow for their efforts in implementing the protocol traffic.</li>
      </ul>
<t>
  This module reuses YANG structures from <xref target="RFC8519"/>, and
      performing interop testing at IETF Hackathons.</t>

      <t>Many thanks to Ben Kaduk for the detailed AD review.</t>

      <t>Thanks to Martin Bjorklund security
  considerations for the guidance on RESTCONF.</t>

      <t>Thanks those nodes continue to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja
      K&uuml;hlewind, and Warren Kumari apply for the review.</t> this usage.
</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

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

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

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

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

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

      <?rfc include='reference.RFC.3688'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.4632'?>

      <?rfc include='reference.RFC.6991'?>

      <?rfc include='reference.RFC.7230'?>

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

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

      <?rfc include='reference.RFC.6125'?>
    <displayreference target="I-D.ietf-dots-architecture" to="DOTS-ARCH"/>
    <displayreference target="I-D.ietf-dots-server-discovery" to="DOTS-SERVER-DISC"/>
    <displayreference target="I-D.ietf-netconf-restconf-client-server" to="RESTCONF-MODELS"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8519.xml"/>
        <reference anchor="RFC8782" target="https://www.rfc-editor.org/info/rfc8782">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
            <author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.K" role="editor">
              <organization/>
            </author>
            <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair" role="editor">
              <organization/>
            </author>
            <author initials="P" surname="Patil" fullname="Prashanth Patil">
              <organization/>
            </author>
            <author initials="A" surname="Mortensen" fullname="Andrew Mortensen">
              <organization/>
            </author>
            <author initials="N" surname="Teague" fullname="Nik Teague">
              <organization/>
            </author>
            <date month="May" year="2020"/>
          </front>
          <seriesInfo name="RFC" value="8782"/>
          <seriesInfo name="DOI" value="10.17487/RFC8782"/>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4632.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
      </references>

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

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

      <?rfc include='reference.RFC.8499'?>

      <?rfc include='reference.RFC.4034'?>

      <?rfc include='reference.RFC.7858'?>

      <?rfc include='reference.RFC.8484'?>

      <?rfc include='reference.RFC.4340'?>

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

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

      <?rfc include='reference.RFC.3986'?>

      <?rfc include='reference.RFC.4960'?>

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

      <?rfc include='reference.RFC.8340'?>

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

      <?rfc include='reference.I-D.ietf-dots-server-discovery'?>

      <?rfc include='reference.I-D.ietf-netconf-restconf-client-server'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dots-architecture.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6520.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8612.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5575.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dots-server-discovery.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf-client-server.xml"/>
        <reference anchor="proto_numbers" anchor="IANA-PROTO" target="http://www.iana.org/assignments/protocol-numbers">
          <front>
          <title>IANA, "Protocol Numbers"</title>
            <title>Protocol Numbers</title>
            <author>
            <organization></organization>
              <organization>IANA</organization>
            </author>

          <date year="2011" />
            <date></date>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="frag" title="Sample Examples: numbered="true" toc="default">
      <name>Examples: Filtering Fragments"> Fragments</name>
      <t>This specification strongly recommends the use of "fragment" 'fragment' for
      handling fragments.</t>
      <t><xref target="fragdnsv4"></xref> target="fragdnsv4" format="default"/> shows the content of the POST
      request to be issued by a DOTS client to its DOTS server to allow the
      traffic destined to 198.51.100.0/24 and UDP port number 53, but to drop
      all fragmented packets. The following ACEs are defined (in this
      order):</t>

      <t><list style="symbols">
          <t>"drop-all-fragments"
      <ul spacing="normal">
        <li>"drop-all-fragments" ACE: discards all fragments.</t>

          <t>"allow-dns-packets" fragments.</li>
        <li>"allow-dns-packets" ACE: accepts DNS packets destined to
          198.51.100.0/24.</t>
        </list></t>

      <t><figure anchor="fragdnsv4" title="Filtering
          198.51.100.0/24.</li>
      </ul>
      <figure anchor="fragdnsv4">
        <name>Filtering IPv4 Fragmented Packets">
          <artwork align="left"><![CDATA[ Packets</name>
        <sourcecode type=""><![CDATA[
POST /restconf/data/ietf-dots-data-channel:dots-data\
     /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "dns-fragments",
        "type": "ipv4-acl-type",
        "aces": {
          "ace": [
            {
              "name": "drop-all-fragments",
              "matches": {
                "ipv4": {
                  "fragment": {
                    "operator": "match",
                    "type": "isf"
                  }
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]
          "ace": [
            },
            {
              "name": "allow-dns-packets",
              "matches": {
                "ipv4": {
                  "destination-ipv4-network": "198.51.100.0/24"
                }
                },
                "udp": {
                  "destination-port":
                  "destination-port-range-or-operator": {
                    "operator": "eq",
                    "port": 53
                  }
                },
                "actions": {
                  "forwarding": "accept"
                }
              }
            }
          ]
        }
      }
    ]
  }
 }]]></artwork>
        </figure></t>
}
]]></sourcecode>
      </figure>
      <t><xref target="fragdnsv6"></xref> target="fragdnsv6" format="default"/> shows an example of a POST request example issued
      by a DOTS client to its DOTS server to allow the traffic destined to
      2001:db8::/32 and UDP port number 53, but to drop all fragmented
      packets. The following ACEs are defined (in this order):</t>

      <t><list style="symbols">
          <t>"drop-all-fragments"
      <ul spacing="normal">
        <li>"drop-all-fragments" ACE: discards all fragments (including
          atomic fragments). That is, IPv6 packets which that include a Fragment
          header (44) are dropped.</t>

          <t>"allow-dns-packets" dropped.</li>
        <li>"allow-dns-packets" ACE: accepts DNS packets destined to
          2001:db8::/32.</t>
        </list></t>

      <t><figure anchor="fragdnsv6" title="Filtering
          2001:db8::/32.</li>
      </ul>
      <figure anchor="fragdnsv6">
        <name>Filtering IPv6 Fragmented Packets">
          <artwork align="left"><![CDATA[ Packets</name>
        <sourcecode type=""><![CDATA[
POST /restconf/data/ietf-dots-data-channel:dots-data\
     /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "dns-fragments",
        "type": "ipv6-acl-type",
        "aces": {
          "ace": [
            {
              "name": "drop-all-fragments",
              "matches": {
                "ipv6": {
                  "fragment": {
                    "operator": "match",
                    "type": "isf"
                  }
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]
          "ace": [
            },
            {
              "name": "allow-dns-packets",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8::/32"
                }
                },
                "udp": {
                  "destination-port":
                  "destination-port-range-or-operator": {
                    "operator": "eq",
                    "port": 53
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></artwork>
        </figure></t>
]]>
</sourcecode>
      </figure>
    </section>
    <section anchor="flags" title="Sample Examples: numbered="true" toc="default">
      <name>Examples: Filtering TCP Messages"> Messages</name>
      <t>This section provides sample examples to illustrate TCP-specific
      filtering based on the flag bits. These examples should not be
      interpreted as recommended filtering behaviors under specific DDoS
      attacks.</t>
      <section title="Discard numbered="true" toc="default">
        <name>Discard TCP Null Attack"> Attack</name>
        <t><xref target="ex3"></xref> target="ex3" format="default"/> shows an example of a DOTS request sent
        by a DOTS client to install immediately a filter to discard incoming
        TCP messages having all flags unset. The bitmask can be set to 255 to
        check against the (CWR, ECE, URG, ACK, PSH, RST, SYN, FIN) flags.</t>

        <t><figure anchor="ex3"
            title="Example
        <figure anchor="ex3">
          <name>Example of a DOTS Request to Deny TCP Null Attack Messages">
            <artwork><![CDATA[PUT Messages</name>
          <sourcecode type=""><![CDATA[
PUT /restconf/data/ietf-dots-data-channel:dots-data\
    /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
    /acl=tcp-flags-example HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:acls": {
    "acl": [{
      "name": "tcp-flags-example",
      "activation-type": "immediate",
      "aces": {
        "ace": [{
          "name": "null-attack",
          "matches": {
            "tcp": {
              "flags-bitmask": {
                "operator": "not any",
                "bitmask": 4095
              }
            }
          },
          "actions": {
            "forwarding": "drop"
          }
        }]
      }
    }]
  }
}
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
      </section>
      <section title="Rate-Limit numbered="true" toc="default">
        <name>Rate-Limit SYN Flooding"> Flooding</name>
        <t><xref target="syn-rate"></xref> target="syn-rate" format="default"/> shows an ACL example to rate-limit
        incoming SYNs during a SYN-flood attack.<figure anchor="syn-rate"
            title="Example SYN flood attack.</t>
        <figure anchor="syn-rate">
          <name>Example of DOTS Request to Rate-Limit Incoming TCP SYNs">
            <artwork><![CDATA[PUT SYNs</name>
          <sourcecode type=""><![CDATA[
PUT /restconf/data/ietf-dots-data-channel:dots-data\
    /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
    /acl=tcp-flags-example HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:acls": {
    "acl": [{
      "name": "tcp-flags-example",
      "activation-type": "activate-when-mitigating",
      "aces": {
        "ace": [{
          "name": "rate-limit-syn",
          "matches": {
            "tcp": {
              "flags-bitmask": {
                "operator": "match",
                "bitmask": 2
              }
            }
          },
          "actions": {
            "forwarding": "accept",
            "rate-limit": "20.00"
          }
        }]
      }
    }]
  }
}
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
      </section>
      <section title="Rate-Limit numbered="true" toc="default">
        <name>Rate-Limit ACK Flooding"> Flooding</name>
        <t><xref target="ex1"></xref> target="ex1" format="default"/> shows an ACL example to rate-limit
        incoming ACKs during an ACK-flood ACK flood attack.</t>

        <t><figure anchor="ex1"
            title="Example
        <figure anchor="ex1">
          <name>Example of DOTS Request to Rate-Limit Incoming TCP ACKs">
            <artwork><![CDATA[PUT ACKs</name>
          <sourcecode type=""><![CDATA[
PUT /restconf/data/ietf-dots-data-channel:dots-data\
    /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
    /acl=tcp-flags-example HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:acls": {
    "acl": [{
      "name": "tcp-flags-example",
      "type": "ipv4-acl-type",
      "activation-type": "activate-when-mitigating",
      "aces": {
        "ace": [{
          "name": "rate-limit-ack",
          "matches": {
            "tcp": {
              "flags-bitmask": {
                "operator": "match",
                "bitmask": 16
              }
            }
          },
          "actions": {
            "forwarding": "accept",
            "rate-limit": "20.00"
          }
        }]
      }
    }]
  }
}
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="ack" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to <contact fullname="Christian Jacquenet"/>,
      <contact fullname="Roland Dobbins"/>, <contact fullname="Roman Danyliw"/>,
      <contact fullname="Ehud Doron"/>, <contact fullname="Russ White"/>,
      <contact fullname="Gilbert Clark"/>, <contact fullname="Kathleen Moriarty"/>,
      <contact fullname="Nesredien Suleiman"/>, <contact fullname="Roni Even"/>, and
      <contact fullname="Brian Trammel"/> for the discussion and comments.</t>
      <t>The authors would like to give special thanks to <contact fullname="Kaname Nishizuka"/> and
      <contact fullname="Jon Shallow"/> for their efforts in implementing the protocol and
      performing interop testing at IETF Hackathons.</t>
      <t>Many thanks to <contact fullname="Benjamin Kaduk"/> for the detailed AD review.</t>
      <t>Thanks to <contact fullname="Martin Björklund"/> for the guidance on RESTCONF.</t>
      <t>Thanks to <contact fullname="Alexey Melnikov"/>, <contact fullname="Adam Roach"/>,
      <contact fullname="Suresh Krishnan"/>, <contact fullname="Mirja Kühlewind"/>, and
       <contact fullname="Warren Kumari"/> for the review.</t>
    </section>

    <section numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following people contributed substantially to the content of this
   document and should be considered coauthors:</t>

      <contact fullname="Kaname Nishizuka" >
        <organization>NTT Communications</organization>
        <address>
          <postal>
            <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
            <city></city>
            <region>Tokyo</region><code>108-8118</code>
            <country>Japan</country>
          </postal>
          <email>kaname@nttv6.jp</email>
        </address>
      </contact>

      <contact fullname="Liang Xia" >
        <organization>Huawei</organization>
        <address>
          <postal>
            <street>101 Software Avenue, Yuhuatai District</street>
            <city>Nanjing</city>
            <region>Jiangsu</region><code>210012</code>
            <country>China</country>
          </postal>
          <email>frank.xialiang@huawei.com</email>
        </address>
      </contact>

            <contact fullname="Prashanth Patil" >
        <organization>Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country></country>
          </postal>
          <email>praspati@cisco.com</email>
        </address>
	    </contact>

	          <contact fullname="Andrew Mortensen" >
        <organization>Arbor Networks, Inc.</organization>
        <address>
          <postal>
            <street>2727 S. State Street</street>
            <city>Ann Arbor</city>
            <region>Michigan</region><code>48104</code>
            <country>United States of America</country>
          </postal>
          <email>andrew@moretension.com</email>
        </address>
		  </contact>

		        <contact fullname="Nik Teague" >
        <organization>Iron Mountain Data Centers</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country>United Kingdom</country>
          </postal>
          <email>nteague@ironmountain.co.uk</email>
        </address>
      </contact>

      <t>The following individuals have contributed to this
      document:</t>

      <contact fullname="Dan Wing" >
        <organization></organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country></country>
          </postal>
          <email>dwing-ietf@fuggles.com</email>
        </address>
      </contact>

            <contact fullname="Jon Shallow" >
        <organization>NCC Group</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country></country>
          </postal>
          <email>jon.shallow@nccgroup.com</email>
        </address>
      </contact>
    </section>
  </back>
</rfc>