draft-ietf-dots-signal-call-home.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-dots-signal-call-home-latest"
     ipr="trust200902">
  <front>
    <title abbrev="DOTS Signal Call Home">Distributed Denial-of-Service Open
    Threat Signaling (DOTS) Signal Channel Call Home</title>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <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>

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

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

          <city>Rennes</city>

          <code>35000</code>

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

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

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

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

          <city></city>

          <code></code>

          <country>UK</country>
        </postal>

        <email>supjps-ietf@jpshallow.com</email>
      </address>
    </author>

    <date />

    <workgroup>DOTS</workgroup>

    <keyword>Automation</keyword>

    <keyword>Anti-DDoS Automation</keyword>

    <keyword>DDoS Mitigation</keyword>

    <keyword>Collaborative Networking</keyword>

    <keyword>Protective Networking</keyword>

    <keyword>Security</keyword>

    <keyword>Scrubbing</keyword>

    <abstract>
      <t>This document specifies the DOTS signal channel Call Home, which
      enables a Call Home DOTS server to initiate a secure connection to a
      Call Home DOTS client, and to receive attack traffic information from
      the Call Home DOTS client. The Call Home DOTS server in turn uses the
      attack traffic information to identify compromised devices launching
      outgoing DDoS attacks and take appropriate mitigation action(s).</t>

      <t>The DOTS signal channel Call Home is not specific to home networks;
      the solution targets any deployment in which it is required to block
      DDoS attack traffic closer to the source(s) of a DDoS attack.</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 Denial-of-Service Open Threat Signaling
          (DOTS) Signal Channel Call Home";</t>

          <t>"| [RFCXXXX] |"</t>

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

      <t>Please update this statement with the RFC number to be assigned to
      the following documents:<list style="symbols">
          <t>"RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
          (DOTS) Signal Channel Specification" (used to be
          I-D.ietf-dots-rfc8782-bis)</t>
        </list></t>

      <t>Please update TBD/TBA statements with the assignments made by IANA to
      DOTS Signal Channel Call Home.</t>

      <t>Also, please update the "revision" date of the YANG module.</t>
    </note>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal
      channel protocol <xref target="I-D.ietf-dots-rfc8782-bis"></xref> is
      used to carry information about a network resource or a network (or a
      part thereof) that is under a Distributed Denial of Service (DDoS)
      attack <xref target="RFC4732"></xref>. Such information is sent by a
      DOTS client to one or multiple DOTS servers so that appropriate
      mitigation actions are undertaken on traffic deemed suspicious. Various
      use cases are discussed in <xref
      target="I-D.ietf-dots-use-cases"></xref>.</t>

      <t>However, <xref target="I-D.ietf-dots-rfc8782-bis"></xref> only covers
      how to mitigate when being attacked (i.e., protect a network from
      inbound DDoS attacks). It does not cover how to control the attacks
      close to their source(s) that are misusing network resources (i.e.,
      outbound DDoS attacks). In particular, the DOTS signal protocol does not
      discuss cooperative DDoS mitigation between the network hosting an
      attack source and the Internet Service Provider (ISP) to suppress the
      outbound DDoS attack traffic originating from that network. As a
      reminder, the base basic DOTS architecture is depicted in <xref
      target="basea"></xref> (Section 2 of <xref
      target="RFC8811"></xref>).</t>

      <t><figure align="center" anchor="basea" title="Basic DOTS Architecture">
          <artwork align="center"><![CDATA[+-----------+            +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server |
+-----------+            +-------------+
                                |
                                |
                                |
+---------------+        +-------------+
| Attack Target | ~~~~~~ | DOTS Client |
+---------------+        +-------------+
]]></artwork>
        </figure></t>

      <t><xref target="home"></xref> details why the rise of Internet of
      Things (IoT) compounds the possibility of these being used as malicious
      actors which need to be controlled. Similar issues can be encountered in
      enterprise networks, data centers, etc. The ISP offering a DDoS
      mitigation service can detect outgoing DDoS attack traffic originating
      from its subscribers or the ISP may receive filtering rules (e.g., using
      BGP Flowspec <xref target="RFC8955"></xref><xref
      target="RFC8956"></xref>) from a transit provider to filter, block, or
      rate-limit DDoS attack traffic originating from the ISP's subscribers to
      a downstream target. Nevertheless, the DOTS signal channel does not
      provide means for the ISP to request blocking such attacks close to the
      sources without altering legitimate traffic. This document fills that
      void by specifying an extension to the DOTS signal channel: DOTS signal
      channel Call Home.<list style="empty">
          <t>Note: Another design approach would be to extend the DOTS signal
          channel with a new attribute to explicitly indicate whether a
          mitigation request is about an outbound DDoS attack. In such an
          approach, it is assumed that a DOTS server is deployed within the
          domain that is hosting the attack source(s), while a DOTS client is
          enabled within an upstream network (e.g., access network). However,
          initiating a DOTS signal channel from an upstream network to a
          source network is complicated because of the presence of translators
          and firewalls. Moreover, the use of the same signal channel to
          handle both inbound and outbound attacks complicates both the
          heartbeat and redirection mechanisms that are executed as a function
          of the attack direction (see Sections <xref format="counter"
          target="hb"></xref> and <xref format="counter"
          target="redirect"></xref>). Also, the DOTS server will be subject to
          fingerprinting (e.g., using scanning tools) and DoS attacks (e.g.,
          by having the DOTS server to perform computationally expensive
          operations). Various management and deployment considerations that
          motivate the Call Home functionality are listed in Section 1.1 of
          <xref target="RFC8071"></xref>.</t>
        </list></t>

      <t>'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers
      to a DOTS signal channel established at the initiative of a DOTS server
      thanks to a role reversal at the (D)TLS layer (<xref
      target="proc"></xref>). That is, the DOTS server initiates a secure
      connection to a DOTS client, and uses that connection to receive the
      attack traffic information (e.g., attack sources) from the DOTS
      client.</t>

      <t>A high-level DOTS Call Home functional architecture is shown in <xref
      target="fa"></xref>. Attack source(s) are within the DOTS server
      domain.</t>

      <t><figure align="center" anchor="fa"
          title="Basic DOTS Signal Channel Call Home Functional Architecture">
          <artwork align="center"><![CDATA[                               Scope
                     +.-.-.-.-.-.-.-.-.-.-.-.+
+---------------+    :    +-------------+    :
|    Alert      | ~~~:~~~ |  Call Home  |    :
|               |    :    | DOTS client |    :
+---------------+    :    +------+------+    :
                     :           |           :
                     :           |           :
                     :           |           :
+---------------+    :    +------+------+    :
|    Attack     | ~~~:~~~ |  Call Home  |    :
|   Source(s)   |    :    | DOTS server |    :
+---------------+    :    +-------------+    :
                     +.-.-.-.-.-.-.-.-.-.-.-.+]]></artwork>
        </figure></t>

      <t>DOTS agents involved in the DOTS Call Home otherwise adhere to the
      DOTS roles as defined in <xref target="RFC8612"></xref>. For clarity,
      this document uses "Call Home DOTS client" (or "Call Home DOTS server")
      to refer to a DOTS client (or DOTS server) deployed in a Call Home
      scenario (<xref target="fa"></xref>). DOTS Call Home agents may (or not)
      be co-located with DOTS agents that are compliant with <xref
      target="I-D.ietf-dots-rfc8782-bis"></xref> (see <xref
      target="coex"></xref> for more details).</t>

      <t>A Call Home DOTS client relies upon a variety of triggers to make use
      of the Call Home function (e.g., scrubbing the traffic from the attack
      source, receiving an alert from an attack target, a peer DDoS Mitigation
      System (DMS), or a transit provider). The definition of these triggers
      is deployment-specific. It is therefore out of the scope of this
      document to elaborate on how these triggers are made available to a Call
      Home DOTS client.</t>

      <t>In a typical deployment scenario, the Call Home DOTS server is
      enabled on a Customer Premises Equipment (CPE), which is aligned with
      recent trends to enrich the CPE with advanced security features. For
      example, the DOTS Call Home service can be part of services supported by
      an ISP-managed CPE or a managed security service subscribed by the user.
      Unlike classic DOTS deployments <xref
      target="I-D.ietf-dots-use-cases"></xref>, a Call Home DOTS server
      maintains a single DOTS signal channel session for each DOTS-capable
      upstream provisioning domain <xref target="I-D.ietf-dots-multihoming">
      </xref>.</t>

      <t>For instance, the Call Home DOTS server in the home network initiates
      the signal channel Call Home in 'idle' time and then subsequently the
      Call Home DOTS client in the ISP environment can initiate a mitigation
      request whenever the ISP detects there is an attack from a compromised
      device in the DOTS server domain (i.e., from within the home
      network).</t>

      <t>The Call Home DOTS server uses the DDoS attack traffic information to
      identify the compromised device in its domain that is responsible for
      launching the DDoS attack, optionally notifies a network administrator,
      and takes appropriate mitigation action(s). For example, a mitigation
      action can be to quarantine the compromised device or block its traffic
      to the attack target(s) until the mitigation request is withdrawn.</t>

      <t>This document assumes that Call Home DOTS servers are provisioned
      with a way to know how to reach the upstream Call Home DOTS client(s),
      which could occur by a variety of means (e.g., <xref
      target="RFC8973"></xref>). The specification of such means are out of
      scope of this document.</t>

      <t>More information about the applicability scope of the DOTS signal
      channel Call Home is provided in <xref target="as"></xref>.</t>
    </section>

    <section anchor="notation" title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and
      only when, they appear in all capitals, as shown here.</t>

      <t>The reader should be familiar with the terms defined in Section 1.2
      of <xref target="RFC8612"></xref>.</t>

      <t>DDoS Mitigation System (DMS) refers to a system that performs DDoS
      mitigation.</t>

      <t>'Base DOTS signal channel' refers to <xref
      target="I-D.ietf-dots-rfc8782-bis"></xref>.</t>

      <t>The meaning of the symbols in YANG tree diagrams are defined in <xref
      target="RFC8340"></xref> and <xref target="RFC8791"></xref>.</t>

      <t>(D)TLS is used for statements that apply to both Transport Layer
      Security (TLS) <xref target="RFC8446"></xref> and Datagram Transport
      Layer Security (DTLS) <xref target="RFC6347"></xref>. Specific terms are
      used for any statement that applies to either protocol alone.</t>
    </section>

    <section anchor="as" title="Applicability Scope">
      <t>The problems discussed in <xref target="introduction"></xref> may be
      encountered in many deployments (e.g., home networks, enterprise
      networks, transit networks, data centers). The solution specified in
      this document can be used for those deployments to block DDoS attack
      traffic closer to the source(s) of the attack. That is, attacks that are
      issued, e.g., from within an enterprise network or a data center, will
      thus be blocked before exiting these networks.</t>

      <t>An instantiation of the Call Home functional architecture is depicted
      in <xref target="pb"></xref>.</t>

      <t><figure align="center" anchor="pb"
          title="DOTS Signal Channel Call Home Reference Architecture">
          <artwork align="center"><![CDATA[                +-------------+
                |Attack Target|
                +-----+-------+  
                      | /\      Target Network
......................|.||....................      
             .--------+-||-------. 
            (           ||        )-.
          .'            ||           ' 
          (  Internet   ||            ) 
           (            ||          -'
            '-(         ||          )
               '------+-||---------' 
......................|.||..................... 
             .--------+-||-------.      Network   
            (           ||        )-.  Provider
          .' Call Home  ||           '   (DMS)
          ( DOTS client ||            ) 
           (            ||          -'
            '-(         ||          )
               '------+-||---------' 
......................|.||.......................
             .--------+-||-------. Source Network
            (           ||        )-.
          .' Call Home  ||           ' 
          ( DOTS server || Outbound   ) 
           (            ||   DDoS   -'
            '-(         ||  Attack  )
               '------+-||---------' 
                      | ||
                +-----+-++----+
                |Attack Source|                           
                +-------------+
]]></artwork>
        </figure></t>

      <t>It is out of the scope of this document to identify an exhaustive
      list of such deployments.</t>

      <t>Call Home DOTS agent relationships are similar to those discussed in
      Section 2.3 of <xref target="RFC8811"></xref>. For example, multiple
      Call Home DOTS servers of the same domain can be associated with the
      same Call Home DOTS client. A Call Home DOTS client may decide to
      contact these Call Home DOTS servers sequentially, fork a mitigation
      request to all of them, or select one Call Home DOTS server to place a
      mitigation request. Such decision is implementation-specific.</t>

      <t>For some mitigations, a feedback may be required from an
      administrator to confirm a filtering action. Means to seek for an
      administrator's consent are deployment-specific. Indeed, a variety of
      implementation options can be considered as a function of the Call Home
      DOTS deployment: push notifications using a dedicated application,
      Syslog, etc. It is out of the scope of this document to make
      recommendations about how such interactions are implemented (see <xref
      target="fa"></xref>).</t>

      <t>The Call Home DOTS server can be enabled on a border router or a
      dedicated appliance. For the particular case of home networks, the Call
      Home DOTS server functionality can be enabled on a managed CPE or be
      bundled with a CPE management application that is provided by an ISP to
      its subscribers. These managed services are likely to be designed to
      hide the complexity of managing (including configuring) the CPE. For
      example, managed CPEs support means to notify the user when a new device
      is detected in order to seek a confirmation whether access should be
      granted or not to the device. These means can be upgraded to interface
      with the Call Home DOTS server. Customized settings can be configured by
      users to control the notifications (e.g., triggers, type) and default
      actions.</t>
    </section>

    <section anchor="coex"
             title="Co-existence of Base DOTS Signal Channel and DOTS Call Home">
      <t>The DOTS signal channel Call Home does not require nor preclude the
      activation of the base DOTS signal channel <xref
      target="I-D.ietf-dots-rfc8782-bis"></xref>. Some sample deployment
      schemes are discussed in this section for illustration purposes.</t>

      <t>The network that hosts an attack source may also be subject to
      inbound DDoS attacks. In that case, both the base DOTS signal channel
      and DOTS signal channel Call Home may be enabled as shown in <xref
      target="merged"></xref> (Same DMS provider) or <xref
      target="merged1"></xref> (Distinct DMS providers).</t>

      <t><figure align="center" anchor="merged"
          title="Activation of Base DOTS Signal Channel and Call Home (Same DMS Provider)">
          <artwork align="center"><![CDATA[    DOTS Signal Channel      Base DOTS
        Call Home          Signal Channel  
   +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
   :          +------+ :: +------+          :
   :          | DOTS | :: | DOTS |          :
   :          |client| :: |server|          :
   :          +--+---+ :: +---+--+          :
   :     /\      |     ::     |             : Network
   :     ||      |     ::     |             :Provider
   :     ||      |     ::     |             :  (DMS)  
...:.....||......|.....::.....|.............:........
Outbound ||      |     ::     |       || Inbound
  DDoS   ||      |     ::     |       ||   DDoS
 Attack  ||      |     ::     |       \/  Attack
   :          +--+---+ :: +---+--+          : 
   :          | DOTS | :: | DOTS |          :
   :          |server| :: |client|          :
   :          +------+ :: +------+          :
   +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
                   Network #A]]></artwork>
        </figure></t>

      <t>Note that a DMS provider may not be on the default forwarding path of
      an inbound DDoS attack traffic targeting a network (e.g., Network #B in
      <xref target="merged1"></xref>). Nevertheless, the DOTS signal channel
      Call Home requires the DMS provider to be on the default forwarding path
      of the outbound traffic from a given network.</t>

      <t><figure align="center" anchor="merged1"
          title="Activation of Base DOTS Signal Channel and Call Home (Distinct DMS Providers)">
          <artwork align="center"><![CDATA[    DOTS Signal Channel      Base DOTS
        Call Home          Signal Channel  
   +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
   : Network  +------+ :: +------+   Third  :
   : Provider | DOTS | :: | DOTS |   Party  :
   :  (DMS)   |client| :: |server|    DMS   :
   :          +--+---+ :: +---+--+ Provider :
   :     /\      |     ::     |             : 
   :     ||      |     ::     |             :
   :     ||      |     ::     |             :
...:.....||......|.....::.....|.............:........
Outbound ||      |     ::     |       || Inbound
  DDoS   ||      |     ::     |       ||   DDoS
 Attack  ||      |     ::     |       \/  Attack
   :          +--+---+ :: +---+--+          : 
   :          | DOTS | :: | DOTS |          :
   :          |server| :: |client|          :
   :          +------+ :: +------+          :
   +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
                   Network #B
]]></artwork>
        </figure></t>

      <t>Figures <xref format="counter" target="snode"></xref> and <xref
      format="counter" target="snode2"></xref> depict examples where the same
      node embeds both base DOTS and DOTS Call Home agents. For example, a
      DOTS server and a Call Home DOTS client may be enabled on the same
      device within the infrastructure of a DMS provider (e.g., Node #i in
      <xref target="snode"></xref>) or a DOTS client and a Call Home DOTS
      server may be enabled on the same device within a source network (e.g.,
      Node #j with Network #D shown in <xref target="snode2"></xref>) .</t>

      <t>Whether the same or distinct nodes are used to host base DOTS and
      DOTS Call Home agents is specific to each domain.</t>

      <t><figure align="center" anchor="snode"
          title="An Example of the Same Node Embedding both a Call Home DOTS Client and a DOTS Server at the Network Provider's Side">
          <artwork align="center"><![CDATA[    DOTS Signal Channel      Base DOTS
        Call Home          Signal Channel  
   +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 
   :        +----------------------+        :                   
   :        |       Node #i        |        :
   :        | +------+    +------+ |        :
   :        | | DOTS |    | DOTS | |        :
   :        | |client|    |server| |        :
   :        | +--+---+    +---+--+ |        :
   :        +----|-----::-----|----+        : Network
   :     /\      |     ::     |             :Provider
   :     ||      |     ::     |             :  (DMS)  
...:.....||......|.....::.....|.............:........
Outbound ||      |     ::     |       || Inbound
  DDoS   ||      |     ::     |       ||   DDoS
 Attack  ||      |     ::     |       \/  Attack
   :          +--+---+ :: +---+--+          : 
   :          | DOTS | :: | DOTS |          :
   :          |server| :: |client|          :
   :          +------+ :: +------+          :
   +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
                   Network #C
]]></artwork>
        </figure></t>

      <t><figure align="center" anchor="snode2"
          title="Another Example where the Same Node Embeds both a DOTS Client and a Call Home DOTS Server">
          <artwork align="center"><![CDATA[    DOTS Signal Channel      Base DOTS
        Call Home          Signal Channel  
   +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 
   :        +----------------------+        :                   
   :        |       Node #k        |        :
   :        | +------+    +------+ |        :
   :        | | DOTS |    | DOTS | |        :
   :        | |client|    |server| |        :
   :        | +--+---+    +---+--+ |        :
   :        +----|-----::-----|----+        : Network
   :     /\      |     ::     |             :Provider
   :     ||      |     ::     |             :  (DMS)  
...:.....||......|.....::.....|.............:........
Outbound ||      |     ::     |       || Inbound
  DDoS   ||      |     ::     |       ||   DDoS
 Attack  ||      |     ::     |       \/  Attack
   :        +----|-----::-----|----+        :
   :        | +--+---+    +---+--+ |        :
   :        | | DOTS |    | DOTS | |        :
   :        | |server|    |client| |        :
   :        | +------+    +------+ |        :
   :        |       Node #j        |        :
   :        +----------------------+        :
   +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
                   Network #D]]></artwork>
        </figure><xref target="app"></xref> elaborates on the considerations
      to unambiguously distinguish DOTS messages which belong to each of these
      channels.</t>
    </section>

    <section anchor="spec" title="DOTS Signal Channel Call Home">
      <section anchor="proc" title="Procedure">
        <t>The DOTS signal channel Call Home preserves all but one of the DOTS
        client/server roles in the DOTS protocol stack, as compared to DOTS
        client-initiated DOTS signal channel protocol <xref
        target="I-D.ietf-dots-rfc8782-bis"></xref>. The role reversal that
        occurs is at the (D)TLS layer; that is, (1) the Call Home DOTS server
        acts as a DTLS client and the Call Home DOTS client acts as a DTLS
        server or (2) the Call Home DOTS server acts as a TLS client
        initiating the underlying TCP connection and the Call Home DOTS client
        acts as a TLS server. The Call Home DOTS server initiates (D)TLS
        handshake to the Call Home DOTS client.</t>

        <t>For example, a home network element (e.g., home router) co-located
        with a Call Home DOTS server is the (D)TLS client. That is, the Call
        Home DOTS server assumes the role of the (D)TLS client, but the
        network element's role as a DOTS server remains the same.</t>

        <t>Existing certificate chains and mutual authentication mechanisms
        between the DOTS agents are unaffected by the Call Home function. From
        a deployment standpoint, and given the scale of Call Home DOTS servers
        that may be involved, enabling means for automating the provisioning
        of credentials on Call Home DOTS servers to authenticate to the Call
        Home DOTS client is encouraged. It is out of the scope of this
        document to elaborate on these means.</t>

        <t><xref target="signalch"></xref> illustrates a sample DOTS Call Home
        flow exchange:</t>

        <t><figure align="center" anchor="signalch"
            title="DOTS Signal Channel Call Home Sequence Diagram">
            <artwork><![CDATA[           +-----------+                        +-----------+
           | Call Home |                        | Call Home |
           |    DOTS   |                        |    DOTS   |
           |   server  |                        |   client  |
           +-----+-----+                        +-----+-----+
           (D)TLS client                        (D)TLS server
                 |                                    |
                 |         1. (D)TLS connection       |
                 |----------------------------------->|
                 |         2. Mitigation request      |
                 |<-----------------------------------|
                 |              ...                   |
]]></artwork>
          </figure></t>

        <t>The DOTS signal channel Call Home procedure is as follows:</t>

        <t><list style="numbers">
            <t>If UDP transport is used, the Call Home DOTS server begins by
            initiating a DTLS connection to the Call Home DOTS client.<vspace
            blankLines="1" />If TCP is used, the Call Home DOTS server begins
            by initiating a TCP connection to the Call Home DOTS client. Once
            connected, the Call Home DOTS server continues to initiate a TLS
            connection to the Call Home DOTS client.<vspace
            blankLines="1" />Peer DOTS agents may have mutual agreement to use
            a specific port number, such as by explicit configuration or
            dynamic discovery <xref target="RFC8973"></xref>. The interaction
            between the base DOTS signal channel and the Call Home is
            discussed in <xref target="app"></xref>.<vspace
            blankLines="1" />The Happy Eyeballs mechanism explained in Section
            4.3 of <xref target="I-D.ietf-dots-rfc8782-bis"></xref> is used
            for initiating (D)TLS connections.</t>

            <t>Using this (D)TLS connection, the Call Home DOTS client may
            request, withdraw, or retrieve the status of mitigation requests.
            The Call Home DOTS client supplies the source information by means
            of new attributes defined in <xref target="mitigation"></xref>.
            <vspace blankLines="1" />The Heartbeat mechanism used for the DOTS
            Call Home deviates from the one defined in Section 4.7 of <xref
            target="I-D.ietf-dots-rfc8782-bis"></xref>. <xref
            target="hb"></xref> specifies the behavior to be followed by Call
            Home DOTS agents.</t>
          </list></t>

        <t></t>
      </section>

      <section title="DOTS Signal Channel Variations">
        <t></t>

        <section anchor="hb" title="Heartbeat Mechanism">
          <t>Once the (D)TLS section is established between the DOTS agents,
          the Call Home DOTS client contacts the Call Home DOTS server to
          retrieve the session configuration parameters (Section 4.5 of <xref
          target="I-D.ietf-dots-rfc8782-bis"></xref>). The Call Home DOTS
          server adjusts the 'heartbeat-interval' to accommodate binding
          timers used by on-path NATs and firewalls. Heartbeats will be then
          exchanged by the DOTS agents following the instructions retrieved
          using the signal channel session configuration exchange.</t>

          <t>It is the responsibility of Call Home DOTS servers to ensure that
          on-path translators/firewalls are maintaining a binding so that the
          same external IP address and/or port number is retained for the DOTS
          signal channel session. A Call Home DOTS client MAY trigger their
          heartbeat requests immediately after receiving heartbeat probes from
          its peer Call Home DOTS server.</t>

          <t>When an outgoing attack that saturates the outgoing link from the
          Call Home DOTS server is detected and reported by a Call Home DOTS
          client, the latter MUST continue to use the DOTS signal channel even
          if no traffic is received from the Call Home DOTS server.</t>

          <t>If the Call Home DOTS server receives traffic from the Call Home
          DOTS client, the Call Home DOTS server MUST continue to use the DOTS
          signal channel even if the missing heartbeats allowed threshold
          ('missing-hb-allowed') is reached.</t>

          <t>If the Call Home DOTS server does not receive any traffic from
          the peer Call Home DOTS client during the time span required to
          exhaust the maximum 'missing-hb-allowed' threshold, the Call Home
          DOTS server concludes the session is disconnected. Then, the Call
          Home DOTS server MUST try to establish a new DOTS signal channel
          session, preferably by resuming the (D)TLS session.</t>
        </section>

        <section anchor="redirect" title="Redirected Signaling">
          <t>A Call Home DOTS server MUST NOT support the Redirected Signaling
          mechanism as specified in Section 4.6 of <xref
          target="I-D.ietf-dots-rfc8782-bis"></xref> (i.e., a 5.03 response
          that conveys an alternate DOTS server's FQDN or alternate DOTS
          server's IP address(es)). A Call Home DOTS client MUST silently
          discard such message as only a Call Home DOTS server can initiate a
          new (D)TLS connection.</t>

          <t>If a Call Home DOTS client wants to redirect a Call Home DOTS
          server to another Call Home DOTS client, it MUST send a
          Non-confirmable PUT request to the predefined resource
          &ldquo;.well-known/dots/redirect&rdquo; with the following
          attributes in the body of the PUT request:</t>

          <t><list style="hanging">
              <t hangText="alt-ch-client:">The FQDN of an alternate Call Home
              DOTS client. It is also presented as reference identifier for
              authentication purposes.<vspace blankLines="1" />This is a
              mandatory attribute for DOTS signal Call Home. It MUST NOT be
              used for base DOTS signal channel operations.</t>

              <t hangText="alt-ch-client-record:">List of IP addresses for the
              alternate Call Home DOTS client. If no 'alt-ch-client-record' is
              provided, the Call Home DOTS server passes the 'alt-ch-client'
              name to a name resolution library to retrieve one or more IP
              addresses of the alternate Call Home DOTS client.<vspace
              blankLines="1" />This is an optional attribute for DOTS signal
              Call Home. It MUST NOT be used for base DOTS signal channel
              operations.</t>

              <t hangText="ttl:">The Time to live (TTL) of the alternate Call
              Home DOTS client. That is, the time interval that the alternate
              Call Home DOTS client may be cached for use by a Call Home DOTS
              server.<vspace blankLines="1" />This is an optional attribute
              for DOTS signal Call Home. It MUST NOT be used for base DOTS
              signal channel operations.</t>
            </list></t>

          <t>On receipt of this PUT request, the Call Home DOTS server
          responds with a 2.01 (Created), closes this connection and
          establishes a connection with the new Call Home DOTS client. The
          processing of the TTL is defined in Section 4.6 of <xref
          target="I-D.ietf-dots-rfc8782-bis"></xref>. If the Call Home DOTS
          server cannot service the PUT request, the response is rejected with
          a 4.00 (Bad Request).</t>

          <t><xref target="red-example"></xref> shows a PUT request example to
          convey the alternate Call Home DOTS client
          'alt-call-home-client.example' together with its IP addresses
          2001:db8:6401::1 and 2001:db8:6401::2. The validity of this
          alternate Call Home DOTS client is 10 minutes.</t>

          <t><figure anchor="red-example"
              title="Example of a PUT Request for Redirected Signaling">
              <artwork><![CDATA[   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "redirect"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "mid=123"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-signal-channel:redirected-signal": {
       "ietf-dots-call-home:alt-ch-client": 
                     "alt-call-home-client.example",
       "ietf-dots-call-home:alt-ch-client-record": [
          "2001:db8:6401::1",
          "2001:db8:6401::2"
        ],
       "ietf-dots-call-home:ttl": 600
   }
]]></artwork>
            </figure></t>
        </section>
      </section>

      <section title="DOTS Signal Channel Extension">
        <section anchor="mitigation" title="Mitigation Request">
          <t>This specification extends the mitigation request defined in
          Section 4.4.1 of <xref target="I-D.ietf-dots-rfc8782-bis"></xref> to
          convey the attack source information (e.g., source prefixes, source
          port numbers). The DOTS client conveys the following new parameters
          in the CBOR body of the mitigation request:<list style="hanging">
              <t hangText="source-prefix:">A list of attacker IP prefixes used
              to attack the target. Prefixes are represented using Classless
              Inter-Domain Routing (CIDR) notation <xref target="RFC4632">BCP
              122 </xref>. <vspace blankLines="1" />As a reminder, the prefix
              length MUST be less than or equal to 32 (or 128) for IPv4 (or
              IPv6).<vspace blankLines="1" />The prefix list MUST NOT include
              broadcast, loopback, or multicast addresses. These addresses are
              considered as invalid values. Note that link-local addresses are
              allowed. The Call Home DOTS client MUST validate that attacker
              prefixes are within the scope of the Call Home DOTS server
              domain (e.g., prefixes assigned to the Call Home DOTS server
              domain or networks it services). This check is meant to avoid
              contacting Call Home DOTS servers that are not entitled to
              enforce actions on specific prefixes.<vspace
              blankLines="1" />This is an optional attribute for the base DOTS
              signal channel operations.</t>

              <t hangText="source-port-range:">A list of port numbers used by
              the attack traffic flows. <vspace blankLines="1" />A port range
              is defined by two bounds, a lower port number (lower-port) and
              an upper port number (upper-port). When only 'lower-port' is
              present, it represents a single port number. <vspace
              blankLines="1" />For TCP, UDP, Stream Control Transmission
              Protocol (SCTP) <xref target="RFC4960"></xref>, or Datagram
              Congestion Control Protocol (DCCP) <xref
              target="RFC4340"></xref>, a range of ports can be any subrange
              of 0-65535, for example, 0-1023, 1024-65535, or 1024-49151.
              <vspace blankLines="1" />This is an optional attribute for the
              base DOTS signal channel operations.</t>

              <t hangText="source-icmp-type-range:">A list of ICMP types used
              by the attack traffic flows. An ICMP type range is defined by
              two bounds, a lower ICMP type (lower-type) and an upper ICMP
              type (upper-type). When only 'lower-type' is present, it
              represents a single ICMP type. Both ICMP <xref
              target="RFC0792"></xref> and ICMPv6 <xref
              target="RFC4443"></xref> types are supported. Whether ICMP or
              ICMPv6 types are to be used is determined by the address family
              of the 'target-prefix'. <vspace blankLines="1" />This is an
              optional attribute for the base DOTS signal channel
              operations.</t>
            </list></t>

          <t>The 'source-prefix' parameter is a mandatory attribute when the
          attack traffic information is signaled by a Call Home DOTS client
          (i.e., the Call Home scenario depicted in <xref
          target="signalch"></xref>). The 'target-prefix' attribute MUST be
          included in the mitigation request signaling the attack information
          to a Call Home DOTS server. The 'target-uri' or 'target-fqdn'
          parameters can be included in a mitigation request for diagnostic
          purposes to notify the Call Home DOTS server domain administrator,
          but SHOULD NOT be used to determine the target IP addresses.
          'alias-name' is unlikely to be conveyed in a Call Home mitigation
          request given that a target may be any IP resource and that there is
          no incentive for a Call Home DOTS server (embedded, for example, in
          a CPE) to maintain aliases.</t>

          <t>In order to help attack source identification by a Call Home DOTS
          server, the Call Home DOTS client SHOULD include in its mitigation
          request additional information such as 'source-port-range' or
          'source-icmp-type-range' to disambiguate nodes sharing the same
          'source-prefix'. IPv6 addresses/prefixes are sufficient to uniquely
          identify a network endpoint, without need for port numbers or ICMP
          type information. While this is also possible for IPv4, it is much
          less often the case than for IPv6. More address sharing implications
          on the setting of source information ('source-prefix',
          'source-port-range') are discussed in <xref
          target="nat"></xref>.</t>

          <t>Only immediate mitigation requests (i.e., 'trigger-mitigation'
          set to 'true') are allowed; Call Home DOTS clients MUST NOT send
          requests with 'trigger-mitigation' set to 'false'. Such requests
          MUST be discarded by the Call Home DOTS server with a 4.00 (Bad
          Request).</t>

          <t>An example of a mitigation request sent by a Call Home DOTS
          client is shown in <xref target="example"></xref>.<figure
              anchor="example"
              title="An Example of Mitigation Request Issued by a Call Home DOTS Client">
              <artwork align="left"><![CDATA[  Header: PUT (Code=0.03)
  Uri-Path: ".well-known"
  Uri-Path: "dots"
  Uri-Path: "mitigate"
  Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
  Uri-Path: "mid=56"
  Content-Format: "application/dots+cbor"

  {
    "ietf-dots-signal-channel:mitigation-scope": {
      "scope": [
        {
          "target-prefix": [
             "2001:db8:c000::/128"
           ],
          "ietf-dots-call-home:source-prefix": [
             "2001:db8:123::1/128"
           ],
          "lifetime": 3600
        }
      ]
    }
  }]]></artwork>
            </figure></t>

          <t>The Call Home DOTS server MUST check that the 'source-prefix' is
          within the scope of the Call Home DOTS server domain. Note that in a
          DOTS Call Home scenario, the Call Home DOTS server considers, by
          default, that any routeable IP prefix enclosed in 'target-prefix' is
          within the scope of the Call Home DOTS client. Invalid mitigation
          requests are handled as per Section 4.4.1 of <xref
          target="I-D.ietf-dots-rfc8782-bis"></xref>.<list style="empty">
              <t>Note: These validation checks do not apply when the source
              information is included as a hint in the context of the base
              DOTS signal channel.</t>
            </list></t>

          <t>The Call Home DOTS server domain administrator consent MAY be
          required to block the traffic from the compromised device to the
          attack target. An implementation MAY have a configuration knob to
          block the traffic from the compromised device to the attack target
          with or without DOTS server domain administrator consent.</t>

          <t>If a consent from the Call Home DOTS server domain administrator
          is required, the Call Home DOTS server replies with 2.01 (Created)
          and 'status' code set to 1 (attack-mitigation-in-progress). Then,
          the mechanisms defined in Section 4.4.2 of <xref
          target="I-D.ietf-dots-rfc8782-bis"></xref> are followed by the DOTS
          agents to update the mitigation status. Particularly, if the attack
          traffic is blocked, the Call Home DOTS server informs the Call Home
          DOTS client that the attack is being mitigated (i.e., by setting the
          'status' code to 2 (attack-successfully-mitigated)).</t>

          <t>If the attack traffic information is identified by the Call Home
          DOTS server or the Call Home DOTS server domain administrator as
          legitimate traffic, the mitigation request is rejected with a 4.09
          (Conflict) (e.g., when no consent is required from an administrator)
          or a notification message with the 'conflict-clause' (Section 4.4.1
          of <xref target="I-D.ietf-dots-rfc8782-bis"></xref>) set to the
          following new value:</t>

          <t><list style="hanging">
              <t hangText="4:">Mitigation request rejected. This code is
              returned by the DOTS server to indicate the attack traffic has
              been classified as legitimate traffic.</t>
            </list></t>

          <t>Once the request is validated by the Call Home DOTS server,
          appropriate actions are enforced to block the attack traffic within
          the source network. For example, if the Call Home DOTS server is
          embedded in a CPE, it can program the packet processor to punt all
          the traffic from the compromised device to the target to slow path.
          The CPE inspects the punted slow path traffic to detect and block
          the outgoing DDoS attack traffic or quarantine the device (e.g.,
          using MAC level filtering) until it is remediated, and notifies the
          CPE administrator about the compromised device. Note that the Call
          Home DOTS client is informed about the progress of the attack
          mitigation following the rules in Section 4.4.2 of <xref
          target="I-D.ietf-dots-rfc8782-bis"></xref>.</t>

          <t>The DOTS agents follow the same procedures specified in <xref
          target="I-D.ietf-dots-rfc8782-bis"></xref> for managing a mitigation
          request.</t>
        </section>

        <section anchor="nat" title="Address Sharing Considerations">
          <t><xref target="ex1"></xref> depicts an example of a network
          provider that hosts a Call Home DOTS client and deploys a Carrier
          Grade NAT (CGN) between the DOTS client domain and DOTS server
          domain. In such cases, communicating an external IP address in a
          mitigation request by a Call Home DOTS client is likely to be
          discarded by the Call Home DOTS server because the external IP
          address is not visible locally to the Call Home DOTS server (<xref
          target="ex1"></xref>). The Call Home DOTS server is only aware of
          the internal IP addresses/prefixes bound to its domain (i.e., those
          used in the Internal Realm shown in <xref target="ex1"></xref>).
          Thus, Call Home DOTS clients that are aware of the presence of
          on-path CGNs MUST NOT include the external IP address and/or port
          number identifying the suspect attack source (i.e., those used in
          the External Realm shown in <xref target="ex1"></xref>), but MUST
          include the internal IP address and/or port number. To that aim, the
          Call Home DOTS client SHOULD rely on mechanisms, such as <xref
          target="RFC8512"></xref> or <xref target="RFC8513"></xref>, to
          retrieve the internal IP address and port number which are mapped to
          an external IP address and port number. For the particular case of
          NAT64 <xref target="RFC6146"></xref>, if the target address is an
          IPv4 address, the IPv4-converted IPv6 address of this target address
          <xref target="RFC6052"></xref> SHOULD be used.</t>

          <t><figure align="center" anchor="ex1"
              title="Example of a CGN between DOTS Domains">
              <artwork align="center"><![CDATA[  N |        .-------------------. 
  E |       (                     )-.
  T |     .'                         ' 
  W |     (        Call Home          ) 
  O |      (      DOTS client       -'
  R |       '-(                     )
  K |          '-------+-----------' 
    |                  |      
  P |                  |
  R |              +---+---+
  O |              |  CGN  |        External Realm
  V |..............|       |......................         
  I |              |       |        Internal Realm
  D |              +---+---+        
  E |                  |
  R |                  |
   ---                 |   
             .---------+---------. 
            (                     )-.
          .'     Source Network      ' 
          (                           ) 
           (        Call Home        -'
            '-(    DOTS server      )
               '------+------------' 
                      |  
                +-----+-------+
                |Attack Source|
                +-------------+
]]></artwork>
            </figure></t>

          <t>If a MAP Border Relay <xref target="RFC7597"></xref> or lwAFTR
          <xref target="RFC7596"></xref> is enabled in the provider's domain
          to service its customers, the identification of an attack source
          bound to an IPv4 address/prefix MUST also rely on source port
          numbers because the same IPv4 address is assigned to multiple
          customers. The port information is required to unambiguously
          identify the source of an attack.</t>

          <t>If a translator is enabled on the boundaries of the domain
          hosting the Call Home DOTS server (e.g., a CPE with NAT enabled as
          shown in Figures <xref format="counter" target="ex2"></xref> and
          <xref format="counter" target="ex2b"></xref>), the Call Home DOTS
          server uses the attack traffic information conveyed in a mitigation
          request to find the internal source IP address of the compromised
          device and blocks the traffic from the compromised device traffic to
          the attack target until the mitigation request is withdrawn. The
          Call Home DOTS server proceeds with a NAT mapping table lookup using
          the attack information (or a subset thereof) as a key. The lookup
          can be local (<xref target="ex2"></xref>) or via a dedicated
          administration interface that is offered by the CPE (<xref
          target="ex2b"></xref>). This identification allows the suspicious
          device to be isolated while avoiding disturbances of other
          services.</t>

          <t><figure align="center" anchor="ex2"
              title="Example of a DOTS Server Domain with a NAT Embedded in a CPE">
              <artwork align="center"><![CDATA[             .-------------------. 
            (                     )-.
          .'   Network Provider (DMS)' 
          (                           ) 
           (        Call Home       -'
            '-(    DOTS client      )
               '-------+-----------' 
                       |
   ---             +---+---+   
  S |              |  CPE  |  External Realm
  O |..............|       |................         
  U |              |  NAT  |  Internal Realm
  R |              +---+---+        
  C |                  |   
  E |        .---------+---------. 
    |       (                     )-.
  N |     .'                         ' 
  E |     (          Call Home        ) 
  T |      (        DOTS server     -'
  W |       '-(                     )
  O |          '-------+-----------' 
  R |                  |  
  K |           +------+------+
    |           |Attack Source|                           
                +-------------+
]]></artwork>
            </figure></t>

          <t><figure align="center" anchor="ex2b"
              title="Example of a Call Home DOTS Server and a NAT Embedded in a CPE">
              <artwork align="center"><![CDATA[             .-------------------. 
            (                     )-.
          .'  Network Provider (DMS) ' 
          (                           ) 
           (        Call Home       -'
            '-(    DOTS client      )
               '---------+---------' 
                         |
   ---             +-----+-----+   
  S |              |  CPE/NAT  |  External Realm
  O |..............|           |................
  U |              | Call Home |  Internal Realm        
  R |              |DOTS server| 
  C |              +-----+-----+        
  E |                    |   
    |        .-----------+-------. 
    |       (                     )-.
  N |     .'                         ' 
  E |     (     Local Area Network    ) 
  T |      (                        -'
  W |       '-(                     )
  O |          '--------+----------' 
  R |                   |  
  K |            +------+------+
    |            |Attack Source|                           
                 +-------------+
]]></artwork>
            </figure></t>

          <t>If for any reason address sharing is deployed in both source and
          provider networks, both Call Home DOTS agents have to proceed with
          address mapping lookups following the behavior specified in
          reference to <xref target="ex1"></xref> (network provider) and
          Figures <xref format="counter" target="ex2"></xref> and <xref
          format="counter" target="ex2b"></xref> (source network).</t>
        </section>
      </section>
    </section>

    <section anchor="YANG" title="DOTS Signal Call Home YANG Module ">
      <section title="Tree Structure">
        <t>This document augments the "ietf-dots-signal-channel" (dots-signal)
        DOTS signal YANG module defined in <xref
        target="I-D.ietf-dots-rfc8782-bis"></xref> for signaling the attack
        traffic information. This document defines the YANG module
        "ietf-dots-call-home", which has the following tree structure:<figure>
            <artwork><![CDATA[module: ietf-dots-call-home

  augment-structure /dots-signal:dots-signal/dots-signal:message-type
                    /dots-signal:mitigation-scope/dots-signal:scope:
    +-- source-prefix*            inet:ip-prefix
    +-- source-port-range* [lower-port]
    |  +-- lower-port    inet:port-number
    |  +-- upper-port?   inet:port-number
    +-- source-icmp-type-range* [lower-type]
       +-- lower-type    uint8
       +-- upper-type?   uint8
  augment-structure /dots-signal:dots-signal/dots-signal:message-type
                    /dots-signal:redirected-signal:
    +-- (type)?
       +--:(call-home-only)
          +-- alt-ch-client           inet:domain-name
          +-- alt-ch-client-record*   inet:ip-address
          +-- ttl?                    uint32
]]></artwork>
          </figure></t>
      </section>

      <section title="YANG/JSON Mapping Parameters to CBOR">
        <t>The YANG/JSON mapping parameters to CBOR are listed in Table
        1.<list style="symbols">
            <t>Note: Implementers must check that the mapping output provided
            by their YANG-to-CBOR encoding schemes is aligned with the content
            of Table 1.</t>
          </list></t>

        <t><figure align="center">
            <artwork><![CDATA[+--------------------+------------+------+---------------+--------+
| Parameter Name     | YANG       | CBOR | CBOR Major    | JSON   |
|                    | Type       | Key  |    Type &     | Type   |
|                    |            |      | Information   |        |
+====================+============+======+===============+========+
|ietf-dots-call-home:| leaf-list  |      |               |        |
| source-prefix      | inet:      | TBA1 | 4 array       | Array  |
|                    |  ip-prefix |      | 3 text string | String |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:|            |      |               |        |
| source-port-range  | list       | TBA2 | 4 array       | Array  |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:|            |      |               |        |
| source-icmp-type-  | list       | TBA3 | 4 array       | Array  |
|  range             |            |      |               |        |
+--------------------+------------+------+---------------+--------+
| lower-type         | uint8      | TBA4 | 0 unsigned    | Number |
+--------------------+------------+------+---------------+--------+
| upper-type         | uint8      | TBA5 | 0 unsigned    | Number |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:| inet:      |      |               |        |
| alt-ch-client      | domain-name| TBA6 | 3 text string | String |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:| leaf-list  | TBA7 | 4 array       | Array  |
| alt-ch-client-     | inet:      |      |               |        |
|  record            |  ip-address|      | 3 text string | String |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:|            |      |               |        |
| ttl                | uint32     | TBA8 | 0 unsigned    | Number |
+--------------------+------------+------+---------------+--------+

           Table 1: YANG/JSON Mapping Parameters to CBOR
]]></artwork>
          </figure></t>

        <t>The YANG/JSON mappings to CBOR for 'lower-port' and 'upper-port'
        are already defined in Table 5 of <xref
        target="I-D.ietf-dots-rfc8782-bis"></xref>.</t>
      </section>

      <section title="YANG Module ">
        <t>This module uses the common YANG types defined in <xref
        target="RFC6991"></xref> and the data structure extension defined in
        <xref target="RFC8791"></xref>.</t>

        <t><figure>
            <artwork><![CDATA[<CODE BEGINS> file "ietf-dots-call-home@2020-12-02.yang"
module ietf-dots-call-home {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";
  prefix dots-call-home;

  import ietf-inet-types {
    prefix inet;
    reference
      "Section 4 of RFC 6991";
  }
  import ietf-dots-signal-channel {
    prefix dots-signal;
    reference
      "RFC YYYY: Distributed Denial-of-Service Open Threat 
                 Signaling (DOTS) Signal Channel Specification";
  }
  import ietf-yang-structure-ext {
    prefix sx;
    reference
      "RFC 8791: YANG Data Structure Extensions";
  }

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

     Author:  Konda, Tirumaleswar Reddy
              <mailto:TirumaleswarReddy_Konda@McAfee.com>;

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

     Author:  Jon Shallow
              <mailto:ietf-supjps@jpshallow.com>";
  description
    "This module contains YANG definitions for the signaling
     messages exchanged between a DOTS client and a DOTS server
     for the Call Home deployment scenario.

     Copyright (c) 2021 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; see
     the RFC itself for full legal notices.";

  revision 2020-12-02 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Signal Channel Call Home";
  }
  sx:augment-structure "/dots-signal:dots-signal"
                     + "/dots-signal:message-type"
                     + "/dots-signal:mitigation-scope"
                     + "/dots-signal:scope" {
    description
      "Attack source details.";
    leaf-list source-prefix {
      type inet:ip-prefix;
      description
        "IPv4 or IPv6 prefix identifying the attack source(s).";
    }
    list source-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;
        description
          "Lower port number of the port range.";
      }
      leaf upper-port {
        type inet:port-number;
        must '. >= ../lower-port' {
          error-message
            "The upper port number must be greater than
             or equal to lower port number.";
        }
        description
          "Upper port number of the port range.";
      }
    }
    list source-icmp-type-range {
      key "lower-type";
      description
        "ICMP/ICMPv6 type range. When only lower-type is
         present, it represents a single ICMP/ICMPv6 type.

         The address family of the target-prefix is used 
         to determine whether ICMP or ICMPv6 are used.";
      leaf lower-type {
        type uint8;
        description
          "Lower ICMP/ICMPv6 type of the ICMP type range.";
        reference
          "RFC 792: Internet Control Message Protocol
           RFC 4443: Internet Control Message Protocol (ICMPv6)
                     for Internet Protocol Version 6 (IPv6)
                     Specification.";
      }
      leaf upper-type {
        type uint8;
        must '. >= ../lower-type' {
          error-message
            "The upper ICMP/ICMPv6 type must be greater than
             or equal to lower ICMP type.";
        }
        description
          "Upper type of the ICMP type range.";
        reference
          "RFC 792: Internet Control Message Protocol
           RFC 4443: Internet Control Message Protocol (ICMPv6)
                     for Internet Protocol Version 6 (IPv6)
                     Specification.";
      }
    }
  }
  sx:augment-structure "/dots-signal:dots-signal"
                     + "/dots-signal:message-type"
                     + "/dots-signal:redirected-signal" {
    description
      "Augments the redirected signal to communicate an 
       alternate Call Home DOTS client.";
    choice type {
      description
        "Indicates the type of the DOTS session (e.g., base
         DOTS signal channel, DOTS Call Home).";
      case call-home-only {
        description
          "These attributes appear only in a call home signal
           channel message from a Call Home DOTS client
           to a Call Home DOTS server.";
        leaf alt-ch-client {
          type inet:domain-name;
          mandatory true;
          description
            "FQDN of an alternate Call Home DOTS client. 

             This name is also presented as reference 
             identifier for authentication purposes.";
        }
        leaf-list alt-ch-client-record {
          type inet:ip-address;
          description
            "List of IP addresses for the alternate Call 
             Home DOTS client.

             If this data node is not present, a Call Home
             DOTS server resolves the alt-ch-client into 
             one or more IP addresses.";
        }
        leaf ttl {
          type uint32;
          units "seconds";
          description
            "The Time to live (TTL) of the alternate Call Home
             DOTS client.";
          reference
            "Section 4.6 of RFC YYYY";
        }
      }
    }
  }
}
<CODE ENDS>]]></artwork>
          </figure></t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t></t>

      <section anchor="map" title="DOTS Signal Channel CBOR Mappings Registry">
        <t>This specification registers the following comprehension-optional
        parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key Values"
        registry <xref target="Key-Map"></xref>.</t>

        <t><list style="symbols">
            <t>Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys
            are assigned from the 32768-49151 range.</t>
          </list><figure>
            <artwork><![CDATA[   +--------------------+-------+-------+------------+---------------+
   | Parameter Name     | CBOR  | CBOR  | Change     | Specification |
   |                    | Key   | Major | Controller | Document(s)   |
   |                    | Value | Type  |            |               |
   +====================+=======+=======+============+===============+
   |ietf-dots-call-home:|       |       |            |               |
   | source-prefix      |  TBA1 |   4   |    IESG    |   [RFCXXXX]   |
   +--------------------+-------+-------+------------+---------------+
   |ietf-dots-call-home:|       |       |            |               |
   | source-port-range  |  TBA2 |   4   |    IESG    |   [RFCXXXX]   |
   +--------------------+-------+-------+------------+---------------+
   |ietf-dots-call-home:|       |       |            |               |
   | source-icmp-type-  |  TBA3 |   4   |    IESG    |   [RFCXXXX]   |
   |  range             |       |       |            |               |
   +--------------------+-------+-------+------------+---------------+
   | lower-type         |  TBA4 |   0   |    IESG    |   [RFCXXXX]   |
   +--------------------+-------+-------+------------+---------------+
   | upper-type         |  TBA5 |   0   |    IESG    |   [RFCXXXX]   |
   +--------------------+-------+-------+------------+---------------+
   |ietf-dots-call-home:|       |       |            |               |
   | alt-ch-client      |  TBA6 |   3   |    IESG    |   [RFCXXXX]   |
   +--------------------+-------+-------+------------+---------------+
   |ietf-dots-call-home:|       |       |            |               |
   |alt-ch-client-record|  TBA7 |   4   |    IESG    |   [RFCXXXX]   |
   +--------------------+-------+-------+------------+---------------+
   |ietf-dots-call-home:|       |       |            |               |
   | ttl                |  TBA8 |   0   |    IESG    |   [RFCXXXX]   |
   +--------------------+-------+-------+------------+---------------+

           Table 2: Assigned DOTS Signal Channel CBOR Key Values
]]></artwork>
          </figure></t>

        <t></t>
      </section>

      <section title="New DOTS Conflict Cause">
        <t>This document requests IANA to assign a new code from the "DOTS
        Signal Channel Conflict Cause Codes" registry <xref
        target="Cause"></xref>.</t>

        <texttable>
          <ttcol>Code</ttcol>

          <ttcol>Label</ttcol>

          <ttcol>Description</ttcol>

          <ttcol>Reference</ttcol>

          <c>4 (TBA9)</c>

          <c>request-rejected-legitimate-traffic</c>

          <c>Mitigation request rejected. This code is returned by the DOTS
          server to indicate the attack traffic has been classified as
          legitimate traffic.</c>

          <c>[RFCXXXX]</c>
        </texttable>

        <t></t>
      </section>

      <section anchor="yang" title="DOTS Signal Call Home YANG Module">
        <t>This document requests IANA to register 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-call-home
         Registrant Contact: The IETF.
         XML: N/A; the requested URI is an XML namespace.
]]></artwork>
          </figure>This document requests IANA to register the following YANG
        module in the "YANG Module Names" subregistry <xref
        target="RFC6020"></xref> within the "YANG Parameters" registry:<figure>
            <artwork><![CDATA[         name: ietf-dots-call-home
         namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home
         maintained by IANA: N
         prefix: dots-call-home
         reference: RFC XXXX
]]></artwork>
          </figure></t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This document deviates from classic DOTS signal channel usage by
      having the DOTS server initiate the (D)TLS connection. DOTS signal
      channel related security considerations discussed in Section 11 of <xref
      target="I-D.ietf-dots-rfc8782-bis"></xref> MUST be considered. DOTS
      agents MUST authenticate each other using (D)TLS before a DOTS signal
      channel session is considered valid.</t>

      <t>The Call Home function enables a Call Home DOTS server to be
      reachable by only the intended Call Home DOTS client. Appropriate
      filters (e.g., access control lists) can be installed on the Call Home
      DOTS server and network between the Call Home DOTS agents so that only
      communications from a trusted Call Home DOTS client to the Call Home
      DOTS server are allowed. These filters can be automatically installed by
      a Call Home DOTS server based on the configured or discovered peer Call
      Home DOTS client(s).</t>

      <t>An attacker may launch a DoS attack on the DOTS client by having it
      perform computationally expensive operations, before deducing that the
      attacker doesn't possess a valid key. For instance, in TLS 1.3 <xref
      target="RFC8446"></xref>, the ServerHello message contains a Key Share
      value based on an expensive asymmetric key operation for key
      establishment. Common precautions mitigating DoS attacks are
      recommended, such as temporarily adding to a drop-list the source
      address after a set number of unsuccessful authentication attempts.</t>

      <t>The DOTS Call Home signal channel can be misused by a misbehaving
      Call Home DOTS client by arbitrarily signalling legitimate traffic as
      being attack traffic or falsifying mitigation signals so that some
      sources are disconnected or some traffic is rate-limited. Such
      misbehaving Call Home DOTS clients may include sources identified by IP
      addresses that are used for internal use only (that is, these addresses
      are not visible outside a Call Home DOTS server domain). Absent explicit
      policy (e.g., the Call Home DOTS client and server are managed by the
      same administrative entity), such requests should be discarded by the
      Call Home DOTS server. More generally, Call Home DOTS servers should not
      blindly trust mitigation requests from Call Home DOTS clients. For
      example, Call Home DOTS servers could use the attack flow information
      contained in a mitigation request to enable a full-fledged packet
      inspection function to inspect all the traffic from the compromised
      device to the target, or could re-direct the traffic from the
      potentially compromised device to the target towards a DDoS mitigation
      system that can scrub the suspicious traffic, without blindly blocking
      all traffic from the indicated attack source to the target. Call Home
      DOTS servers can also seek the consent of DOTS server domain
      administrator to block the traffic from the potentially compromised
      device to the target (see <xref target="mitigation"></xref>). Means to
      seek the consent are implementation-specific.</t>

      <t>Call Home DOTS agents may interact with on-path address sharing
      functions to retrieve an internal IP addresss/external IP address
      mapping (<xref target="nat"></xref>) identifying an attack source.
      Blocking access or manipulating the mapping information will complicate
      DDoS attack mitigation close to an attack source. Additional security
      considerations are specific to the actual mechanism used to access that
      mapping (refer, e.g., to Section 4 of <xref target="RFC8512"></xref> or
      Section 4 of <xref target="RFC8513"></xref>).</t>
    </section>

    <section title="Privacy Considerations">
      <t>The considerations discussed in <xref target="RFC6973"></xref> were
      taken into account to assess whether the DOTS Call Home introduces
      privacy threats.</t>

      <t>Concretely, the protocol does not leak any new information that can
      be used to ease surveillance. In particular, the Call Home DOTS server
      is not required to share information that is local to its network (e.g.,
      internal identifiers of an attack source) with the Call Home DOTS
      client. Also, the recommended data to be included in Call Home DOTS
      messages is a subset of the Layer 3/Layer 4 information that can be
      learnt from the overall traffic flows that exit the Call Home DOTS
      server domain. Furthermore, Call Home DOTS clients do not publicly
      reveal attack identification information; that information is encrypted
      and only shared with an authorized entity in the domain to which the IP
      address/prefix is assigned, from which an attack was issued.</t>

      <t>The DOTS Call Home does not preclude the validation of mitigation
      requests received from a Call Home DOTS client. For example, a security
      service running on the CPE may require an administrator's consent before
      the CPE acts upon the mitigation request indicated by the Call Home DOTS
      client. How the consent is obtained is out of scope of this
      document.</t>

      <t>Note that a Call Home DOTS server can seek an administrator's
      consent, validate the request by inspecting the relevant traffic for
      attack signatures, or proceed with both courses of action.</t>

      <t>The DOTS Call Home is only advisory in nature. Concretely, the DOTS
      Call Home does not impose any action to be enforced within the network
      hosting an attack source; it is up to the Call Home DOTS server (and/or
      network administrator) to decide whether and which actions are
      required.</t>

      <t>Moreover, the DOTS Call Home avoids misattribution by appropriately
      identifying the network to which a suspect attack source belongs to
      (e.g., address sharing issues discussed in <xref
      target="mitigation"></xref>).</t>

      <t>Triggers to send a DOTS mitigation request to a Call Home DOTS server
      are deployment-specific. For example, a Call Home DOTS client may rely
      on the output of some DDoS detection systems (flow exports or similar
      functions) deployed within the DOTS client domain to detect potential
      outbound DDoS attacks or on abuse claims received from remote victim
      networks. These systems may be misused to track users and infer their
      activities. Such misuses are not required to achieve the functionality
      defined in this document (that is, protect the Internet and avoid
      altering the IP reputation of source networks). It is out of the scope
      to identify privacy threats specific to a given attack detection
      technology. The reader may refer, for example, to Section 11.8 of <xref
      target="RFC7011"></xref>.</t>
    </section>

    <section anchor="contr" title="Contributors">
      <t>The following individuals have contributed to this document:</t>

      <figure>
        <artwork><![CDATA[   Joshi Harsha
   McAfee, Inc.
   Embassy Golf Link Business Park
   Bangalore, Karnataka  560071
   India

   Email: harsha_joshi@mcafee.com

   Wei Pan
   Huawei Technologies
   China

   Email: william.panwei@huawei.com
]]></artwork>
      </figure>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, T&ouml;ma
      Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments.</t>

      <t>Benjamin Kaduk's AD review is valuable. Many thanks to him for the
      detailed review.</t>

      <t>Thanks to Radia Perlman and David Schinazi for the directorate
      reviews.</t>

      <t>Thanks to Ebben Aries for the yangdoctors review.</t>

      <t>Thanks to &Eacute;ric Vyncke, Roman Danyliw, Barry Leiba, Robert
      Wilton, and Erik Kline for the IESG review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-dots-rfc8782-bis'?>
    </references>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-i2nsf-terminology'?>

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

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

      <reference anchor="Sec-by-design"
                 target="https://www.gov.uk/government/publications/secure-by-design-report">
        <front>
          <title>Secure by Design: Improving the cyber security of consumer
          Internet of Things Report</title>

          <author fullname="" surname="">
            <organization>UK Department for Digital Culture, Media &amp;
            Sport</organization>
          </author>

          <date month="March" year="2018" />
        </front>
      </reference>

      <reference anchor="Key-Map"
                 target="https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-cbor-key-values">
        <front>
          <title>DOTS Signal Channel CBOR Key Values</title>

          <author fullname="IANA">
            <organization></organization>
          </author>

          <date />
        </front>
      </reference>

      <reference anchor="Cause"
                 target="https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-conflict-cause-codes">
        <front>
          <title>DOTS Signal Channel Conflict Cause Codes</title>

          <author fullname="IANA">
            <organization></organization>
          </author>

          <date />
        </front>
      </reference>

      <reference anchor="RS"
                 target="https://web.archive.org/web/20150315054838/http://ha.ckers.org/slowloris/">
        <front>
          <title>Slowloris HTTP DoS</title>

          <author fullname="RSnake" surname="RSnake">
            <organization></organization>
          </author>

          <date />
        </front>
      </reference>
    </references>

    <section anchor="home" title="Some Home Network Issues">
      <t>Internet of Things (IoT) devices are becoming more and more
      prevalent, in particular in home networks. With compute and memory
      becoming cheaper and cheaper, various types of IoT devices become
      available in the consumer market at affordable prices. But on the
      downside, there is a corresponding threat since most of these IoT
      devices are bought off-the-shelf and most manufacturers haven't
      considered security in the product design (e.g., <xref
      target="Sec-by-design"></xref>). IoT devices deployed in home networks
      can be easily compromised, they often do not have an easy mechanism to
      upgrade, and even when upgradable, IoT manufacturers may cease
      manufacture and/or discontinue patching vulnerabilities on IoT devices
      (Sections 5.4 and 5.5 of <xref target="RFC8576"></xref>). These
      vulnerable and compromised devices will continue to be used for a long
      period of time in the home, and the end-user does not know that IoT
      devices in his/her home are compromised. The compromised IoT devices are
      typically used for launching DDoS attacks (Section 3 of <xref
      target="RFC8576"></xref>) on victims while the owner/administrator of
      the home network is not aware about such misbehaviors. Similar to other
      DDoS attacks, the victim in this attack can be an application server, a
      host, a router, a firewall, or an entire network. Such misbehaviors can
      cause collateral damage that will affect end users, and can also harm
      the reputation of an Internet Service Provider (ISP) for being a source
      of attack traffic.</t>

      <t>Nowadays, network devices in a home network can offer network
      security functions (e.g., firewall <xref target="RFC4949"></xref> or
      Intrusion Protection System (IPS) service <xref
      target="I-D.ietf-i2nsf-terminology"></xref> on a home router) to protect
      the devices connected to the home network from both external and
      internal attacks. It is natural to seek to provide DDoS defense in these
      devices as well, and over the years several techniques have been
      identified to detect DDoS attacks; some of these techniques can be
      enabled on home network devices but most of them are used within the
      ISP's network.</t>

      <t>Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris
      <xref target="RS"></xref>, and Transport Layer Security (TLS)
      renegotiation are difficult to detect on a home network device without
      adversely affecting its performance. The reason is that typically home
      devices such as home routers have fast path to boost the throughput. For
      every new TCP/UDP flow, only the first few packets are punted through
      the slow path. Hence, it is not possible to detect various DDoS attacks
      in the slow path, since the attack payload is sent to the target server
      after the flow is switched to fast path. The reader may refer to Section
      2 of <xref target="RFC6398"></xref> for a brief definition of slow and
      fast paths.</t>

      <t>Deep Packet Inspection (DPI) of all the packets of a flow would be
      able to detect some of the attacks. However, a full-fledged DPI to
      detect these type of DDoS attacks is functionally or operationally not
      possible for all the devices attached to the home network because of the
      memory and CPU limitations of the home routers. Furthermore, for certain
      DDoS attacks the logic needed to distinguish legitimate traffic from
      attack traffic on a per-packet basis is complex. This complexity is
      because that the packet itself may look "legitimate" and no attack
      signature can be identified. The anomaly can be identified only after
      detailed statistical analysis. In addition, network security services in
      home networks may not be able to detect all types of DDoS attacks using
      DPI. ISPs offering DDoS mitigation services have a DDoS detection
      capability that relies upon anomaly detection to identify zero day DDoS
      attacks and to detect DDoS attacks that cannot be detected using
      signatures and rate-limit techniques.</t>

      <t>ISPs can detect some DDoS attacks originating from a home network
      (e.g., Section 2.6 of <xref target="RFC8517"></xref>), but the ISP
      usually does not have a mechanism to detect which device in the home
      network is generating the DDoS attack traffic. The primary reason for
      this is that devices in an IPv4 home network are typically behind a
      Network Address Translation (NAT) border <xref target="RFC2663"></xref>.
      Even in case of an IPv6 home network, although the ISP can identify the
      infected device in the home network launching the DDoS traffic by
      tracking its unique IPv6 address, the infected device can easily change
      its IPv6 address to evade remediation. A security function on the local
      home network is better positioned to track the compromised device across
      IPv6 address (and potentially even MAC address) changes and thus ensure
      that remediation remains in place across such events.</t>
    </section>

    <section anchor="app"
             title="Disambiguating Base DOTS Signal vs. DOTS Call Home">
      <t>With the DOTS signal channel Call Home, there is a chance that two
      DOTS agents can simultaneously establish two DOTS signal channels with
      different directions (base DOTS signal channel and DOTS signal channel
      Call Home). Here is one example drawn from the home network.
      Nevertheless, the outcome of the discussion is not specific to these
      networks, but applies to any DOTS Call Home scenario.</t>

      <t>In the Call Home scenario, the Call Home DOTS server in, for example,
      the home network can mitigate the DDoS attacks launched by the
      compromised device in its domain by receiving the mitigation request
      sent by the Call Home DOTS client in the ISP environment. In addition,
      the DOTS client in the home network can initiate a mitigation request to
      the DOTS server in the ISP environment to ask for help when the home
      network is under a DDoS attack. Such Call Home DOTS server and DOTS
      client in the home network can co-locate in the same home network
      element (e.g., the Customer Premises Equipment). In this case, with the
      same peer at the same time the home network element will have the base
      DOTS signal channel defined in <xref
      target="I-D.ietf-dots-rfc8782-bis"></xref> and the DOTS signal channel
      Call Home defined in this specification. Thus, these two signal channels
      need to be distinguished when they are both supported. Two approaches
      have been considered for distinguishing the two DOTS signal channels,
      but only the one that using the dedicated port number has been chosen as
      the best choice.</t>

      <t>By using a dedicated port number for each, these two signal channels
      can be separated unambiguously and easily. For example, the CPE uses the
      port number 4646 allocated in <xref
      target="I-D.ietf-dots-rfc8782-bis"></xref> to initiate the basic signal
      channel to the ISP when it acts as the DOTS client, and uses another
      port number to initiate the signal channel Call Home. Based on the
      different port numbers, the ISP can directly decide which kind of
      procedures should follow immediately after it receives the DOTS
      messages. This approach just requires two (D)TLS sessions to be
      established respectively for the basic signal channel and signal channel
      Call Home.</t>

      <t>The other approach is signaling the role of each DOTS agent (e.g., by
      using the DOTS data channel as depicted in <xref target="data"></xref>).
      For example, the DOTS agent in the home network first initiates a DOTS
      data channel to the peer DOTS agent in the ISP environment, at this time
      the DOTS agent in the home network is the DOTS client and the peer DOTS
      agent in the ISP environment is the DOTS server. After that, the DOTS
      agent in the home network retrieves the DOTS Call Home capability of the
      peer DOTS agent. If the peer supports the DOTS Call Home, the DOTS agent
      needs to subscribe to the peer to use this extension. Then, the reversal
      of DOTS role can be recognized as done by both DOTS agents. When the
      DOTS agent in the ISP environment, which now is the DOTS client, wants
      to filter the attackers' traffic, it requests the DOTS agent in the home
      network, which now is the DOTS server, for help.</t>

      <t><figure align="center" anchor="data"
          title="Example of DOTS Data Channel Augmentation">
          <artwork><![CDATA[  augment /ietf-data:dots-data/ietf-data:capabilities:
    +--ro call-home-support?   boolean
  augment /ietf-data:dots-data/ietf-data:dots-client:
    +--rw call-home-enable?   boolean
]]></artwork>
        </figure></t>

      <t>Signaling the role will complicate the DOTS protocols, and this
      complexity is not required in context where the DOTS Call Home is not
      required or only when the DOTS Call Home is needed. Besides, the DOTS
      data channel may not work during attack time. Even if changing the above
      example from using the DOTS data channel to the DOTS signal channel, the
      more procedures will still reduce the efficiency. Using the dedicated
      port number is much easier and more concise compared to the second
      approach, and its cost that establishing two (D)TLS sessions is much
      less. So, using a dedicated port number for the DOTS Call Home is
      recommended in this specification. The dedicated port number can be
      configured locally or discovered using means such as <xref
      target="RFC8973"></xref>.</t>
    </section>
  </back>
</rfc>