<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "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"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dots-signal-call-home-14"ipr="trust200902">number="9066" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="DOTS Signal Call Home">Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home</title> <seriesInfo name="RFC" value="9066"/> <author fullname="TirumaleswarReddy"Reddy.K" initials="T."surname="Reddy"> <organization abbrev="McAfee">McAfee, Inc.</organization>surname="Reddy.K"> <organization>Akamai</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><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><organization/> <address> <postal><street></street> <city></city> <code></code> <country>UK</country><street/> <city/> <code/> <country>United Kingdom</country> </postal> <email>supjps-ietf@jpshallow.com</email> </address> </author> <date year="2021" month="November" /> <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 theDOTSDenial-of-Service Open Threat Signaling (DOTS) signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTSclient,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">numbered="true" toc="default"> <name>Introduction</name> <t>The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" format="default"/> is used to carry information about a network resource or a network (or a part thereof) that is under a DistributedDenial of ServiceDenial-of-Service (DDoS) attack <xreftarget="RFC4732"></xref>.target="RFC4732" format="default"/>. 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 <xreftarget="I-D.ietf-dots-use-cases"></xref>.</t>target="RFC8903" format="default"/>.</t> <t>However, <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" format="default"/> only covers how to mitigate when being attacked (i.e.,protectprotecting 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 <xreftarget="basea"></xref> (Section 2 of <xref target="RFC8811"></xref>).</t> <t><figure align="center" anchor="basea" title="Basictarget="basea" format="default"/> (<xref target="RFC8811" sectionFormat="of" section="2"/>).</t> <figure anchor="basea"> <name>Basic DOTSArchitecture">Architecture</name> <artworkalign="center"><![CDATA[+-----------+align="center" name="" type="" alt=""><![CDATA[+-----------+ +-------------+ | Mitigator | ~~~~~~~~~~ | DOTS Server | +-----------+ +-------------+ | | | +---------------+ +-------------+ | Attack Target | ~~~~~~ | DOTS Client | +---------------+ +-------------+ ]]></artwork></figure></t></figure> <t><xreftarget="home"></xref>target="home" format="default"/> details why the rise of Internet of Things (IoT) compounds the possibility of these being used as malicious actorswhichthat 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 itssubscriberssubscribers, or the ISP may receive filtering rules (e.g., using BGP Flowspec <xreftarget="RFC8955"></xref><xref target="RFC8956"></xref>)target="RFC8955" format="default"/> <xref target="RFC8956" format="default"/>) 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 CallHome.<list style="empty"> <t>Note:Home.</t> <t indent="3">Note: Another design approach would be to extend the DOTS signal channel with a new attribute to explicitly indicate whether a mitigation requestis aboutconcerns 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>target="hb"/> and <xref format="counter"target="redirect"></xref>).target="redirect"/>). Also, the DOTS server will be subject to fingerprinting (e.g., using scanning tools) and DoS attacks (e.g., by having the DOTS servertoperform computationally expensive operations). Various management and deployment considerations that motivate the Call Home functionality are listed inSection 1.1 of<xreftarget="RFC8071"></xref>.</t> </list></t> <t>'DOTStarget="RFC8071" sectionFormat="of" section="1.1"/>.</t> <t>"DOTS signal channel CallHome'Home" (orDOTS"DOTS CallHome,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 (<xreftarget="proc"></xref>).target="proc" format="default"/>). That is, the DOTS server initiates a secure connection to a DOTSclient,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 <xreftarget="fa"></xref>.target="fa" format="default"/>. Attack source(s) are within the DOTS server domain.</t><t><figure align="center" anchor="fa" title="Basic<figure anchor="fa"> <name>Basic DOTS Signal Channel Call Home FunctionalArchitecture">Architecture</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ Scope +.-.-.-.-.-.-.-.-.-.-.-.+ +---------------+ : +-------------+ : | Alert | ~~~:~~~ | Call Home | : | | : | DOTS client | : +---------------+ : +------+------+ : : | : : | : : | : +---------------+ : +------+------+ : | Attack | ~~~:~~~ | Call Home | : | Source(s) | : | DOTS server | : +---------------+ : +-------------+ : +.-.-.-.-.-.-.-.-.-.-.-.+]]></artwork></figure></t></figure> <t>DOTS agents involved in the DOTS Call Home otherwise adhere to the DOTS roles as defined in <xreftarget="RFC8612"></xref>.target="RFC8612" format="default"/>. 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 (<xreftarget="fa"></xref>). DOTStarget="fa" format="default"/>). Call Home DOTS agents may (or may not) be co-located with DOTS agents that are compliant with <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" format="default"/> (see <xreftarget="coex"></xref>target="coex" format="default"/> 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 attacksource,source or receiving an alert from an attack target, a peer DDoS Mitigation System (DMS), or a transit provider). The definition of these triggers isdeployment-specific.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 to by the user. Unlike classic DOTS deployments <xreftarget="I-D.ietf-dots-use-cases"></xref>,target="RFC8903" format="default"/>, a Call Home DOTS server maintains a single DOTS signal channel session for each DOTS-capable upstream provisioning domain <xreftarget="I-D.ietf-dots-multihoming">target="I-D.ietf-dots-multihoming" format="default"> </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"idle" time; 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., <xreftarget="RFC8973"></xref>).target="RFC8973" format="default"/>). 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 <xreftarget="as"></xref>.</t>target="as" format="default"/>.</t> </section> <section anchor="notation"title="Terminology"> <t>Thenumbered="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 inBCP 14BCP 14 <xref target="RFC2119"/> <xreftarget="RFC2119"></xref><xref target="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>The reader should be familiar with the terms defined inSection 1.2 of<xreftarget="RFC8612"></xref>.</t> <t>DDoStarget="RFC8612" sectionFormat="of" section="1.2"/>.</t> <t>"DDoS Mitigation System(DMS)(DMS)" refers to a system that performs DDoS mitigation.</t><t>'Base<t>"Base DOTS signalchannel'channel" refers to <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>.</t>target="RFC9132" format="default"/>.</t> <t>The meaning of the symbols in YANG tree diagrams are defined in <xreftarget="RFC8340"></xref>target="RFC8340" format="default"/> and <xreftarget="RFC8791"></xref>.</t>target="RFC8791" format="default"/>.</t> <t>(D)TLS is used for statements that apply to both Transport Layer Security (TLS) <xreftarget="RFC8446"></xref>target="RFC8446" format="default"/> and Datagram Transport Layer Security (DTLS) <xreftarget="RFC6347"></xref>.target="RFC6347" format="default"/> <xref target="I-D.ietf-tls-dtls13"/>. Specific terms are used for any statement that applies to either protocol alone.</t> </section> <section anchor="as"title="Applicability Scope">numbered="true" toc="default"> <name>Applicability Scope</name> <t>The problems discussed in <xreftarget="introduction"></xref>target="introduction" format="default"/> 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 datacenter,center will thus be blocked before exiting these networks.</t> <t>An instantiation of the Call Home functional architecture is depicted in <xreftarget="pb"></xref>.</t> <t><figure align="center" anchor="pb" title="DOTStarget="pb" format="default"/>.</t> <figure anchor="pb"> <name>DOTS Signal Channel Call Home ReferenceArchitecture">Architecture</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![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></figure> <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 inSection 2.3 of<xreftarget="RFC8811"></xref>.target="RFC8811" sectionFormat="of" section="2.3"/>. 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 a decision isimplementation-specific.</t>implementation specific.</t> <t>For some mitigations,afeedback may be required from an administrator to confirm a filtering action.MeansThe means to seekforan administrator's consent aredeployment-specific.deployment specific. Indeed, a variety of implementation options can be consideredas a function of thefor any given Call Home DOTSdeployment:deployment, such as 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 <xreftarget="fa"></xref>).</t>target="fa" format="default"/>).</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 orbebundled 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 the means to notify the user when a new device is detected in order to seekaconfirmation as to whether or not access should be grantedor notto 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-existencenumbered="true" toc="default"> <name>Coexistence of a Base DOTS Signal Channel and DOTS CallHome">Home</name> <t>The DOTS signal channel Call Home does not requirenoror preclude the activation of the base DOTS signal channel <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>.target="RFC9132" format="default"/>. 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 <xreftarget="merged"></xref> (Sametarget="merged" format="default"/> (same DMS provider) or <xreftarget="merged1"></xref> (Distincttarget="merged1" format="default"/> (distinct DMS providers).</t><t><figure align="center" anchor="merged" title="Activation<figure anchor="merged"> <name>Activation of a Base DOTS Signal Channel and Call Home (Same DMSProvider)">Provider)</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![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></figure> <t>Note that a DMS provider may not be on the default forwarding path ofaninbound DDoS attack traffic targeting a network (e.g., Network #B in <xreftarget="merged1"></xref>).target="merged1" format="default"/>). 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<figure anchor="merged1"> <name>Activation of a Base DOTS Signal Channel and Call Home (Distinct DMSProviders)">Providers)</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![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></figure> <t>Figures <xref format="counter"target="snode"></xref>target="snode"/> and <xref format="counter"target="snode2"></xref>target="snode2"/> depict examples where the same node embeds both base DOTS andDOTSCall Home DOTS 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 <xreftarget="snode"></xref>)target="snode" format="default"/>), 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 <xreftarget="snode2"></xref>) .</t>target="snode2" format="default"/>).</t> <t>Whether the same or distinct nodes are used to host base DOTS andDOTSCall Home DOTS agents is specific to each domain.</t><t><figure align="center" anchor="snode" title="An Example of the<figure anchor="snode"> <name>The Same Node Embeddingbotha Call Home DOTS Client and a DOTS Server at the Network Provider'sSide">Side</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![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</figure> <figure anchor="snode2"> <name>The Same NodeEmbedsEmbedding both a DOTS Client and a Call Home DOTSServer">Server</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![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></figure> <t><xref target="app" format="default"/> elaborates on the considerations to unambiguously distinguish DOTS messageswhichthat belong to each of these channels.</t> </section> <section anchor="spec"title="DOTSnumbered="true" toc="default"> <name>DOTS Signal Channel CallHome">Home</name> <section anchor="proc"title="Procedure">numbered="true" toc="default"> <name>Procedure</name> <t>The DOTS signal channel Call Home preserves all but one of the DOTS client/server roles in the DOTS protocol stack, as compared toDOTSthe client-initiated DOTS signal channel protocol <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>.target="RFC9132" format="default"/>. The role reversal that occurs is at the (D)TLS layer; that is, (1) the Call Home DOTS server acts as a DTLSclientclient, and the Call Home DOTS client acts as a DTLSserverserver; or (2) the Call Home DOTS server acts as a TLS client initiating the underlying TCPconnectionconnection, and the Call Home DOTS client acts as a TLS server. The Call Home DOTS server initiates a (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><xreftarget="signalch"></xref>target="signalch" format="default"/> illustrates a sample DOTS Call Home flow exchange:</t><t><figure align="center" anchor="signalch" title="DOTS<figure anchor="signalch"> <name>DOTS Signal Channel Call Home SequenceDiagram"> <artwork><![CDATA[Diagram</name> <artwork name="" type="" align="left" alt=""><![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></figure> <t>The DOTS signal channel Call Home procedure is as follows:</t><t><list style="numbers"><ol spacing="normal" type="1"><li> <t>If UDP transport is used, the Call Home DOTS server begins by initiating a DTLS connection to the Call Home DOTSclient.<vspace blankLines="1" />Ifclient.</t> <t>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 DOTSclient.<vspace blankLines="1" />Peerclient.</t> <t>Peer DOTS agents may have mutual agreement to use a specific port number, such as by explicit configuration or dynamic discovery <xreftarget="RFC8973"></xref>.target="RFC8973" format="default"/>. The interaction between the base DOTS signal channel and the Call Home is discussed in <xreftarget="app"></xref>.<vspace blankLines="1" />Thetarget="app" format="default"/>.</t> <t>The Happy Eyeballs mechanism explained inSection 4.3 of<xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" sectionFormat="of" section="4.3"/> is used for initiating (D)TLS connections.</t> </li> <li> <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 <xreftarget="mitigation"></xref>. <vspace blankLines="1" />The Heartbeattarget="mitigation" format="default"/>. </t> <t>The heartbeat mechanism used for the DOTS Call Home deviates from the one defined inSection 4.7 of<xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>.target="RFC9132" sectionFormat="of" section="4.7"/>. <xreftarget="hb"></xref>target="hb" format="default"/> specifies the behavior to be followed by Call Home DOTS agents.</t></list></t> <t></t></li> </ol> <t/> </section> <sectiontitle="DOTSnumbered="true" toc="default"> <name>DOTS Signal ChannelVariations"> <t></t>Variations</name> <t/> <section anchor="hb"title="Heartbeat Mechanism">numbered="true" toc="default"> <name>Heartbeat Mechanism</name> <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>).(<xref target="RFC9132" sectionFormat="of" section="4.5"/>). The Call Home DOTS server adjusts the'heartbeat-interval'"heartbeat-interval" to accommodate binding timers used by on-path NATs and firewalls. Heartbeats willbethen be 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 clientMAY<bcp14>MAY</bcp14> 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 latterMUST<bcp14>MUST</bcp14> 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 serverMUST<bcp14>MUST</bcp14> continue to use the DOTS signal channel even if the threshold of allowed missing heartbeatsallowed threshold ('missing-hb-allowed')("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'"missing-hb-allowed" threshold, the Call Home DOTS server concludes the session is disconnected. Then, the Call Home DOTS serverMUST<bcp14>MUST</bcp14> try to establish a new DOTS signal channel session, preferably by resuming the (D)TLS session.</t> </section> <section anchor="redirect"title="Redirected Signaling">numbered="true" toc="default"> <name>Redirected Signaling</name> <t>A Call Home DOTS serverMUST NOT<bcp14>MUST NOT</bcp14> support theRedirected Signalingredirected signaling mechanism as specified inSection 4.6 of<xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" sectionFormat="of" section="4.6"/> (i.e., a 5.03 response that conveys an alternate DOTS server'sFQDNFully Qualified Domain Name (FQDN) oralternate DOTS server'sIP address(es)). A Call Home DOTS clientMUST<bcp14>MUST</bcp14> silently discard such a 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, itMUST<bcp14>MUST</bcp14> send a Non-confirmable PUT request to the predefined resource“.well-known/dots/redirect”".well-known/dots/redirect" with the following attributes in the body of the PUT request:</t><t><list style="hanging"> <t hangText="alt-ch-client:">The<dl newline="false" spacing="normal"> <dt>alt-ch-client:</dt> <dd> <t>The FQDN of an alternate Call Home DOTS client. It is also presented as a reference identifier for authenticationpurposes.<vspace blankLines="1" />Thispurposes.</t> <t>This is a mandatory attribute for DOTS signal Call Home. ItMUST NOT<bcp14>MUST NOT</bcp14> be used for base DOTS signal channel operations.</t><t hangText="alt-ch-client-record:">List</dd> <dt>alt-ch-client-record:</dt> <dd> <t>List of IP addresses for the alternate Call Home DOTS client. If no'alt-ch-client-record'"alt-ch-client-record" is provided, the Call Home DOTS server passes the'alt-ch-client'"alt-ch-client" name to a name resolution library to retrieve one or more IP addresses of the alternate Call Home DOTSclient.<vspace blankLines="1" />Thisclient.</t> <t>This is an optional attribute for DOTS signal Call Home. ItMUST NOT<bcp14>MUST NOT</bcp14> be used for base DOTS signal channel operations.</t><t hangText="ttl:">The</dd> <dt>ttl:</dt> <dd> <t>The Timeto liveTo Live (TTL) of the alternate Call Home DOTS client. That is, the time intervalthatin which the alternate Call Home DOTS client may be cached for use by a Call Home DOTSserver.<vspace blankLines="1" />Thisserver.</t> <t>This is an optional attribute for DOTS signal Call Home. ItMUST NOT<bcp14>MUST NOT</bcp14> be used for base DOTS signal channel operations.</t></list></t></dd> </dl> <t>On receipt of this PUT request, the Call Home DOTS server responds with a 2.01 (Created), closes thisconnectionconnection, and establishes a connection with the new Call Home DOTS client. The processing of the TTL is defined inSection 4.6 of<xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>.target="RFC9132" sectionFormat="of" section="4.6"/>. If the Call Home DOTS server cannot service the PUT request, the response is rejected with a 4.00 (Bad Request).</t> <t><xreftarget="red-example"></xref>target="red-example" format="default"/> shows a PUT request example to convey the alternate Call Home DOTS client'alt-call-home-client.example'"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<figure anchor="red-example"> <name>Example of a PUT Request for RedirectedSignaling"> <artwork><![CDATA[Signaling</name> <sourcecode name="" type="coap"><![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>]]></sourcecode> </figure> <t><xref target="red-example"/> uses the JSON encoding of YANG-modeled data for the CoAP message body. The same encoding is used in <xref target="example"/> (<xref target="mitigation"/>). </t> </section> </section> <sectiontitle="DOTSnumbered="true" toc="default"> <name>DOTS Signal ChannelExtension">Extension</name> <section anchor="mitigation"title="Mitigation Request">numbered="true" toc="default"> <name>Mitigation Request</name> <t>This specification extends the mitigation request defined inSection 4.4.1 of<xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" sectionFormat="of" section="4.4.1"/> to convey the attack source information (e.g., source prefixes, source port numbers). The DOTS client conveys the following new parameters in theCBORConcise Binary Object Representation (CBOR) body of the mitigationrequest:<list style="hanging"> <t hangText="source-prefix:">Arequest:</t> <dl newline="false" spacing="normal"> <dt>source-prefix:</dt> <dd> <t>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(<xref target="RFC4632" format="default">BCP 122</xref>. <vspace blankLines="1" />As</xref>). </t> <t>As a reminder, the prefix lengthMUST<bcp14>MUST</bcp14> be less than or equal to 32 (or 128) for IPv4 (orIPv6).<vspace blankLines="1" />TheIPv6).</t> <t>The prefix listMUST NOT<bcp14>MUST NOT</bcp14> include broadcast, loopback, or multicast addresses. These addresses are consideredasinvalid values. Note that link-local addresses are allowed. The Call Home DOTS clientMUST<bcp14>MUST</bcp14> 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 specificprefixes.<vspace blankLines="1" />Thisprefixes.</t> <t>This is an optional attribute for the base DOTS signal channel operations.</t><t hangText="source-port-range:">A</dd> <dt>source-port-range:</dt> <dd> <t>A list of port numbers used by the attack traffic flows.<vspace blankLines="1" />A</t> <t>A port range is defined by two bounds, a lower port number(lower-port)("lower-port") and an upper port number(upper-port).("upper-port"). When only'lower-port'"lower-port" is present, it represents a single port number.<vspace blankLines="1" />For</t> <t>For TCP, UDP, Stream Control Transmission Protocol (SCTP) <xreftarget="RFC4960"></xref>,target="RFC4960" format="default"/>, or Datagram Congestion Control Protocol (DCCP) <xreftarget="RFC4340"></xref>,target="RFC4340" format="default"/>, a range of ports can be any subrange of0-65535,0-65535 -- for example, 0-1023, 1024-65535, or 1024-49151.<vspace blankLines="1" />This</t> <t>This is an optional attribute for the base DOTS signal channel operations.</t><t hangText="source-icmp-type-range:">A</dd> <dt>source-icmp-type-range:</dt> <dd> <t>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'"lower-type" is present, it represents a single ICMP type. Both ICMP <xreftarget="RFC0792"></xref>target="RFC0792" format="default"/> and ICMPv6 <xreftarget="RFC4443"></xref>target="RFC4443" format="default"/> 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"target-prefix". </t> <t>This is an optional attribute for the base DOTS signal channel operations.</t></list></t></dd> </dl> <t>The'source-prefix'"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 <xreftarget="signalch"></xref>).target="signalch" format="default"/>). The'target-prefix'"target-prefix" attributeMUST<bcp14>MUST</bcp14> be included in the mitigation request signaling the attack information to a Call Home DOTS server. The'target-uri'"target-uri" or'target-fqdn'"target-fqdn" parameters can be included in a mitigation request for diagnostic purposes to notify the Call Home DOTS server domainadministrator,administrator butSHOULD NOT<bcp14>SHOULD NOT</bcp14> be used to determine the target IP addresses.'alias-name'"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 clientSHOULD<bcp14>SHOULD</bcp14> include in its mitigation request additional information such as'source-port-range'"source-port-range" or'source-icmp-type-range'"source-icmp-type-range" to disambiguate nodes sharing the same'source-prefix'."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')("source-prefix", "source-port-range") are discussed in <xreftarget="nat"></xref>.</t>target="nat" format="default"/>.</t> <t>Only immediate mitigation requests (i.e.,'trigger-mitigation'"trigger-mitigation" set to'true')"true") are allowed; Call Home DOTS clientsMUST NOT<bcp14>MUST NOT</bcp14> send requests with'trigger-mitigation'"trigger-mitigation" set to'false'."false". Such requestsMUST<bcp14>MUST</bcp14> 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 <xreftarget="example"></xref>.<figure anchor="example" title="Antarget="example" format="default"/>.</t> <figure anchor="example"> <name>An Example of a Mitigation Request Issued by a Call Home DOTSClient"> <artwork align="left"><![CDATA[Client</name> <sourcecode name="" type="json"><![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>} ]]></sourcecode> </figure> <t>The Call Home DOTS serverMUST<bcp14>MUST</bcp14> check that the'source-prefix'"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 anyrouteableroutable IP prefix enclosed in'target-prefix'"target-prefix" is within the scope of the Call Home DOTS client. Invalid mitigation requests are handled as perSection 4.4.1 of<xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>.<list style="empty"> <t>Note:target="RFC9132" sectionFormat="of" section="4.4.1"/>.</t> <t indent="3"> 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<t>Call Home DOTS server domain administrator consentMAY<bcp14>MAY</bcp14> be required to block the traffic from the compromised device to the attack target. An implementationMAY<bcp14>MAY</bcp14> 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>Ifaconsent from the Call Home DOTS server domain administrator is required, the Call Home DOTS server replies with 2.01 (Created) and'status'the "status" code set to 1 (attack-mitigation-in-progress). Then, the mechanisms defined inSection 4.4.2 of<xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" sectionFormat="of" section="4.4.2"/> are followed by the DOTS agents to update the mitigation status.Particularly,In particular, 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'"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>)"conflict-clause" (<xref target="RFC9132" sectionFormat="of" section="4.4.1"/>) set to the following new value:</t><t><list style="hanging"> <t hangText="4:">Mitigation<dl newline="false" spacing="normal"> <dt>4:</dt> <dd>Mitigation request rejected. This code is returned by the DOTS server to indicate the attack traffic has been classified as legitimatetraffic.</t> </list></t>traffic.</dd> </dl> <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., usingMAC levelMAC-level filtering) until it isremediated,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 inSection 4.4.2 of<xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>.</t>target="RFC9132" sectionFormat="of" section="4.4.2"/>.</t> <t>The DOTS agents follow the same procedures specified in <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" format="default"/> for managing a mitigation request.</t> </section> <section anchor="nat"title="Addressnumbered="true" toc="default"> <name>Address SharingConsiderations">Considerations</name> <t><xreftarget="ex1"></xref>target="ex1" format="default"/> depicts an example of a network provider that hosts a Call Home DOTS client and deploys aCarrier GradeCarrier-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 (<xreftarget="ex1"></xref>).target="ex1" format="default"/>). The Call Home DOTS server is only aware of the internal IP addresses/prefixes bound to its domain (i.e., those used in theInternal Realminternal realm shown in <xreftarget="ex1"></xref>).target="ex1" format="default"/>). Thus, Call Home DOTS clients that are aware of the presence of on-path CGNsMUST NOT<bcp14>MUST NOT</bcp14> include the external IP address and/or port number identifying the suspect attack source (i.e., those used in theExternal Realmexternal realm shown in <xreftarget="ex1"></xref>),target="ex1" format="default"/>) butMUST<bcp14>MUST</bcp14> include the internal IP address and/or port number. To that aim, the Call Home DOTS clientSHOULD<bcp14>SHOULD</bcp14> rely on mechanisms, such as those described in <xreftarget="RFC8512"></xref>target="RFC8512" format="default"/> or <xreftarget="RFC8513"></xref>,target="RFC8513" format="default"/>, to retrieve the internal IP address and port numberwhichthat are mapped to an external IP address and port number. For the particular case of NAT64 <xreftarget="RFC6146"></xref>,target="RFC6146" format="default"/>, if the target address is an IPv4 address, the IPv4-converted IPv6 address of this target address <xreftarget="RFC6052"></xref> SHOULDtarget="RFC6052" format="default"/> <bcp14>SHOULD</bcp14> be used.</t><t><figure align="center" anchor="ex1" title="Example<figure anchor="ex1"> <name>Example of a CGN between DOTSDomains">Domains</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![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></figure> <t>If aMAPMapping of Address and Port (MAP) Border Relay <xreftarget="RFC7597"></xref>target="RFC7597" format="default"/> orlwAFTRLightweight Address Family Transition Router (lwAFTR) <xreftarget="RFC7596"></xref>target="RFC7596" format="default"/> is enabled in the provider's domain to service its customers, the identification of an attack source bound to an IPv4 address/prefixMUST<bcp14>MUST</bcp14> 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>target="ex2"/> and <xref format="counter"target="ex2b"></xref>),target="ex2b"/>), 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 (<xreftarget="ex2"></xref>)target="ex2" format="default"/>) or via a dedicated administration interface that is offered by the CPE (<xreftarget="ex2b"></xref>).target="ex2b" format="default"/>). This identification allows the suspicious device to be isolated while avoiding disturbances of other services.</t><t><figure align="center" anchor="ex2" title="Example<figure anchor="ex2"> <name>Example of a DOTS Server Domain with a NAT Embedded in aCPE">CPE</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![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</figure> <figure anchor="ex2b"> <name>Example of a Call Home DOTS Server and a NAT Embedded in aCPE">CPE</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![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</figure> <t>If, for anyreasonreason, 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 <xreftarget="ex1"></xref>target="ex1" format="default"/> (network provider) and Figures <xref format="counter"target="ex2"></xref>target="ex2"/> and <xref format="counter"target="ex2b"></xref>target="ex2b"/> (source network).</t> </section> </section> </section> <section anchor="YANG"title="DOTSnumbered="true" toc="default"> <name>DOTS Signal Call Home YANGModule ">Module</name> <sectiontitle="Tree Structure">numbered="true" toc="default"> <name>Tree Structure</name> <t>This document augments the "ietf-dots-signal-channel" (dots-signal) DOTS signal YANG module defined in <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" format="default"/> for signaling the attack traffic information. This document defines the YANG module "ietf-dots-call-home", which has the following treestructure:<figure> <artwork><![CDATA[module:structure:</t> <sourcecode name="" type="yangtree"><![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>]]></sourcecode> </section> <sectiontitle="YANG/JSONnumbered="true" toc="default"> <name>YANG/JSON Mapping Parameters toCBOR">CBOR</name> <t>The YANG/JSON mapping parameters to CBOR are listed inTable 1.<list style="symbols"> <t>Note:<xref target="table1"/>.</t> <t indent="3"> Note: Implementers must check that the mapping output provided by their YANG-to-CBOR encoding schemes is aligned with the content ofTable 1.</t> </list></t> <t><figure align="center"> <artwork><![CDATA[+--------------------+------------+------+---------------+--------+ | Parameter Name | YANG | CBOR | CBOR Major | JSON | | | Type |<xref target="table1"/>. </t> <table anchor="table1"> <name>YANG/JSON Mapping Parameters to CBOR</name> <thead> <tr> <th>Parameter Name</th> <th>YANG Type</th> <th>CBOR Key| Type & |Value</th> <th>CBOR Major Type| | | | | Information | | +====================+============+======+===============+========+ |ietf-dots-call-home:| leaf-list | | | | | source-prefix | inet: | TBA1 | 4 array | Array | | | ip-prefix | | 3& Information</th> <th>JSON Type</th> </tr> </thead> <tbody> <tr> <td>ietf-dots-call-home:&zwsp;source-prefix</td> <td>leaf-list inet:&zwsp;ip-prefix</td> <td>32768</td> <td>4 array<br/>3 textstring | 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 | 3string</td> <td>Array String</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;source-port-range</td> <td>list</td> <td>32769</td> <td>4 array</td> <td>Array</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;source-icmp-type-range</td> <td>list</td> <td>32770</td> <td>4 array</td> <td>Array</td> </tr> <tr> <td>lower-type</td> <td>uint8</td> <td>32771</td> <td>0 unsigned</td> <td>Number</td> </tr> <tr> <td>upper-type</td> <td>uint8</td> <td>32772</td> <td>0 unsigned</td> <td>Number</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;alt-ch-client</td> <td>inet: domain-name</td> <td>32773</td> <td>3 textstring | String | +--------------------+------------+------+---------------+--------+ |ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array | | alt-ch-client- | inet: | | | | | record | ip-address| | 3string</td> <td>String</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;alt-ch-client-record</td> <td>leaf-list inet:&zwsp;ip-address</td> <td>32774</td> <td>4 array<br/>3 textstring | String | +--------------------+------------+------+---------------+--------+ |ietf-dots-call-home:| | | | | | ttl | uint32 | TBA8 | 0 unsigned | Number | +--------------------+------------+------+---------------+--------+ Table 1: YANG/JSON Mapping Parameters to CBOR ]]></artwork> </figure></t>string</td> <td>Array<br/>String</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;ttl</td> <td>uint32</td> <td>32775</td> <td>0 unsigned</td> <td>Number</td> </tr> </tbody> </table> <t>The YANG/JSON mappings to CBOR for'lower-port'"lower-port" and'upper-port'"upper-port" are already defined in Table 5 of <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>.</t>target="RFC9132" format="default"/>.</t> </section> <sectiontitle="YANG Module ">numbered="true" toc="default"> <name>YANG Module</name> <t>This module uses the common YANG types defined in <xreftarget="RFC6991"></xref>target="RFC6991" format="default"/> and the data structure extension defined in <xreftarget="RFC8791"></xref>.</t> <t><figure> <artwork><![CDATA[<CODE BEGINS> file "ietf-dots-call-home@2020-12-02.yang"target="RFC8791" format="default"/>.</t> <sourcecode name="ietf-dots-call-home@2021-09-27.yang" type="yang" markers="true"><![CDATA[ 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 "RFCYYYY:9132: 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>;<mailto:kondtir@gmail.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 RFCXXXX;9066; see the RFC itself for full legal notices."; revision2020-12-022021-09-27 { description "Initial revision."; reference "RFCXXXX:9066: 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 the 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 ICMPv6areis 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 the 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 the 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 the 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 acall homesignal Call Home 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 a 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 Timeto liveTo Live (TTL) of the alternate Call Home DOTS client."; reference "Section 4.6 of RFCYYYY";9132"; } } } } }<CODE ENDS>]]></artwork> </figure></t>]]></sourcecode> </section> </section> <section anchor="IANA"title="IANA Considerations"> <t></t>numbered="true" toc="default"> <name>IANA Considerations</name> <t/> <section anchor="map"title="DOTSnumbered="true" toc="default"> <name>DOTS Signal Channel CBOR MappingsRegistry">Registry</name> <t>This specification registers the following comprehension-optional parameters(Table 2)(<xref target="table2"/>) in the IANA "DOTS Signal Channel CBOR Key Values" registry <xreftarget="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: Assignedtarget="Key-Map" format="default"/>.</t> <table anchor="table2"> <name>Assigned DOTS Signal Channel CBOR KeyValues ]]></artwork> </figure></t> <t></t>Values</name> <thead> <tr> <th>Parameter Name</th> <th>CBOR Key Value</th> <th>CBOR Major Type</th> <th>Change Controller</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>ietf-dots-call-home:&zwsp;source-prefix</td> <td>32768</td> <td>4</td> <td>IESG</td> <td>RFC 9066</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;source-port-range</td> <td>32769</td> <td>4</td> <td>IESG</td> <td>RFC 9066</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;source-icmp-type-range</td> <td>32770</td> <td>4</td> <td>IESG</td> <td>RFC 9066</td> </tr> <tr> <td>lower-type</td> <td>32771</td> <td>0</td> <td>IESG</td> <td>RFC 9066</td> </tr> <tr> <td>upper-type</td> <td>32772</td> <td>0</td> <td>IESG</td> <td>RFC 9066</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;alt-ch-client</td> <td>32773</td> <td>3</td> <td>IESG</td> <td>RFC 9066</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;alt-ch-client-record</td> <td>32774</td> <td>4</td> <td>IESG</td> <td>RFC 9066</td> </tr> <tr> <td>ietf-dots-call-home:&zwsp;ttl</td> <td>32775</td> <td>0</td> <td>IESG</td> <td>RFC 9066</td> </tr> </tbody> </table> </section> <sectiontitle="Newnumbered="true" toc="default"> <name>New DOTS ConflictCause"> <t>This document requestsCause</name> <t>Per this document, IANAto assignhas assigned a new code from the "DOTS Signal Channel Conflict Cause Codes" registry <xreftarget="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>Mitigationtarget="Cause" format="default"/>.</t> <table align="center"> <name>Assigned DOTS Signal Channel Conflict Cause Code</name> <thead> <tr> <th align="left">Code</th> <th align="left">Label</th> <th align="left">Description</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">4</td> <td align="left">request-rejected-legitimate-traffic</td> <td align="left">Mitigation request rejected. This code is returned by the DOTS server to indicate the attack traffic has been classified as legitimatetraffic.</c> <c>[RFCXXXX]</c> </texttable> <t></t>traffic.</td> <td align="left">RFC 9066</td> </tr> </tbody> </table> <t/> </section> <section anchor="yang"title="DOTSnumbered="true" toc="default"> <name>DOTS Signal Call Home YANGModule"> <t>This document requestsModule</name> <t>Per this document, IANAto registerhas registered the following URI in the "ns" subregistry within the "IETF XML Registry" <xreftarget="RFC3688"></xref>: <figure> <artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home Registrant Contact: The IETF. XML:target="RFC3688" format="default"/>: </t> <dl spacing="compact" indent="6"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-call-home</dd> <dt>Registrant Contact:</dt><dd>The IETF.</dd> <dt>XML:</dt><dd> N/A; the requested URI is an XMLnamespace. ]]></artwork> </figure>This document requestsnamespace.</dd> </dl> <t>Per this document, IANAto registerhas registered the following YANG module in the "YANG Module Names" subregistry <xreftarget="RFC6020"></xref>target="RFC6020" format="default"/> 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>registry:</t> <dl spacing="compact" indent="6"> <dt>name:</dt><dd>ietf-dots-call-home</dd> <dt>namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-call-home</dd> <dt>maintained by IANA:</dt><dd>N</dd> <dt>prefix:</dt><dd>dots-call-home</dd> <dt>reference:</dt><dd>RFC 9066</dd> </dl> </section> </section> <section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document deviates from classic DOTS signal channel usage by having the DOTS server initiate the (D)TLS connection. Security considerations related to the DOTS signal channelrelated security considerationsdiscussed inSection 11 of<xreftarget="I-D.ietf-dots-rfc8782-bis"></xref> MUSTtarget="RFC9132" sectionFormat="of" section="11"/> and (D)TLS early data discussed in <xref target="RFC9132" sectionFormat="of" section="7"/> <bcp14>MUST</bcp14> be considered. DOTS agentsMUST<bcp14>MUST</bcp14> 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 expensiveoperations,operations before deducing that the attacker doesn't possess a valid key. For instance, in TLS 1.3 <xreftarget="RFC8446"></xref>,target="RFC8446" format="default"/>, the ServerHello message contains aKey Sharekey share value based on an expensive asymmetric key operation for key establishment. Common precautions mitigating DoS attacks are recommended, such as temporarily addingto a drop-listthe source address to a drop-list after a set number of unsuccessful authentication attempts.</t> <t>The DOTS signal Call Homesignalchannel can be misused by a misbehaving Call Home DOTS client by arbitrarilysignallingsignaling 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 thetarget, ortarget. They couldre-directalso redirect the traffic from the potentially compromised device to the target towards a DDoS mitigation system that can scrub the suspicioustraffic,traffic without blindly blocking all traffic from the indicated attack source to the target. Call Home DOTS servers can also seek the consent of the DOTS server domain administrator to block the traffic from the potentially compromised device to the target (see <xreftarget="mitigation"></xref>). Meanstarget="mitigation" format="default"/>). The means to seektheconsent areimplementation-specific.</t>implementation specific.</t> <t>Call Home DOTS agents may interact with on-path address sharing functions to retrieve an internal IPaddresss/externaladdress / external IP address mapping (<xreftarget="nat"></xref>)target="nat" format="default"/>) 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., toSection 4 of<xreftarget="RFC8512"></xref>target="RFC8512" sectionFormat="of" section="4"/> orSection 4<xref target="RFC8513" sectionFormat="of" section="4"/>).</t> <t> This document augments YANG data structures that are meant to be used as an abstract representation of DOTS signal channel Call Home messages. As such, the "ietf-dots-call-home" module does not introduce any new vulnerabilities beyond those specified above and in <xreftarget="RFC8513"></xref>).</t>target="RFC9132"/>. </t> </section> <sectiontitle="Privacy Considerations">numbered="true" toc="default"> <name>Privacy Considerations</name> <t>The considerations discussed in <xreftarget="RFC6973"></xref>target="RFC6973" format="default"/> 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 Layer3/Layer3 / Layer 4 information that can belearntlearned 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 belongsto(e.g., address sharing issues discussed in <xreftarget="mitigation"></xref>).</t>target="mitigation" format="default"/>).</t> <t>Triggers to send a DOTS mitigation request to a Call Home DOTS server aredeployment-specific.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 may rely 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 toagiven attack detection technology. The reader may refer, for example, toSection 11.8 of<xreftarget="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ö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 Éric Vyncke, Roman Danyliw, Barry Leiba, Robert Wilton, and Erik Kline for the IESG review.</t>target="RFC7011" sectionFormat="of" section="11.8"/>.</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'?><displayreference target="I-D.ietf-dots-multihoming" to="DOTS-MULTIHOMING"/> <displayreference target="I-D.ietf-i2nsf-terminology" to="I2NSF-TERMS"/> <displayreference target="I-D.ietf-tls-dtls13" to="DTLS13"/> <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.3688.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.8174.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.8791.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6052.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9132.xml"/> </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'?><references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4732.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8811.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.8071.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.4340.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-dots-multihoming.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-dtls13.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.8903.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8973.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8956.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8512.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8513.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7596.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7597.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.8517.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8576.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6398.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2663.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-i2nsf-terminology.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/> <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 forDigitalDigital, Culture, Media & Sport</organization> </author> <date month="March"year="2018" />year="2018"/> </front> </reference> <reference anchor="Key-Map"target="https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-cbor-key-values">target="https://www.iana.org/assignments/dots/"> <front> <title>DOTS Signal Channel CBOR Key Values</title><author fullname="IANA"> <organization></organization><author> <organization>IANA</organization> </author><date /><date/> </front> </reference> <reference anchor="Cause"target="https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-conflict-cause-codes">target="https://www.iana.org/assignments/dots/"> <front> <title>DOTS Signal Channel Conflict Cause Codes</title><author fullname="IANA"> <organization></organization><author> <organization>IANA</organization> </author><date /><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><organization/> </author><date /><date/> </front> </reference> </references> </references> <section anchor="home"title="Somenumbered="true" toc="default"> <name>Some Home NetworkIssues">Issues</name> <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., <xreftarget="Sec-by-design"></xref>).target="Sec-by-design" format="default"/>). 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 (Sections5.4<xref target="RFC8576" sectionFormat="bare" section="5.4"/> and5.5<xref target="RFC8576" sectionFormat="bare" section="5.5"/> of <xreftarget="RFC8576"></xref>).target="RFC8576"/>). 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>)(<xref target="RFC8576" sectionFormat="of" section="3"/>) 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 <xreftarget="RFC4949"></xref>target="RFC4949" format="default"/> or Intrusion Protection System (IPS) service <xreftarget="I-D.ietf-i2nsf-terminology"></xref>target="I-D.ietf-i2nsf-terminology" format="default"/> 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 <xreftarget="RS"></xref>,target="RS" format="default"/>, 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 toSection 2 of<xreftarget="RFC6398"></xref>target="RFC6398" sectionFormat="of" section="2"/> 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<xreftarget="RFC8517"></xref>),target="RFC8517" sectionFormat="of" section="2.6"/>), 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 <xreftarget="RFC2663"></xref>.target="RFC2663" format="default"/>. 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="Disambiguatingnumbered="true" toc="default"> <name>Disambiguating Base DOTS Signal vs. DOTS CallHome">Home</name> <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 <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" format="default"/> 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 <xreftarget="I-D.ietf-dots-rfc8782-bis"></xref>target="RFC9132" format="default"/> 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 <xreftarget="data"></xref>).target="data" format="default"/>). 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<figure anchor="data"> <name>Example of DOTS Data ChannelAugmentation"> <artwork><![CDATA[Augmentation</name> <sourcecode name="" type="yangtree"><![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>]]></sourcecode> </figure> <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 <xreftarget="RFC8973"></xref>.</t>target="RFC8973" format="default"/>.</t> </section> <section anchor="ack" numbered="false" toc="default"> <name>Acknowledgements</name> <t>Thanks to <contact fullname="Wei Pei"/>, <contact fullname="Xia Liang"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Dan Wing"/>, <contact fullname="Toema Gavrichenkov"/>, <contact fullname="Daniel Migault"/>, <contact fullname="Sean Turner"/>, and <contact fullname="Valery Smyslov"/> for the comments.</t> <t><contact fullname="Benjamin Kaduk"/>'s AD review is valuable. Many thanks to him for the detailed review.</t> <t>Thanks to <contact fullname="Radia Perlman"/> and <contact fullname="David Schinazi"/> for the directorate reviews.</t> <t>Thanks to <contact fullname="Ebben Aries"/> for the YANG Doctors review.</t> <t>Thanks to <contact fullname="Éric Vyncke"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Robert Wilton"/>, and <contact fullname="Erik Kline"/> for the IESG review.</t> </section> <section anchor="contr" numbered="false" toc="default"> <name>Contributors</name> <t>The following individuals have contributed to this document:</t> <contact fullname="Joshi Harsha" > <organization>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>harsha_joshi@mcafee.com</email> </address> </contact> <contact fullname="Wei Pan" > <organization>Huawei Technologies</organization> <address> <postal> <street/> <city/> <region/> <code/> <country>China</country> </postal> <email>william.panwei@huawei.com</email> </address> </contact> </section> </back> </rfc>