<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="4"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" number="9133" docName="draft-ietf-dots-signal-filter-control-07"ipr="trust200902">ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="DOTS Signal Filter Control">Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel</title> <seriesInfo name="RFC" value="9133"/> <author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka"> <organization>NTT Communications</organization> <address> <postal> <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street><city>Tokyo</city> <region></region><code>108-8118</code> <region>Tokyo</region> <country>Japan</country> </postal> <email>kaname@nttv6.jp</email> </address> </author> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <postal><street></street><street/> <city>Rennes</city> <code>35000</code> <region/> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="TirumaleswarReddy"Reddy.K" initials="T."surname="Reddy">surname="Reddy.K"> <organizationabbrev="McAfee">McAfee, Inc.</organization>abbrev="Akamai">Akamai</organization> <address> <postal> <street>Embassy Golf Link Business Park</street> <city>Bangalore</city><region>Karnataka</region><code>560071</code> <region>Karnataka</region> <country>India</country> </postal> <email>kondtir@gmail.com</email> </address> </author> <author fullname="Takahiko Nagata" initials="T." surname="Nagata"> <organization>Lepidum</organization> <address> <postal><street></street> <city></city> <region></region> <code></code><street/> <city/> <region/> <code/> <country>Japan</country> </postal> <email>nagata@lepidum.co.jp</email> </address> </author> <date/>month="September" year="2021"/> <workgroup>DOTS</workgroup> <keyword>Mitigation</keyword> <keyword>Automation</keyword> <keyword>Filtering</keyword> <keyword>Protective Networking</keyword> <keyword>Protected Networks</keyword> <keyword>Security</keyword> <keyword>Anti-DDoS</keyword> <keyword>Reactive</keyword> <keyword>Collaborative Networking</keyword> <keyword>Collaborative Security</keyword> <abstract> <t>This document specifies an extension to the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active.</t> <t>Particularly, this extension allows a DOTS client to activate orde-activatedeactivate existing filtering rules during aDDoSDistributed Denial-of-Service (DDoS) attack. The characterization of these filtering rules is conveyed by a DOTS client during anidle'idle' time (i.e., no mitigation is active) by means of the DOTS data channel protocol.</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: Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel";</t> <t>reference: RFC XXXX</t> <t>[RFCXXXX]</t> </list>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> <section anchor="problem"title="The Problem">numbered="true" toc="default"> <name>The Problem</name> <t>In the Distributed Denial-of-Service Open Threat Signaling (DOTS) architecture <xreftarget="I-D.ietf-dots-architecture"></xref>,target="RFC8811" format="default"/>, DOTS clients and servers communicate using both a signal channel protocol <xreftarget="RFC8782"></xref>target="RFC9132" format="default"/> and a data channel protocol <xreftarget="RFC8783"></xref>.</t>target="RFC8783" format="default"/>.</t> <t>The DOTS data channel protocol <xreftarget="RFC8783"></xref>target="RFC8783" format="default"/> is used for bulk data exchange between DOTS agents to improve the coordination of parties involved in the response to a Distributed Denial-of-Service (DDoS) attack. Filtermanagementmanagement, which is one ofitsthe taskswhichof the DOTS data channel protocol, enables a DOTS client to retrieve the filtering capabilities of a DOTS server and to manage filtering rules. Typically, these filtering rules are used for dropping or rate-limiting unwanted traffic, and permitting accept-listed traffic.</t> <t>The DOTS signal channel protocol <xreftarget="RFC8782"></xref>target="RFC9132" format="default"/> is designed to be resilient under extremely hostile network conditions and provides continued contact between DOTS agents even as DDoS attack traffic saturates the link. The DOTS signal channel can be established between two DOTS agents prior to or during an attack. At any time, the DOTS client may send mitigation requests (as perSection 4.4 of<xreftarget="RFC8782"></xref>)target="RFC9132" sectionFormat="of" section="4.4"/>) to a DOTS server over the active signal channel. While mitigation is active, the DOTS server periodically sends status messages to the DOTS client, including basic mitigation feedback details. In case of a massive DDoS attack that saturates the incoming link(s) to the DOTS client, all traffic from the DOTS server to the DOTS client will likely be dropped. However, the DOTS server may still receive DOTS messages sent from the DOTS client over thesignallingsignaling channel thanks to the heartbeat requests keeping the channel active (as described inSection 4.7 of<xreftarget="RFC8782"></xref>).</t>target="RFC9132" sectionFormat="of" section="4.7"/>).</t> <t>Unlike the DOTS signal channel protocol, the DOTS data channel protocol is not expected to deal with attack conditions. As such, an issue that might be encountered in some deployments is when filters installed by means of the DOTS data channel protocol may not function as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS attack. In suchconditionsconditions, the DOTS data channel protocol cannot be used to change these filters, which may complicate DDoS mitigation operations <xreftarget="Interop"></xref>.</t>target="INTEROP" format="default"/>.</t> <t>A typical case is a conflict between filtering rules installed by a DOTS client and the mitigation actions of a DDoS mitigator. Consider, for instance, a DOTS client that configures during 'idle' time (i.e., no mitigation is active) some filtering rules using the DOTS data channel protocol to permit traffic from accept-listed sources. However, during a volumetric DDoSattackattack, the DDoS mitigator identifies the source addresses/prefixes in the accept-listed filtering rules are attacking the target. For example, an attacker can spoof the IP addresses of accept-listed sources to generate attacktraffictraffic, or the attacker can compromise the accept-listed sources and program them to launch a DDoS attack.</t> <t><xreftarget="RFC8782"></xref>target="RFC9132" format="default"/> is designed so that the DDoS server notifies the above conflict to the DOTS client (that is, the 'conflict-cause' parameter is set to 2(Conflicts with an existing accept list)),(conflict-with-acceptlist)), but the DOTS client may not be able to withdraw the accept-list rules during the attack period due to the high-volume attack traffic saturating the inbound link to the DOTS client domain. In other words, the DOTS client cannot use the DOTS data channel protocol to withdraw the accept-list filters when a DDoS attack is in progress.</t> </section> <section anchor="sol"title="Controllingnumbered="true" toc="default"> <name>Controlling Filtering Rules Using DOTS SignalChannel">Channel</name> <t>This specification addresses the problems discussed in <xreftarget="problem"></xref>target="problem" format="default"/> by adding a capability for managing filtering rules using the DOTS signal channel protocol, which enables a DOTS client to request the activation (or deactivation) of filtering rules during a DDoS attack. Note that creating these filtering rules is still the responsibility of the DOTS data channel <xreftarget="RFC8783"></xref>.</t>target="RFC8783" format="default"/>.</t> <t>The DOTS signal channel protocol is designed to enable a DOTS client to contact a DOTS server for help even under severe network congestion conditions. Therefore, extending the DOTS signal channel protocol to manage the filtering rules during an attack will enhance the protection capability offered by DOTS protocols.</t><t><list style="empty"><aside> <t>Note: The experiment at theIETF103IETF 103 hackathon <xreftarget="Interop"></xref>target="INTEROP" format="default"/> showed that even when the inbound link is saturated by DDoS attack traffic, the DOTS client can signal mitigation requests using the DOTS signal channel over the saturated link.</t></list></t></aside> <t>Conflicts that are induced by filters installed by other DOTS clients of the same domain are not discussed in this specification.</t> <t>An augmentation to the DOTS signal channel YANG module is defined in <xreftarget="YANG"></xref>.</t>target="YANG" format="default"/>.</t> <t>Sample examples are provided in <xreftarget="sample"></xref>,target="sample" format="default"/>, in particular:<list style="symbols"> <t><xref target="sample1"></xref></t> <ul spacing="normal"> <li> <xref target="sample1" format="default"/> illustrates how the filter control extension is used when conflicts with Access Control Lists (ACLs) are detected and reported by a DOTSserver.</t> <t><xref target="sample2"></xref>server.</li> <li> <xref target="sample2" format="default"/> shows how a DOTS client can instruct a DOTS server to safely forward some specific traffic in 'attack'time.</t> <t><xref target="sample3"></xref>time.</li> <li> <xref target="sample3" format="default"/> shows how a DOTS client can react if the DDoS traffic is still being forwarded to the DOTS client domain even if mitigation requests were sent to a DOTSserver.</t> </list></t>server.</li> </ul> <t>The JavaScript Object Notation (JSON) encoding of YANG-modeled data <xreftarget="RFC7951"></xref>target="RFC7951" format="default"/> is used to illustrate the examples.</t> </section> </section> <section anchor="notation"title="Terminology">numbered="true" toc="default"> <name>Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119" format="default"/> <xreftarget="RFC8174"></xref>target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t> <t>The reader should be familiar with the terms defined in <xreftarget="RFC8612"></xref>.</t>target="RFC8612" format="default"/>.</t> <t>The terminology for describing YANG modules is defined in <xreftarget="RFC7950"></xref>.target="RFC7950" format="default"/>. The meaning of the symbols in the tree diagram is defined in <xreftarget="RFC8340"></xref>.</t>target="RFC8340"/> and <xref target="RFC8791" format="default"/>.</t> </section> <sectiontitle="Controllingnumbered="true" toc="default"> <name>Controlling Filtering Rules of a DOTSClient">Client</name> <section anchor="bind"title="Bindingnumbered="true" toc="default"> <name>Binding DOTS Data and SignalChannels">Channels</name> <t>The filtering rules eventually managed using the DOTS signal channel protocol are created a priori by the same DOTS client using the DOTS data channel protocol. Managing conflicts with filters installed by other DOTS clients of the same domain is out of scope.</t> <t>As discussed inSection 4.4.1 of<xreftarget="RFC8782"></xref>,target="RFC9132" sectionFormat="of" section="4.4.1"/>, a DOTS client must use the same 'cuid' for both the DOTS signal and data channels. This requirement is meant to facilitate binding DOTS channels used by the same DOTS client.</t> <t>The DOTS signal and data channels from a DOTS client may or may not use the same DOTS server. Nevertheless, the scope of the mitigation request, alias, and filtering rules are not restricted to the DOTS server but to the DOTS server domain. To that aim, DOTS servers within a domain are assumed to have a mechanism to coordinate the mitigation requests, aliases, and filtering rules to coordinate their decisions for better mitigation operation efficiency. The exact details about such a mechanism is out of the scope of this document.</t> <t>A filtering rule controlled by the DOTS signal channel is identified by its ACL name(Section 4.3 of <xref target="RFC8782"></xref>).(<xref target="RFC8783" sectionFormat="of" section="4.3"/>). Note that an ACL name unambiguously identifies an ACL bound to a DOTS client, but the same name may be used by distinct DOTS clients.</t> <t>The activation or deactivation of an ACL by the DOTS signal channel overrides the 'activation-type' (defined inSection 4.3 of<xreftarget="RFC8783"></xref>)target="RFC8783" sectionFormat="of" section="4.3"/>) a priori conveyed with the filtering rules using the DOTS data channel protocol.</t> <t>Once the attack is mitigated, the DOTS client may use the data channel to control the 'activation-type' (e.g., revert to a default value) of some of the filtering rules controlled by the DOTS signal channel or delete some of these filters. This behavior is deployment specific.</t> </section> <sectiontitle="DOTSnumbered="true" toc="default"> <name>DOTS Signal ChannelExtension">Extension</name> <section anchor="filtering"title="Parametersnumbered="true" toc="default"> <name>Parameters andBehaviors">Behaviors</name> <t>This specification extends the mitigation request defined inSection 4.4.1 of<xreftarget="RFC8782"></xref>target="RFC9132" sectionFormat="of" section="4.4.1"/> to convey the intended control of configured filtering rules. Concretely, the DOTS client conveys the 'acl-list' attribute with the following sub-attributes in theCBORConcise Binary Object Representation (CBOR) body of a mitigation request (see the YANG structure in <xreftarget="tree"></xref>):<list style="hanging"> <t hangText="acl-name:">Atarget="tree" format="default"/>):</t> <dl newline="false" spacing="normal"> <dt>acl-name:</dt> <dd> <t>A name of an access list defined using the DOTS data channel(Section 4.3 of <xref target="RFC8783"></xref>)(<xref target="RFC8783" sectionFormat="of" section="4.3"/>) that is associated with the DOTSclient.<vspace blankLines="1" />Asclient.</t> <t>As a reminder, an ACL is an ordered list of Access Control Entries(ACE).(ACEs). Each ACE has a list of match criteria and a list of actions <xreftarget="RFC8783"></xref>.target="RFC8783" format="default"/>. The list of configured ACLs can be retrieved using the DOTS data channel during 'idle'time.<vspace blankLines="1" />Thistime.</t> <t>This is a mandatory attribute when 'acl-list' is included.</t><t hangText="activation-type:">Indicates</dd> <dt>activation-type:</dt> <dd> <t>An attribute indicating the activation type of an ACL overriding the existing 'activation-type' installed by the DOTS client using the DOTS data channel.<vspace blankLines="1" />As</t> <t>As a reminder, this attribute can be set to 'deactivate', 'immediate', or 'activate-when-mitigating' as defined in <xreftarget="RFC8783"></xref>. <vspace blankLines="1" />Notetarget="RFC8783" format="default"/>. </t> <t>Note that both 'immediate' and 'activate-when-mitigating' have an immediate effect when a mitigation request is being processed by the DOTS server.<vspace blankLines="1" />This</t> <t>This is an optional attribute.</t></list></t></dd> </dl> <t>By default, ACL-related operations are achieved using the DOTS data channel protocol when no attack is ongoing. DOTS clientsMUST NOT<bcp14>MUST NOT</bcp14> use the filtering control over the DOTS signal channel in 'idle' time; such requestsMUST<bcp14>MUST</bcp14> be discarded by DOTS servers with 4.00 (Bad Request).</t> <t>During an attack time, DOTS clients may include 'acl-list', 'acl-name', and 'activation-type' attributes in a mitigation request. This request may be the initial mitigation request for a given mitigation scope or a new one overriding an existing request. In both cases, a new 'mid'MUST<bcp14>MUST</bcp14> be used. Nevertheless, it isNOT RECOMMENDED<bcp14>NOT RECOMMENDED</bcp14> to include ACL attributes in an initial mitigation request for a given mitigation scope or in a mitigation request adjusting the mitigation scope. This recommendation is meant to avoid delaying attack mitigations because of failures to process ACL attributes.</t> <t>As the attack evolves, DOTS clients can adjust the 'activation-type' of an ACL conveyed in a mitigation request or control other filters as necessary. This can be achieved by sending a PUT request with a new 'mid' value.</t> <t>It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> for a DOTS client to subscribe to asynchronous notifications of the attack mitigation, as detailed inSection 4.4.2.1 of<xreftarget="RFC8782"></xref>.target="RFC9132" sectionFormat="of" section="4.4.2.1"/>. If not, the polling mechanism inSection 4.4.2.2 of<xreftarget="RFC8782"></xref>target="RFC9132" sectionFormat="of" section="4.4.2.2"/> has to be followed by the DOTS client.</t> <t>A DOTS client relies on the information received from the DOTS server and/or local information to the DOTS client domain to trigger a filter control request. Only filters that are pertinent for an ongoing mitigation should be controlled by a DOTS client using the DOTS signal channel.</t> <t>'acl-list', 'acl-name', and 'activation-type' are defined as comprehension-required parameters. Following the rules inSection 6 of<xreftarget="RFC8782"></xref>,target="RFC9132" sectionFormat="of" section="6"/>, if the DOTS server does not understand the'acl-list' or 'acl-name''acl-list', 'acl-name', or 'activation-type' attributes, it responds with a"4.004.00 (BadRequest)"Request) error response code.</t> <t>If the DOTS server does not find the ACL name ('acl-name') conveyed in the mitigation request for this DOTS client, itMUST<bcp14>MUST</bcp14> respond with a 4.04 (Not Found) error response code.</t> <t>If the DOTS server finds the ACL name for this DOTS client, and assuming the request passed the validation checks inSection 4.4.1 of<xreftarget="RFC8782"></xref>,target="RFC9132" sectionFormat="of" section="4.4.1"/>, the DOTS serverMUST<bcp14>MUST</bcp14> proceed with the 'activation-type' update. The update is immediately enforced by the DOTS server and will be maintained as the new activation type for the ACL name even after the termination of the mitigation request. In addition, the DOTS serverMUST<bcp14>MUST</bcp14> update the lifetime of the corresponding ACL similar to the update when a refresh request is received using the DOTS data channel(Section 7.2 of <xref target="RFC8783"></xref>).(<xref target="RFC8783" sectionFormat="of" section="7.2"/>). If, for some reason, the DOTS server fails to apply the filter update, itMUST<bcp14>MUST</bcp14> respond with a 5.03 (Service Unavailable) error response code and include the failed ACL update in the diagnostic payload of the response (an example is shown in <xreftarget="diag"></xref>).target="diag" format="default"/>). Else, the DOTS server replies with the appropriate response code defined inSection 4.4.1 of<xreftarget="RFC8782"></xref>.</t> <t><figure align="center" anchor="diag" title="Exampletarget="RFC9132" sectionFormat="of" section="4.4.1"/>.</t> <figure anchor="diag"> <name>Example of a Diagnostic Payload Including Failed ACLUpdate"> <artwork><![CDATA[{Update</name> <sourcecode> { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "mid": 123, "ietf-dots-signal-control:acl-list": [ { "acl-name": "an-accept-list", "activation-type": "deactivate" } ] } ] }}]]></artwork> </figure></t>} </sourcecode> </figure> <t>The JSON/YANG mappings for DOTS filter control attributes are shown inTable 1.<xref target="table1"/>. As a reminder, the mapping for 'acl-name' is defined in Table 5 of <xreftarget="RFC8782"></xref>.</t> <t><figure> <artwork><![CDATA[+-------------------+------------+--------+---------------+--------+ | Parameter Name | YANG | CBOR | CBOR Major | JSON | | | Type | Key | Type & | Type | | | | | Information | | +===================+============+========+===============+========+ | activation-type | enumeration| TBA1 | 0 unsigned | String | +-------------------+------------+--------+---------------+--------+ | ietf-dots-signal- | | | | | | control:acl-list | list | TBA2 | 4 array | Array | +-------------------+------------+--------+---------------+--------+ | acl-name | leafref | 23 | 3 text string | String | +-------------------+------------+--------+---------------+--------+ Table 1: JSON/YANGtarget="RFC9132"/>.</t> <table anchor="table1"> <name>JSON/YANG Mapping to CBOR for Filter ControlAttributes]]></artwork> </figure></t>Attributes</name> <thead> <tr> <th>Parameter Name</th> <th>YANG Type</th> <th>CBOR Key</th> <th>CBOR Major Type & Information</th> <th>JSON Type</th> </tr> </thead> <tbody> <tr> <td>activation-type</td> <td>enumeration</td> <td>52</td> <td>0 unsigned</td> <td>String</td> </tr> <tr> <td>ietf-dots-signal-control:acl-list</td> <td>list</td> <td>53</td> <td>4 array</td> <td>Array</td> </tr> <tr> <td>acl-name</td> <td>leafref</td> <td>23</td> <td>3 text string</td> <td>String</td> </tr> </tbody> </table> <t>If the DOTS client receives a 5.03 (Service Unavailable) with a diagnostic payload indicating a failed ACL update as a response to an initial mitigation or a mitigation with adjusted scope, the DOTS clientMUST<bcp14>MUST</bcp14> immediately send a new requestwhichthat repeats all the parameters as sent in the failed mitigation request but without including the ACL attributes. After the expiry of Max-Age returned in the 5.03 (Service Unavailable) response, the DOTS client retries with a new mitigation request (i.e., a new 'mid') that repeats all the parameters as sent in the failed mitigation request (i.e., the one including the ACL attributes).</t> <t>If, during an active mitigation, the 'activation-type' is changed at the DOTS server (e.g., as a result of an external action) for an ACL bound to a DOTS client, the DOTS server notifies that DOTS client of the change by including the corresponding ACL parameters in an asynchronous notification (the DOTS client is observing the active mitigation) or in a response to a polling request(Section 4.4.2.2 of <xref target="RFC8782"></xref>).</t>(<xref target="RFC9132" sectionFormat="of" section="4.4.2.2"/>).</t> <t>If the DOTS signal and data channels of a DOTS client are not established with the same DOTS server of a DOTS server domain, the above request processing operations are undertaken using the coordination mechanism discussed in <xreftarget="bind"></xref>.</t>target="bind" format="default"/>.</t> <t>This specification does not require any modification to the efficacy update and the withdrawal procedures defined in <xreftarget="RFC8782"></xref>.target="RFC9132" format="default"/>. In particular, ACL-related clauses are not included in a PUT request used to send an efficacy update and DELETE requests.</t> </section> <section anchor="YANG"title="DOTSnumbered="true" toc="default"> <name>DOTS Signal Filtering ControlModule ">Module</name> <section anchor="tree"title="Tree Structure">numbered="true" toc="default"> <name>Tree Structure</name> <t>This document augments the "ietf-dots-signal-channel" YANG module defined in <xreftarget="RFC8782"></xref>target="RFC9132" format="default"/> for managing filtering rules.</t> <t>This document defines the YANG module "ietf-dots-signal-control", which has the following treestructure:<figure> <artwork><![CDATA[module:structure:</t> <sourcecode type="yangtree"> module: ietf-dots-signal-controlaugment /ietf-signal:dots-signal/ietf-signal:message-type /ietf-signal:mitigation-scope/ietf-signal:scope: +--rwaugment-structure /dots-signal:dots-signal/dots-signal:message-type /dots-signal:mitigation-scope/dots-signal:scope: +-- acl-list* [acl-name]{control-filtering}? +--rw+-- acl-name | ->/ietf-data:dots-data/dots-client/acls/acl/name +--rw/data-channel:dots-data/dots-client/acls/acl/name +-- activation-type?ietf-data:activation-type ]]></artwork> </figure></t>data-channel:activation-type </sourcecode > </section> <sectiontitle="YANG Module">numbered="true" toc="default"> <name>YANG Module</name> <t>This YANG module is not intended to be used via NETCONF/RESTCONF for DOTS server management purposes; such a module is out of the scope of this document. It serves only to provide a data model and encoding, but not a management data model.</t> <t>This module uses types defined in <xreftarget="RFC8783"></xref>.</t> <t><figure> <artwork><![CDATA[<CODE BEGINS> file "ietf-dots-signal-control@2019-05-13.yang"target="RFC8783" format="default"/>.</t> <sourcecode name="ietf-dots-signal-control@2021-09-01.yang" type="yang" markers="true"><![CDATA[ module ietf-dots-signal-control { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; prefix dots-control; import ietf-dots-signal-channel { prefixietf-signal;dots-signal; reference "RFC8782: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"; } import ietf-dots-data-channel { prefixietf-data;data-channel; reference "RFC 8783: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"; } 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: Kaname Nishizuka <mailto:kaname@nttv6.jp> Author: Mohamed Boucadair <mailto:mohamed.boucadair@orange.com> Author:Konda,TirumaleswarReddy <mailto:TirumaleswarReddy_Konda@McAfee.com>Reddy.K <mailto:kondtir@gmail.com> Author: Takahiko Nagata <mailto:nagata@lepidum.co.jp>"; description "This module contains YANG definition for the signaling messages exchanged between a DOTS client and a DOTS server to control, by means of the DOTS signal channel, filtering rules configured using the DOTS data channel. Copyright (c)20202021 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).(https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX;9133; see the RFC itself for full legal notices."; revision2019-05-132021-09-01 { description "Initial revision."; reference "RFCXXXX:9133: Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel"; }feature control-filtering { description "This feature means that the DOTS signal channel is able to manage the filtering rules created by the same DOTS client using the DOTS data channel."; } augment "/ietf-signal:dots-signal/ietf-signal:message-type"sx:augment-structure "/dots-signal:dots-signal" + "/dots-signal:message-type" +"/ietf-signal:mitigation-scope/ietf-signal:scope""/dots-signal:mitigation-scope" + "/dots-signal:scope" {if-feature control-filtering;description "ACL name and activation type."; list acl-list { key "acl-name"; description "List of ACLs as defined using the DOTS data channel. ACLs bound to a DOTS client are uniquely identified by a name."; leaf acl-name { type leafref { path"/ietf-data:dots-data/ietf-data:dots-client""/data-channel:dots-data/data-channel:dots-client" + "/data-channel:acls/data-channel:acl" +"/ietf-data:acls/ietf-data:acl/ietf-data:name";"/data-channel:name"; } description "Reference to the ACL name bound to a DOTS client."; } leaf activation-type { typeietf-data:activation-type;data-channel:activation-type; default "activate-when-mitigating"; description "Sets the activation type of an ACL."; } } } }<CODE ENDS> ]]></artwork> </figure></t>]]></sourcecode> </section> </section> </section> </section> <section anchor="sample"title="Some Examples">numbered="true" toc="default"> <name>Some Examples</name> <t>This section provides some examples to illustrate the behavior specified in <xreftarget="filtering"></xref>.target="filtering" format="default"/>. These examples are provided for illustration purposes; they should not be considered as deployment recommendations.</t> <section anchor="sample1"title="Conflict Handling">numbered="true" toc="default"> <name>Conflict Handling</name> <t>Let's consider a DOTS clientwhichthat contacts its DOTS server during 'idle' time to install an accept-list allowing for UDP traffic issued from 2001:db8:1234::/48 with a destination port number 443 to be forwarded to 2001:db8:6401::2/127. It does so by sending, for example, a PUT request as shown in <xreftarget="PUT"></xref>.</t> <t><figure anchor="PUT" title="DOTStarget="PUT" format="default"/>.</t> <figure anchor="PUT"> <name>DOTS Data Channel Request to Create aFilter"> <artwork align="left"><![CDATA[PUTFilter</name> <sourcecode> PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /acl=an-accept-list HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [ { "name": "an-accept-list", "type": "ipv6-acl-type", "activation-type": "activate-when-mitigating", "aces": { "ace": [ { "name": "test-ace-ipv6-udp", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:6401::2/127", "source-ipv6-network": "2001:db8:1234::/48" }, "udp": { "destination-port-range-or-operator": { "operator": "eq", "port": 443 } } }, "actions": { "forwarding": "accept" } } ] } } ] }}]]></artwork> </figure></t>} </sourcecode> </figure> <t>Sometime later, consider that a DDoS attack is detected by the DOTS client on 2001:db8:6401::2/127. Consequently, the DOTS client sends a mitigation request to its DOTS server as shown in <xreftarget="mitigate"></xref>.</t> <t><figure anchor="mitigate" title="DOTStarget="mitigate" format="default"/>.</t> <figure anchor="mitigate"> <name>DOTS Signal Channel MitigationRequest"> <artwork align="left"><![CDATA[Header:Request</name> <sourcecode> Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" Uri-Path: "mid=123" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], "lifetime": 3600 } ] } }]]></artwork> </figure></t></sourcecode> </figure> <t>The DOTS serveracceptsimmediately accepts the request by replying with 2.01 (Created) (<xreftarget="response"></xref>target="response" format="default"/> depicts the message body of the response).</t><t><figure anchor="response" title="Status<figure anchor="response"> <name>Status Response (MessageBody)"> <artwork align="left"><![CDATA[{Body)</name> <sourcecode> { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "mid": 123, "lifetime": 3600 } ] } }]]></artwork> </figure></t></sourcecode> </figure> <t>Assuming the DOTS client subscribed to asynchronous notifications, when the DOTS server concludes that some of the attack sources belong to 2001:db8:1234::/48, it sends a notification message with 'status' code set to'1 (Attack mitigation is in progress)'1 (attack-mitigation-in-progress) and 'conflict-cause' set to'2'2 (conflict-with-acceptlist) to the DOTS client to indicate that this mitigation request is in progress, but a conflict is detected.</t> <t>Upon receipt of the notification message from the DOTS server, the DOTS client sends a PUT request to deactivate the "an-accept-list" ACL as shown in <xreftarget="control"></xref>.</t>target="control" format="default"/>.</t> <t>The DOTS client can also decide to send a PUT request to deactivate the "an-accept-list"ACL,ACL if suspect traffic is received from an accept-listed source (2001:db8:1234::/48). The structure of that PUT is the same as the one shown in <xreftarget="control"></xref>.</t> <t><figure anchor="control" title="PUTtarget="control" format="default"/>.</t> <figure anchor="control"> <name>PUT for Deactivating a ConflictingFilter"> <artwork align="left"><![CDATA[Header:Filter</name> <sourcecode> Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" Uri-Path: "mid=124" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], "ietf-dots-signal-control:acl-list": [ { "acl-name": "an-accept-list", "activation-type": "deactivate" } ], "lifetime": 3600 } ] } }]]></artwork> </figure></t></sourcecode> </figure> <t>Then, the DOTS server deactivates the "an-accept-list" ACL and replies with a 2.04 (Changed) response to the DOTS client to confirm the successful operation. The message body is similar to the one depicted in <xreftarget="response"></xref>.</t>target="response" format="default"/>.</t> <t>Once the attack is mitigated, the DOTS client may use the data channel to retrieve its ACLs maintained by the DOTS server. As shown in <xreftarget="GET-2"></xref>,target="GET-2" format="default"/>, the activation type is set to 'deactivate' as set by the DOTS signal channel (<xreftarget="control"></xref>)target="control" format="default"/>) instead of the type initially set using the DOTS data channel (<xreftarget="PUT"></xref>).</t> <t><figure anchor="GET-2" title="DOTStarget="PUT" format="default"/>).</t> <figure anchor="GET-2"> <name>DOTS Data Channel GET Response after Mitigation (MessageBody)"> <artwork align="left"><![CDATA[{Body)</name> <sourcecode> { "ietf-dots-data-channel:acls": { "acl": [ { "name": "an-accept-list", "type": "ipv6-acl-type", "activation-type": "deactivate", "pending-lifetime": 10021, "aces": { "ace": [ { "name": "test-ace-ipv6-udp", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:6401::2/127", "source-ipv6-network": "2001:db8:1234::/48" }, "udp": { "destination-port-range-or-operator": { "operator": "eq", "port": 443 } } }, "actions": { "forwarding": "accept" } } ] } } ] }}]]></artwork> </figure></t>} </sourcecode> </figure> </section> <section anchor="sample2"title="On-Demandnumbered="true" toc="default"> <name>On-Demand Activation of an Accept-ListFilter">Filter</name> <t>Let's consider a DOTS clientwhichthat contacts its DOTS server during 'idle' time to install an accept-list allowing for UDP traffic issued from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It does so by sending, for example, a PUT request shown in <xreftarget="PUT1"></xref>.target="PUT1" format="default"/>. The DOTS server installs this filter with a "deactivated" state.</t><t><figure anchor="PUT1" title="DOTS<figure anchor="PUT1"> <name>DOTS Data Channel Request to Create an Accept-ListFilter"> <artwork align="left"><![CDATA[PUTFilter</name> <sourcecode> PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\ /acl=my-accept-list HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [ { "name": "my-accept-list", "type": "ipv6-acl-type", "activation-type": "deactivate", "aces": { "ace": [ { "name": "an-ace", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:6401::2/127", "source-ipv6-network": "2001:db8:1234::/48", "protocol": 17 } }, "actions": { "forwarding": "accept" } } ] } } ] }}]]></artwork> </figure></t>} </sourcecode> </figure> <t>Sometime later, consider that a UDP DDoS attack is detected by the DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let the traffic from 2001:db8:1234::/48tobe accept-listed to the DOTS client domain. Consequently, the DOTS client sends a mitigation request to its DOTS server as shown in <xreftarget="mitigate1"></xref>.</t> <t><figure anchor="mitigate1" title="DOTStarget="mitigate1" format="default"/>.</t> <figure anchor="mitigate1"> <name>DOTS Signal Channel Mitigation Request with a FilterControl"> <artwork align="left"><![CDATA[Header:Control</name> <sourcecode> Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA" Uri-Path: "mid=4879" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], "ietf-dots-signal-control:acl-list": [ { "acl-name": "my-accept-list", "activation-type": "immediate" } ], "lifetime": 3600 } ] } }]]></artwork> </figure></t></sourcecode> </figure> <t>The DOTS server activates the "my-accept-list" ACL and replies with a 2.01 (Created) response to the DOTS client to confirm the successful operation.</t> </section> <section anchor="sample3"title="DOTSnumbered="true" toc="default"> <name>DOTS Servers/Mitigators LackingCapacity">Capacity</name> <t>This section describes a scenario in which a DOTS client activates a drop-list or a rate-limit filter during an attack.</t> <t>Consider a DOTS client that contacts its DOTS server during 'idle' time to install an accept-list that rate-limits all (or a part thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort countermeasure whenever required. Installing the accept-list can be done by sending, for example, the PUT request shown in <xreftarget="rate"></xref>.target="rate" format="default"/>. The DOTS server installs this filter with a "deactivated" state.</t><t><figure anchor="rate" title="DOTS<figure anchor="rate"> <name>DOTS Data Channel Request to Create a Rate-LimitFilter"> <artwork><![CDATA[PUTFilter</name> <sourcecode> PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=OopPisZqo4SLv64TLPXrxA/acls\ /acl=my-ratelimit-list HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [ { "name": "my-ratelimit-list", "type": "ipv6-acl-type", "activation-type": "deactivate", "aces": { "ace": [ { "name": "my-ace", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:123::/48" } }, "actions": { "forwarding": "accept", "rate-limit": "20000.00" } } ] } } ] } }]]></artwork> </figure></t></sourcecode> </figure> <t>Consider now that a DDoS attack is detected by the DOTS client on 2001:db8:123::/48. Consequently, the DOTS client sends a mitigation request to its DOTS server (<xreftarget="ratel"></xref>).</t> <t><figure anchor="ratel" title="DOTStarget="ratel" format="default"/>).</t> <figure anchor="ratel"> <name>DOTS Signal Channel MitigationRequest"> <artwork><![CDATA[Header:Request</name> <sourcecode> Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "mid=85" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:123::/48" ], "lifetime": 3600 } ] } }]]></artwork> </figure></t></sourcecode> </figure> <t>For some reason (e.g., the DOTS server, or the mitigator, is lacking a capability or capacity), the DOTS client is still receiving attacktraffictraffic, which saturates available links. To soften the problem, the DOTS client decides to activate the filter that rate-limits the traffic destined to the DOTS client domain. To that aim, the DOTS client sends the mitigation request to its DOTS server shown in <xreftarget="rateres"></xref>.</t> <t><figure anchor="rateres" title="DOTStarget="rateres" format="default"/>.</t> <figure anchor="rateres"> <name>DOTS Signal Channel Mitigation Request to Activate a Rate-LimitFilter"> <artwork><![CDATA[Header:Filter</name> <sourcecode> Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "mid=86" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:123::/48" ], "ietf-dots-signal-control:acl-list": [ { "acl-name": "my-ratelimit-list", "activation-type": "immediate" } ], "lifetime": 3600 } ] } }]]></artwork> </figure></t></sourcecode> </figure> <t>Then, the DOTS server activates the "my-ratelimit-list" ACL and replies with a 2.04 (Changed) response to the DOTS client to confirm the successful operation.</t> <t>As the attack mitigation evolves, the DOTS client may decide to deactivate the rate-limit policy (e.g., upon receipt of a notification status change from 'attack-exceeded-capability' to 'attack-mitigation-in-progress'). Based on the mitigation status conveyed by the DOTS server, the DOTS client cande-activatedeactivate the rate-limit action. It does so by sending the request shown in <xreftarget="rateres2"></xref>.</t> <t><figure anchor="rateres2" title="DOTStarget="rateres2" format="default"/>.</t> <figure anchor="rateres2"> <name>DOTS Signal Channel Mitigation Request to Deactivate a Rate-LimitFilter"> <artwork><![CDATA[Header:Filter</name> <sourcecode type="cbor"> Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "mid=87" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:123::/48" ], "ietf-dots-signal-control:acl-list": [ { "acl-name": "my-ratelimit-list", "activation-type": "deactivate" } ], "lifetime": 3600 } ] } }]]></artwork> </figure></t></sourcecode> </figure> </section> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="map"title="DOTSnumbered="true" toc="default"> <name>DOTS Signal Channel CBORMappings Registry"> <t>This specification registersKey Values Subregistry</name> <t>Per this specification, IANA has registered the following parameters in theIANA"DOTS Signal Channel CBOR Key Values" subregistry within the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" registry <xreftarget="Key-Map"></xref>.</t> <t><list style="symbols"> <t>Note to the RFC Editor: Please delete (TBA1-TBA2) once the CBOR keys are assigned from the 1-16383 range. Please update Table 1 accordingly.</t> </list></t> <t><figure align="center"> <artwork><![CDATA[ +--------------------+--------+-------+------------+---------------+ | Parameter Name | CBOR | CBOR | Change | Specification | | |target="Key-Map" format="default"/>.</t> <table anchor="table2"> <thead> <tr> <th>Parameter Name</th> <th>CBOR Key|Value</th> <th>CBOR Major| Controller | Document(s) | | | Value | Type | | | +====================+========+=======+============+===============+ | activation-type | 52 | | | | | | (TBA1) | 0 | IESG | [RFCXXXX] | +--------------------+--------+-------+------------+---------------+ | ietf-dots-signal- | 53 | | | | | control:acl-list | (TBA2) | 4 | IESG | [RFCXXXX] | +--------------------+--------+-------+------------+---------------+ ]]></artwork> </figure></t>Type</th> <th>Change Controller</th> <th>Specification Document(s)</th> </tr> </thead> <tbody> <tr> <td>activation-type</td> <td>52</td> <td>0</td> <td>IESG</td> <td>RFC 9133</td> </tr> <tr> <td>ietf-dots-signal-control:acl-list</td> <td>53</td> <td>4</td> <td>IESG</td> <td>RFC 9133</td> </tr> </tbody> </table> </section> <section anchor="yang-iana"title="DOTS Signal Filtering Controlnumbered="true" toc="default"> <name>A New YANGModule"> <t>This document requests IANA to registerModule</name> <t>IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" <xreftarget="RFC3688"></xref>:</t> <t><figure> <artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control Registrant Contact: The IESG. XML: N/A;target="RFC3688" format="default"/>:</t> <dl newline="false" spacing="compact"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. ]]></artwork> </figure></t> <t>This document requests IANA to registernamespace.</dd> </dl> <t>IANA has registered the following YANG module in the "YANG Module Names" subregistry <xreftarget="RFC7950"></xref>target="RFC6020" format="default"/> within the "YANG Parameters" registry.</t><t><figure> <artwork><![CDATA[ Name: ietf-dots-signal-control Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control Maintained by IANA: N Prefix: dots-control Reference: RFC XXXX ]]></artwork> </figure></t><dl newline="false" spacing="compact"> <dt>Name:</dt><dd>ietf-dots-signal-control</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd> <dt>Maintained by IANA:</dt><dd>N</dd> <dt>Prefix:</dt><dd>dots-control</dd> <dt>Reference:</dt><dd>RFC 9133</dd> </dl> </section> </section> <section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The security considerations for the DOTS signal channel protocol are discussed inSection 10 of<xreftarget="RFC8782"></xref>,target="RFC9132" sectionFormat="of" section="11"/>, while those for the DOTS data channel protocol are discussed inSection 10 of<xreftarget="RFC8783"></xref>.target="RFC8783" sectionFormat="of" section="10"/>. The following discusses the security considerations that are specific to the DOTS signal channel extension defined in this document.</t> <t>This specification does not allowto createthe creation of new filtering rules, which is the responsibility of the DOTS data channel. DOTS client domains should be adequately prepared prior to an attack, e.g., by creating filters that will be activated on demand when an attack is detected.</t> <t>A DOTS client is entitled to access only the resources it creates. In particular, a DOTS client can not tweak filtering rules created by other DOTS clients of the same DOTS client domain. As a reminder, DOTS servers must associate filtering rules with the DOTS client that created these resources. Failure to ensure such association by a DOTS server will have severe impact on DOTS client domains.</t> <t>A compromised DOTS client can use the filtering control capability to exacerbate an ongoing attack. Likewise, such a compromised DOTS client may abstain from reacting to an ACL conflict notification received from the DOTS server during attacks. These are not new attack vectors, but variations of threats discussed in <xreftarget="RFC8782"></xref>target="RFC9132" format="default"/> and <xreftarget="RFC8783"></xref>.target="RFC8783" format="default"/>. DOTS operators should carefully monitor and audit DOTS agents to detect misbehaviors andtodeter misuses.</t> </section><section anchor="ack" title="Acknowledgements"> <t>Many thanks to Wei Pan, Xia Liang, Jon Shallow, Dan Wing, Christer Holmberg, Shawn Emery, Tim Chown, Murray Kucherawy, Roman Danyliw, Erik Kline, and Eric Vyncke for the comments.</t> <t>Thanks to Benjamin Kaduk for the AD review.</t> </section></middle> <back><references title="Normative References"> <?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.7950"?> <?rfc include="reference.RFC.3688"?> <?rfc include='reference.RFC.8174'?> <?rfc include="reference.RFC.8782"?> <?rfc include="reference.RFC.8783" ?> <?rfc ?><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.7950.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.6020.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.8791.xml"/> <reference anchor="RFC9132" target="https://www.rfc-editor.org/info/rfc9132"> <front> <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title> <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair" role="editor"> <organization /> </author> <author initials="J" surname="Shallow" fullname="Jon Shallow"> <organization /> </author> <author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.K"> <organization /> </author> <date month="September" year="2021" /> </front> <seriesInfo name="RFC" value="9132" /> <seriesInfo name="DOI" value="10.17487/RFC9132"/> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml"/> </references><references title="Informative References"> <?rfc include="reference.RFC.8612"?> <?rfc include='reference.RFC.7951'?> <?rfc include='reference.RFC.8340'?> <?rfc include='reference.I-D.ietf-dots-architecture'?><references> <name>Informative References</name> <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.7951.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.8811.xml"/> <referenceanchor="Interop"anchor="INTEROP" target="https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00"> <front> <title>DOTS Interop test report, IETF 103 Hackathon</title> <author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka"> <organization>NTT Communications</organization> <address> <postal> <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street> <city>Tokyo</city><region></region><region/> <code>108-8118</code> <country>Japan</country> </postal> <email>kaname@nttv6.jp</email> </address> </author> <author fullname="Jon Shallow" initials="J." surname=" Shallow"> <organization>J.NCC Group</organization> <address> <postal><street></street> <city></city> <region></region> <code></code> <country></country><street/> <city/> <region/> <code/> <country/> </postal><phone></phone> <facsimile></facsimile> <email></email> <uri></uri><phone/> <email/> <uri/> </address> </author> <author fullname="Liang Xia" initials="L." surname="Xia "> <organization>Huawei</organization> <address> <postal><street></street> <city></city> <region></region> <code></code> <country></country><street/> <city/> <region/> <code/> <country/> </postal><phone></phone> <facsimile></facsimile> <email></email> <uri></uri><phone/> <email/> <uri/> </address> </author> <date month="November"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<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) SignalChannel CBOR Key Values</title>Channel</title> <author fullname="IANA"><organization></organization><organization/> </author><date /></front> </reference> </references> </references> <section anchor="ack" numbered="false" toc="default"> <name>Acknowledgements</name> <t>Many thanks to <contact fullname="Wei Pan"/>, <contact fullname="Xia Liang"/>, <contact fullname="Jon Shallow"/>, <contact fullname="Dan Wing"/>, <contact fullname="Christer Holmberg"/>, <contact fullname="Shawn Emery"/>, <contact fullname="Tim Chown"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Erik Kline"/>, and <contact fullname="Éric Vyncke"/> for the comments.</t> <t>Thanks to <contact fullname="Benjamin Kaduk"/> for the AD review.</t> </section> </back> </rfc>