1<?xml version='1.0' encoding='utf-8'?>
2<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-dots-signal-filter-control-07" indexInclude="true" ipr="trust200902" number="9133" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
3  <link href="https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control-07" rel="prev"/>
4  <link href="https://dx.doi.org/10.17487/rfc9133" rel="alternate"/>
5  <link href="urn:issn:2070-1721" rel="alternate"/>
6  <front>
7    <title abbrev="DOTS Signal Filter Control">Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel</title>
8    <seriesInfo name="RFC" value="9133" stream="IETF"/>
9    <author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka">
10      <organization>NTT Communications</organization>
11      <address>
12        <postal>
13          <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
14          <code>108-8118</code>
15          <region>Tokyo</region>
16          <country>Japan</country>
17        </postal>
18        <email>kaname@nttv6.jp</email>
19      </address>
20    </author>
21    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
22      <organization>Orange</organization>
23      <address>
24        <postal>
25          <street/>
26          <city>Rennes</city>
27          <code>35000</code>
28          <region/>
29          <country>France</country>
30        </postal>
31        <email>mohamed.boucadair@orange.com</email>
32      </address>
33    </author>
34    <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
35      <organization abbrev="Akamai">Akamai</organization>
36      <address>
37        <postal>
38          <street>Embassy Golf Link Business Park</street>
39          <city>Bangalore</city>
40          <code>560071</code>
41          <region>Karnataka</region>
42          <country>India</country>
43        </postal>
44        <email>kondtir@gmail.com</email>
45      </address>
46    </author>
47    <author fullname="Takahiko Nagata" initials="T." surname="Nagata">
48      <organization>Lepidum</organization>
49      <address>
50        <postal>
51          <street/>
52          <city/>
53          <region/>
54          <code/>
55          <country>Japan</country>
56        </postal>
57        <email>nagata@lepidum.co.jp</email>
58      </address>
59    </author>
60    <date month="09" year="2021"/>
61    <workgroup>DOTS</workgroup>
62    <keyword>Mitigation</keyword>
63    <keyword>Automation</keyword>
64    <keyword>Filtering</keyword>
65    <keyword>Protective Networking</keyword>
66    <keyword>Protected Networks</keyword>
67    <keyword>Security</keyword>
68    <keyword>Anti-DDoS</keyword>
69    <keyword>Reactive</keyword>
70    <keyword>Collaborative Networking</keyword>
71    <keyword>Collaborative Security</keyword>
72    <abstract>
73      <t>This document specifies an extension to the Distributed
74      Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol
75      so that DOTS clients can control their filtering rules when an attack
76      mitigation is active.</t>
77      <t>Particularly, this extension allows a DOTS client to activate or
78      deactivate existing filtering rules during a Distributed
79      Denial-of-Service (DDoS) attack. The
80      characterization of these filtering rules is conveyed by a DOTS client
81      during an 'idle' time (i.e., no mitigation is active) by means of the DOTS
82      data channel protocol.</t>
83    </abstract>
84  </front>
85  <middle>
86    <section anchor="introduction">
87      <name>Introduction</name>
88      <section anchor="problem">
89        <name>The Problem</name>
90        <t>In the Distributed Denial-of-Service Open Threat Signaling (DOTS)
91        architecture <xref target="RFC8811"/>, DOTS
92        clients and servers communicate using both a signal channel protocol
93        <xref target="RFC9132"/> and a data channel protocol <xref target="RFC8783"/>.</t>
94        <t>The DOTS data channel protocol <xref target="RFC8783"/> is used for bulk data exchange between DOTS agents
95        to improve the coordination of parties involved in the response to a
96        Distributed Denial-of-Service (DDoS) attack. Filter management, which
97        is one of the tasks of the DOTS data channel protocol, enables a DOTS
98        client to retrieve the filtering capabilities of a DOTS server and to
99        manage filtering rules. Typically, these filtering rules are used for
100        dropping or rate-limiting unwanted traffic, and permitting
101        accept-listed traffic.</t>
102        <t>The DOTS signal channel protocol <xref target="RFC9132"/> is
103        designed to be resilient under extremely hostile network conditions
104        and provides continued contact between DOTS agents even as DDoS attack
105        traffic saturates the link. The DOTS signal channel can be established
106        between two DOTS agents prior to or during an attack. At any time, the
107        DOTS client may send mitigation requests (as per <xref target="RFC9132" section="4.4"/>) to a DOTS server over the active signal
108        channel. While mitigation is active, the DOTS server periodically
109        sends status messages to the DOTS client, including basic mitigation
110        feedback details. In case of a massive DDoS attack that saturates the
111        incoming link(s) to the DOTS client, all traffic from the DOTS server
112        to the DOTS client will likely be dropped. However, the DOTS server
113        may still receive DOTS messages sent from the DOTS client over the
114        signaling channel thanks to the heartbeat requests keeping the
115        channel active (as described in <xref target="RFC9132" section="4.7"/>).</t>
116        <t>Unlike the DOTS signal channel protocol, the DOTS data channel
117        protocol is not expected to deal with attack conditions. As such, an
118        issue that might be encountered in some deployments is when filters
119        installed by means of the DOTS data channel protocol may not function
120        as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS
121        attack. In such conditions, the DOTS data channel protocol cannot be
122        used to change these filters, which may complicate DDoS mitigation
123        operations <xref target="INTEROP"/>.</t>
124        <t>A typical case is a conflict between filtering rules installed by a
125        DOTS client and the mitigation actions of a DDoS mitigator. Consider,
126        for instance, a DOTS client that configures during 'idle' time (i.e.,
127        no mitigation is active) some filtering rules using the DOTS data
128        channel protocol to permit traffic from accept-listed sources.
129        However, during a volumetric DDoS attack, the DDoS mitigator identifies
130        the source addresses/prefixes in the accept-listed filtering rules are
131        attacking the target. For example, an attacker can spoof the IP
132        addresses of accept-listed sources to generate attack traffic, or the
133        attacker can compromise the accept-listed sources and program them to
134        launch a DDoS attack.</t>
135        <t><xref target="RFC9132"/> is designed so that the
136        DDoS server notifies the above conflict to the DOTS client (that is,
137        the 'conflict-cause' parameter is set to 2 (conflict-with-acceptlist)),
138        but the DOTS client may not be able to withdraw the accept-list rules
139        during the attack period due to the high-volume attack traffic
140        saturating the inbound link to the DOTS client domain.  In other
141        words, the DOTS client cannot use the DOTS data channel protocol to
142        withdraw the accept-list filters when a DDoS attack is in
143        progress.</t>
144      </section>
145      <section anchor="sol">
146        <name>Controlling Filtering Rules Using DOTS Signal Channel</name>
147        <t>This specification addresses the problems discussed in <xref target="problem"/> by adding a capability for managing filtering
148        rules using the DOTS signal channel protocol, which enables a DOTS
149        client to request the activation (or deactivation) of filtering rules
150        during a DDoS attack. Note that creating these filtering rules is
151        still the responsibility of the DOTS data channel <xref target="RFC8783"/>.</t>
152        <t>The DOTS signal channel protocol is designed to enable a DOTS
153        client to contact a DOTS server for help even under severe network
154        congestion conditions. Therefore, extending the DOTS signal channel
155        protocol to manage the filtering rules during an attack will enhance
156        the protection capability offered by DOTS protocols.</t>
157        <aside>
158          <t>Note: The experiment at the IETF 103 hackathon <xref target="INTEROP"/> showed that even when the
159          inbound link is saturated by DDoS attack traffic, the DOTS client
160          can signal mitigation requests using the DOTS signal channel over
161          the saturated link.</t>
162        </aside>
163        <t>Conflicts that are induced by filters installed by other DOTS
164        clients of the same domain are not discussed in this
165        specification.</t>
166        <t>An augmentation to the DOTS signal channel YANG module is defined
167        in <xref target="YANG"/>.</t>
168        <t>Sample examples are provided in <xref target="sample"/>, in
169        particular: </t>
170        <ul>
171          <li>
172            <xref target="sample1"/> illustrates how the filter
173            control extension is used when conflicts with Access Control Lists
174            (ACLs) are detected and reported by a DOTS server.</li>
175          <li>
176            <xref target="sample2"/> shows how a DOTS client can
177            instruct a DOTS server to safely forward some specific traffic in
178            'attack' time.</li>
179          <li>
180            <xref target="sample3"/> shows how a DOTS client can
181            react if the DDoS traffic is still being forwarded to the DOTS
182            client domain even if mitigation requests were sent to a DOTS
183            server.</li>
184        </ul>
185        <t>The JavaScript Object Notation (JSON) encoding of YANG-modeled data
186        <xref target="RFC7951"/> is used to illustrate the examples.</t>
187      </section>
188    </section>
189    <section anchor="notation">
190      <name>Terminology</name>
191      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
192      "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
193      "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
194      "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
195      to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
196      only when, they appear in all capitals, as shown here.</t>
197      <t>The reader should be familiar with the terms defined in <xref target="RFC8612"/>.</t>
198      <t>The terminology for describing YANG modules is defined in <xref target="RFC7950"/>. The meaning of the symbols in the
199      tree diagram is defined in <xref target="RFC8340"/> and <xref target="RFC8791"/>.</t>
200    </section>
201    <section>
202      <name>Controlling Filtering Rules of a DOTS Client</name>
203      <section anchor="bind">
204        <name>Binding DOTS Data and Signal Channels</name>
205        <t>The filtering rules eventually managed using the DOTS signal
206        channel protocol are created a priori by the same DOTS client using
207        the DOTS data channel protocol. Managing conflicts with filters
208        installed by other DOTS clients of the same domain is out of
209        scope.</t>
210        <t>As discussed in <xref target="RFC9132" section="4.4.1"/>, a DOTS client must use the same 'cuid' for both the
211        DOTS signal and data channels. This requirement is meant to facilitate
212        binding DOTS channels used by the same DOTS client.</t>
213        <t>The DOTS signal and data channels from a DOTS client may or may not
214        use the same DOTS server. Nevertheless, the scope of the mitigation
215        request, alias, and filtering rules are not restricted to the DOTS
216        server but to the DOTS server domain. To that aim, DOTS servers within
217        a domain are assumed to have a mechanism to coordinate the mitigation
218        requests, aliases, and filtering rules to coordinate their decisions
219        for better mitigation operation efficiency. The exact details about
220        such a mechanism is out of the scope of this document.</t>
221        <t>A filtering rule controlled by the DOTS signal channel is
222        identified by its ACL name (<xref target="RFC8783" section="4.3"/>). Note that an ACL name unambiguously
223        identifies an ACL bound to a DOTS client, but the same name may be
224        used by distinct DOTS clients.</t>
225        <t>The activation or deactivation of an ACL by the DOTS signal channel
226        overrides the 'activation-type' (defined in <xref target="RFC8783" section="4.3"/>) a priori conveyed with the
227        filtering rules using the DOTS data channel protocol.</t>
228        <t>Once the attack is mitigated, the DOTS client may use the data
229        channel to control the 'activation-type' (e.g., revert to a default
230        value) of some of the filtering rules controlled by the DOTS signal
231        channel or delete some of these filters. This behavior is deployment
232        specific.</t>
233      </section>
234      <section>
235        <name>DOTS Signal Channel Extension</name>
236        <section anchor="filtering">
237          <name>Parameters and Behaviors</name>
238          <t>This specification extends the mitigation request defined in
239          <xref target="RFC9132" section="4.4.1"/> to
240          convey the intended control of configured filtering
241          rules. Concretely, the DOTS client conveys the 'acl-list' attribute with
242          the following sub-attributes in the Concise Binary Object
243   Representation (CBOR) body of a mitigation
244          request (see the YANG structure in <xref target="tree"/>):</t>
245          <dl>
246            <dt>acl-name:</dt>
247            <dd>
248              <t>A name of an access list defined using
249              the DOTS data channel (<xref target="RFC8783" section="4.3"/>) that is associated with the DOTS
250              client.</t>
251              <t>As a reminder, an ACL is an ordered list of Access Control
252              Entries (ACEs). Each ACE has a list of match criteria and a list
253              of actions <xref target="RFC8783"/>. The list
254              of configured ACLs can be retrieved using the DOTS data channel
255              during 'idle' time.</t>
256              <t>This is a mandatory attribute when 'acl-list'
257              is included.</t>
258            </dd>
259            <dt>activation-type:</dt>
260            <dd>
261              <t>An attribute indicating the activation type of
262              an ACL overriding the existing 'activation-type' installed by
263              the DOTS client using the DOTS data channel. </t>
264              <t>As a reminder, this attribute can be set to
265              'deactivate', 'immediate', or 'activate-when-mitigating' as
266              defined in <xref target="RFC8783"/>. </t>
267              <t>Note that both 'immediate' and
268              'activate-when-mitigating' have an immediate effect when a
269              mitigation request is being processed by the DOTS server.
270              </t>
271              <t>This is an optional attribute.</t>
272            </dd>
273          </dl>
274          <t>By default, ACL-related operations are achieved using the DOTS
275          data channel protocol when no attack is ongoing. DOTS clients <bcp14>MUST NOT</bcp14> use the filtering control over the DOTS signal channel in 'idle'
276          time; such requests <bcp14>MUST</bcp14> be discarded by DOTS servers with 4.00 (Bad
277          Request).</t>
278          <t>During an attack time, DOTS clients may include 'acl-list',
279          'acl-name', and 'activation-type' attributes in a mitigation
280          request. This request may be the initial mitigation request for a
281          given mitigation scope or a new one overriding an existing request.
282          In both cases, a new 'mid' <bcp14>MUST</bcp14> be used. Nevertheless, it is <bcp14>NOT RECOMMENDED</bcp14> to include ACL attributes in an initial mitigation
283          request for a given mitigation scope or in a mitigation request
284          adjusting the mitigation scope. This recommendation is meant to
285          avoid delaying attack mitigations because of failures to process ACL
286          attributes.</t>
287          <t>As the attack evolves, DOTS clients can adjust the
288          'activation-type' of an ACL conveyed in a mitigation request or
289          control other filters as necessary. This can be achieved by sending
290          a PUT request with a new 'mid' value.</t>
291          <t>It is <bcp14>RECOMMENDED</bcp14> for a DOTS client to subscribe
292          to asynchronous notifications of the attack mitigation, as detailed
293          in <xref target="RFC9132" section="4.4.2.1"/>. If
294          not, the polling mechanism in <xref target="RFC9132" section="4.4.2.2"/> has to be followed by the
295          DOTS client.</t>
296          <t>A DOTS client relies on the information received from the DOTS
297          server and/or local information to the DOTS client domain to trigger
298          a filter control request. Only filters that are pertinent for an
299          ongoing mitigation should be controlled by a DOTS client using the
300          DOTS signal channel.</t>
301          <t>'acl-list', 'acl-name', and 'activation-type' are defined as
302          comprehension-required parameters. Following the rules in <xref target="RFC9132" section="6"/>, if the DOTS
303          server does not understand the 'acl-list', 'acl-name', or
304          'activation-type' attributes, it responds with a 4.00 (Bad
305          Request) error response code.</t>
306          <t>If the DOTS server does not find the ACL name ('acl-name')
307          conveyed in the mitigation request for this DOTS client, it <bcp14>MUST</bcp14>
308          respond with a 4.04 (Not Found) error response code.</t>
309          <t>If the DOTS server finds the ACL name for this DOTS client, and
310          assuming the request passed the validation checks in <xref target="RFC9132" section="4.4.1"/>, the DOTS
311          server <bcp14>MUST</bcp14> proceed with the 'activation-type'
312          update. The update is immediately enforced by the DOTS server and
313          will be maintained as the new activation type for the ACL name even
314          after the termination of the mitigation request. In addition, the
315          DOTS server <bcp14>MUST</bcp14> update the lifetime of the
316          corresponding ACL similar to the update when a refresh request is
317          received using the DOTS data channel (<xref target="RFC8783" section="7.2"/>). If, for some reason, the DOTS
318          server fails to apply the filter update, it <bcp14>MUST</bcp14>
319          respond with a 5.03 (Service Unavailable) error response code and
320          include the failed ACL update in the diagnostic payload of the
321          response (an example is shown in <xref target="diag"/>). Else, the DOTS server replies with the
322          appropriate response code defined in <xref target="RFC9132" section="4.4.1"/>.</t>
323          <figure anchor="diag">
324            <name>Example of a Diagnostic Payload Including Failed ACL Update</name>
325            <sourcecode>
326{
327  "ietf-dots-signal-channel:mitigation-scope": {
328    "scope": [
329      {
330        "mid": 123,
331        "ietf-dots-signal-control:acl-list": [
332          {
333            "acl-name": "an-accept-list",
334            "activation-type": "deactivate"
335          }
336        ]
337      }
338    ]
339  }
340}
341</sourcecode>
342          </figure>
343          <t>The JSON/YANG mappings for DOTS filter control attributes are
344          shown in <xref target="table1"/>. As a reminder, the mapping for 'acl-name' is
345          defined in Table 5 of <xref target="RFC9132"/>.</t>
346          <table anchor="table1">
347            <name>JSON/YANG Mapping to CBOR for Filter Control Attributes</name>
348            <thead>
349              <tr>
350                <th>Parameter Name</th>
351                <th>YANG Type</th>
352                <th>CBOR Key</th>
353                <th>CBOR Major Type &amp; Information</th>
354                <th>JSON Type</th>
355              </tr>
356            </thead>
357            <tbody>
358              <tr>
359                <td>activation-type</td>
360                <td>enumeration</td>
361                <td>52</td>
362                <td>0 unsigned</td>
363                <td>String</td>
364              </tr>
365              <tr>
366                <td>ietf-dots-signal-control:acl-list</td>
367                <td>list</td>
368                <td>53</td>
369                <td>4 array</td>
370                <td>Array</td>
371              </tr>
372              <tr>
373                <td>acl-name</td>
374                <td>leafref</td>
375                <td>23</td>
376                <td>3 text string</td>
377                <td>String</td>
378              </tr>
379            </tbody>
380          </table>
381          <t>If the DOTS client receives a 5.03 (Service Unavailable) with a
382          diagnostic payload indicating a failed ACL update as a response to
383          an initial mitigation or a mitigation with adjusted scope, the DOTS
384          client <bcp14>MUST</bcp14> immediately send a new request that
385          repeats all the parameters as sent in the failed mitigation request
386          but without including the ACL attributes. After the expiry of
387          Max-Age returned in the 5.03 (Service Unavailable) response, the
388          DOTS client retries with a new mitigation request (i.e., a new
389          'mid') that repeats all the parameters as sent in the failed
390          mitigation request (i.e., the one including the ACL attributes).</t>
391          <t>If, during an active mitigation, the 'activation-type' is changed
392          at the DOTS server (e.g., as a result of an external action) for an
393          ACL bound to a DOTS client, the DOTS server notifies that DOTS
394          client of the change by including the corresponding ACL parameters
395          in an asynchronous notification (the DOTS client is observing the
396          active mitigation) or in a response to a polling request (<xref target="RFC9132" section="4.4.2.2"/>).</t>
397          <t>If the DOTS signal and data channels of a DOTS client are not
398          established with the same DOTS server of a DOTS server domain, the
399          above request processing operations are undertaken using the
400          coordination mechanism discussed in <xref target="bind"/>.</t>
401          <t>This specification does not require any modification to the
402          efficacy update and the withdrawal procedures defined in <xref target="RFC9132"/>. In particular, ACL-related clauses are not
403          included in a PUT request used to send an efficacy update and DELETE
404          requests.</t>
405        </section>
406        <section anchor="YANG">
407          <name>DOTS Signal Filtering Control Module</name>
408          <section anchor="tree">
409            <name>Tree Structure</name>
410            <t>This document augments the "ietf-dots-signal-channel" YANG
411            module defined in <xref target="RFC9132"/> for managing
412            filtering rules.</t>
413            <t>This document defines the YANG module
414            "ietf-dots-signal-control", which has the following tree
415            structure:</t>
416            <sourcecode type="yangtree">
417module: ietf-dots-signal-control
418 augment-structure /dots-signal:dots-signal/dots-signal:message-type
419                   /dots-signal:mitigation-scope/dots-signal:scope:
420   +-- acl-list* [acl-name]
421      +-- acl-name
422      |       -&gt; /data-channel:dots-data/dots-client/acls/acl/name
423      +-- activation-type?   data-channel:activation-type
424</sourcecode>
425          </section>
426          <section>
427            <name>YANG Module</name>
428            <t>This YANG module is not intended to be used via
429            NETCONF/RESTCONF for DOTS server management purposes; such a module
430            is out of the scope of this document. It serves only to provide a
431            data model and encoding, but not a management data model.</t>
432            <t>This module uses types defined in <xref target="RFC8783"/>.</t>
433            <sourcecode name="ietf-dots-signal-control@2021-09-02.yang" type="yang" markers="true">
434module ietf-dots-signal-control {
435  yang-version 1.1;
436  namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
437  prefix dots-control;
438
439  import ietf-dots-signal-channel {
440    prefix dots-signal;
441    reference
442      "RFC 9132: Distributed Denial-of-Service Open Threat
443                 Signaling (DOTS) Signal Channel Specification";
444  }
445
446
447  import ietf-yang-structure-ext {
448    prefix sx;
449    reference
450      "RFC 8791: YANG Data Structure Extensions";
451  }
452
453  import ietf-dots-data-channel {
454    prefix data-channel;
455    reference
456      "RFC 8783: Distributed Denial-of-Service Open Threat
457                 Signaling (DOTS) Data Channel Specification";
458  }
459
460  organization
461    "IETF DDoS Open Threat Signaling (DOTS) Working Group";
462  contact
463    "WG Web:   &lt;https://datatracker.ietf.org/wg/dots/&gt;
464     WG List:  &lt;mailto:dots@ietf.org&gt;
465
466     Author:  Kaname Nishizuka
467              &lt;mailto:kaname@nttv6.jp&gt;
468
469     Author:  Mohamed Boucadair
470              &lt;mailto:mohamed.boucadair@orange.com&gt;
471
472     Author:  Tirumaleswar Reddy.K
473              &lt;mailto:kondtir@gmail.com&gt;
474
475     Author:  Takahiko Nagata
476              &lt;mailto:nagata@lepidum.co.jp&gt;";
477
478  description
479    "This module contains YANG definition for the signaling
480     messages exchanged between a DOTS client and a DOTS server
481     to control, by means of the DOTS signal channel, filtering
482     rules configured using the DOTS data channel.
483
484     Copyright (c) 2021 IETF Trust and the persons identified as
485     authors of the code.  All rights reserved.
486
487     Redistribution and use in source and binary forms, with or
488     without modification, is permitted pursuant to, and subject
489     to the license terms contained in, the Simplified BSD License
490     set forth in Section 4.c of the IETF Trust's Legal Provisions
491     Relating to IETF Documents
492     (https://trustee.ietf.org/license-info).
493
494     This version of this YANG module is part of RFC 9133; see
495     the RFC itself for full legal notices.";
496
497  revision 2021-09-02 {
498    description
499      "Initial revision.";
500    reference
501      "RFC 9133: Controlling Filtering Rules Using Distributed
502                 Denial-of-Service Open Threat Signaling (DOTS)
503                 Signal Channel";
504  }
505
506  sx:augment-structure "/dots-signal:dots-signal"
507                     + "/dots-signal:message-type"
508                     + "/dots-signal:mitigation-scope"
509                     + "/dots-signal:scope" {
510
511    description
512      "ACL name and activation type.";
513
514    list acl-list {
515      key "acl-name";
516      description
517        "List of ACLs as defined using the DOTS data
518         channel. ACLs bound to a DOTS client are uniquely
519         identified by a name.";
520      leaf acl-name {
521        type leafref {
522          path "/data-channel:dots-data/data-channel:dots-client"
523             + "/data-channel:acls/data-channel:acl"
524             + "/data-channel:name";
525        }
526        description
527          "Reference to the ACL name bound to a DOTS client.";
528      }
529      leaf activation-type {
530        type data-channel:activation-type;
531        default "activate-when-mitigating";
532        description
533          "Sets the activation type of an ACL.";
534      }
535    }
536  }
537}
538</sourcecode>
539          </section>
540        </section>
541      </section>
542    </section>
543    <section anchor="sample">
544      <name>Some Examples</name>
545      <t>This section provides some examples to illustrate the behavior
546      specified in <xref target="filtering"/>. These examples are
547      provided for illustration purposes; they should not be considered as
548      deployment recommendations.</t>
549      <section anchor="sample1">
550        <name>Conflict Handling</name>
551        <t>Let's consider a DOTS client that contacts its DOTS server during
552        'idle' time to install an accept-list allowing for UDP traffic issued
553        from 2001:db8:1234::/48 with a destination port number 443 to be
554        forwarded to 2001:db8:6401::2/127. It does so by sending, for example,
555        a PUT request as shown in <xref target="PUT"/>.</t>
556        <figure anchor="PUT">
557          <name>DOTS Data Channel Request to Create a Filter</name>
558          <sourcecode>
559PUT /restconf/data/ietf-dots-data-channel:dots-data\
560    /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
561    /acl=an-accept-list HTTP/1.1
562Host: example.com
563Content-Type: application/yang-data+json
564
565{
566  "ietf-dots-data-channel:acls": {
567    "acl": [
568      {
569        "name": "an-accept-list",
570        "type": "ipv6-acl-type",
571        "activation-type": "activate-when-mitigating",
572        "aces": {
573          "ace": [
574            {
575              "name": "test-ace-ipv6-udp",
576              "matches": {
577                "ipv6": {
578                  "destination-ipv6-network": "2001:db8:6401::2/127",
579                  "source-ipv6-network": "2001:db8:1234::/48"
580                },
581                "udp": {
582                  "destination-port-range-or-operator": {
583                    "operator": "eq",
584                    "port": 443
585                  }
586                }
587              },
588              "actions": {
589                "forwarding": "accept"
590              }
591            }
592          ]
593        }
594      }
595    ]
596  }
597}
598</sourcecode>
599        </figure>
600        <t>Sometime later, consider that a DDoS attack is detected by the DOTS
601        client on 2001:db8:6401::2/127. Consequently, the DOTS client sends a
602        mitigation request to its DOTS server as shown in <xref target="mitigate"/>.</t>
603        <figure anchor="mitigate">
604          <name>DOTS Signal Channel Mitigation Request</name>
605          <sourcecode>
606Header: PUT (Code=0.03)
607Uri-Path: ".well-known"
608Uri-Path: "dots"
609Uri-Path: "mitigate"
610Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
611Uri-Path: "mid=123"
612Content-Format: "application/dots+cbor"
613
614{
615  "ietf-dots-signal-channel:mitigation-scope": {
616    "scope": [
617      {
618        "target-prefix": [
619          "2001:db8:6401::2/127"
620        ],
621        "target-protocol": [
622          17
623        ],
624        "lifetime": 3600
625      }
626    ]
627  }
628}
629</sourcecode>
630        </figure>
631        <t>The DOTS server immediately accepts the request by replying with
632        2.01 (Created) (<xref target="response"/> depicts the message
633        body of the response).</t>
634        <figure anchor="response">
635          <name>Status Response (Message Body)</name>
636          <sourcecode>
637{
638  "ietf-dots-signal-channel:mitigation-scope": {
639    "scope": [
640      {
641        "mid": 123,
642        "lifetime": 3600
643      }
644    ]
645  }
646}
647</sourcecode>
648        </figure>
649        <t>Assuming the DOTS client subscribed to asynchronous notifications,
650        when the DOTS server concludes that some of the attack sources belong
651        to 2001:db8:1234::/48, it sends a notification message with 'status'
652        code set to 1 (attack-mitigation-in-progress) and 'conflict-cause' set
653        to 2 (conflict-with-acceptlist) to the DOTS client to indicate that
654        this mitigation request is in progress, but a conflict is
655        detected.</t>
656        <t>Upon receipt of the notification message from the DOTS server, the
657        DOTS client sends a PUT request to deactivate the "an-accept-list" ACL
658        as shown in <xref target="control"/>.</t>
659        <t>The DOTS client can also decide to send a PUT request to deactivate
660        the "an-accept-list" ACL if suspect traffic is received from an
661        accept-listed source (2001:db8:1234::/48). The structure of that PUT
662        is the same as the one shown in <xref target="control"/>.</t>
663        <figure anchor="control">
664          <name>PUT for Deactivating a Conflicting Filter</name>
665          <sourcecode>
666Header: PUT (Code=0.03)
667Uri-Path: ".well-known"
668Uri-Path: "dots"
669Uri-Path: "mitigate"
670Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
671Uri-Path: "mid=124"
672Content-Format: "application/dots+cbor"
673
674{
675  "ietf-dots-signal-channel:mitigation-scope": {
676    "scope": [
677      {
678        "target-prefix": [
679          "2001:db8:6401::2/127"
680        ],
681        "target-protocol": [
682          17
683        ],
684        "ietf-dots-signal-control:acl-list": [
685          {
686            "acl-name": "an-accept-list",
687            "activation-type": "deactivate"
688          }
689        ],
690        "lifetime": 3600
691      }
692    ]
693  }
694}
695</sourcecode>
696        </figure>
697        <t>Then, the DOTS server deactivates the "an-accept-list" ACL and replies
698        with a 2.04 (Changed) response to the DOTS client to confirm the
699        successful operation. The message body is similar to the one depicted
700        in <xref target="response"/>.</t>
701        <t>Once the attack is mitigated, the DOTS client may use the data
702        channel to retrieve its ACLs maintained by the DOTS server. As shown
703        in <xref target="GET-2"/>, the activation type is set to
704        'deactivate' as set by the DOTS signal channel (<xref target="control"/>) instead of the type initially set using the
705        DOTS data channel (<xref target="PUT"/>).</t>
706        <figure anchor="GET-2">
707          <name>DOTS Data Channel GET Response after Mitigation (Message Body)</name>
708          <sourcecode>
709{
710  "ietf-dots-data-channel:acls": {
711    "acl": [
712      {
713        "name": "an-accept-list",
714        "type": "ipv6-acl-type",
715        "activation-type": "deactivate",
716        "pending-lifetime": 10021,
717        "aces": {
718          "ace": [
719            {
720              "name": "test-ace-ipv6-udp",
721              "matches": {
722                "ipv6": {
723                  "destination-ipv6-network": "2001:db8:6401::2/127",
724                  "source-ipv6-network": "2001:db8:1234::/48"
725                },
726                "udp": {
727                  "destination-port-range-or-operator": {
728                    "operator": "eq",
729                    "port": 443
730                  }
731                }
732              },
733              "actions": {
734                "forwarding": "accept"
735              }
736            }
737          ]
738        }
739      }
740    ]
741  }
742}
743</sourcecode>
744        </figure>
745      </section>
746      <section anchor="sample2">
747        <name>On-Demand Activation of an Accept-List Filter</name>
748        <t>Let's consider a DOTS client that contacts its DOTS server during
749        'idle' time to install an accept-list allowing for UDP traffic issued
750        from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It
751        does so by sending, for example, a PUT request shown in <xref target="PUT1"/>. The DOTS server installs this filter
752        with a "deactivated" state.</t>
753        <figure anchor="PUT1">
754          <name>DOTS Data Channel Request to Create an Accept-List Filter</name>
755          <sourcecode>
756PUT /restconf/data/ietf-dots-data-channel:dots-data\
757    /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\
758    /acl=my-accept-list HTTP/1.1
759Host: example.com
760Content-Type: application/yang-data+json
761
762{
763  "ietf-dots-data-channel:acls": {
764    "acl": [
765      {
766        "name": "my-accept-list",
767        "type": "ipv6-acl-type",
768        "activation-type": "deactivate",
769        "aces": {
770          "ace": [
771            {
772              "name": "an-ace",
773              "matches": {
774                "ipv6": {
775                  "destination-ipv6-network": "2001:db8:6401::2/127",
776                  "source-ipv6-network": "2001:db8:1234::/48",
777                  "protocol": 17
778                }
779              },
780              "actions": {
781                "forwarding": "accept"
782              }
783            }
784          ]
785        }
786      }
787    ]
788  }
789}
790</sourcecode>
791        </figure>
792        <t>Sometime later, consider that a UDP DDoS attack is detected by the
793        DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let
794        the traffic from 2001:db8:1234::/48 be accept-listed to the DOTS
795        client domain. Consequently, the DOTS client sends a mitigation
796        request to its DOTS server as shown in <xref target="mitigate1"/>.</t>
797        <figure anchor="mitigate1">
798          <name>DOTS Signal Channel Mitigation Request with a Filter Control</name>
799          <sourcecode>
800Header: PUT (Code=0.03)
801Uri-Path: ".well-known"
802Uri-Path: "dots"
803Uri-Path: "mitigate"
804Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA"
805Uri-Path: "mid=4879"
806Content-Format: "application/dots+cbor"
807
808{
809  "ietf-dots-signal-channel:mitigation-scope": {
810    "scope": [
811      {
812        "target-prefix": [
813          "2001:db8:6401::2/127"
814        ],
815        "target-protocol": [
816          17
817        ],
818        "ietf-dots-signal-control:acl-list": [
819          {
820            "acl-name": "my-accept-list",
821            "activation-type": "immediate"
822          }
823        ],
824        "lifetime": 3600
825      }
826    ]
827  }
828}
829</sourcecode>
830        </figure>
831        <t>The DOTS server activates the "my-accept-list" ACL and replies with
832        a 2.01 (Created) response to the DOTS client to confirm the successful
833        operation.</t>
834      </section>
835      <section anchor="sample3">
836        <name>DOTS Servers/Mitigators Lacking Capacity</name>
837        <t>This section describes a scenario in which a DOTS client activates
838        a drop-list or a rate-limit filter during an attack.</t>
839        <t>Consider a DOTS client that contacts its DOTS server during 'idle'
840        time to install an accept-list that rate-limits all (or a part
841        thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort
842        countermeasure whenever required. Installing the accept-list can be
843        done by sending, for example, the PUT request shown in <xref target="rate"/>. The DOTS server installs this filter
844        with a "deactivated" state.</t>
845        <figure anchor="rate">
846          <name>DOTS Data Channel Request to Create a Rate-Limit Filter</name>
847          <sourcecode>
848PUT /restconf/data/ietf-dots-data-channel:dots-data\
849    /dots-client=OopPisZqo4SLv64TLPXrxA/acls\
850    /acl=my-ratelimit-list HTTP/1.1
851Host: example.com
852Content-Type: application/yang-data+json
853
854{
855  "ietf-dots-data-channel:acls": {
856    "acl": [
857      {
858        "name": "my-ratelimit-list",
859        "type": "ipv6-acl-type",
860        "activation-type": "deactivate",
861        "aces": {
862          "ace": [
863            {
864              "name": "my-ace",
865              "matches": {
866                "ipv6": {
867                  "destination-ipv6-network": "2001:db8:123::/48"
868                }
869              },
870              "actions": {
871                "forwarding": "accept",
872                "rate-limit": "20000.00"
873              }
874            }
875          ]
876        }
877      }
878    ]
879  }
880}
881</sourcecode>
882        </figure>
883        <t>Consider now that a DDoS attack is detected by the DOTS client on
884        2001:db8:123::/48. Consequently, the DOTS client sends a mitigation
885        request to its DOTS server (<xref target="ratel"/>).</t>
886        <figure anchor="ratel">
887          <name>DOTS Signal Channel Mitigation Request</name>
888          <sourcecode>
889Header: PUT (Code=0.03)
890Uri-Path: ".well-known"
891Uri-Path: "dots"
892Uri-Path: "mitigate"
893Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
894Uri-Path: "mid=85"
895Content-Format: "application/dots+cbor"
896
897{
898  "ietf-dots-signal-channel:mitigation-scope": {
899    "scope": [
900      {
901        "target-prefix": [
902          "2001:db8:123::/48"
903        ],
904        "lifetime": 3600
905      }
906    ]
907  }
908}
909</sourcecode>
910        </figure>
911        <t>For some reason (e.g., the DOTS server, or the mitigator, is
912        lacking a capability or capacity), the DOTS client is still receiving
913        attack traffic, which saturates available links. To soften the
914        problem, the DOTS client decides to activate the filter that
915        rate-limits the traffic destined to the DOTS client domain. To that
916        aim, the DOTS client sends the mitigation request to its DOTS server
917        shown in <xref target="rateres"/>.</t>
918        <figure anchor="rateres">
919          <name>DOTS Signal Channel Mitigation Request to Activate a Rate-Limit Filter</name>
920          <sourcecode>
921Header: PUT (Code=0.03)
922Uri-Path: ".well-known"
923Uri-Path: "dots"
924Uri-Path: "mitigate"
925Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
926Uri-Path: "mid=86"
927Content-Format: "application/dots+cbor"
928
929{
930  "ietf-dots-signal-channel:mitigation-scope": {
931    "scope": [
932      {
933        "target-prefix": [
934          "2001:db8:123::/48"
935        ],
936        "ietf-dots-signal-control:acl-list": [
937          {
938            "acl-name": "my-ratelimit-list",
939            "activation-type": "immediate"
940          }
941        ],
942        "lifetime": 3600
943      }
944    ]
945  }
946}
947</sourcecode>
948        </figure>
949        <t>Then, the DOTS server activates the "my-ratelimit-list" ACL and replies
950        with a 2.04 (Changed) response to the DOTS client to confirm the
951        successful operation.</t>
952        <t>As the attack mitigation evolves, the DOTS client may decide to
953        deactivate the rate-limit policy (e.g., upon receipt of a notification
954        status change from 'attack-exceeded-capability' to
955        'attack-mitigation-in-progress'). Based on the mitigation status
956        conveyed by the DOTS server, the DOTS client can deactivate the
957        rate-limit action. It does so by sending the request shown in <xref target="rateres2"/>.</t>
958        <figure anchor="rateres2">
959          <name>DOTS Signal Channel Mitigation Request to Deactivate a Rate-Limit Filter</name>
960          <sourcecode type="cbor">
961Header: PUT (Code=0.03)
962Uri-Path: ".well-known"
963Uri-Path: "dots"
964Uri-Path: "mitigate"
965Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
966Uri-Path: "mid=87"
967Content-Format: "application/dots+cbor"
968
969{
970  "ietf-dots-signal-channel:mitigation-scope": {
971    "scope": [
972      {
973        "target-prefix": [
974          "2001:db8:123::/48"
975        ],
976        "ietf-dots-signal-control:acl-list": [
977          {
978            "acl-name": "my-ratelimit-list",
979            "activation-type": "deactivate"
980          }
981        ],
982        "lifetime": 3600
983      }
984    ]
985  }
986}
987</sourcecode>
988        </figure>
989      </section>
990    </section>
991    <section anchor="IANA">
992      <name>IANA Considerations</name>
993      <section anchor="map">
994        <name>DOTS Signal Channel CBOR Key Values Subregistry</name>
995        <t>Per this specification, IANA has registered the following parameters in the
996        "DOTS Signal Channel CBOR Key Values" subregistry within the
997 "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
998 Channel" registry <xref target="Key-Map"/>.</t>
999        <table anchor="table2">
1000          <thead>
1001            <tr>
1002              <th>Parameter Name</th>
1003              <th>CBOR Key Value</th>
1004              <th>CBOR Major Type</th>
1005              <th>Change Controller</th>
1006              <th>Specification Document(s)</th>
1007            </tr>
1008          </thead>
1009          <tbody>
1010            <tr>
1011              <td>activation-type</td>
1012              <td>52</td>
1013              <td>0</td>
1014              <td>IESG</td>
1015              <td>RFC 9133</td>
1016            </tr>
1017            <tr>
1018              <td>ietf-dots-signal-control:acl-list</td>
1019              <td>53</td>
1020              <td>4</td>
1021              <td>IESG</td>
1022              <td>RFC 9133</td>
1023            </tr>
1024          </tbody>
1025        </table>
1026      </section>
1027      <section anchor="yang-iana">
1028        <name>A New YANG Module</name>
1029        <t>IANA has registered the following URI in the
1030        "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688"/>:</t>
1031        <dl spacing="compact">
1032          <dt>URI:</dt>
1033          <dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd>
1034          <dt>Registrant Contact:</dt>
1035          <dd>The IESG.</dd>
1036          <dt>XML:</dt>
1037          <dd>N/A; the requested URI is an XML namespace.</dd>
1038        </dl>
1039        <t>IANA has registered the following YANG module
1040        in the "YANG Module Names" subregistry <xref target="RFC6020"/>
1041        within the "YANG Parameters" registry.</t>
1042        <dl spacing="compact">
1043          <dt>Name:</dt>
1044          <dd>ietf-dots-signal-control</dd>
1045          <dt>Namespace:</dt>
1046          <dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd>
1047          <dt>Maintained by IANA:</dt>
1048          <dd>N</dd>
1049          <dt>Prefix:</dt>
1050          <dd>dots-control</dd>
1051          <dt>Reference:</dt>
1052          <dd>RFC 9133</dd>
1053        </dl>
1054      </section>
1055    </section>
1056    <section anchor="security">
1057      <name>Security Considerations</name>
1058      <t>The security considerations for the DOTS signal channel protocol are
1059      discussed in <xref target="RFC9132" section="11"/>,
1060      while those for the DOTS data channel protocol are discussed in <xref target="RFC8783" section="10"/>. The following
1061      discusses the security considerations that are specific to the DOTS
1062      signal channel extension defined in this document.</t>
1063      <t>This specification does not allow the creation of new filtering rules,
1064      which is the responsibility of the DOTS data channel. DOTS client
1065      domains should be adequately prepared prior to an attack, e.g., by
1066      creating filters that will be activated on demand when an attack is
1067      detected.</t>
1068      <t>A DOTS client is entitled to access only the resources it creates. In
1069      particular, a DOTS client can not tweak filtering rules created by other
1070      DOTS clients of the same DOTS client domain. As a reminder, DOTS servers
1071      must associate filtering rules with the DOTS client that created these
1072      resources. Failure to ensure such association by a DOTS server will have
1073      severe impact on DOTS client domains.</t>
1074      <t>A compromised DOTS client can use the filtering control capability to
1075      exacerbate an ongoing attack. Likewise, such a compromised DOTS client
1076      may abstain from reacting to an ACL conflict notification received from
1077      the DOTS server during attacks. These are not new attack vectors, but
1078      variations of threats discussed in <xref target="RFC9132"/> and <xref target="RFC8783"/>. DOTS
1079      operators should carefully monitor and audit DOTS agents to detect
1080      misbehaviors and deter misuses.</t>
1081    </section>
1082  </middle>
1083  <back>
1084    <references>
1085      <name>References</name>
1086      <references>
1087        <name>Normative References</name>
1088        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" derivedAnchor="RFC2119">
1089          <front>
1090            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1091            <author initials="S." surname="Bradner" fullname="S. Bradner">
1092              <organization/>
1093            </author>
1094            <date year="1997" month="March"/>
1095            <abstract>
1096              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
1097            </abstract>
1098          </front>
1099          <seriesInfo name="BCP" value="14"/>
1100          <seriesInfo name="RFC" value="2119"/>
1101          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
1102        </reference>
1103        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" derivedAnchor="RFC3688">
1104          <front>
1105            <title>The IETF XML Registry</title>
1106            <author initials="M." surname="Mealling" fullname="M. Mealling">
1107              <organization/>
1108            </author>
1109            <date year="2004" month="January"/>
1110            <abstract>
1111              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
1112            </abstract>
1113          </front>
1114          <seriesInfo name="BCP" value="81"/>
1115          <seriesInfo name="RFC" value="3688"/>
1116          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
1117        </reference>
1118        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" derivedAnchor="RFC6020">
1119          <front>
1120            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
1121            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
1122              <organization/>
1123            </author>
1124            <date year="2010" month="October"/>
1125            <abstract>
1126              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
1127            </abstract>
1128          </front>
1129          <seriesInfo name="RFC" value="6020"/>
1130          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
1131        </reference>
1132        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" derivedAnchor="RFC7950">
1133          <front>
1134            <title>The YANG 1.1 Data Modeling Language</title>
1135            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
1136              <organization/>
1137            </author>
1138            <date year="2016" month="August"/>
1139            <abstract>
1140              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
1141            </abstract>
1142          </front>
1143          <seriesInfo name="RFC" value="7950"/>
1144          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
1145        </reference>
1146        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" derivedAnchor="RFC8174">
1147          <front>
1148            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
1149            <author initials="B." surname="Leiba" fullname="B. Leiba">
1150              <organization/>
1151            </author>
1152            <date year="2017" month="May"/>
1153            <abstract>
1154              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
1155            </abstract>
1156          </front>
1157          <seriesInfo name="BCP" value="14"/>
1158          <seriesInfo name="RFC" value="8174"/>
1159          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
1160        </reference>
1161        <reference anchor="RFC8783" target="https://www.rfc-editor.org/info/rfc8783" derivedAnchor="RFC8783">
1162          <front>
1163            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification</title>
1164            <author initials="M." surname="Boucadair" fullname="M. Boucadair" role="editor">
1165              <organization/>
1166            </author>
1167            <author initials="T." surname="Reddy.K" fullname="T. Reddy.K" role="editor">
1168              <organization/>
1169            </author>
1170            <date year="2020" month="May"/>
1171            <abstract>
1172              <t>The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.</t>
1173              <t>This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).</t>
1174            </abstract>
1175          </front>
1176          <seriesInfo name="RFC" value="8783"/>
1177          <seriesInfo name="DOI" value="10.17487/RFC8783"/>
1178        </reference>
1179        <reference anchor="RFC8791" target="https://www.rfc-editor.org/info/rfc8791" derivedAnchor="RFC8791">
1180          <front>
1181            <title>YANG Data Structure Extensions</title>
1182            <author initials="A." surname="Bierman" fullname="A. Bierman">
1183              <organization/>
1184            </author>
1185            <author initials="M." surname="Björklund" fullname="M. Björklund">
1186              <organization/>
1187            </author>
1188            <author initials="K." surname="Watsen" fullname="K. Watsen">
1189              <organization/>
1190            </author>
1191            <date year="2020" month="June"/>
1192            <abstract>
1193              <t>This document describes YANG mechanisms for defining abstract data structures with YANG.</t>
1194            </abstract>
1195          </front>
1196          <seriesInfo name="RFC" value="8791"/>
1197          <seriesInfo name="DOI" value="10.17487/RFC8791"/>
1198        </reference>
1199        <reference anchor="RFC9132" target="https://www.rfc-editor.org/info/rfc9132" derivedAnchor="RFC9132">
1200          <front>
1201            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
1202            <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair" role="editor">
1203              <organization/>
1204            </author>
1205            <author initials="J" surname="Shallow" fullname="Jon Shallow">
1206              <organization/>
1207            </author>
1208            <author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.K">
1209              <organization/>
1210            </author>
1211            <date month="September" year="2021"/>
1212          </front>
1213          <seriesInfo name="RFC" value="9132"/>
1214          <seriesInfo name="DOI" value="10.17487/RFC9132"/>
1215        </reference>
1216      </references>
1217      <references>
1218        <name>Informative References</name>
1219        <reference anchor="INTEROP" target="https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00" derivedAnchor="INTEROP">
1220          <front>
1221            <title>DOTS Interop test report, IETF 103 Hackathon</title>
1222            <author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka">
1223              <organization>NTT Communications</organization>
1224              <address>
1225                <postal>
1226                  <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
1227                  <city>Tokyo</city>
1228                  <region/>
1229                  <code>108-8118</code>
1230                  <country>Japan</country>
1231                </postal>
1232                <email>kaname@nttv6.jp</email>
1233              </address>
1234            </author>
1235            <author fullname="Jon Shallow" initials="J." surname="Shallow">
1236              <organization>J.NCC Group</organization>
1237              <address>
1238                <postal>
1239                  <street/>
1240                  <city/>
1241                  <region/>
1242                  <code/>
1243                  <country/>
1244                </postal>
1245                <phone/>
1246                <email/>
1247                <uri/>
1248              </address>
1249            </author>
1250            <author fullname="Liang Xia" initials="L." surname="Xia">
1251              <organization>Huawei</organization>
1252              <address>
1253                <postal>
1254                  <street/>
1255                  <city/>
1256                  <region/>
1257                  <code/>
1258                  <country/>
1259                </postal>
1260                <phone/>
1261                <email/>
1262                <uri/>
1263              </address>
1264            </author>
1265            <date month="November" year="2018"/>
1266          </front>
1267        </reference>
1268        <reference anchor="Key-Map" target="https://www.iana.org/assignments/dots" derivedAnchor="Key-Map">
1269          <front>
1270            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel</title>
1271            <author fullname="IANA">
1272              <organization/>
1273            </author>
1274          </front>
1275        </reference>
1276        <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951" derivedAnchor="RFC7951">
1277          <front>
1278            <title>JSON Encoding of Data Modeled with YANG</title>
1279            <author initials="L." surname="Lhotka" fullname="L. Lhotka">
1280              <organization/>
1281            </author>
1282            <date year="2016" month="August"/>
1283            <abstract>
1284              <t>This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t>
1285            </abstract>
1286          </front>
1287          <seriesInfo name="RFC" value="7951"/>
1288          <seriesInfo name="DOI" value="10.17487/RFC7951"/>
1289        </reference>
1290        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" derivedAnchor="RFC8340">
1291          <front>
1292            <title>YANG Tree Diagrams</title>
1293            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
1294              <organization/>
1295            </author>
1296            <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
1297              <organization/>
1298            </author>
1299            <date year="2018" month="March"/>
1300            <abstract>
1301              <t>This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.</t>
1302            </abstract>
1303          </front>
1304          <seriesInfo name="BCP" value="215"/>
1305          <seriesInfo name="RFC" value="8340"/>
1306          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
1307        </reference>
1308        <reference anchor="RFC8612" target="https://www.rfc-editor.org/info/rfc8612" derivedAnchor="RFC8612">
1309          <front>
1310            <title>DDoS Open Threat Signaling (DOTS) Requirements</title>
1311            <author initials="A." surname="Mortensen" fullname="A. Mortensen">
1312              <organization/>
1313            </author>
1314            <author initials="T." surname="Reddy" fullname="T. Reddy">
1315              <organization/>
1316            </author>
1317            <author initials="R." surname="Moskowitz" fullname="R. Moskowitz">
1318              <organization/>
1319            </author>
1320            <date year="2019" month="May"/>
1321            <abstract>
1322              <t>This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.</t>
1323            </abstract>
1324          </front>
1325          <seriesInfo name="RFC" value="8612"/>
1326          <seriesInfo name="DOI" value="10.17487/RFC8612"/>
1327        </reference>
1328        <reference anchor="RFC8811" target="https://www.rfc-editor.org/info/rfc8811" derivedAnchor="RFC8811">
1329          <front>
1330            <title>DDoS Open Threat Signaling (DOTS) Architecture</title>
1331            <author initials="A." surname="Mortensen" fullname="A. Mortensen" role="editor">
1332              <organization/>
1333            </author>
1334            <author initials="T." surname="Reddy.K" fullname="T. Reddy.K" role="editor">
1335              <organization/>
1336            </author>
1337            <author initials="F." surname="Andreasen" fullname="F. Andreasen">
1338              <organization/>
1339            </author>
1340            <author initials="N." surname="Teague" fullname="N. Teague">
1341              <organization/>
1342            </author>
1343            <author initials="R." surname="Compton" fullname="R. Compton">
1344              <organization/>
1345            </author>
1346            <date year="2020" month="August"/>
1347            <abstract>
1348              <t>This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.</t>
1349            </abstract>
1350          </front>
1351          <seriesInfo name="RFC" value="8811"/>
1352          <seriesInfo name="DOI" value="10.17487/RFC8811"/>
1353        </reference>
1354      </references>
1355    </references>
1356    <section anchor="ack" numbered="false">
1357      <name>Acknowledgements</name>
1358      <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>
1359      <t>Thanks to <contact fullname="Benjamin Kaduk"/> for the AD review.</t>
1360    </section>
1361  </back>
1362</rfc>
  • <?xml version="1.0" encoding="utf-8"?>
  • <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
  • <rfc version="3" category="std" consensus="true" docName="draft-ietf-dots-signal-filter-control-07" indexInclude="true" ipr="trust200902" number="9133" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en" obsoletes="" updates="" xmlns:xi="http://www.w3.org/2001/XInclude">
    • <link href="https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control-07" rel="prev"/>
    • <link href="https://dx.doi.org/10.17487/rfc9133" rel="alternate"/>
    • <link href="urn:issn:2070-1721" rel="alternate"/>
    • <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" stream="IETF"/>
      • <author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka">
        • <organization>
          • NTT Communications
          • </organization>
        • <address>
          • <postal>
            • <street>
              • GranPark 16F 3-4-1 Shibaura, Minato-ku
              • </street>
            • <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/>
            • <city>
              • Rennes
              • </city>
            • <code>
              • 35000
              • </code>
            • <region/>
            • <country>
              • France
              • </country>
            • </postal>
          • <email>
            • mohamed.boucadair@orange.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
        • <organization abbrev="Akamai">
          • Akamai
          • </organization>
        • <address>
          • <postal>
            • <street>
              • Embassy Golf Link Business Park
              • </street>
            • <city>
              • Bangalore
              • </city>
            • <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/>
            • <city/>
            • <region/>
            • <code/>
            • <country>
              • Japan
              • </country>
            • </postal>
          • <email>
            • nagata@lepidum.co.jp
            • </email>
          • </address>
        • </author>
      • <date month="09" "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 or deactivate existing filtering rules during a Distributed Denial-of-Service (DDoS) attack. The characterization of these filtering rules is conveyed by a DOTS client during an 'idle' time (i.e., no mitigation is active) by means of the DOTS data channel protocol.
          • </t>
        • </abstract>
      • </front>
    • <middle>
      • <section anchor="introduction" numbered="true" toc="default">
        • <name>
          • Introduction
          • </name>
        • <section anchor="problem" numbered="true" toc="default">
          • <name>
            • The Problem
            • </name>
          • <t>
            • In the Distributed Denial-of-Service Open Threat Signaling (DOTS) architecture <xref target="RFC8811"/>, "RFC8811" format="default"/>, DOTS clients and servers communicate using both a signal channel protocol <xref target="RFC9132" format ="RFC9132"/> "default"/> and a data channel protocol <xref target="RFC8783" format ="RFC8783"/>. "default"/>.
            • </t>
          • <t>
            • The DOTS data channel protocol <xref target="RFC8783"/> "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. Filter management, which is one of the tasks of 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 <xref target="RFC9132"/> "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 per <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 the signaling channel thanks to the heartbeat requests keeping the channel active (as described in <xref 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 such conditions, the DOTS data channel protocol cannot be used to change these filters, which may complicate DDoS mitigation operations <xref target="INTEROP"/>. "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 DDoS attack, 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 attack traffic, or the attacker can compromise the accept-listed sources and program them to launch a DDoS attack.
            • </t>
          • <t>
            • <xref target="RFC9132"/> "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 (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" numbered="true" toc="default">
          • <name>
            • Controlling Filtering Rules Using DOTS Signal Channel
            • </name>
          • <t>
            • This specification addresses the problems discussed in <xref target="problem"/> "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 <xref target="RFC8783" format ="RFC8783"/>. "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>
          • <aside>
            • <t>
              • Note: The experiment at the IETF 103 hackathon <xref target="INTEROP"/> "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>
            • </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 <xref target="YANG"/>. "YANG" format="default"/>.
            • </t>
          • <t>
            • Sample examples are provided in <xref target="sample"/>, "sample" format="default"/>, in particular:
            • </t>
          • <ul spacing="normal">
            • <li>
              • <xref target="sample1"/> "sample1" format="default"/> illustrates how the filter control extension is used when conflicts with Access Control Lists (ACLs) are detected and reported by a DOTS server.
              • </li>
            • <li>
              • <xref target="sample2"/> "sample2" format="default"/> shows how a DOTS client can instruct a DOTS server to safely forward some specific traffic in 'attack' time.
              • </li>
            • <li>
              • <xref target="sample3"/> "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 DOTS server.
              • </li>
            • </ul>
          • <t>
            • The JavaScript Object Notation (JSON) encoding of YANG-modeled data <xref target="RFC7951"/> "RFC7951" format="default"/> is used to illustrate the examples.
            • </t>
          • </section>
        • </section>
      • <section anchor="notation" numbered="true" toc="default">
        • <name>
          • Terminology
          • </name>
        • <t>
          • The key words "<bcp14", "<bcp14 NOT</bcp14>", "<bcp14", "<bcp14", "<bcp14 NOT</bcp14>", "<bcp14", "<bcp14 NOT</bcp14>", "<bcp14", "<bcp14 RECOMMENDED</bcp14>", "<bcp14", and "<bcp14" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> "RFC2119" format="default"/> <xref target="RFC8174" format ="RFC8174"/> "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 <xref target="RFC8612"/>. "RFC8612" format="default"/>.
          • </t>
        • <t>
          • The terminology for describing YANG modules is defined in <xref target="RFC7950"/>. "RFC7950" format="default"/>. The meaning of the symbols in the tree diagram is defined in <xref target="RFC8340"/> and <xref target="RFC8791" format ="RFC8791"/>. "default"/>.
          • </t>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • Controlling Filtering Rules of a DOTS Client
          • </name>
        • <section anchor="bind" numbered="true" toc="default">
          • <name>
            • Binding DOTS Data and Signal 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 in <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 (<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 in <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>
        • <section numbered="true" toc="default">
          • <name>
            • DOTS Signal Channel Extension
            • </name>
          • <section anchor="filtering" numbered="true" toc="default">
            • <name>
              • Parameters and Behaviors
              • </name>
            • <t>
              • This specification extends the mitigation request defined in <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 the Concise Binary Object Representation (CBOR) body of a mitigation request (see the YANG structure in <xref target="tree" format ="tree"/>): "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 (<xref target="RFC8783" sectionFormat="of" section="4.3"/>) that is associated with the DOTS client.
                  • </t>
                • <t>
                  • As a reminder, an ACL is an ordered list of Access Control Entries (ACEs). Each ACE has a list of match criteria and a list of actions <xref target="RFC8783"/>. "RFC8783" format="default"/>. The list of configured ACLs can be retrieved using the DOTS data channel during 'idle' time.
                  • </t>
                • <t>
                  • This is a mandatory attribute when 'acl-list' is included.
                  • </t>
                • </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.
                  • </t>
                • <t>
                  • As a reminder, this attribute can be set to 'deactivate', 'immediate', or 'activate-when-mitigating' as defined in <xref target="RFC8783"/>. "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.
                  • </t>
                • <t>
                  • This is an optional attribute.
                  • </t>
                • </dd>
              • </dl>
            • <t>
              • By default, ACL-related operations are achieved using the DOTS data channel protocol when no attack is ongoing. DOTS clients <bcp14 NOT</bcp14> use the filtering control over the DOTS signal channel in 'idle' time; such requests <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' <bcp14 be used. Nevertheless, it is <bcp14 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 is <bcp14 for a DOTS client to subscribe to asynchronous notifications of the attack mitigation, as detailed in <xref target="RFC9132" sectionFormat="of" section="4.4.2.1"/>. If not, the polling mechanism in <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 in <xref target="RFC9132" sectionFormat="of" section="6"/>, if the DOTS server does not understand the 'acl-list', 'acl-name', or 'activation-type' attributes, it responds with a 4.00 (Bad 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, it <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 in <xref target="RFC9132" sectionFormat="of" section="4.4.1"/>, the DOTS server <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 server <bcp14 update the lifetime of the corresponding ACL similar to the update when a refresh request is received using the DOTS data channel (<xref target="RFC8783" sectionFormat="of" section="7.2"/>). If, for some reason, the DOTS server fails to apply the filter update, it <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 <xref target="diag" format ="diag"/>). "default"/>). Else, the DOTS server replies with the appropriate response code defined in <xref target="RFC9132" sectionFormat="of" section="4.4.1"/>.
              • </t>
            • <figure anchor="diag">
              • <name>
                • Example of a Diagnostic Payload Including Failed ACL 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"           }         ]       }     ]   } } 
                • </sourcecode>
              • </figure>
            • <t>
              • The JSON/YANG mappings for DOTS filter control attributes are shown in <xref target="table1"/>. As a reminder, the mapping for 'acl-name' is defined in Table 5 of <xref target="RFC9132"/>.
              • </t>
            • <table anchor="table1">
              • <name>
                • JSON/YANG Mapping to CBOR for Filter Control 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 client <bcp14 immediately send a new request that 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 (<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 <xref target="bind"/>. "bind" format="default"/>.
              • </t>
            • <t>
              • This specification does not require any modification to the efficacy update and the withdrawal procedures defined in <xref target="RFC9132"/>. "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" numbered="true" toc="default">
            • <name>
              • DOTS Signal Filtering Control Module
              • </name>
            • <section anchor="tree" numbered="true" toc="default">
              • <name>
                • Tree Structure
                • </name>
              • <t>
                • This document augments the "ietf-dots-signal-channel" YANG module defined in <xref target="RFC9132"/> "RFC9132" format="default"/> for managing filtering rules.
                • </t>
              • <t>
                • This document defines the YANG module "ietf-dots-signal-control", which has the following tree structure:
                • </t>
              • <sourcecode type="yangtree">
                •  module: ietf-dots-signal-control  augment-structure /dots-signal:dots-signal/dots-signal:message-type                    /dots-signal:mitigation-scope/dots-signal:scope:    +-- acl-list* [acl-name]       +-- acl-name       |       -> /data-channel:dots-data/dots-client/acls/acl/name       +-- activation-type?   data-channel:activation-type 
                • </sourcecode>
              • </section>
            • <section 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 <xref target="RFC8783"/>. "RFC8783" format="default"/>.
                • </t>
              • <sourcecode name="ietf-dots-signal-control@2021-09-02.yang" type="yang" markers="true">
                •  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 {     prefix dots-signal;     reference       "RFC 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 {     prefix 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:  Tirumaleswar 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) 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      (https://trustee.ietf.org/license-info).       This version of this YANG module is part of RFC 9133; see      the RFC itself for full legal notices.";    revision 2021-09-02 {     description       "Initial revision.";     reference       "RFC 9133: Controlling Filtering Rules Using Distributed                  Denial-of-Service Open Threat Signaling (DOTS)                  Signal Channel";   }    sx:augment-structure "/dots-signal:dots-signal"                      + "/dots-signal:message-type"                      + "/dots-signal:mitigation-scope"                      + "/dots-signal:scope" {        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 "/data-channel:dots-data/data-channel:dots-client"                + "/data-channel:acls/data-channel:acl"              + "/data-channel:name";         }         description           "Reference to the ACL name bound to a DOTS client.";       }       leaf activation-type {         type data-channel:activation-type;         default "activate-when-mitigating";         description           "Sets the activation type of an ACL.";       }     }       } } 
                • </sourcecode>
              • </section>
            • </section>
          • </section>
        • </section>
      • <section anchor="sample" numbered="true" toc="default">
        • <name>
          • Some Examples
          • </name>
        • <t>
          • This section provides some examples to illustrate the behavior specified in <xref target="filtering"/>. "filtering" format="default"/>. These examples are provided for illustration purposes; they should not be considered as deployment recommendations.
          • </t>
        • <section anchor="sample1" numbered="true" toc="default">
          • <name>
            • Conflict Handling
            • </name>
          • <t>
            • Let's consider a DOTS client that 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 <xref target="PUT"/>. "PUT" format="default"/>.
            • </t>
          • <figure anchor="PUT">
            • <name>
              • DOTS Data Channel Request to Create a Filter
              • </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"               }             }           ]         }       }     ]   } } 
              • </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 <xref target="mitigate"/>. "mitigate" format="default"/>.
            • </t>
          • <figure anchor="mitigate">
            • <name>
              • DOTS Signal Channel Mitigation 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       }     ]   } } 
              • </sourcecode>
            • </figure>
          • <t>
            • The DOTS server immediately accepts the request by replying with 2.01 (Created) (<xref target="response"/> "response" format="default"/> depicts the message body of the response).
            • </t>
          • <figure anchor="response">
            • <name>
              • Status Response (Message Body)
              • </name>
            • <sourcecode>
              •    {   "ietf-dots-signal-channel:mitigation-scope": {     "scope": [       {         "mid": 123,         "lifetime": 3600       }     ]   } } 
              • </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-in-progress) and 'conflict-cause' set to 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 <xref target="control"/>. "control" format="default"/>.
            • </t>
          • <t>
            • The DOTS client can also decide to send a PUT request to deactivate the "an-accept-list" 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 <xref target="control"/>. "control" format="default"/>.
            • </t>
          • <figure anchor="control">
            • <name>
              • PUT for Deactivating a Conflicting 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       }     ]   } } 
              • </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 <xref target="response"/>. "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 <xref target="GET-2"/>, "GET-2" format="default"/>, the activation type is set to 'deactivate' as set by the DOTS signal channel (<xref target="control" format ="control"/>) "default"/>) instead of the type initially set using the DOTS data channel (<xref target="PUT" format ="PUT"/>). "default"/>).
            • </t>
          • <figure anchor="GET-2">
            • <name>
              • DOTS Data Channel GET Response after Mitigation (Message 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"               }             }           ]         }       }     ]   } } 
              • </sourcecode>
            • </figure>
          • </section>
        • <section anchor="sample2" numbered="true" toc="default">
          • <name>
            • On-Demand Activation of an Accept-List Filter
            • </name>
          • <t>
            • Let's consider a DOTS client that 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 <xref target="PUT1"/>. "PUT1" format="default"/>. The DOTS server installs this filter with a "deactivated" state.
            • </t>
          • <figure anchor="PUT1">
            • <name>
              • DOTS Data Channel Request to Create an Accept-List Filter
              • </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"               }             }           ]         }       }     ]   } } 
              • </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::/48 be accept-listed to the DOTS client domain. Consequently, the DOTS client sends a mitigation request to its DOTS server as shown in <xref target="mitigate1"/>. "mitigate1" format="default"/>.
            • </t>
          • <figure anchor="mitigate1">
            • <name>
              • DOTS Signal Channel Mitigation Request with a Filter 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       }     ]   } } 
              • </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" numbered="true" toc="default">
          • <name>
            • DOTS Servers/Mitigators Lacking 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 <xref target="rate"/>. "rate" format="default"/>. The DOTS server installs this filter with a "deactivated" state.
            • </t>
          • <figure anchor="rate">
            • <name>
              • DOTS Data Channel Request to Create a Rate-Limit Filter
              • </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"               }             }           ]         }       }     ]   } } 
              • </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 (<xref target="ratel"/>). "ratel" format="default"/>).
            • </t>
          • <figure anchor="ratel">
            • <name>
              • DOTS Signal Channel Mitigation 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       }     ]   } } 
              • </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 attack traffic, 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 <xref target="rateres"/>. "rateres" format="default"/>.
            • </t>
          • <figure anchor="rateres">
            • <name>
              • DOTS Signal Channel Mitigation Request to Activate a Rate-Limit 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       }     ]   } } 
              • </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 can deactivate the rate-limit action. It does so by sending the request shown in <xref target="rateres2"/>. "rateres2" format="default"/>.
            • </t>
          • <figure anchor="rateres2">
            • <name>
              • DOTS Signal Channel Mitigation Request to Deactivate a Rate-Limit 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       }     ]   } } 
              • </sourcecode>
            • </figure>
          • </section>
        • </section>
      • <section anchor="IANA" numbered="true" toc="default">
        • <name>
          • IANA Considerations
          • </name>
        • <section anchor="map" numbered="true" toc="default">
          • <name>
            • DOTS Signal Channel CBOR Key Values Subregistry
            • </name>
          • <t>
            • Per this specification, IANA has registered the following parameters in the "DOTS Signal Channel CBOR Key Values" subregistry within the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" registry <xref target="Key-Map"/>. "Key-Map" format="default"/>.
            • </t>
          • <table anchor="table2">
            • <thead>
              • <tr>
                • <th>
                  • Parameter Name
                  • </th>
                • <th>
                  • CBOR Key Value
                  • </th>
                • <th>
                  • CBOR Major 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" numbered="true" toc="default">
          • <name>
            • A New YANG Module
            • </name>
          • <t>
            • IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688"/>: "RFC3688" format="default"/>:
            • </t>
          • <dl spacing="compact" newline="false">
            • <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 XML namespace.
              • </dd>
            • </dl>
          • <t>
            • IANA has registered the following YANG module in the "YANG Module Names" subregistry <xref target="RFC6020"/> "RFC6020" format="default"/> within the "YANG Parameters" registry.
            • </t>
          • <dl spacing="compact" newline="false">
            • <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" numbered="true" toc="default">
        • <name>
          • Security Considerations
          • </name>
        • <t>
          • The security considerations for the DOTS signal channel protocol are discussed in <xref target="RFC9132" sectionFormat="of" section="11"/>, while those for the DOTS data channel protocol are discussed in <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 allow the 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 <xref target="RFC9132"/> "RFC9132" format="default"/> and <xref target="RFC8783" format ="RFC8783"/>. "default"/>. DOTS operators should carefully monitor and audit DOTS agents to detect misbehaviors and deter misuses.
          • </t>
        • </section>
      • </middle>
    • <back>
      • <references>
        • <name>
          • References
          • </name>
        • <references>
          • <name>
            • Normative References
            • </name>
          • <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" derivedAnchor="RFC2119" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
            • <front>
              • <title>
                • Key words for use in RFCs to Indicate Requirement Levels
                • </title>
              • <author initials="S." surname="Bradner" fullname="S. Bradner">
                • <organization/>
                • </author>
              • <date year="1997" month="March"/>
              • <abstract>
                • <t>
                  • In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="BCP" value="14"/>
            • <seriesInfo name="RFC" value="2119"/>
            • <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            • </reference>
          • <reference anchor="RFC3688" "RFC7950" target="https://www.rfc-editor.org/info/rfc3688" "https://www.rfc-editor.org/info/rfc7950" derivedAnchor="RFC3688" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
            • <front>
              • <title>
                • The IETF XML Registry YANG 1.1 Data Modeling Language
                • </title>
              • <author initials="M." surname="Mealling" "Bjorklund" fullname="M. Mealling" Bjorklund" role="editor">
                • <organization/>
                • </author>
              • <date year="2004" "2016" month="January" "August" />
              • <abstract>
                • <t>
                  • This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="BCP" value="81"/>
            • <seriesInfo name="RFC" value="3688" "7950" />
            • <seriesInfo name="DOI" value="10.17487/RFC3688" "10.17487/RFC7950" />
            • </reference>
          • <reference anchor="RFC6020" "RFC3688" target="https://www.rfc-editor.org/info/rfc6020" "https://www.rfc-editor.org/info/rfc3688" derivedAnchor="RFC6020" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
            • <front>
              • <title>
                • YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) The IETF XML Registry
                • </title>
              • <author initials="M." surname="Bjorklund" "Mealling" fullname="M. Bjorklund" Mealling" role="editor">
                • <organization/>
                • </author>
              • <date year="2010" "2004" month="October" "January" />
              • <abstract>
                • <t>
                  • YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="BCP" value="81"/>
            • <seriesInfo name="RFC" value="6020" "3688" />
            • <seriesInfo name="DOI" value="10.17487/RFC6020" "10.17487/RFC3688" />
            • </reference>
          • <reference anchor="RFC7950" "RFC6020" target="https://www.rfc-editor.org/info/rfc7950" "https://www.rfc-editor.org/info/rfc6020" derivedAnchor="RFC7950" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">
            • <front>
              • <title>
                • The YANG 1.1 - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
                • </title>
              • <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
                • <organization/>
                • </author>
              • <date year="2016" "2010" month="August" "October" />
              • <abstract>
                • <t>
                  • YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to state data manipulated by the Network Configuration Protocol (NETCONF). (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="7950" "6020" />
            • <seriesInfo name="DOI" value="10.17487/RFC7950" "10.17487/RFC6020" />
            • </reference>
          • <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" derivedAnchor="RFC8174" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
            • <front>
              • <title>
                • Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
                • </title>
              • <author initials="B." surname="Leiba" fullname="B. Leiba">
                • <organization/>
                • </author>
              • <date year="2017" month="May"/>
              • <abstract>
                • <t>
                  • RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="BCP" value="14"/>
            • <seriesInfo name="RFC" value="8174"/>
            • <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            • </reference>
          • <reference anchor="RFC8783" "RFC8791" target="https://www.rfc-editor.org/info/rfc8783" "https://www.rfc-editor.org/info/rfc8791" derivedAnchor="RFC8783" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8791.xml">
            • <front>
              • <title>
                • Distributed Denial-of-Service Open Threat Signaling (DOTS) YANG Data Channel Specification Structure Extensions
                • </title>
              • <author initials="A." surname="Bierman" fullname="A. Bierman">
                • <organization/>
                • </author>
              • <author initials="M." surname="Boucadair" "Björklund" fullname="M. Boucadair" Björklund" role="editor">
                • <organization/>
                • </author>
              • <author initials="T." "K." surname="Reddy.K" "Watsen" fullname="T. Reddy.K" "K. Watsen" role="editor">
                • <organization/>
                • </author>
              • <date year="2020" month="May" "June" />
              • <abstract>
                • <t>
                  • The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.
                  • </t>
                • <t>
                  • This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782). describes YANG mechanisms for defining abstract data structures with YANG.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="8783" "8791" />
            • <seriesInfo name="DOI" value="10.17487/RFC8783" "10.17487/RFC8791" />
            • </reference>
          • <reference anchor="RFC8791" "RFC9132" target="https://www.rfc-editor.org/info/rfc8791" "https://www.rfc-editor.org/info/rfc9132" derivedAnchor="RFC8791">
            • <front>
              • <title>
                • YANG Data Structure Extensions Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
                • </title>
              • <author initials="A." "M" surname="Bierman" "Boucadair" fullname="A. Bierman" "Mohamed Boucadair" role="editor">
                • <organization/>
                • </author>
              • <author initials="M." "J" surname="Björklund" "Shallow" fullname="M. Björklund" "Jon Shallow" >
                • <organization/>
                • </author>
              • <author initials="K." "T" surname="Watsen" "Reddy.K" fullname="K. Watsen" "Tirumaleswar Reddy.K" >
                • <organization/>
                • </author>
              • <date year="2020" "2021" month="June" "September" />
              • <abstract>
                • <t>
                  • This document describes YANG mechanisms for defining abstract data structures with YANG.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="8791" "9132" />
            • <seriesInfo name="DOI" value="10.17487/RFC8791" "10.17487/RFC9132" />
            • </reference>
          • <reference anchor="RFC9132" "RFC8783" target="https://www.rfc-editor.org/info/rfc9132" "https://www.rfc-editor.org/info/rfc8783" derivedAnchor="RFC9132" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml">
            • <front>
              • <title>
                • Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Data Channel Specification
                • </title>
              • <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair" role="editor">
                • <organization/>
                • </author>
              • <author initials="J" "M." surname="Shallow" "Boucadair" fullname="Jon Shallow" "M. Boucadair" role="editor">
                • <organization/>
                • </author>
              • <author initials="T" "T." surname="Reddy.K" fullname="Tirumaleswar "T. Reddy.K" role="editor">
                • <organization/>
                • </author>
              • <date month="September" "May" year="2021" "2020" />
              • <abstract>
                • <t>
                  • The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.
                  • </t>
                • <t>
                  • This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="9132" "8783" />
            • <seriesInfo name="DOI" value="10.17487/RFC9132" "10.17487/RFC8783" />
            • </reference>
          • </references>
        • <references>
          • <name>
            • Informative References
            • </name>
          • <reference anchor="INTEROP" "RFC8612" target="https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00" "https://www.rfc-editor.org/info/rfc8612" derivedAnchor="INTEROP" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8612.xml">
            • <front>
              • <title>
                • DOTS Interop test report, IETF 103 Hackathon DDoS Open Threat Signaling (DOTS) Requirements
                • </title>
              • <author fullname="Kaname Nishizuka" "A. Mortensen" initials="K." "A." surname="Nishizuka" "Mortensen" >
                • <organization>
                  • NTT Communications
                  • </organization>
                • <address>
                  • <postal>
                    • <street>
                      • GranPark 16F 3-4-1 Shibaura, Minato-ku
                      • </street>
                    • <city>
                      • Tokyo
                      • </city>
                    • <region/>
                    • <code>
                      • 108-8118
                      • </code>
                    • <country>
                      • Japan
                      • </country>
                    • </postal>
                  • <email>
                    • kaname@nttv6.jp
                    • </email>
                  • </address>
                • </author>
              • <author fullname="Jon Shallow" "T. Reddy" initials="J." "T." surname="Shallow" "Reddy" >
                • <organization>
                  • J.NCC Group
                  • </organization>
                • <address>
                  • <postal>
                    • <street/>
                    • <city/>
                    • <region/>
                    • <code/>
                    • <country/>
                    • </postal>
                  • <phone/>
                  • <email/>
                  • <uri/>
                  • </address>
                • </author>
              • <author fullname="Liang Xia" "R. Moskowitz" initials="L." "R." surname="Xia" "Moskowitz" >
                • <organization>
                  • Huawei
                  • </organization>
                • <address>
                  • <postal>
                    • <street/>
                    • <city/>
                    • <region/>
                    • <code/>
                    • <country/>
                    • </postal>
                  • <phone/>
                  • <email/>
                  • <uri/>
                  • </address>
                • </author>
              • <date month="November" "May" year="2018" "2019" />
              • <abstract>
                • <t>
                  • This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="8612"/>
            • <seriesInfo name="DOI" value="10.17487/RFC8612"/>
            • </reference>
          • <reference anchor="Key-Map" target="https://www.iana.org/assignments/dots" derivedAnchor="Key-Map">
            • <front>
              • <title>
                • Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
                • </title>
              • <author fullname="IANA">
                • <organization/>
                • </author>
              • </front>
            • </reference>
          • <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951" derivedAnchor="RFC7951" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml">
            • <front>
              • <title>
                • JSON Encoding of Data Modeled with YANG
                • </title>
              • <author initials="L." surname="Lhotka" fullname="L. Lhotka">
                • <organization/>
                • </author>
              • <date year="2016" month="August"/>
              • <abstract>
                • <t>
                  • This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="7951"/>
            • <seriesInfo name="DOI" value="10.17487/RFC7951"/>
            • </reference>
          • <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" derivedAnchor="RFC8340" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml">
            • <front>
              • <title>
                • YANG Tree Diagrams
                • </title>
              • <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
                • <organization/>
                • </author>
              • <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
                • <organization/>
                • </author>
              • <date year="2018" month="March"/>
              • <abstract>
                • <t>
                  • This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="BCP" value="215"/>
            • <seriesInfo name="RFC" value="8340"/>
            • <seriesInfo name="DOI" value="10.17487/RFC8340"/>
            • </reference>
          • <reference anchor="RFC8612" "RFC8811" target="https://www.rfc-editor.org/info/rfc8612" "https://www.rfc-editor.org/info/rfc8811" derivedAnchor="RFC8612" xml:base="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8811.xml">
            • <front>
              • <title>
                • DDoS Open Threat Signaling (DOTS) Requirements Architecture
                • </title>
              • <author initials="A." surname="Mortensen" fullname="A. Mortensen" role="editor">
                • <organization/>
                • </author>
              • <author initials="T." surname="Reddy.K" fullname="T. Reddy.K" role="editor">
                • <organization/>
                • </author>
              • <author initials="A." "F." surname="Mortensen" "Andreasen" fullname="A. Mortensen" "F. Andreasen" >
                • <organization/>
                • </author>
              • <author initials="T." "N." surname="Reddy" "Teague" fullname="T. Reddy" "N. Teague" >
                • <organization/>
                • </author>
              • <author initials="R." surname="Moskowitz" "Compton" fullname="R. Moskowitz" Compton" >
                • <organization/>
                • </author>
              • <date year="2019" "2020" month="May" "August" />
              • <abstract>
                • <t>
                  • This document defines the requirements describes an architecture for the establishing and maintaining Distributed Denial-of- Service Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols enabling coordinated response to DDoS attacks. or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="8612" "8811" />
            • <seriesInfo name="DOI" value="10.17487/RFC8612" "10.17487/RFC8811" />
            • </reference>
          • <reference anchor="RFC8811" "INTEROP" target="https://www.rfc-editor.org/info/rfc8811" "https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00" derivedAnchor="RFC8811">
            • <front>
              • <title>
                • DDoS Open Threat Signaling (DOTS) Architecture DOTS Interop test report, IETF 103 Hackathon
                • </title>
              • <author initials="A." surname="Mortensen" fullname="A. Mortensen" role="editor">
                • <organization/>
                • </author>
              • <author initials="T." surname="Reddy.K" fullname="T. Reddy.K" role="editor">
                • <organization/>
                • </author>
              • <author initials="F." "K." surname="Andreasen" "Nishizuka" fullname="F. Andreasen" "Kaname Nishizuka" >
                • <organization>
                  • NTT Communications
                  • </organization>
                • <address>
                  • <postal>
                    • <street>
                      • GranPark 16F 3-4-1 Shibaura, Minato-ku
                      • </street>
                    • <city>
                      • Tokyo
                      • </city>
                    • <region/>
                    • <code>
                      • 108-8118
                      • </code>
                    • <country>
                      • Japan
                      • </country>
                    • </postal>
                  • <email>
                    • kaname@nttv6.jp
                    • </email>
                  • </address>
                • </author>
              • <author initials="N." "J." surname="Teague" " Shallow" fullname="N. Teague" "Jon Shallow" >
                • <organization>
                  • J.NCC Group
                  • </organization>
                • <address>
                  • <postal>
                    • <street/>
                    • <city/>
                    • <region/>
                    • <code/>
                    • <country/>
                    • </postal>
                  • <phone/>
                  • <email/>
                  • <uri/>
                  • </address>
                • </author>
              • <author initials="R." "L." surname="Compton" "Xia " fullname="R. Compton" "Liang Xia" >
                • <organization>
                  • Huawei
                  • </organization>
                • <address>
                  • <postal>
                    • <street/>
                    • <city/>
                    • <region/>
                    • <code/>
                    • <country/>
                    • </postal>
                  • <phone/>
                  • <email/>
                  • <uri/>
                  • </address>
                • </author>
              • <date year="2020" "2018" month="August" "November" />
              • <abstract>
                • <t>
                  • This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="8811"/>
            • <seriesInfo name="DOI" value="10.17487/RFC8811"/>
            • </reference>
          • <reference anchor="Key-Map" target="https://www.iana.org/assignments/dots">
            • <front>
              • <title>
                • Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
                • </title>
              • <author fullname="IANA">
                • <organization/>
                • </author>
              • </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="&#xC9;ric Vyncke"/> for the comments.
          • </t>
        • <t>
          • Thanks to <contact fullname="Benjamin Kaduk"/> for the AD review.
          • </t>
        • </section>
      • </back>
    • </rfc>
1<?xml version='1.0' encoding='utf-8'?>
2<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
3
4<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
5     consensus="true" number="9133" docName="draft-ietf-dots-signal-filter-control-07"
6     ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
7     xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
8     sortRefs="true" version="3"> 
9
10  <front>
11    <title abbrev="DOTS Signal Filter Control">Controlling Filtering Rules
12    Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
13    Channel</title>
14    <seriesInfo name="RFC" value="9133"/>
15
16
17   
18 <author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka">
19      <organization>NTT Communications</organization>
20      <address>
21        <postal>
22          <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
23   <code>108-8118</code>
24          <region>Tokyo</region>
25          <country>Japan</country>
26        </postal>
27        <email>kaname@nttv6.jp</email>
28      </address>
29    </author>
30
31
32    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
33      <organization>Orange</organization>
34      <address>
35        <postal>
36          <street/>
37          <city>Rennes</city>
38          <code>35000</code>
39          <region/>
40          <country>France</country>
41        </postal>
42        <email>mohamed.boucadair@orange.com</email>
43      </address>
44    </author>
45
46
47    <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
48      <organization abbrev="Akamai">Akamai</organization>
49      <address>
50        <postal>
51          <street>Embassy Golf Link Business Park</street>
52          <city>Bangalore</city>
53          <code>560071</code>
54          <region>Karnataka</region>
55          <country>India</country>
56        </postal>
57        <email>kondtir@gmail.com</email>
58      </address>
59    </author>
60
61    <author fullname="Takahiko Nagata" initials="T." surname="Nagata">
62      <organization>Lepidum</organization>
63      <address>
64        <postal>
65          <street/>
66          <city/>
67          <region/>
68          <code/>
69          <country>Japan</country>
70        </postal>
71        <email>nagata@lepidum.co.jp</email>
72      </address>
73    </author>
74    <date month="September" year="2021"/>
75    <workgroup>DOTS</workgroup>
76    <keyword>Mitigation</keyword>
77    <keyword>Automation</keyword>
78    <keyword>Filtering</keyword>
79    <keyword>Protective Networking</keyword>
80    <keyword>Protected Networks</keyword>
81    <keyword>Security</keyword>
82    <keyword>Anti-DDoS</keyword>
83    <keyword>Reactive</keyword>
84    <keyword>Collaborative Networking</keyword>
85    <keyword>Collaborative Security</keyword>
86    <abstract>
87      <t>This document specifies an extension to the Distributed
88      Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol
89      so that DOTS clients can control their filtering rules when an attack
90      mitigation is active.</t>
91      <t>Particularly, this extension allows a DOTS client to activate or
92      deactivate existing filtering rules during a Distributed
93      Denial-of-Service (DDoS) attack. The
94      characterization of these filtering rules is conveyed by a DOTS client
95      during an 'idle' time (i.e., no mitigation is active) by means of the DOTS
96      data channel protocol.</t>
97    </abstract>
98
99  </front>
100  <middle>
101    <section anchor="introduction" numbered="true" toc="default">
102      <name>Introduction</name>
103      <section anchor="problem" numbered="true" toc="default">
104        <name>The Problem</name>
105        <t>In the Distributed Denial-of-Service Open Threat Signaling (DOTS)
106        architecture <xref target="RFC8811" format="default"/>, DOTS
107        clients and servers communicate using both a signal channel protocol
108        <xref target="RFC9132" format="default"/> and a data channel protocol <xref target="RFC8783" format="default"/>.</t>
109
110        <t>The DOTS data channel protocol <xref target="RFC8783"
111        format="default"/> is used for bulk data exchange between DOTS agents
112        to improve the coordination of parties involved in the response to a
113        Distributed Denial-of-Service (DDoS) attack. Filter management, which
114        is one of the tasks of the DOTS data channel protocol, enables a DOTS
115        client to retrieve the filtering capabilities of a DOTS server and to
116        manage filtering rules. Typically, these filtering rules are used for
117        dropping or rate-limiting unwanted traffic, and permitting
118        accept-listed traffic.</t>
119        <t>The DOTS signal channel protocol <xref target="RFC9132" format="default"/> is
120        designed to be resilient under extremely hostile network conditions
121        and provides continued contact between DOTS agents even as DDoS attack
122        traffic saturates the link. The DOTS signal channel can be established
123        between two DOTS agents prior to or during an attack. At any time, the
124        DOTS client may send mitigation requests (as per <xref
125 target="RFC9132" sectionFormat="of" section="4.4"/>) to a DOTS server over the active signal
126        channel. While mitigation is active, the DOTS server periodically
127        sends status messages to the DOTS client, including basic mitigation
128        feedback details. In case of a massive DDoS attack that saturates the
129        incoming link(s) to the DOTS client, all traffic from the DOTS server
130        to the DOTS client will likely be dropped. However, the DOTS server
131        may still receive DOTS messages sent from the DOTS client over the
132        signaling channel thanks to the heartbeat requests keeping the
133        channel active (as described in <xref target="RFC9132"
134 sectionFormat="of" section="4.7"/>).</t>
135        <t>Unlike the DOTS signal channel protocol, the DOTS data channel
136        protocol is not expected to deal with attack conditions. As such, an
137        issue that might be encountered in some deployments is when filters
138        installed by means of the DOTS data channel protocol may not function
139        as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS
140        attack. In such conditions, the DOTS data channel protocol cannot be
141        used to change these filters, which may complicate DDoS mitigation
142        operations <xref target="INTEROP" format="default"/>.</t>
143        <t>A typical case is a conflict between filtering rules installed by a
144        DOTS client and the mitigation actions of a DDoS mitigator. Consider,
145        for instance, a DOTS client that configures during 'idle' time (i.e.,
146        no mitigation is active) some filtering rules using the DOTS data
147        channel protocol to permit traffic from accept-listed sources.
148        However, during a volumetric DDoS attack, the DDoS mitigator identifies
149        the source addresses/prefixes in the accept-listed filtering rules are
150        attacking the target. For example, an attacker can spoof the IP
151        addresses of accept-listed sources to generate attack traffic, or the
152        attacker can compromise the accept-listed sources and program them to
153        launch a DDoS attack.</t>
154
155
156        <t><xref target="RFC9132" format="default"/> is designed so that the
157        DDoS server notifies the above conflict to the DOTS client (that is,
158        the 'conflict-cause' parameter is set to 2 (conflict-with-acceptlist)),
159        but the DOTS client may not be able to withdraw the accept-list rules
160        during the attack period due to the high-volume attack traffic
161        saturating the inbound link to the DOTS client domain.  In other
162        words, the DOTS client cannot use the DOTS data channel protocol to
163        withdraw the accept-list filters when a DDoS attack is in
164        progress.</t>
165
166      </section>
167      <section anchor="sol" numbered="true" toc="default">
168        <name>Controlling Filtering Rules Using DOTS Signal Channel</name>
169        <t>This specification addresses the problems discussed in <xref target="problem" format="default"/> by adding a capability for managing filtering
170        rules using the DOTS signal channel protocol, which enables a DOTS
171        client to request the activation (or deactivation) of filtering rules
172        during a DDoS attack. Note that creating these filtering rules is
173        still the responsibility of the DOTS data channel <xref target="RFC8783" format="default"/>.</t>
174        <t>The DOTS signal channel protocol is designed to enable a DOTS
175        client to contact a DOTS server for help even under severe network
176        congestion conditions. Therefore, extending the DOTS signal channel
177        protocol to manage the filtering rules during an attack will enhance
178        the protection capability offered by DOTS protocols.</t>
179
180<aside>
181          <t>Note: The experiment at the IETF 103 hackathon <xref
182          target="INTEROP" format="default"/> showed that even when the
183          inbound link is saturated by DDoS attack traffic, the DOTS client
184          can signal mitigation requests using the DOTS signal channel over
185          the saturated link.</t>
186</aside>
187        <t>Conflicts that are induced by filters installed by other DOTS
188        clients of the same domain are not discussed in this
189        specification.</t>
190        <t>An augmentation to the DOTS signal channel YANG module is defined
191        in <xref target="YANG" format="default"/>.</t>
192        <t>Sample examples are provided in <xref target="sample" format="default"/>, in
193        particular: </t>
194        <ul spacing="normal">
195          <li>
196            <xref target="sample1" format="default"/> illustrates how the filter
197            control extension is used when conflicts with Access Control Lists
198            (ACLs) are detected and reported by a DOTS server.</li>
199          <li>
200            <xref target="sample2" format="default"/> shows how a DOTS client can
201            instruct a DOTS server to safely forward some specific traffic in
202            'attack' time.</li>
203          <li>
204            <xref target="sample3" format="default"/> shows how a DOTS client can
205            react if the DDoS traffic is still being forwarded to the DOTS
206            client domain even if mitigation requests were sent to a DOTS
207            server.</li>
208        </ul>
209        <t>The JavaScript Object Notation (JSON) encoding of YANG-modeled data
210        <xref target="RFC7951" format="default"/> is used to illustrate the examples.</t>
211      </section>
212    </section>
213    <section anchor="notation" numbered="true" toc="default">
214      <name>Terminology</name>
215
216      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
217      "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
218      NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
219      "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
220      "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
221      to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"
222      format="default"/> <xref target="RFC8174" format="default"/> when, and
223      only when, they appear in all capitals, as shown here.</t>
224      <t>The reader should be familiar with the terms defined in <xref
225      target="RFC8612" format="default"/>.</t>
226      <t>The terminology for describing YANG modules is defined in <xref
227      target="RFC7950" format="default"/>. The meaning of the symbols in the
228      tree diagram is defined in <xref target="RFC8340"/> and <xref target="RFC8791"
229      format="default"/>.</t>
230    </section>
231    <section numbered="true" toc="default">
232      <name>Controlling Filtering Rules of a DOTS Client</name>
233      <section anchor="bind" numbered="true" toc="default">
234        <name>Binding DOTS Data and Signal Channels</name>
235        <t>The filtering rules eventually managed using the DOTS signal
236        channel protocol are created a priori by the same DOTS client using
237        the DOTS data channel protocol. Managing conflicts with filters
238        installed by other DOTS clients of the same domain is out of
239        scope.</t>
240        <t>As discussed in <xref target="RFC9132" sectionFormat="of"
241        section="4.4.1"/>, a DOTS client must use the same 'cuid' for both the
242        DOTS signal and data channels. This requirement is meant to facilitate
243        binding DOTS channels used by the same DOTS client.</t>
244        <t>The DOTS signal and data channels from a DOTS client may or may not
245        use the same DOTS server. Nevertheless, the scope of the mitigation
246        request, alias, and filtering rules are not restricted to the DOTS
247        server but to the DOTS server domain. To that aim, DOTS servers within
248        a domain are assumed to have a mechanism to coordinate the mitigation
249        requests, aliases, and filtering rules to coordinate their decisions
250        for better mitigation operation efficiency. The exact details about
251        such a mechanism is out of the scope of this document.</t>
252
253        <t>A filtering rule controlled by the DOTS signal channel is
254        identified by its ACL name (<xref target="RFC8783"
255 sectionFormat="of" section="4.3"/>). Note that an ACL name unambiguously
256        identifies an ACL bound to a DOTS client, but the same name may be
257        used by distinct DOTS clients.</t>
258
259        <t>The activation or deactivation of an ACL by the DOTS signal channel
260        overrides the 'activation-type' (defined in <xref target="RFC8783"
261        sectionFormat="of" section="4.3"/>) a priori conveyed with the
262        filtering rules using the DOTS data channel protocol.</t>
263        <t>Once the attack is mitigated, the DOTS client may use the data
264        channel to control the 'activation-type' (e.g., revert to a default
265        value) of some of the filtering rules controlled by the DOTS signal
266        channel or delete some of these filters. This behavior is deployment
267        specific.</t>
268      </section>
269      <section numbered="true" toc="default">
270        <name>DOTS Signal Channel Extension</name>
271        <section anchor="filtering" numbered="true" toc="default">
272          <name>Parameters and Behaviors</name>
273          <t>This specification extends the mitigation request defined in
274          <xref target="RFC9132" sectionFormat="of" section="4.4.1"/> to
275          convey the intended control of configured filtering
276          rules. Concretely, the DOTS client conveys the 'acl-list' attribute with
277          the following sub-attributes in the Concise Binary Object
278   Representation (CBOR) body of a mitigation
279          request (see the YANG structure in <xref target="tree"
280          format="default"/>):</t>
281          <dl newline="false" spacing="normal">
282            <dt>acl-name:</dt>
283            <dd>
284              <t>A name of an access list defined using
285              the DOTS data channel (<xref target="RFC8783"
286       sectionFormat="of" section="4.3"/>) that is associated with the DOTS
287              client.</t>
288              <t>As a reminder, an ACL is an ordered list of Access Control
289              Entries (ACEs). Each ACE has a list of match criteria and a list
290              of actions <xref target="RFC8783" format="default"/>. The list
291              of configured ACLs can be retrieved using the DOTS data channel
292              during 'idle' time.</t>
293              <t>This is a mandatory attribute when 'acl-list'
294              is included.</t>
295            </dd>
296            <dt>activation-type:</dt>
297            <dd>
298              <t>An attribute indicating the activation type of
299              an ACL overriding the existing 'activation-type' installed by
300              the DOTS client using the DOTS data channel. </t>
301              <t>As a reminder, this attribute can be set to
302              'deactivate', 'immediate', or 'activate-when-mitigating' as
303              defined in <xref target="RFC8783" format="default"/>. </t>
304              <t>Note that both 'immediate' and
305              'activate-when-mitigating' have an immediate effect when a
306              mitigation request is being processed by the DOTS server.
307              </t>
308              <t>This is an optional attribute.</t>
309            </dd>
310          </dl>
311
312          <t>By default, ACL-related operations are achieved using the DOTS
313          data channel protocol when no attack is ongoing. DOTS clients <bcp14>MUST
314          NOT</bcp14> use the filtering control over the DOTS signal channel in 'idle'
315          time; such requests <bcp14>MUST</bcp14> be discarded by DOTS servers with 4.00 (Bad
316          Request).</t>
317          <t>During an attack time, DOTS clients may include 'acl-list',
318          'acl-name', and 'activation-type' attributes in a mitigation
319          request. This request may be the initial mitigation request for a
320          given mitigation scope or a new one overriding an existing request.
321          In both cases, a new 'mid' <bcp14>MUST</bcp14> be used. Nevertheless, it is <bcp14>NOT
322          RECOMMENDED</bcp14> to include ACL attributes in an initial mitigation
323          request for a given mitigation scope or in a mitigation request
324          adjusting the mitigation scope. This recommendation is meant to
325          avoid delaying attack mitigations because of failures to process ACL
326          attributes.</t>
327          <t>As the attack evolves, DOTS clients can adjust the
328          'activation-type' of an ACL conveyed in a mitigation request or
329          control other filters as necessary. This can be achieved by sending
330          a PUT request with a new 'mid' value.</t>
331          <t>It is <bcp14>RECOMMENDED</bcp14> for a DOTS client to subscribe
332          to asynchronous notifications of the attack mitigation, as detailed
333          in <xref target="RFC9132" sectionFormat="of" section="4.4.2.1"/>. If
334          not, the polling mechanism in <xref target="RFC9132"
335          sectionFormat="of" section="4.4.2.2"/> has to be followed by the
336          DOTS client.</t>
337          <t>A DOTS client relies on the information received from the DOTS
338          server and/or local information to the DOTS client domain to trigger
339          a filter control request. Only filters that are pertinent for an
340          ongoing mitigation should be controlled by a DOTS client using the
341          DOTS signal channel.</t>
342          <t>'acl-list', 'acl-name', and 'activation-type' are defined as
343          comprehension-required parameters. Following the rules in <xref
344          target="RFC9132" sectionFormat="of" section="6"/>, if the DOTS
345          server does not understand the 'acl-list', 'acl-name', or
346          'activation-type' attributes, it responds with a 4.00 (Bad
347          Request) error response code.</t>
348          <t>If the DOTS server does not find the ACL name ('acl-name')
349          conveyed in the mitigation request for this DOTS client, it <bcp14>MUST</bcp14>
350          respond with a 4.04 (Not Found) error response code.</t>
351          <t>If the DOTS server finds the ACL name for this DOTS client, and
352          assuming the request passed the validation checks in <xref
353          target="RFC9132" sectionFormat="of" section="4.4.1"/>, the DOTS
354          server <bcp14>MUST</bcp14> proceed with the 'activation-type'
355          update. The update is immediately enforced by the DOTS server and
356          will be maintained as the new activation type for the ACL name even
357          after the termination of the mitigation request. In addition, the
358          DOTS server <bcp14>MUST</bcp14> update the lifetime of the
359          corresponding ACL similar to the update when a refresh request is
360          received using the DOTS data channel (<xref target="RFC8783"
361          sectionFormat="of" section="7.2"/>). If, for some reason, the DOTS
362          server fails to apply the filter update, it <bcp14>MUST</bcp14>
363          respond with a 5.03 (Service Unavailable) error response code and
364          include the failed ACL update in the diagnostic payload of the
365          response (an example is shown in <xref target="diag"
366          format="default"/>). Else, the DOTS server replies with the
367          appropriate response code defined in <xref target="RFC9132"
368          sectionFormat="of" section="4.4.1"/>.</t>
369          <figure anchor="diag">
370            <name>Example of a Diagnostic Payload Including Failed ACL Update</name>
371<sourcecode>
372{
373  "ietf-dots-signal-channel:mitigation-scope": {
374    "scope": [
375      {
376        "mid": 123,
377        "ietf-dots-signal-control:acl-list": [
378          {
379            "acl-name": "an-accept-list",
380            "activation-type": "deactivate"
381          }
382        ]
383      }
384    ]
385  }
386}
387</sourcecode>
388          </figure>
389          <t>The JSON/YANG mappings for DOTS filter control attributes are
390          shown in <xref target="table1"/>. As a reminder, the mapping for 'acl-name' is
391          defined in Table 5 of <xref target="RFC9132"/>.</t>
392
393
394<table anchor="table1">
395  <name>JSON/YANG Mapping to CBOR for Filter Control Attributes</name>   
396
397  <thead>
398    <tr>
399      <th>Parameter Name</th>   
400      <th>YANG Type</th>
401      <th>CBOR Key</th>
402      <th>CBOR Major Type &amp; Information</th>
403      <th>JSON Type</th>
404    </tr>
405  </thead>
406  <tbody>      
407    <tr>
408      <td>activation-type</td>
409      <td>enumeration</td>
410      <td>52</td>
411      <td>0 unsigned</td>
412      <td>String</td>
413
414    </tr>
415    <tr>
416      <td>ietf-dots-signal-control:acl-list</td>
417      <td>list</td>
418      <td>53</td>
419      <td>4 array</td>
420      <td>Array</td>
421    </tr>
422    <tr>
423      <td>acl-name</td>
424      <td>leafref</td>
425      <td>23</td>
426      <td>3 text string</td>
427      <td>String</td>
428    </tr>
429
430  </tbody>
431</table>
432          <t>If the DOTS client receives a 5.03 (Service Unavailable) with a
433          diagnostic payload indicating a failed ACL update as a response to
434          an initial mitigation or a mitigation with adjusted scope, the DOTS
435          client <bcp14>MUST</bcp14> immediately send a new request that
436          repeats all the parameters as sent in the failed mitigation request
437          but without including the ACL attributes. After the expiry of
438          Max-Age returned in the 5.03 (Service Unavailable) response, the
439          DOTS client retries with a new mitigation request (i.e., a new
440          'mid') that repeats all the parameters as sent in the failed
441          mitigation request (i.e., the one including the ACL attributes).</t>
442          <t>If, during an active mitigation, the 'activation-type' is changed
443          at the DOTS server (e.g., as a result of an external action) for an
444          ACL bound to a DOTS client, the DOTS server notifies that DOTS
445          client of the change by including the corresponding ACL parameters
446          in an asynchronous notification (the DOTS client is observing the
447          active mitigation) or in a response to a polling request (<xref
448          target="RFC9132" sectionFormat="of" section="4.4.2.2"/>).</t>
449          <t>If the DOTS signal and data channels of a DOTS client are not
450          established with the same DOTS server of a DOTS server domain, the
451          above request processing operations are undertaken using the
452          coordination mechanism discussed in <xref target="bind" format="default"/>.</t>
453          <t>This specification does not require any modification to the
454          efficacy update and the withdrawal procedures defined in <xref target="RFC9132" format="default"/>. In particular, ACL-related clauses are not
455          included in a PUT request used to send an efficacy update and DELETE
456          requests.</t>
457        </section>
458        <section anchor="YANG" numbered="true" toc="default">
459          <name>DOTS Signal Filtering Control Module</name>
460          <section anchor="tree" numbered="true" toc="default">
461            <name>Tree Structure</name>
462            <t>This document augments the "ietf-dots-signal-channel" YANG
463            module defined in <xref target="RFC9132" format="default"/> for managing
464            filtering rules.</t>
465            <t>This document defines the YANG module
466            "ietf-dots-signal-control", which has the following tree
467            structure:</t>
468
469
470
471<sourcecode type="yangtree">
472module: ietf-dots-signal-control
473 augment-structure /dots-signal:dots-signal/dots-signal:message-type
474                   /dots-signal:mitigation-scope/dots-signal:scope:
475   +-- acl-list* [acl-name]
476      +-- acl-name
477      |       -> /data-channel:dots-data/dots-client/acls/acl/name
478      +-- activation-type?   data-channel:activation-type
479</sourcecode >
480          </section>
481          <section numbered="true" toc="default">
482            <name>YANG Module</name>
483            <t>This YANG module is not intended to be used via
484            NETCONF/RESTCONF for DOTS server management purposes; such a module
485            is out of the scope of this document. It serves only to provide a
486            data model and encoding, but not a management data model.</t>
487            <t>This module uses types defined in <xref target="RFC8783" format="default"/>.</t>
488
489 <sourcecode name="ietf-dots-signal-control@2021-09-02.yang" type="yang" markers="true"><![CDATA[
490module ietf-dots-signal-control {
491  yang-version 1.1;
492  namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
493  prefix dots-control;
494
495  import ietf-dots-signal-channel {
496    prefix dots-signal;
497    reference
498      "RFC 9132: Distributed Denial-of-Service Open Threat
499                 Signaling (DOTS) Signal Channel Specification";
500  }
501
502
503  import ietf-yang-structure-ext {
504    prefix sx;
505    reference
506      "RFC 8791: YANG Data Structure Extensions";
507  }
508
509  import ietf-dots-data-channel {
510    prefix data-channel;
511    reference
512      "RFC 8783: Distributed Denial-of-Service Open Threat
513                 Signaling (DOTS) Data Channel Specification";
514  }
515    
516  organization
517    "IETF DDoS Open Threat Signaling (DOTS) Working Group";
518  contact
519    "WG Web:   <https://datatracker.ietf.org/wg/dots/>
520     WG List:  <mailto:dots@ietf.org>
521
522     Author:  Kaname Nishizuka
523              <mailto:kaname@nttv6.jp>
524
525     Author:  Mohamed Boucadair
526              <mailto:mohamed.boucadair@orange.com>
527
528     Author:  Tirumaleswar Reddy.K
529              <mailto:kondtir@gmail.com>
530
531     Author:  Takahiko Nagata
532              <mailto:nagata@lepidum.co.jp>";
533
534  description
535    "This module contains YANG definition for the signaling
536     messages exchanged between a DOTS client and a DOTS server
537     to control, by means of the DOTS signal channel, filtering
538     rules configured using the DOTS data channel.
539
540     Copyright (c) 2021 IETF Trust and the persons identified as
541     authors of the code.  All rights reserved.
542
543     Redistribution and use in source and binary forms, with or
544     without modification, is permitted pursuant to, and subject
545     to the license terms contained in, the Simplified BSD License
546     set forth in Section 4.c of the IETF Trust's Legal Provisions
547     Relating to IETF Documents
548     (https://trustee.ietf.org/license-info).
549
550     This version of this YANG module is part of RFC 9133; see
551     the RFC itself for full legal notices.";
552
553  revision 2021-09-02 {
554    description
555      "Initial revision.";
556    reference
557      "RFC 9133: Controlling Filtering Rules Using Distributed
558                 Denial-of-Service Open Threat Signaling (DOTS)
559                 Signal Channel";
560  }
561
562  sx:augment-structure "/dots-signal:dots-signal"
563                     + "/dots-signal:message-type"
564                     + "/dots-signal:mitigation-scope"
565                     + "/dots-signal:scope" {
566 
567    description 
568      "ACL name and activation type.";
569
570    list acl-list {
571      key "acl-name";
572      description
573        "List of ACLs as defined using the DOTS data
574         channel. ACLs bound to a DOTS client are uniquely
575         identified by a name.";
576      leaf acl-name {
577        type leafref {
578          path "/data-channel:dots-data/data-channel:dots-client" 
579             + "/data-channel:acls/data-channel:acl"
580             + "/data-channel:name";
581        }
582        description
583          "Reference to the ACL name bound to a DOTS client.";
584      }
585      leaf activation-type {
586        type data-channel:activation-type;
587        default "activate-when-mitigating";
588        description
589          "Sets the activation type of an ACL.";
590      }
591    }   
592  }
593}
594]]></sourcecode>
595          </section>
596        </section>
597      </section>
598    </section>
599    <section anchor="sample" numbered="true" toc="default">
600      <name>Some Examples</name>
601      <t>This section provides some examples to illustrate the behavior
602      specified in <xref target="filtering" format="default"/>. These examples are
603      provided for illustration purposes; they should not be considered as
604      deployment recommendations.</t>
605      <section anchor="sample1" numbered="true" toc="default">
606        <name>Conflict Handling</name>
607        <t>Let's consider a DOTS client that contacts its DOTS server during
608        'idle' time to install an accept-list allowing for UDP traffic issued
609        from 2001:db8:1234::/48 with a destination port number 443 to be
610        forwarded to 2001:db8:6401::2/127. It does so by sending, for example,
611        a PUT request as shown in <xref target="PUT" format="default"/>.</t>
612        <figure anchor="PUT">
613          <name>DOTS Data Channel Request to Create a Filter</name>
614<sourcecode>
615PUT /restconf/data/ietf-dots-data-channel:dots-data\
616    /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
617    /acl=an-accept-list HTTP/1.1
618Host: example.com
619Content-Type: application/yang-data+json
620
621{
622  "ietf-dots-data-channel:acls": {
623    "acl": [
624      {
625        "name": "an-accept-list",
626        "type": "ipv6-acl-type",
627        "activation-type": "activate-when-mitigating",
628        "aces": {
629          "ace": [
630            {
631              "name": "test-ace-ipv6-udp",
632              "matches": {
633                "ipv6": {
634                  "destination-ipv6-network": "2001:db8:6401::2/127",
635                  "source-ipv6-network": "2001:db8:1234::/48"
636                },
637                "udp": {
638                  "destination-port-range-or-operator": {
639                    "operator": "eq",
640                    "port": 443
641                  }
642                }
643              },
644              "actions": {
645                "forwarding": "accept"
646              }
647            }
648          ]
649        }
650      }
651    ]
652  }
653}
654</sourcecode>
655        </figure>
656        <t>Sometime later, consider that a DDoS attack is detected by the DOTS
657        client on 2001:db8:6401::2/127. Consequently, the DOTS client sends a
658        mitigation request to its DOTS server as shown in <xref target="mitigate" format="default"/>.</t>
659        <figure anchor="mitigate">
660          <name>DOTS Signal Channel Mitigation Request</name>
661<sourcecode>
662Header: PUT (Code=0.03)
663Uri-Path: ".well-known"
664Uri-Path: "dots"
665Uri-Path: "mitigate"
666Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
667Uri-Path: "mid=123"
668Content-Format: "application/dots+cbor"
669
670{
671  "ietf-dots-signal-channel:mitigation-scope": {
672    "scope": [
673      {
674        "target-prefix": [
675          "2001:db8:6401::2/127"
676        ],
677        "target-protocol": [
678          17
679        ],
680        "lifetime": 3600
681      }
682    ]
683  }
684}
685</sourcecode>
686        </figure>
687        <t>The DOTS server immediately accepts the request by replying with
688        2.01 (Created) (<xref target="response" format="default"/> depicts the message
689        body of the response).</t>
690        <figure anchor="response">
691          <name>Status Response (Message Body)</name>
692<sourcecode> 
693{
694  "ietf-dots-signal-channel:mitigation-scope": {
695    "scope": [
696      {
697        "mid": 123,
698        "lifetime": 3600
699      }
700    ]
701  }
702}
703</sourcecode>
704        </figure>
705        <t>Assuming the DOTS client subscribed to asynchronous notifications,
706        when the DOTS server concludes that some of the attack sources belong
707        to 2001:db8:1234::/48, it sends a notification message with 'status'
708        code set to 1 (attack-mitigation-in-progress) and 'conflict-cause' set
709        to 2 (conflict-with-acceptlist) to the DOTS client to indicate that
710        this mitigation request is in progress, but a conflict is
711        detected.</t>
712        <t>Upon receipt of the notification message from the DOTS server, the
713        DOTS client sends a PUT request to deactivate the "an-accept-list" ACL
714        as shown in <xref target="control" format="default"/>.</t>
715        <t>The DOTS client can also decide to send a PUT request to deactivate
716        the "an-accept-list" ACL if suspect traffic is received from an
717        accept-listed source (2001:db8:1234::/48). The structure of that PUT
718        is the same as the one shown in <xref target="control" format="default"/>.</t>
719        <figure anchor="control">
720          <name>PUT for Deactivating a Conflicting Filter</name>
721<sourcecode>
722Header: PUT (Code=0.03)
723Uri-Path: ".well-known"
724Uri-Path: "dots"
725Uri-Path: "mitigate"
726Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
727Uri-Path: "mid=124"
728Content-Format: "application/dots+cbor"
729
730{
731  "ietf-dots-signal-channel:mitigation-scope": {
732    "scope": [
733      {
734        "target-prefix": [
735          "2001:db8:6401::2/127"
736        ],
737        "target-protocol": [
738          17
739        ],
740        "ietf-dots-signal-control:acl-list": [
741          {
742            "acl-name": "an-accept-list",
743            "activation-type": "deactivate"
744          }
745        ],
746        "lifetime": 3600
747      }
748    ]
749  }
750}
751</sourcecode>
752        </figure>
753        <t>Then, the DOTS server deactivates the "an-accept-list" ACL and replies
754        with a 2.04 (Changed) response to the DOTS client to confirm the
755        successful operation. The message body is similar to the one depicted
756        in <xref target="response" format="default"/>.</t>
757        <t>Once the attack is mitigated, the DOTS client may use the data
758        channel to retrieve its ACLs maintained by the DOTS server. As shown
759        in <xref target="GET-2" format="default"/>, the activation type is set to
760        'deactivate' as set by the DOTS signal channel (<xref target="control" format="default"/>) instead of the type initially set using the
761        DOTS data channel (<xref target="PUT" format="default"/>).</t>
762        <figure anchor="GET-2">
763          <name>DOTS Data Channel GET Response after Mitigation (Message Body)</name>
764<sourcecode>
765{
766  "ietf-dots-data-channel:acls": {
767    "acl": [
768      {
769        "name": "an-accept-list",
770        "type": "ipv6-acl-type",
771        "activation-type": "deactivate",
772        "pending-lifetime": 10021,
773        "aces": {
774          "ace": [
775            {
776              "name": "test-ace-ipv6-udp",
777              "matches": {
778                "ipv6": {
779                  "destination-ipv6-network": "2001:db8:6401::2/127",
780                  "source-ipv6-network": "2001:db8:1234::/48"
781                },
782                "udp": {
783                  "destination-port-range-or-operator": {
784                    "operator": "eq",
785                    "port": 443
786                  }
787                }
788              },
789              "actions": {
790                "forwarding": "accept"
791              }
792            }
793          ]
794        }
795      }
796    ]
797  }
798}
799</sourcecode>
800        </figure>
801      </section>
802      <section anchor="sample2" numbered="true" toc="default">
803        <name>On-Demand Activation of an Accept-List Filter</name>
804        <t>Let's consider a DOTS client that contacts its DOTS server during
805        'idle' time to install an accept-list allowing for UDP traffic issued
806        from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It
807        does so by sending, for example, a PUT request shown in <xref
808        target="PUT1" format="default"/>. The DOTS server installs this filter
809        with a "deactivated" state.</t>
810        <figure anchor="PUT1">
811          <name>DOTS Data Channel Request to Create an Accept-List Filter</name>
812<sourcecode>
813PUT /restconf/data/ietf-dots-data-channel:dots-data\
814    /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\
815    /acl=my-accept-list HTTP/1.1
816Host: example.com
817Content-Type: application/yang-data+json
818
819{
820  "ietf-dots-data-channel:acls": {
821    "acl": [
822      {
823        "name": "my-accept-list",
824        "type": "ipv6-acl-type",
825        "activation-type": "deactivate",
826        "aces": {
827          "ace": [
828            {
829              "name": "an-ace",
830              "matches": {
831                "ipv6": {
832                  "destination-ipv6-network": "2001:db8:6401::2/127",
833                  "source-ipv6-network": "2001:db8:1234::/48",
834                  "protocol": 17
835                }
836              },
837              "actions": {
838                "forwarding": "accept"
839              }
840            }
841          ]
842        }
843      }
844    ]
845  }
846}
847</sourcecode>
848        </figure>
849        <t>Sometime later, consider that a UDP DDoS attack is detected by the
850        DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let
851        the traffic from 2001:db8:1234::/48 be accept-listed to the DOTS
852        client domain. Consequently, the DOTS client sends a mitigation
853        request to its DOTS server as shown in <xref target="mitigate1" format="default"/>.</t>
854        <figure anchor="mitigate1">
855          <name>DOTS Signal Channel Mitigation Request with a Filter Control</name>
856<sourcecode>
857Header: PUT (Code=0.03)
858Uri-Path: ".well-known"
859Uri-Path: "dots"
860Uri-Path: "mitigate"
861Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA"
862Uri-Path: "mid=4879"
863Content-Format: "application/dots+cbor"
864
865{
866  "ietf-dots-signal-channel:mitigation-scope": {
867    "scope": [
868      {
869        "target-prefix": [
870          "2001:db8:6401::2/127"
871        ],
872        "target-protocol": [
873          17
874        ],
875        "ietf-dots-signal-control:acl-list": [
876          {
877            "acl-name": "my-accept-list",
878            "activation-type": "immediate"
879          }
880        ],
881        "lifetime": 3600
882      }
883    ]
884  }
885}
886</sourcecode>
887        </figure>
888        <t>The DOTS server activates the "my-accept-list" ACL and replies with
889        a 2.01 (Created) response to the DOTS client to confirm the successful
890        operation.</t>
891      </section>
892
893
894      <section anchor="sample3" numbered="true" toc="default">
895        <name>DOTS Servers/Mitigators Lacking Capacity</name>
896        <t>This section describes a scenario in which a DOTS client activates
897        a drop-list or a rate-limit filter during an attack.</t>
898        <t>Consider a DOTS client that contacts its DOTS server during 'idle'
899        time to install an accept-list that rate-limits all (or a part
900        thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort
901        countermeasure whenever required. Installing the accept-list can be
902        done by sending, for example, the PUT request shown in <xref
903        target="rate" format="default"/>. The DOTS server installs this filter
904        with a "deactivated" state.</t>
905        <figure anchor="rate">
906          <name>DOTS Data Channel Request to Create a Rate-Limit Filter</name>
907<sourcecode>
908PUT /restconf/data/ietf-dots-data-channel:dots-data\
909    /dots-client=OopPisZqo4SLv64TLPXrxA/acls\
910    /acl=my-ratelimit-list HTTP/1.1
911Host: example.com
912Content-Type: application/yang-data+json
913
914{
915  "ietf-dots-data-channel:acls": {
916    "acl": [
917      {
918        "name": "my-ratelimit-list",
919        "type": "ipv6-acl-type",
920        "activation-type": "deactivate",
921        "aces": {
922          "ace": [
923            {
924              "name": "my-ace",
925              "matches": {
926                "ipv6": {
927                  "destination-ipv6-network": "2001:db8:123::/48"
928                }
929              },
930              "actions": {
931                "forwarding": "accept",
932                "rate-limit": "20000.00"
933              }
934            }
935          ]
936        }
937      }
938    ]
939  }
940}
941</sourcecode>
942        </figure>
943        <t>Consider now that a DDoS attack is detected by the DOTS client on
944        2001:db8:123::/48. Consequently, the DOTS client sends a mitigation
945        request to its DOTS server (<xref target="ratel" format="default"/>).</t>
946        <figure anchor="ratel">
947          <name>DOTS Signal Channel Mitigation Request</name>
948<sourcecode>
949Header: PUT (Code=0.03)
950Uri-Path: ".well-known"
951Uri-Path: "dots"
952Uri-Path: "mitigate"
953Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
954Uri-Path: "mid=85"
955Content-Format: "application/dots+cbor"
956
957{
958  "ietf-dots-signal-channel:mitigation-scope": {
959    "scope": [
960      {
961        "target-prefix": [
962          "2001:db8:123::/48"
963        ],
964        "lifetime": 3600
965      }
966    ]
967  }
968}
969</sourcecode>
970        </figure>
971        <t>For some reason (e.g., the DOTS server, or the mitigator, is
972        lacking a capability or capacity), the DOTS client is still receiving
973        attack traffic, which saturates available links. To soften the
974        problem, the DOTS client decides to activate the filter that
975        rate-limits the traffic destined to the DOTS client domain. To that
976        aim, the DOTS client sends the mitigation request to its DOTS server
977        shown in <xref target="rateres" format="default"/>.</t>
978        <figure anchor="rateres">
979          <name>DOTS Signal Channel Mitigation Request to Activate a Rate-Limit Filter</name>
980<sourcecode>
981Header: PUT (Code=0.03)
982Uri-Path: ".well-known"
983Uri-Path: "dots"
984Uri-Path: "mitigate"
985Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
986Uri-Path: "mid=86"
987Content-Format: "application/dots+cbor"
988
989{
990  "ietf-dots-signal-channel:mitigation-scope": {
991    "scope": [
992      {
993        "target-prefix": [
994          "2001:db8:123::/48"
995        ],
996        "ietf-dots-signal-control:acl-list": [
997          {
998            "acl-name": "my-ratelimit-list",
999            "activation-type": "immediate"
1000          }
1001        ],
1002        "lifetime": 3600
1003      }
1004    ]
1005  }
1006}
1007</sourcecode>
1008        </figure>
1009        <t>Then, the DOTS server activates the "my-ratelimit-list" ACL and replies
1010        with a 2.04 (Changed) response to the DOTS client to confirm the
1011        successful operation.</t>
1012        <t>As the attack mitigation evolves, the DOTS client may decide to
1013        deactivate the rate-limit policy (e.g., upon receipt of a notification
1014        status change from 'attack-exceeded-capability' to
1015        'attack-mitigation-in-progress'). Based on the mitigation status
1016        conveyed by the DOTS server, the DOTS client can deactivate the
1017        rate-limit action. It does so by sending the request shown in <xref target="rateres2" format="default"/>.</t>
1018        <figure anchor="rateres2">
1019          <name>DOTS Signal Channel Mitigation Request to Deactivate a Rate-Limit Filter</name>
1020<sourcecode type="cbor">
1021Header: PUT (Code=0.03)
1022Uri-Path: ".well-known"
1023Uri-Path: "dots"
1024Uri-Path: "mitigate"
1025Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
1026Uri-Path: "mid=87"
1027Content-Format: "application/dots+cbor"
1028
1029{
1030  "ietf-dots-signal-channel:mitigation-scope": {
1031    "scope": [
1032      {
1033        "target-prefix": [
1034          "2001:db8:123::/48"
1035        ],
1036        "ietf-dots-signal-control:acl-list": [
1037          {
1038            "acl-name": "my-ratelimit-list",
1039            "activation-type": "deactivate"
1040          }
1041        ],
1042        "lifetime": 3600
1043      }
1044    ]
1045  }
1046}
1047</sourcecode>
1048        </figure>
1049      </section>
1050    </section>
1051    <section anchor="IANA" numbered="true" toc="default">
1052
1053      <name>IANA Considerations</name>
1054      <section anchor="map" numbered="true" toc="default">
1055        <name>DOTS Signal Channel CBOR Key Values Subregistry</name>
1056        <t>Per this specification, IANA has registered the following parameters in the
1057        "DOTS Signal Channel CBOR Key Values" subregistry within the
1058 "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
1059 Channel" registry <xref target="Key-Map" format="default"/>.</t>
1060
1061<table anchor="table2"> 
1062
1063  <thead>
1064    <tr>
1065      <th>Parameter Name</th>   
1066      <th>CBOR Key Value</th>
1067      <th>CBOR Major Type</th>
1068      <th>Change Controller</th>
1069      <th>Specification Document(s)</th>
1070    </tr>
1071  </thead>
1072  <tbody>         
1073    <tr>
1074      <td>activation-type</td>
1075      <td>52</td>
1076      <td>0</td>
1077      <td>IESG</td>
1078      <td>RFC 9133</td>
1079    </tr>
1080    <tr>
1081      <td>ietf-dots-signal-control:acl-list</td>
1082      <td>53</td>
1083      <td>4</td>
1084      <td>IESG</td>
1085      <td>RFC 9133</td>
1086    </tr>
1087
1088  </tbody>
1089</table>
1090
1091
1092      </section>
1093      <section anchor="yang-iana" numbered="true" toc="default">
1094        <name>A New YANG Module</name>
1095        <t>IANA has registered the following URI in the
1096        "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" format="default"/>:</t>
1097
1098<dl newline="false" spacing="compact">
1099<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd>
1100<dt>Registrant Contact:</dt><dd>The IESG.</dd>
1101<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
1102</dl>
1103
1104        <t>IANA has registered the following YANG module
1105        in the "YANG Module Names" subregistry <xref target="RFC6020" format="default"/>
1106        within the "YANG Parameters" registry.</t>
1107
1108<dl newline="false" spacing="compact"> 
1109<dt>Name:</dt><dd>ietf-dots-signal-control</dd>
1110<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd>
1111<dt>Maintained by IANA:</dt><dd>N</dd>
1112<dt>Prefix:</dt><dd>dots-control</dd>
1113<dt>Reference:</dt><dd>RFC 9133</dd>
1114</dl>
1115      </section>
1116    </section>
1117    <section anchor="security" numbered="true" toc="default">
1118      <name>Security Considerations</name>
1119
1120      <t>The security considerations for the DOTS signal channel protocol are
1121      discussed in <xref target="RFC9132" sectionFormat="of" section="11"/>,
1122      while those for the DOTS data channel protocol are discussed in <xref
1123      target="RFC8783" sectionFormat="of" section="10"/>. The following
1124      discusses the security considerations that are specific to the DOTS
1125      signal channel extension defined in this document.</t>
1126      <t>This specification does not allow the creation of new filtering rules,
1127      which is the responsibility of the DOTS data channel. DOTS client
1128      domains should be adequately prepared prior to an attack, e.g., by
1129      creating filters that will be activated on demand when an attack is
1130      detected.</t>
1131      <t>A DOTS client is entitled to access only the resources it creates. In
1132      particular, a DOTS client can not tweak filtering rules created by other
1133      DOTS clients of the same DOTS client domain. As a reminder, DOTS servers
1134      must associate filtering rules with the DOTS client that created these
1135      resources. Failure to ensure such association by a DOTS server will have
1136      severe impact on DOTS client domains.</t>
1137      <t>A compromised DOTS client can use the filtering control capability to
1138      exacerbate an ongoing attack. Likewise, such a compromised DOTS client
1139      may abstain from reacting to an ACL conflict notification received from
1140      the DOTS server during attacks. These are not new attack vectors, but
1141      variations of threats discussed in <xref target="RFC9132"
1142      format="default"/> and <xref target="RFC8783" format="default"/>. DOTS
1143      operators should carefully monitor and audit DOTS agents to detect
1144      misbehaviors and deter misuses.</t>
1145    </section>
1146
1147  </middle>
1148  <back>
1149
1150    <references>
1151      <name>References</name>
1152      <references>
1153        <name>Normative References</name>
1154        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
1155        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
1156        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
1157        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
1158        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
1159        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8791.xml"/>
1160
1161
1162   <reference anchor="RFC9132" target="https://www.rfc-editor.org/info/rfc9132">
1163
1164     <front>
1165       <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
1166
1167       <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair" role="editor">
1168         <organization />
1169       </author>
1170       <author initials="J" surname="Shallow" fullname="Jon Shallow">
1171         <organization />
1172       </author>
1173       <author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.K">
1174         <organization />
1175       </author>
1176
1177       <date month="September" year="2021" />
1178     </front>
1179     <seriesInfo name="RFC" value="9132" />
1180     <seriesInfo name="DOI" value="10.17487/RFC9132"/>
1181
1182   </reference>
1183
1184
1185
1186        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml"/>
1187      </references>
1188      <references>
1189        <name>Informative References</name>
1190        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8612.xml"/>
1191        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml"/>
1192        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
1193        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8811.xml"/>
1194
1195        <reference anchor="INTEROP" target="https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00">
1196          <front>
1197            <title>DOTS Interop test report, IETF 103 Hackathon</title>
1198            <author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka">
1199              <organization>NTT Communications</organization>
1200              <address>
1201                <postal>
1202                  <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
1203                  <city>Tokyo</city>
1204                  <region/>
1205                  <code>108-8118</code>
1206                  <country>Japan</country>
1207                </postal>
1208                <email>kaname@nttv6.jp</email>
1209              </address>
1210            </author>
1211            <author fullname="Jon Shallow" initials="J." surname=" Shallow">
1212              <organization>J.NCC Group</organization>
1213              <address>
1214                <postal>
1215                  <street/>
1216                  <city/>
1217                  <region/>
1218                  <code/>
1219                  <country/>
1220                </postal>
1221                <phone/>
1222                <email/>
1223                <uri/>
1224              </address>
1225            </author>
1226            <author fullname="Liang Xia" initials="L." surname="Xia ">
1227              <organization>Huawei</organization>
1228              <address>
1229                <postal>
1230                  <street/>
1231                  <city/>
1232                  <region/>
1233                  <code/>
1234                  <country/>
1235                </postal>
1236                <phone/>
1237                <email/>
1238                <uri/>
1239              </address>
1240            </author>
1241            <date month="November" year="2018"/>
1242          </front>
1243        </reference>
1244
1245        <reference anchor="Key-Map" target="https://www.iana.org/assignments/dots">
1246          <front>
1247            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS)
1248     Signal Channel</title>
1249            <author fullname="IANA">
1250              <organization/>
1251            </author>
1252          </front>
1253        </reference>
1254      </references>
1255
1256    </references>
1257
1258    <section anchor="ack" numbered="false" toc="default">
1259      <name>Acknowledgements</name>
1260      <t>Many thanks to <contact fullname="Wei Pan"/>, <contact fullname="Xia
1261      Liang"/>, <contact fullname="Jon Shallow"/>, <contact fullname="Dan
1262      Wing"/>, <contact fullname="Christer
1263      Holmberg"/>, <contact fullname="Shawn Emery"/>, <contact fullname="Tim
1264      Chown"/>, <contact fullname="Murray Kucherawy"/>, <contact
1265      fullname="Roman Danyliw"/>, <contact fullname="Erik
1266      Kline"/>, and <contact fullname="Éric Vyncke"/> for the comments.</t>
1267      <t>Thanks to <contact fullname="Benjamin Kaduk"/> for the AD review.</t>
1268    </section>
1269  </back>
1270
1271
1272
1273
1274</rfc>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
4<front>
5<title>Key words for use in RFCs to Indicate Requirement Levels</title>
6<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
7<date year='1997' month='March' />
8<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
9</front>
10<seriesInfo name='BCP' value='14'/>
11<seriesInfo name='RFC' value='2119'/>
12<seriesInfo name='DOI' value='10.17487/RFC2119'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7950' target='https://www.rfc-editor.org/info/rfc7950'>
4<front>
5<title>The YANG 1.1 Data Modeling Language</title>
6<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'><organization /></author>
7<date year='2016' month='August' />
8<abstract><t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t></abstract>
9</front>
10<seriesInfo name='RFC' value='7950'/>
11<seriesInfo name='DOI' value='10.17487/RFC7950'/>
12</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC3688' target='https://www.rfc-editor.org/info/rfc3688'>
4<front>
5<title>The IETF XML Registry</title>
6<author initials='M.' surname='Mealling' fullname='M. Mealling'><organization /></author>
7<date year='2004' month='January' />
8<abstract><t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t></abstract>
9</front>
10<seriesInfo name='BCP' value='81'/>
11<seriesInfo name='RFC' value='3688'/>
12<seriesInfo name='DOI' value='10.17487/RFC3688'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC6020' target='https://www.rfc-editor.org/info/rfc6020'>
4<front>
5<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
6<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'><organization /></author>
7<date year='2010' month='October' />
8<abstract><t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t></abstract>
9</front>
10<seriesInfo name='RFC' value='6020'/>
11<seriesInfo name='DOI' value='10.17487/RFC6020'/>
12</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
4<front>
5<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
6<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
7<date year='2017' month='May' />
8<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
9</front>
10<seriesInfo name='BCP' value='14'/>
11<seriesInfo name='RFC' value='8174'/>
12<seriesInfo name='DOI' value='10.17487/RFC8174'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8791' target='https://www.rfc-editor.org/info/rfc8791'>
4<front>
5<title>YANG Data Structure Extensions</title>
6<author initials='A.' surname='Bierman' fullname='A. Bierman'><organization /></author>
7<author initials='M.' surname='Björklund' fullname='M. Björklund'><organization /></author>
8<author initials='K.' surname='Watsen' fullname='K. Watsen'><organization /></author>
9<date year='2020' month='June' />
10<abstract><t>This document describes YANG mechanisms for defining abstract data structures with YANG.</t></abstract>
11</front>
12<seriesInfo name='RFC' value='8791'/>
13<seriesInfo name='DOI' value='10.17487/RFC8791'/>
14</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8783' target='https://www.rfc-editor.org/info/rfc8783'>
4<front>
5<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification</title>
6<author initials='M.' surname='Boucadair' fullname='M. Boucadair' role='editor'><organization /></author>
7<author initials='T.' surname='Reddy.K' fullname='T. Reddy.K' role='editor'><organization /></author>
8<date year='2020' month='May' />
9<abstract><t>The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.</t><t>This is a companion document to &quot;Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification&quot; (RFC 8782).</t></abstract>
10</front>
11<seriesInfo name='RFC' value='8783'/>
12<seriesInfo name='DOI' value='10.17487/RFC8783'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8612' target='https://www.rfc-editor.org/info/rfc8612'>
4<front>
5<title>DDoS Open Threat Signaling (DOTS) Requirements</title>
6<author initials='A.' surname='Mortensen' fullname='A. Mortensen'><organization /></author>
7<author initials='T.' surname='Reddy' fullname='T. Reddy'><organization /></author>
8<author initials='R.' surname='Moskowitz' fullname='R. Moskowitz'><organization /></author>
9<date year='2019' month='May' />
10<abstract><t>This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.</t></abstract>
11</front>
12<seriesInfo name='RFC' value='8612'/>
13<seriesInfo name='DOI' value='10.17487/RFC8612'/>
14</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7951' target='https://www.rfc-editor.org/info/rfc7951'>
4<front>
5<title>JSON Encoding of Data Modeled with YANG</title>
6<author initials='L.' surname='Lhotka' fullname='L. Lhotka'><organization /></author>
7<date year='2016' month='August' />
8<abstract><t>This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t></abstract>
9</front>
10<seriesInfo name='RFC' value='7951'/>
11<seriesInfo name='DOI' value='10.17487/RFC7951'/>
12</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8340' target='https://www.rfc-editor.org/info/rfc8340'>
4<front>
5<title>YANG Tree Diagrams</title>
6<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization /></author>
7<author initials='L.' surname='Berger' fullname='L. Berger' role='editor'><organization /></author>
8<date year='2018' month='March' />
9<abstract><t>This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.</t></abstract>
10</front>
11<seriesInfo name='BCP' value='215'/>
12<seriesInfo name='RFC' value='8340'/>
13<seriesInfo name='DOI' value='10.17487/RFC8340'/>
14</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8811' target='https://www.rfc-editor.org/info/rfc8811'>
4<front>
5<title>DDoS Open Threat Signaling (DOTS) Architecture</title>
6<author initials='A.' surname='Mortensen' fullname='A. Mortensen' role='editor'><organization /></author>
7<author initials='T.' surname='Reddy.K' fullname='T. Reddy.K' role='editor'><organization /></author>
8<author initials='F.' surname='Andreasen' fullname='F. Andreasen'><organization /></author>
9<author initials='N.' surname='Teague' fullname='N. Teague'><organization /></author>
10<author initials='R.' surname='Compton' fullname='R. Compton'><organization /></author>
11<date year='2020' month='August' />
12<abstract><t>This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.</t></abstract>
13</front>
14<seriesInfo name='RFC' value='8811'/>
15<seriesInfo name='DOI' value='10.17487/RFC8811'/>
16</reference>