idnits 2.17.1 draft-ietf-dots-signal-channel-33.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFCXXXX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2567 has weird spacing: '...er-port ine...' -- The document date (May 10, 2019) is 1784 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 4201, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-core-hop-limit-03 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Downref: Normative reference to an Informational RFC: RFC 7918 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-04 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-10 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-13 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-28 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-01 == Outdated reference: A later version (-15) exists of draft-ietf-dots-server-discovery-02 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-31 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy, Ed. 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair, Ed. 5 Expires: November 11, 2019 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 May 10, 2019 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel Specification 16 draft-ietf-dots-signal-channel-33 18 Abstract 20 This document specifies the DOTS signal channel, a protocol for 21 signaling the need for protection against Distributed Denial-of- 22 Service (DDoS) attacks to a server capable of enabling network 23 traffic mitigation on behalf of the requesting client. 25 A companion document defines the DOTS data channel, a separate 26 reliable communication layer for DOTS management and configuration 27 purposes. 29 Editorial Note (To be removed by RFC Editor) 31 Please update these statements within the document with the RFC 32 number to be assigned to this document: 34 o "This version of this YANG module is part of RFC XXXX;" 36 o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling 37 (DOTS) Signal Channel Specification"; 39 o "| [RFCXXXX] |" 41 o reference: RFC XXXX 43 Please update this statement with the RFC number to be assigned to 44 the following documents: 46 o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling 47 (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data- 48 channel) 50 Please update TBD/TBD1/TBD2 statements with the assignments made by 51 IANA to DOTS Signal Channel Protocol. 53 Also, please update the "revision" date of the YANG modules. 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at https://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on November 11, 2019. 72 Copyright Notice 74 Copyright (c) 2019 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (https://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 90 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 91 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 92 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 9 93 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 9 94 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 95 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 10 96 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 12 97 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 13 98 4.4.2. Retrieve Information Related to a Mitigation . . . . 29 99 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 34 100 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37 101 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38 102 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40 103 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41 104 4.5.1. Discover Configuration Parameters . . . . . . . . . . 43 105 4.5.2. Convey DOTS Signal Channel Session Configuration . . 47 106 4.5.3. Configuration Freshness and Notifications . . . . . . 52 107 4.5.4. Delete DOTS Signal Channel Session Configuration . . 53 108 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 54 109 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 56 110 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 57 111 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 58 112 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 60 113 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 64 114 6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 74 115 7. (D)TLS Protocol Profile and Performance Considerations . . . 76 116 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 76 117 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 78 118 7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 80 119 8. Mutual Authentication of DOTS Agents & Authorization of DOTS 120 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 121 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 122 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 82 123 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 82 124 9.3. Media Type Registration . . . . . . . . . . . . . . . . . 82 125 9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 83 126 9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 83 127 9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 84 128 9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 84 129 9.6.1.1. Registration Template . . . . . . . . . . . . . . 84 130 9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 85 131 9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 87 132 9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 88 133 9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 90 134 9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 90 135 9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 91 136 10. Security Considerations . . . . . . . . . . . . . . . . . . . 92 137 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 94 138 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 139 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 140 13.1. Normative References . . . . . . . . . . . . . . . . . . 95 141 13.2. Informative References . . . . . . . . . . . . . . . . . 98 142 Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 103 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 145 1. Introduction 147 A distributed denial-of-service (DDoS) attack is a distributed 148 attempt to make machines or network resources unavailable to their 149 intended users. In most cases, sufficient scale for an effective 150 attack can be achieved by compromising enough end-hosts and using 151 those infected hosts to perpetrate and amplify the attack. The 152 victim in this attack can be an application server, a host, a router, 153 a firewall, or an entire network. 155 Network applications have finite resources like CPU cycles, the 156 number of processes or threads they can create and use, the maximum 157 number of simultaneous connections they can handle, the limited 158 resources of the control plane, etc. When processing network 159 traffic, such applications are supposed to use these resources to 160 provide the intended functionality in the most efficient manner. 161 However, a DDoS attacker may be able to prevent an application from 162 performing its intended task by making the application exhaust its 163 finite resources. 165 A TCP DDoS SYN-flood [RFC4987], for example, is a memory-exhausting 166 attack while an ACK-flood is a CPU-exhausting attack. Attacks on the 167 link are carried out by sending enough traffic so that the link 168 becomes congested, thereby likely causing packet loss for legitimate 169 traffic. Stateful firewalls can also be attacked by sending traffic 170 that causes the firewall to maintain an excessive number of states 171 that may jeopardize the firewall's operation overall, besides likely 172 performance impacts. The firewall then runs out of memory, and can 173 no longer instantiate the states required to process legitimate 174 flows. Other possible DDoS attacks are discussed in [RFC4732]. 176 In many cases, it may not be possible for network administrators to 177 determine the cause(s) of an attack. They may instead just realize 178 that certain resources seem to be under attack. This document 179 defines a lightweight protocol that allows a DOTS client to request 180 mitigation from one or more DOTS servers for protection against 181 detected, suspected, or anticipated attacks. This protocol enables 182 cooperation between DOTS agents to permit a highly-automated network 183 defense that is robust, reliable, and secure. Note that "secure" 184 means the support of the features defined in Section 2.4 of 185 [I-D.ietf-dots-requirements]. 187 An example of a network diagram that illustrates a deployment of DOTS 188 agents is shown in Figure 1. In this example, a DOTS server is 189 operating on the access network. A DOTS client is located on the LAN 190 (Local Area Network), while a DOTS gateway is embedded in the CPE 191 (Customer Premises Equipment). 193 Network 194 Resource CPE router Access network __________ 195 +-----------+ +--------------+ +-------------+ / \ 196 | |___| |____| |___ | Internet | 197 |DOTS client| | DOTS gateway | | DOTS server | | | 198 | | | | | | | | 199 +-----------+ +--------------+ +-------------+ \__________/ 201 Figure 1: Sample DOTS Deployment (1) 203 DOTS servers can also be reachable over the Internet, as depicted in 204 Figure 2. 206 Network DDoS mitigation 207 Resource CPE router __________ service 208 +-----------+ +-------------+ / \ +-------------+ 209 | |___| |____| |___ | | 210 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 211 | | | | | | | | 212 +-----------+ +-------------+ \__________/ +-------------+ 214 Figure 2: Sample DOTS Deployment (2) 216 In typical deployments, the DOTS client belongs to a different 217 administrative domain than the DOTS server. For example, the DOTS 218 client is embedded in a firewall protecting services owned and 219 operated by a customer, while the DOTS server is owned and operated 220 by a different administrative entity (service provider, typically) 221 providing DDoS mitigation services. The latter might or might not 222 provide connectivity services to the network hosting the DOTS client. 224 The DOTS server may (not) be co-located with the DOTS mitigator. In 225 typical deployments, the DOTS server belongs to the same 226 administrative domain as the mitigator. The DOTS client can 227 communicate directly with a DOTS server or indirectly via a DOTS 228 gateway. 230 The document adheres to the DOTS architecture 231 [I-D.ietf-dots-architecture]. The requirements for DOTS signal 232 channel protocol are documented in [I-D.ietf-dots-requirements]. 233 This document satisfies all the use cases discussed in 234 [I-D.ietf-dots-use-cases]. 236 This document focuses on the DOTS signal channel. This is a 237 companion document of the DOTS data channel specification 238 [I-D.ietf-dots-data-channel] that defines a configuration and a bulk 239 data exchange mechanism supporting the DOTS signal channel. 241 2. Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 245 "OPTIONAL" in this document are to be interpreted as described in BCP 246 14 [RFC2119][RFC8174] when, and only when, they appear in all 247 capitals, as shown here. 249 (D)TLS is used for statements that apply to both Transport Layer 250 Security [RFC5246][RFC8446] and Datagram Transport Layer Security 251 [RFC6347]. Specific terms are used for any statement that applies to 252 either protocol alone. 254 The reader should be familiar with the terms defined in 255 [I-D.ietf-dots-requirements]. 257 The meaning of the symbols in YANG tree diagrams is defined in 258 [RFC8340]. 260 3. Design Overview 262 The DOTS signal channel is built on top of the Constrained 263 Application Protocol (CoAP) [RFC7252], a lightweight protocol 264 originally designed for constrained devices and networks. The many 265 features of CoAP (expectation of packet loss, support for 266 asynchronous Non-confirmable messaging, congestion control, small 267 message overhead limiting the need for fragmentation, use of minimal 268 resources, and support for (D)TLS) makes it a good candidate to build 269 the DOTS signaling mechanism from. 271 The DOTS signal channel is layered on existing standards (Figure 3). 273 +---------------------+ 274 | DOTS Signal Channel | 275 +---------------------+ 276 | CoAP | 277 +----------+----------+ 278 | TLS | DTLS | 279 +----------+----------+ 280 | TCP | UDP | 281 +----------+----------+ 282 | IP | 283 +---------------------+ 285 Figure 3: Abstract Layering of DOTS Signal Channel over CoAP over 286 (D)TLS 288 In some cases, a DOTS client and server may have mutual agreement to 289 use a specific port number, such as by explicit configuration or 290 dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such 291 mutual agreement, the DOTS signal channel MUST run over port number 292 TBD as defined in Section 9.1, for both UDP and TCP. In order to use 293 a distinct port number (as opposed to TBD), DOTS clients and servers 294 SHOULD support a configurable parameter to supply the port number to 295 use. The rationale for not using the default port number 5684 296 ((D)TLS CoAP) is to allow for differentiated behaviors in 297 environments where both a DOTS gateway and an IoT gateway (e.g., 298 Figure 3 of [RFC7452]) are present. 300 The signal channel uses the "coaps" URI scheme defined in Section 6 301 of [RFC7252] and the "coaps+tcp" URI scheme defined in Section 8.2 of 302 [RFC8323] to identify DOTS server resources accessible using CoAP 303 over UDP secured with DTLS and CoAP over TCP secured with TLS, 304 respectively. 306 The DOTS signal channel can be established between two DOTS agents 307 prior or during an attack. The DOTS signal channel is initiated by 308 the DOTS client. The DOTS client can then negotiate, configure, and 309 retrieve the DOTS signal channel session behavior with its DOTS peer 310 (Section 4.5). Once the signal channel is established, the DOTS 311 agents periodically send heartbeats to keep the channel active 312 (Section 4.7). At any time, the DOTS client may send a mitigation 313 request message (Section 4.4) to a DOTS server over the active signal 314 channel. While mitigation is active (because of the higher 315 likelihood of packet loss during a DDoS attack), the DOTS server 316 periodically sends status messages to the client, including basic 317 mitigation feedback details. Mitigation remains active until the 318 DOTS client explicitly terminates mitigation, or the mitigation 319 lifetime expires. Also, the DOTS server may rely on the signal 320 channel session loss to trigger mitigation for pre-configured 321 mitigation requests (if any). 323 DOTS signaling can happen with DTLS over UDP and TLS over TCP. 324 Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer 325 capabilities. A Happy Eyeballs procedure for DOTS signal channel is 326 specified in Section 4.3. 328 A DOTS client is entitled to access only to resources it creates. In 329 particular, a DOTS client can not retrieve data related to mitigation 330 requests created by other DOTS clients of the same DOTS client 331 domain. 333 Messages exchanged between DOTS agents are serialized using Concise 334 Binary Object Representation (CBOR) [RFC7049], a binary encoding 335 scheme designed for small code and message size. CBOR-encoded 336 payloads are used to carry signal channel-specific payload messages 337 which convey request parameters and response information such as 338 errors. In order to allow reusing data models across protocols, 339 [RFC7951] specifies the JavaScript Object Notation (JSON) encoding of 340 YANG-modeled data. A similar effort for CBOR is defined in 341 [I-D.ietf-core-yang-cbor]. 343 DOTS agents determine that a CBOR data structure is a DOTS signal 344 channel object from the application context, such as from the port 345 number assigned to the DOTS signal channel. The other method DOTS 346 agents use to indicate that a CBOR data structure is a DOTS signal 347 channel object is the use of the "application/dots+cbor" content type 348 (Section 9.3). 350 This document specifies a YANG module for representing DOTS 351 mitigation scopes, DOTS signal channel session configuration data, 352 and DOTS redirected signaling (Section 5). All parameters in the 353 payload of the DOTS signal channel are mapped to CBOR types as 354 specified in Table 4 (Section 6). 356 In order to prevent fragmentation, DOTS agents must follow the 357 recommendations documented in Section 4.6 of [RFC7252]. Refer to 358 Section 7.3 for more details. 360 DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The 361 payload included in CoAP responses with 2.xx Response Codes MUST be 362 of content type "application/dots+cbor". CoAP responses with 4.xx 363 and 5.xx error Response Codes MUST include a diagnostic payload 364 (Section 5.5.2 of [RFC7252]). The Diagnostic Payload may contain 365 additional information to aid troubleshooting. 367 In deployments where multiple DOTS clients are enabled in a network 368 (owned and operated by the same entity), the DOTS server may detect 369 conflicting mitigation requests from these clients. This document 370 does not aim to specify a comprehensive list of conditions under 371 which a DOTS server will characterize two mitigation requests from 372 distinct DOTS clients as conflicting, nor recommend a DOTS server 373 behavior for processing conflicting mitigation requests. Those 374 considerations are implementation- and deployment-specific. 375 Nevertheless, the document specifies the mechanisms to notify DOTS 376 clients when conflicts occur, including the conflict cause 377 (Section 4.4). 379 In deployments where one or more translators (e.g., Traditional NAT 380 [RFC3022], CGN [RFC6888], NAT64 [RFC6146], NPTv6 [RFC6296]) are 381 enabled between the client's network and the DOTS server, DOTS signal 382 channel messages forwarded to a DOTS server MUST NOT include internal 383 IP addresses/prefixes and/or port numbers; external addresses/ 384 prefixes and/or port numbers as assigned by the translator MUST be 385 used instead. This document does not make any recommendation about 386 possible translator discovery mechanisms. The following are some 387 (non-exhaustive) deployment examples that may be considered: 389 o Port Control Protocol (PCP) [RFC6887] or Session Traversal 390 Utilities for NAT (STUN) [RFC5389] may be used to retrieve the 391 external addresses/prefixes and/or port numbers. Information 392 retrieved by means of PCP or STUN will be used to feed the DOTS 393 signal channel messages that will be sent to a DOTS server. 395 o A DOTS gateway may be co-located with the translator. The DOTS 396 gateway will need to update the DOTS messages, based upon the 397 local translator's binding table. 399 4. DOTS Signal Channel: Messages & Behaviors 401 4.1. DOTS Server(s) Discovery 403 This document assumes that DOTS clients are provisioned with the 404 reachability information of their DOTS server(s) using any of a 405 variety of means (e.g., local configuration, or dynamic means such as 406 DHCP [I-D.ietf-dots-server-discovery]). The description of such 407 means is out of scope of this document. 409 Likewise, it is out of scope of this document to specify the behavior 410 to be followed by a DOTS client to send DOTS requests when multiple 411 DOTS servers are provisioned (e.g., contact all DOTS servers, select 412 one DOTS server among the list). Such behavior is specified in other 413 documents (e.g. [I-D.ietf-dots-multihoming]). 415 4.2. CoAP URIs 417 The DOTS server MUST support the use of the path-prefix of "/.well- 418 known/" as defined in [RFC5785] and the registered name of "dots". 419 Each DOTS operation is indicated by a path-suffix that indicates the 420 intended operation. The operation path (Table 1) is appended to the 421 path-prefix to form the URI used with a CoAP request to perform the 422 desired DOTS operation. 424 +-----------------------+----------------+-------------+ 425 | Operation | Operation Path | Details | 426 +-----------------------+----------------+-------------+ 427 | Mitigation | /mitigate | Section 4.4 | 428 +-----------------------+----------------+-------------+ 429 | Session configuration | /config | Section 4.5 | 430 +-----------------------+----------------+-------------+ 432 Table 1: Operations and their Corresponding URIs 434 4.3. Happy Eyeballs for DOTS Signal Channel 436 [I-D.ietf-dots-requirements] mentions that DOTS agents will have to 437 support both connectionless and connection-oriented protocols. As 438 such, the DOTS signal channel is designed to operate with DTLS over 439 UDP and TLS over TCP. Further, a DOTS client may acquire a list of 440 IPv4 and IPv6 addresses (Section 4.1), each of which can be used to 441 contact the DOTS server using UDP and TCP. The following specifies 442 the procedure to follow to select the address family and the 443 transport protocol for sending DOTS signal channel messages. 445 Such procedure is needed to avoid experiencing long connection 446 delays. For example, if an IPv4 path to reach a DOTS server is 447 functional, but the DOTS server's IPv6 path is non-functional, a 448 dual-stack DOTS client may experience a significant connection delay 449 compared to an IPv4-only DOTS client, in the same network conditions. 450 The other problem is that if a middlebox between the DOTS client and 451 DOTS server is configured to block UDP traffic, the DOTS client will 452 fail to establish a DTLS association with the DOTS server and, as a 453 consequence, will have to fall back to TLS over TCP, thereby 454 incurring significant connection delays. 456 To overcome these connection setup problems, the DOTS client attempts 457 to connect to its DOTS server(s) using both IPv6 and IPv4, and tries 458 both DTLS over UDP and TLS over TCP following a DOTS Happy Eyeballs 459 approach. To some extent, this approach is similar to the Happy 460 Eyeballs mechanism defined in [RFC8305]. The connection attempts are 461 performed by the DOTS client when it initializes, or in general when 462 it has to select an address family and transport to contact its DOTS 463 server. The results of the Happy Eyeballs procedure are used by the 464 DOTS client for sending its subsequent messages to the DOTS server. 465 The difference in behavior with respect to the Happy Eyeballs 466 mechanism [RFC8305] are listed below: 468 o The order of preference of the DOTS signal channel address family 469 and transport protocol (most preferred first) is: UDP over IPv6, 470 UDP over IPv4, TCP over IPv6, and finally TCP over IPv4. This 471 order adheres to the address preference order specified in 473 [RFC6724] and the DOTS signal channel preference which privileges 474 the use of UDP over TCP (to avoid TCP's head of line blocking). 476 o The DOTS client after successfully establishing a connection MUST 477 cache information regarding the outcome of each connection attempt 478 for a specific time period, and it uses that information to avoid 479 thrashing the network with subsequent attempts. The cached 480 information is flushed when its age exceeds a specific time period 481 on the order of few minutes (e.g., 10 mn). Typically, if the DOTS 482 client has to re-establish the connection with the same DOTS 483 server within few seconds after the Happy Eyeballs mechanism is 484 completed, caching avoids trashing the network especially in the 485 presence of DDoS attack traffic. 487 o If DOTS signal channel session is established with TLS (but DTLS 488 failed), the DOTS client periodically repeats the mechanism to 489 discover whether DOTS signal channel messages with DTLS over UDP 490 becomes available from the DOTS server, so the DOTS client can 491 migrate the DOTS signal channel from TCP to UDP. Such probing 492 SHOULD NOT be done more frequently than every 24 hours and MUST 493 NOT be done more frequently than every 5 minutes. 495 When connection attempts are made during an attack, the DOTS client 496 SHOULD use a "Connection Attempt Delay" [RFC8305] set to 100 ms. 498 In reference to Figure 4, the DOTS client proceeds with the 499 connection attempts following the rules in [RFC8305]. In this 500 example, it is assumed that the IPv6 path is broken and UDP traffic 501 is dropped by a middlebox but has little impact to the DOTS client 502 because there is no long delay before using IPv4 and TCP. 504 +-----------+ +-----------+ 505 |DOTS client| |DOTS server| 506 +-----------+ +-----------+ 507 | | 508 T0 |--DTLS ClientHello, IPv6 ---->X | 509 T1 |--DTLS ClientHello, IPv4 ---->X | 510 T2 |--TCP SYN, IPv6-------------->X | 511 T3 |--TCP SYN, IPv4--------------------------------------->| 512 |<-TCP SYNACK-------------------------------------------| 513 |--TCP ACK--------------------------------------------->| 514 |<------------Establish TLS Session-------------------->| 515 |----------------DOTS signal--------------------------->| 516 | | 518 Note: 519 * Retransmission messages are not shown. 520 * T1-T0=T2-T1=T3-T2= Connection Attempt Delay. 522 Figure 4: DOTS Happy Eyeballs (Sample Flow) 524 A single DOTS signal channel between DOTS agents can be used to 525 exchange multiple DOTS signal messages. To reduce DOTS client and 526 DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session. 528 4.4. DOTS Mitigation Methods 530 The following methods are used by a DOTS client to request, withdraw, 531 or retrieve the status of mitigation requests: 533 PUT: DOTS clients use the PUT method to request mitigation from a 534 DOTS server (Section 4.4.1). During active mitigation, DOTS 535 clients may use PUT requests to carry mitigation efficacy 536 updates to the DOTS server (Section 4.4.3). 538 GET: DOTS clients may use the GET method to subscribe to DOTS 539 server status messages, or to retrieve the list of its 540 mitigations maintained by a DOTS server (Section 4.4.2). 542 DELETE: DOTS clients use the DELETE method to withdraw a request for 543 mitigation from a DOTS server (Section 4.4.4). 545 Mitigation request and response messages are marked as Non- 546 confirmable messages (Section 2.2 of [RFC7252]). 548 DOTS agents MUST follow the data transmission guidelines discussed in 549 Section 3.1.3 of [RFC8085] and control transmission behavior by not 550 sending more than one UDP datagram per round-trip time (RTT) to the 551 peer DOTS agent on average. 553 Requests marked by the DOTS client as Non-confirmable messages are 554 sent at regular intervals until a response is received from the DOTS 555 server. If the DOTS client cannot maintain an RTT estimate, it MUST 556 NOT send more than one Non-confirmable request every 3 seconds, and 557 SHOULD use an even less aggressive rate whenever possible (case 2 in 558 Section 3.1.3 of [RFC8085]). 560 JSON encoding of YANG modelled data [RFC7951] is used to illustrate 561 the various methods defined in the following sub-sections. Also, the 562 examples use the Labels defined in Sections 9.6.2, 9.6.3, 9.6.4, and 563 9.6.5. 565 4.4.1. Request Mitigation 567 When a DOTS client requires mitigation for some reason, the DOTS 568 client uses the CoAP PUT method to send a mitigation request to its 569 DOTS server(s) (Figures 5 and 6). 571 If a DOTS client is entitled to solicit the DOTS service, the DOTS 572 server enables mitigation on behalf of the DOTS client by 573 communicating the DOTS client's request to a mitigator (which may be 574 co-located with the DOTS server) and relaying the feedback of the 575 thus-selected mitigator to the requesting DOTS client. 577 Header: PUT (Code=0.03) 578 Uri-Path: ".well-known" 579 Uri-Path: "dots" 580 Uri-Path: "mitigate" 581 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 582 Uri-Path: "mid=123" 583 Content-Format: "application/dots+cbor" 585 { 586 ... 587 } 589 Figure 5: PUT to Convey DOTS Mitigation Requests 591 The order of the Uri-Path options is important as it defines the CoAP 592 resource. In particular, 'mid' MUST follow 'cuid'. 594 The additional Uri-Path parameters to those defined in Section 4.2 595 are as follows: 597 cuid: Stands for Client Unique Identifier. A globally unique 598 identifier that is meant to prevent collisions among DOTS clients, 599 especially those from the same domain. It MUST be generated by 600 DOTS clients. 602 For the reasons discussed in Appendix A, implementations SHOULD 603 set 'cuid' to the output of a cryptographic hash algorithm whose 604 input is the Distinguished Encoding Rules (DER)-encoded Abstract 605 Syntax Notation One (ASN.1) representation of the Subject Public 606 Key Info (SPKI) of the DOTS client X.509 certificate [RFC5280], 607 the DOTS client raw public key [RFC7250], or the "Pre-Shared Key 608 (PSK) identity" used by the DOTS client in the TLS 609 ClientKeyExchange message. In this version of the specification, 610 the cryptographic hash algorithm used is SHA-256 [RFC6234]. The 611 output of the cryptographic hash algorithm is truncated to 16 612 bytes; truncation is done by stripping off the final 16 bytes. 613 The truncated output is base64url encoded (Section 5 of [RFC4648]) 614 with the trailing "=" removed from the encoding. 616 The 'cuid' is intended to be stable when communicating with a 617 given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD 618 NOT change over time. Distinct 'cuid' values MAY be used by a 619 single DOTS client per DOTS server. 621 If a DOTS client has to change its 'cuid' for some reason, it MUST 622 NOT do so when mitigations are still active for the old 'cuid'. 623 The 'cuid' SHOULD be 22 characters to avoid DOTS signal message 624 fragmentation over UDP. Furthermore, if that DOTS client created 625 aliases and filtering entries at the DOTS server by means of the 626 DOTS data channel, it MUST delete all the entries bound to the old 627 'cuid' and re-install them using the new 'cuid'. 629 DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer 630 to notify that the 'cuid' is already in-use by another DOTS 631 client. Upon receipt of that error code, a new 'cuid' MUST be 632 generated by the DOTS peer (e.g., using [RFC4122]). 634 Client-domain DOTS gateways MUST handle 'cuid' collision directly 635 and it is RECOMMENDED that 'cuid' collision is handled directly by 636 server-domain DOTS gateways. 638 DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. 639 Triggers for such rewriting are out of scope. 641 This is a mandatory Uri-Path parameter. 643 mid: Identifier for the mitigation request represented with an 644 integer. This identifier MUST be unique for each mitigation 645 request bound to the DOTS client, i.e., the 'mid' parameter value 646 in the mitigation request needs to be unique (per 'cuid' and DOTS 647 server) relative to the 'mid' parameter values of active 648 mitigation requests conveyed from the DOTS client to the DOTS 649 server. 651 In order to handle out-of-order delivery of mitigation requests, 652 'mid' values MUST increase monotonically. 654 If the 'mid' value has reached 3/4 of (2**32 - 1) (i.e., 655 3221225471) and no attack is detected, the DOTS client MUST reset 656 'mid' to 0 to handle 'mid' rollover. If the DOTS client maintains 657 mitigation requests with pre-configured scopes, it MUST re-create 658 them with the 'mid' restarting at 0. 660 This identifier MUST be generated by the DOTS client. 662 This is a mandatory Uri-Path parameter. 664 'cuid' and 'mid' MUST NOT appear in the PUT request message body 665 (Figure 6). The schema in Figure 6 uses the types defined in 666 Section 6. Note that this figure (and other similar figures 667 depicting a schema) are non-normative sketches of the structure of 668 the message. 670 { 671 "ietf-dots-signal-channel:mitigation-scope": { 672 "scope": [ 673 { 674 "target-prefix": [ 675 "string" 676 ], 677 "target-port-range": [ 678 { 679 "lower-port": number, 680 "upper-port": number 681 } 682 ], 683 "target-protocol": [ 684 number 685 ], 686 "target-fqdn": [ 687 "string" 688 ], 689 "target-uri": [ 690 "string" 691 ], 692 "alias-name": [ 693 "string" 694 ], 695 "lifetime": number, 696 "trigger-mitigation": true|false 697 } 698 ] 699 } 700 } 702 Figure 6: PUT to Convey DOTS Mitigation Requests (Message Body 703 Schema) 705 The parameters in the CBOR body (Figure 6) of the PUT request are 706 described below: 708 target-prefix: A list of prefixes identifying resources under 709 attack. Prefixes are represented using Classless Inter-Domain 710 Routing (CIDR) notation [RFC4632]. 711 As a reminder, the prefix length must be less than or equal to 32 712 (or 128) for IPv4 (or IPv6). 714 The prefix list MUST NOT include broadcast, loopback, or multicast 715 addresses. These addresses are considered as invalid values. In 716 addition, the DOTS server MUST validate that target prefixes are 717 within the scope of the DOTS client domain. Other validation 718 checks may be supported by DOTS servers. 720 This is an optional attribute. 722 target-port-range: A list of port numbers bound to resources under 723 attack. 725 A port range is defined by two bounds, a lower port number (lower- 726 port) and an upper port number (upper-port). When only 'lower- 727 port' is present, it represents a single port number. 729 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 730 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 731 [RFC4340], a range of ports can be, for example, 0-1023, 732 1024-65535, or 1024-49151. 734 This is an optional attribute. 736 target-protocol: A list of protocols involved in an attack. Values 737 are taken from the IANA protocol registry [proto_numbers]. 739 If 'target-protocol' is not specified, then the request applies to 740 any protocol. 742 This is an optional attribute. 744 target-fqdn: A list of Fully Qualified Domain Names (FQDNs) 745 identifying resources under attack [RFC8499]. 747 How a name is passed to an underlying name resolution library is 748 implementation- and deployment-specific. Nevertheless, once the 749 name is resolved into one or multiple IP addresses, DOTS servers 750 MUST apply the same validation checks as those for 'target- 751 prefix'. 753 The use of FQDNs may be suboptimal because: 755 * It induces both an extra load and increased delays on the DOTS 756 server to handle and manage DNS resolution requests. 758 * It does not guarantee that the DOTS server will resolve a name 759 to the same IP addresses that the DOTS client does. 761 This is an optional attribute. 763 target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986] 764 identifying resources under attack. 766 The same validation checks used for 'target-fqdn' MUST be followed 767 by DOTS servers to validate a target URI. 769 This is an optional attribute. 771 alias-name: A list of aliases of resources for which the mitigation 772 is requested. Aliases can be created using the DOTS data channel 773 (Section 6.1 of [I-D.ietf-dots-data-channel]), direct 774 configuration, or other means. 776 An alias is used in subsequent signal channel exchanges to refer 777 more efficiently to the resources under attack. 779 This is an optional attribute. 781 lifetime: Lifetime of the mitigation request in seconds. The 782 RECOMMENDED lifetime of a mitigation request is 3600 seconds -- 783 this value was chosen to be long enough so that refreshing is not 784 typically a burden on the DOTS client, while still making the 785 request expire in a timely manner when the client has unexpectedly 786 quit. DOTS clients MUST include this parameter in their 787 mitigation requests. Upon the expiry of this lifetime, and if the 788 request is not refreshed, the mitigation request is removed. The 789 request can be refreshed by sending the same request again. 791 A lifetime of '0' in a mitigation request is an invalid value. 793 A lifetime of negative one (-1) indicates indefinite lifetime for 794 the mitigation request. The DOTS server MAY refuse indefinite 795 lifetime, for policy reasons; the granted lifetime value is 796 returned in the response. DOTS clients MUST be prepared to not be 797 granted mitigations with indefinite lifetimes. 799 The DOTS server MUST always indicate the actual lifetime in the 800 response and the remaining lifetime in status messages sent to the 801 DOTS client. 803 This is a mandatory attribute. 805 trigger-mitigation: If the parameter value is set to 'false', DDoS 806 mitigation will not be triggered for the mitigation request unless 807 the DOTS signal channel session is lost. 809 If the DOTS client ceases to respond to heartbeat messages, the 810 DOTS server can detect that the DOTS signal channel session is 811 lost. More details are discussed in Section 4.7. 813 The default value of the parameter is 'true' (that is, the 814 mitigation starts immediately). If 'trigger-mitigation' is not 815 present in a request, this is equivalent to receiving a request 816 with 'trigger-mitigation' set to 'true'. 818 This is an optional attribute. 820 In deployments where server-domain DOTS gateways are enabled, 821 identity information about the origin source client domain ('cdid') 822 SHOULD be propagated to the DOTS server. That information is meant 823 to assist the DOTS server to enforce some policies such as grouping 824 DOTS clients that belong to the same DOTS domain, limiting the number 825 of DOTS requests, and identifying the mitigation scope. These 826 policies can be enforced per-client, per-client domain, or both. 827 Also, the identity information may be used for auditing and debugging 828 purposes. 830 Figure 7 shows an example of a request relayed by a server-domain 831 DOTS gateway. 833 Header: PUT (Code=0.03) 834 Uri-Path: ".well-known" 835 Uri-Path: "dots" 836 Uri-Path: "mitigate" 837 Uri-Path: "cdid=7eeaf349529eb55ed50113" 838 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 839 Uri-Path: "mid=123" 840 Content-Format: "application/dots+cbor" 842 { 843 ... 844 } 846 Figure 7: PUT for DOTS Mitigation Request as Relayed by a DOTS 847 Gateway 849 A server-domain DOTS gateway SHOULD add the following Uri-Path 850 parameter: 852 cdid: Stands for Client Domain Identifier. The 'cdid' is conveyed 853 by a server-domain DOTS gateway to propagate the source domain 854 identity from the gateway's client-facing-side to the gateway's 855 server-facing-side, and from the gateway's server-facing-side to 856 the DOTS server. 'cdid' may be used by the final DOTS server for 857 policy enforcement purposes (e.g., enforce a quota on filtering 858 rules). These policies are deployment-specific. 860 Server-domain DOTS gateways SHOULD support a configuration option 861 to instruct whether 'cdid' parameter is to be inserted. 863 In order to accommodate deployments that require enforcing per- 864 client policies, per-client domain policies, or a combination 865 thereof, server-domain DOTS gateways instructed to insert the 866 'cdid' parameter MUST supply the SPKI hash of the DOTS client 867 X.509 certificate, the DOTS client raw public key, or the hash of 868 the "PSK identity" in the 'cdid', following the same rules for 869 generating the hash conveyed in 'cuid', which is then used by the 870 ultimate DOTS server to determine the corresponding client's 871 domain. The 'cdid' generated by a server-domain gateway is likely 872 to be the same as the 'cuid' except if the DOTS message was 873 relayed by a client-domain DOTS gateway or the 'cuid' was 874 generated from a rogue DOTS client. 876 If a DOTS client is provisioned, for example, with distinct 877 certificates as a function of the peer server-domain DOTS gateway, 878 distinct 'cdid' values may be supplied by a server-domain DOTS 879 gateway. The ultimate DOTS server MUST treat those 'cdid' values 880 as equivalent. 882 The 'cdid' attribute MUST NOT be generated and included by DOTS 883 clients. 885 DOTS servers MUST ignore 'cdid' attributes that are directly 886 supplied by source DOTS clients or client-domain DOTS gateways. 887 This implies that first server-domain DOTS gateways MUST strip 888 'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD 889 support a configuration parameter to identify DOTS gateways that 890 are trusted to supply 'cdid' attributes. 892 Only single-valued 'cdid' are defined in this document. That is, 893 only the first on-path server-domain DOTS gateway can insert a 894 'cdid' value. This specification does not allow multiple server- 895 domain DOTS gateways, whenever involved in the path, to insert a 896 'cdid' value for each server-domain gateway. 898 This is an optional Uri-Path. When present, 'cdid' MUST be 899 positioned before 'cuid'. 901 A DOTS gateway MAY add the CoAP Hop-Limit Option 902 [I-D.ietf-core-hop-limit]. 904 Because of the complexity to handle partial failure cases, this 905 specification does not allow for including multiple mitigation 906 requests in the same PUT request. Concretely, a DOTS client MUST NOT 907 include multiple entries in the 'scope' array of the same PUT 908 request. 910 FQDN and URI mitigation scopes may be thought of as a form of scope 911 alias, in which the addresses associated with the domain name or URI 912 (as resolved by the DOTS server) represent the scope of the 913 mitigation. Particularly, the IP addresses to which the host 914 subcomponent of authority component of an URI resolves represent the 915 'target-prefix', the URI scheme represents the 'target-protocol', the 916 port subcomponent of authority component of an URI represents the 917 'target-port-range'. If the optional port information is not present 918 in the authority component, the default port defined for the URI 919 scheme represents the 'target-port'. 921 In the PUT request at least one of the attributes 'target-prefix', 922 'target-fqdn','target-uri', or 'alias-name' MUST be present. 924 Attributes and Uri-Path parameters with empty values MUST NOT be 925 present in a request and render the entire request invalid. 927 Figure 8 shows a PUT request example to signal that TCP port numbers 928 80, 8080, and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 929 servers are under attack. The presence of 'cdid' indicates that a 930 server-domain DOTS gateway has modified the initial PUT request sent 931 by the DOTS client. Note that 'cdid' MUST NOT appear in the PUT 932 request message body. 934 Header: PUT (Code=0.03) 935 Uri-Path: ".well-known" 936 Uri-Path: "dots" 937 Uri-Path: "mitigate" 938 Uri-Path: "cdid=7eeaf349529eb55ed50113" 939 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 940 Uri-Path: "mid=123" 941 Content-Format: "application/dots+cbor" 943 { 944 "ietf-dots-signal-channel:mitigation-scope": { 945 "scope": [ 946 { 947 "target-prefix": [ 948 "2001:db8:6401::1/128", 949 "2001:db8:6401::2/128" 950 ], 951 "target-port-range": [ 952 { 953 "lower-port": 80 954 }, 955 { 956 "lower-port": 443 957 }, 958 { 959 "lower-port": 8080 960 } 961 ], 962 "target-protocol": [ 963 6 964 ], 965 "lifetime": 3600 966 } 967 ] 968 } 969 } 971 Figure 8: PUT for DOTS Mitigation Request (An Example) 973 The corresponding CBOR encoding format for the payload is shown in 974 Figure 9. 976 A1 # map(1) 977 01 # unsigned(1) 978 A1 # map(1) 979 02 # unsigned(2) 980 81 # array(1) 981 A3 # map(3) 982 06 # unsigned(6) 983 82 # array(2) 984 74 # text(20) 985 323030313A6462383A363430313A3A312F313238 986 74 # text(20) 987 323030313A6462383A363430313A3A322F313238 988 07 # unsigned(7) 989 83 # array(3) 990 A1 # map(1) 991 08 # unsigned(8) 992 18 50 # unsigned(80) 993 A1 # map(1) 994 08 # unsigned(8) 995 19 01BB # unsigned(443) 996 A1 # map(1) 997 08 # unsigned(8) 998 19 1F90 # unsigned(8080) 999 0A # unsigned(10) 1000 81 # array(1) 1001 06 # unsigned(6) 1002 0E # unsigned(14) 1003 19 0E10 # unsigned(3600) 1005 Figure 9: PUT for DOTS Mitigation Request (CBOR) 1007 In both DOTS signal and data channel sessions, the DOTS client MUST 1008 authenticate itself to the DOTS server (Section 8). The DOTS server 1009 MAY use the algorithm presented in Section 7 of [RFC7589] to derive 1010 the DOTS client identity or username from the client certificate. 1011 The DOTS client identity allows the DOTS server to accept mitigation 1012 requests with scopes that the DOTS client is authorized to manage. 1014 The DOTS server couples the DOTS signal and data channel sessions 1015 using the DOTS client identity and optionally the 'cdid' parameter 1016 value, so the DOTS server can validate whether the aliases conveyed 1017 in the mitigation request were indeed created by the same DOTS client 1018 using the DOTS data channel session. If the aliases were not created 1019 by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in 1020 the response. 1022 The DOTS server couples the DOTS signal channel sessions using the 1023 DOTS client identity and optionally the 'cdid' parameter value, and 1024 the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to 1025 detect duplicate mitigation requests. If the mitigation request 1026 contains the 'alias-name' and other parameters identifying the target 1027 resources (such as 'target-prefix', 'target-port-range', 'target- 1028 fqdn', or 'target-uri'), the DOTS server appends the parameter values 1029 in 'alias-name' with the corresponding parameter values in 'target- 1030 prefix', 'target-port-range', 'target-fqdn', or 'target-uri'. 1032 The DOTS server indicates the result of processing the PUT request 1033 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 1034 codes are some sort of invalid requests (client errors). COAP 5.xx 1035 codes are returned if the DOTS server is in an error state or is 1036 currently unavailable to provide mitigation in response to the 1037 mitigation request from the DOTS client. 1039 Figure 10 shows an example response to a PUT request that is 1040 successfully processed by a DOTS server (i.e., CoAP 2.xx response 1041 codes). This version of the specification forbids 'cuid' and 'cdid' 1042 (if used) to be returned in a response message body. 1044 { 1045 "ietf-dots-signal-channel:mitigation-scope": { 1046 "scope": [ 1047 { 1048 "mid": 123, 1049 "lifetime": 3600 1050 } 1051 ] 1052 } 1053 } 1055 Figure 10: 2.xx Response Body 1057 If the request is missing a mandatory attribute, does not include 1058 'cuid' or 'mid' Uri-Path options, includes multiple 'scope' 1059 parameters, or contains invalid or unknown parameters, the DOTS 1060 server MUST reply with 4.00 (Bad Request). DOTS agents can safely 1061 ignore comprehension-optional parameters they don't understand 1062 (Section 9.6.1.1). 1064 A DOTS server that receives a mitigation request with a lifetime set 1065 to '0' MUST reply with a 4.00 (Bad Request). 1067 If the DOTS server does not find the 'mid' parameter value conveyed 1068 in the PUT request in its configuration data, it MAY accept the 1069 mitigation request by sending back a 2.01 (Created) response to the 1070 DOTS client; the DOTS server will consequently try to mitigate the 1071 attack. A DOTS server could reject mitigation requests when it is 1072 near capacity or needs to rate-limit a particular client, for 1073 example. 1075 The relative order of two mitigation requests, having the same 1076 'trigger-mitigation' type, from a DOTS client is determined by 1077 comparing their respective 'mid' values. If two mitigation requests 1078 with the same 'trigger-mitigation' type have overlapping mitigation 1079 scopes, the mitigation request with the highest numeric 'mid' value 1080 will override the other mitigation request. Two mitigation requests 1081 from a DOTS client have overlapping scopes if there is a common IP 1082 address, IP prefix, FQDN, URI, or alias-name. To avoid maintaining a 1083 long list of overlapping mitigation requests (i.e., requests with the 1084 same 'trigger-mitigation' type and overlapping scopes) from a DOTS 1085 client and avoid error-prone provisioning of mitigation requests from 1086 a DOTS client, the overlapped lower numeric 'mid' MUST be 1087 automatically deleted and no longer available at the DOTS server. 1088 For example, if the DOTS server receives a mitigation request which 1089 overlaps with an existing mitigation with a higher numeric 'mid', the 1090 DOTS server rejects the request by returning 4.09 (Conflict) to the 1091 DOTS client. The response includes enough information for a DOTS 1092 client to recognize the source of the conflict as described below in 1093 the 'conflict-information' subtree with only the relevant nodes 1094 listed: 1096 conflict-information: Indicates that a mitigation request is 1097 conflicting with another mitigation request. This optional 1098 attribute has the following structure: 1100 conflict-cause: Indicates the cause of the conflict. The 1101 following values are defined: 1103 1: Overlapping targets. 'conflict-scope' provides more details 1104 about the conflicting target clauses. 1106 conflict-scope: Characterizes the exact conflict scope. It may 1107 include a list of IP addresses, a list of prefixes, a list of 1108 port numbers, a list of target protocols, a list of FQDNs, a 1109 list of URIs, a list of alias-names, or a 'mid'. 1111 If the DOTS server receives a mitigation request which overlaps with 1112 an active mitigation request, but both having distinct 'trigger- 1113 mitigation' types, the DOTS server SHOULD deactivate (absent explicit 1114 policy/configuration otherwise) the mitigation request with 'trigger- 1115 mitigation' set to false. Particularly, if the mitigation request 1116 with 'trigger-mitigation' set to false is active, the DOTS server 1117 withdraws the mitigation request (i.e., status code is set to '7' as 1118 defined in Table 2) and transitions the status of the mitigation 1119 request to '8'. 1121 Upon DOTS signal channel session loss with a peer DOTS client, the 1122 DOTS server SHOULD withdraw (absent explicit policy/configuration 1123 otherwise) any active mitigation requests overlapping with mitigation 1124 requests having 'trigger-mitigation' set to false from that DOTS 1125 client, as the loss of the session implictily activates these 1126 preconfigured mitigation requests and they take precedence. Note 1127 that active-but-terminating period is not observed for mitigations 1128 withdrawn at the initiative of the DOTS server. 1130 DOTS clients may adopt various strategies for setting the scopes of 1131 immediate and pre-configured mitigation requests to avoid potential 1132 conflicts. For example, a DOTS client may tweak pre-configured 1133 scopes so that the scope of any overlapping immediate mitigation 1134 request will be a subset of the pre-configured scopes. Also, if an 1135 immediate mitigation request overlaps with any of the pre-configured 1136 scopes, the DOTS client sets the scope of the overlapping immediate 1137 mitigation request to be a subset of the pre-configured scopes, so as 1138 to get a broad mitigation when the DOTS signal channel collapses and 1139 maximize the chance of recovery. 1141 If the request is conflicting with an existing mitigation request 1142 from a different DOTS client, the DOTS server may return 2.01 1143 (Created) or 4.09 (Conflict) to the requesting DOTS client. If the 1144 DOTS server decides to maintain the new mitigation request, the DOTS 1145 server returns 2.01 (Created) to the requesting DOTS client. If the 1146 DOTS server decides to reject the new mitigation request, the DOTS 1147 server returns 4.09 (Conflict) to the requesting DOTS client. For 1148 both 2.01 (Created) and 4.09 (Conflict) responses, the response 1149 includes enough information for a DOTS client to recognize the source 1150 of the conflict as described below: 1152 conflict-information: Indicates that a mitigation request is 1153 conflicting with another mitigation request(s) from other DOTS 1154 client(s). This optional attribute has the following structure: 1156 conflict-status: Indicates the status of a conflicting mitigation 1157 request. The following values are defined: 1159 1: DOTS server has detected conflicting mitigation requests 1160 from different DOTS clients. This mitigation request is 1161 currently inactive until the conflicts are resolved. 1162 Another mitigation request is active. 1164 2: DOTS server has detected conflicting mitigation requests 1165 from different DOTS clients. This mitigation request is 1166 currently active. 1168 3: DOTS server has detected conflicting mitigation requests 1169 from different DOTS clients. All conflicting mitigation 1170 requests are inactive. 1172 conflict-cause: Indicates the cause of the conflict. The 1173 following values are defined: 1175 1: Overlapping targets. 'conflict-scope' provides more details 1176 about the conflicting target clauses. 1178 2: Conflicts with an existing accept-list. This code is 1179 returned when the DDoS mitigation detects source addresses/ 1180 prefixes in the accept-listed ACLs are attacking the 1181 target. 1183 3: CUID Collision. This code is returned when a DOTS client 1184 uses a 'cuid' that is already used by another DOTS client. 1185 This code is an indication that the request has been 1186 rejected and a new request with a new 'cuid' is to be re- 1187 sent by the DOTS client (see the example shown in 1188 Figure 11). Note that 'conflict-status', 'conflict-scope', 1189 and 'retry-timer' MUST NOT be returned in the error 1190 response. 1192 conflict-scope: Characterizes the exact conflict scope. It may 1193 include a list of IP addresses, a list of prefixes, a list of 1194 port numbers, a list of target protocols, a list of FQDNs, a 1195 list of URIs, a list of alias-names, or references to 1196 conflicting ACLs (by an 'acl-name', typically 1197 [I-D.ietf-dots-data-channel]). 1199 retry-timer: Indicates, in seconds, the time after which the DOTS 1200 client may re-issue the same request. The DOTS server returns 1201 'retry-timer' only to DOTS client(s) for which a mitigation 1202 request is deactivated. Any retransmission of the same 1203 mitigation request before the expiry of this timer is likely to 1204 be rejected by the DOTS server for the same reasons. 1206 The retry-timer SHOULD be equal to the lifetime of the active 1207 mitigation request resulting in the deactivation of the 1208 conflicting mitigation request. 1210 If the DOTS server decides to maintain a state for the 1211 deactivated mitigation request, the DOTS server updates the 1212 lifetime of the deactivated mitigation request to (retry-timer 1213 + 45 seconds), so that the DOTS client can refresh the 1214 deactivated mitigation request after 'retry-timer' seconds, but 1215 before the expiry of the lifetime, and check if the conflict is 1216 resolved. 1218 Header: PUT (Code=0.03) 1219 Uri-Path: ".well-known" 1220 Uri-Path: "dots" 1221 Uri-Path: "mitigate" 1222 Uri-Path: "cuid=7eeaf349529eb55ed50113" 1223 Uri-Path: "mid=12" 1225 (1) Request with a conflicting 'cuid' 1227 { 1228 "ietf-dots-signal-channel:mitigation-scope": { 1229 "scope": [ 1230 { 1231 "conflict-information": { 1232 "conflict-cause": "cuid-collision" 1233 } 1234 } 1235 ] 1236 } 1237 } 1239 (2) Message body of the 4.09 (Conflict) response 1240 from the DOTS server 1242 Header: PUT (Code=0.03) 1243 Uri-Path: ".well-known" 1244 Uri-Path: "dots" 1245 Uri-Path: "mitigate" 1246 Uri-Path: "cuid=f30d281ce6b64fc5a0b91e" 1247 Uri-Path: "mid=12" 1249 (3) Request with a new 'cuid' 1251 Figure 11: Example of Generating a New 'cuid' 1253 As an active attack evolves, DOTS clients can adjust the scope of 1254 requested mitigation as necessary, by refining the scope of resources 1255 requiring mitigation. This can be achieved by sending a PUT request 1256 with a new 'mid' value that will override the existing one with 1257 overlapping mitigation scopes. 1259 For a mitigation request to continue beyond the initial negotiated 1260 lifetime, the DOTS client has to refresh the current mitigation 1261 request by sending a new PUT request. This PUT request MUST use the 1262 same 'mid' value, and MUST repeat all the other parameters as sent in 1263 the original mitigation request apart from a possible change to the 1264 lifetime parameter value. In such case, the DOTS server MAY update 1265 the mitigation request, and a 2.04 (Changed) response is returned to 1266 indicate a successful update of the mitigation request. If this is 1267 not the case, the DOTS server MUST reject the request with a 4.00 1268 (Bad Request). 1270 4.4.2. Retrieve Information Related to a Mitigation 1272 A GET request is used by a DOTS client to retrieve information 1273 (including status) of DOTS mitigations from a DOTS server. 1275 'cuid' is a mandatory Uri-Path parameter for GET requests. 1277 Uri-Path parameters with empty values MUST NOT be present in a 1278 request. 1280 The same considerations for manipulating 'cdid' parameter by server- 1281 domain DOTS gateways specified in Section 4.4.1 MUST be followed for 1282 GET requests. 1284 The 'c' Uri-Query option is used to control selection of 1285 configuration and non-configuration data nodes. Concretely, the 'c' 1286 (content) parameter and its permitted values defined in the following 1287 table [I-D.ietf-core-comi] can be used to retrieve non-configuration 1288 data (attack mitigation status), configuration data, or both. The 1289 DOTS server MAY support this optional filtering capability. It can 1290 safely ignore it if not supported. If the DOTS client supports the 1291 optional filtering capability, it SHOULD use "c=n" query (to get back 1292 only the dynamically changing data) or "c=c" query (to get back the 1293 static configuration values) when the DDoS attack is active to limit 1294 the size of the response. 1296 +-------+-----------------------------------------------------+ 1297 | Value | Description | 1298 +-------+-----------------------------------------------------+ 1299 | c | Return only configuration descendant data nodes | 1300 | n | Return only non-configuration descendant data nodes | 1301 | a | Return all descendant data nodes | 1302 +-------+-----------------------------------------------------+ 1304 The DOTS client can use Block-wise transfer [RFC7959] to get the list 1305 of all its mitigations maintained by a DOTS server, it can send 1306 Block2 Option in a GET request with NUM = 0 to aid in limiting the 1307 size of the response. If the representation of all the active 1308 mitigation requests associated with the DOTS client does not fit 1309 within a single datagram, the DOTS server MUST use the Block2 Option 1310 with NUM = 0 in the GET response. The Size2 Option may be conveyed 1311 in the response to indicate the total size of the resource 1312 representation. The DOTS client retrieves the rest of the 1313 representation by sending additional GET requests with Block2 Options 1314 containing NUM values greater than zero. The DOTS client MUST adhere 1315 to the block size preferences indicated by the DOTS server in the 1316 response. If the DOTS server uses the Block2 Option in the GET 1317 response and the response is for a dynamically changing resource 1318 (e.g. "c=n" or "c=a" query), the DOTS server MUST include the ETag 1319 Option in the response. The DOTS client MUST include the same ETag 1320 value in subsequent GET requests to retrieve the rest of the 1321 representation. 1323 The following examples illustrate how a DOTS client retrieves active 1324 mitigation requests from a DOTS server. In particular: 1326 o Figure 12 shows the example of a GET request to retrieve all DOTS 1327 mitigation requests signaled by a DOTS client. 1329 o Figure 13 shows the example of a GET request to retrieve a 1330 specific DOTS mitigation request signaled by a DOTS client. The 1331 configuration data to be reported in the response is formatted in 1332 the same order as was processed by the DOTS server in the original 1333 mitigation request. 1335 These two examples assume the default of "c=a"; that is, the DOTS 1336 client asks for all data to be reported by the DOTS server. 1338 Header: GET (Code=0.01) 1339 Uri-Path: ".well-known" 1340 Uri-Path: "dots" 1341 Uri-Path: "mitigate" 1342 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1343 Observe: 0 1345 Figure 12: GET to Retrieve all DOTS Mitigation Requests 1347 Header: GET (Code=0.01) 1348 Uri-Path: ".well-known" 1349 Uri-Path: "dots" 1350 Uri-Path: "mitigate" 1351 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1352 Uri-Path: "mid=12332" 1353 Observe: 0 1355 Figure 13: GET to Retrieve a Specific DOTS Mitigation Request 1357 If the DOTS server does not find the 'mid' Uri-Path value conveyed in 1358 the GET request in its configuration data for the requesting DOTS 1359 client, it MUST respond with a 4.04 (Not Found) error response code. 1360 Likewise, the same error MUST be returned as a response to a request 1361 to retrieve all mitigation records (i.e., 'mid' Uri-Path is not 1362 defined) of a given DOTS client if the DOTS server does not find any 1363 mitigation record for that DOTS client. As a reminder, a DOTS client 1364 is identified by its identity (e.g., client certificate, 'cuid') and 1365 optionally the 'cdid'. 1367 Figure 14 shows a response example of all active mitigation requests 1368 associated with the DOTS client as maintained by the DOTS server. 1369 The response indicates the mitigation status of each mitigation 1370 request. 1372 { 1373 "ietf-dots-signal-channel:mitigation-scope": { 1374 "scope": [ 1375 { 1376 "mid": 12332, 1377 "mitigation-start": "1507818434", 1378 "target-prefix": [ 1379 "2001:db8:6401::1/128", 1380 "2001:db8:6401::2/128" 1381 ], 1382 "target-protocol": [ 1383 17 1384 ], 1385 "lifetime": 1756, 1386 "status": "attack-successfully-mitigated", 1387 "bytes-dropped": "134334555", 1388 "bps-dropped": "43344", 1389 "pkts-dropped": "333334444", 1390 "pps-dropped": "432432" 1391 }, 1392 { 1393 "mid": 12333, 1394 "mitigation-start": "1507818393", 1395 "target-prefix": [ 1396 "2001:db8:6401::1/128", 1397 "2001:db8:6401::2/128" 1398 ], 1399 "target-protocol": [ 1400 6 1401 ], 1402 "lifetime": 1755, 1403 "status": "attack-stopped", 1404 "bytes-dropped": "0", 1405 "bps-dropped": "0", 1406 "pkts-dropped": "0", 1407 "pps-dropped": "0" 1408 } 1409 ] 1410 } 1411 } 1413 Figure 14: Response Body to a GET Request 1415 The mitigation status parameters are described below: 1417 mitigation-start: Mitigation start time is expressed in seconds 1418 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 1420 [RFC7049]). The CBOR encoding is modified so that the leading tag 1421 1 (epoch-based date/time) MUST be omitted. 1423 This is a mandatory attribute when an attack mitigation is active. 1424 Particularly, 'mitigation-start' is not returned for a mitigation 1425 with 'status' code set to 8. 1427 lifetime: The remaining lifetime of the mitigation request, in 1428 seconds. 1430 This is a mandatory attribute. 1432 status: Status of attack mitigation. The various possible values of 1433 'status' parameter are explained in Table 2. 1435 This is a mandatory attribute. 1437 bytes-dropped: The total dropped byte count for the mitigation 1438 request since the attack mitigation is triggered. The count wraps 1439 around when it reaches the maximum value of unsigned integer64. 1441 This is an optional attribute. 1443 bps-dropped: The average number of dropped bytes per second for the 1444 mitigation request since the attack mitigation is triggered. This 1445 average SHOULD be over five-minute intervals (that is, measuring 1446 bytes into five-minute buckets and then averaging these buckets 1447 over the time since the mitigation was triggered). 1449 This is an optional attribute. 1451 pkts-dropped: The total number of dropped packet count for the 1452 mitigation request since the attack mitigation is triggered. The 1453 count wraps around when it reaches the maximum value of unsigned 1454 integer64. 1456 This is an optional attribute. 1458 pps-dropped: The average number of dropped packets per second for 1459 the mitigation request since the attack mitigation is triggered. 1460 This average SHOULD be over five-minute intervals (that is, 1461 measuring packets into five-minute buckets and then averaging 1462 these buckets over the time since the mitigation was triggered). 1464 This is an optional attribute. 1466 +-----------+-------------------------------------------------------+ 1467 | Parameter | Description | 1468 | Value | | 1469 +-----------+-------------------------------------------------------+ 1470 | 1 | Attack mitigation setup is in progress (e.g., | 1471 | | changing the network path to redirect the inbound | 1472 | | traffic to a DOTS mitigator). | 1473 +-----------+-------------------------------------------------------+ 1474 | 2 | Attack is being successfully mitigated (e.g., traffic | 1475 | | is redirected to a DDoS mitigator and attack traffic | 1476 | | is dropped). | 1477 +-----------+-------------------------------------------------------+ 1478 | 3 | Attack has stopped and the DOTS client can withdraw | 1479 | | the mitigation request. This status code will be | 1480 | | transmitted for immediate mitigation requests till | 1481 | | the mitigation is withdrawn or the lifetime expires. | 1482 | | For mitigation requests with pre-configured scopes | 1483 | | (i.e., 'trigger-mitigation' set to 'false'), this | 1484 | | status code will be transmitted 4 times and then | 1485 | | transition to "8". | 1486 +-----------+-------------------------------------------------------+ 1487 | 4 | Attack has exceeded the mitigation provider | 1488 | | capability. | 1489 +-----------+-------------------------------------------------------+ 1490 | 5 | DOTS client has withdrawn the mitigation request and | 1491 | | the mitigation is active but terminating. | 1492 +-----------+-------------------------------------------------------+ 1493 | 6 | Attack mitigation is now terminated. | 1494 +-----------+-------------------------------------------------------+ 1495 | 7 | Attack mitigation is withdrawn (by the DOTS server). | 1496 | | If a mitigation request with 'trigger-mitigation' set | 1497 | | to false is withdrawn because it overlaps with an | 1498 | | immediate mitigation request, this status code will | 1499 | | be transmitted 4 times and then transition to "8" for | 1500 | | the mitigation request with pre-configured scopes. | 1501 +-----------+-------------------------------------------------------+ 1502 | 8 | Attack mitigation will be triggered for the | 1503 | | mitigation request only when the DOTS signal channel | 1504 | | session is lost. | 1505 +-----------+-------------------------------------------------------+ 1507 Table 2: Values of 'status' Parameter 1509 4.4.2.1. DOTS Servers Sending Mitigation Status 1511 The Observe Option defined in [RFC7641] extends the CoAP core 1512 protocol with a mechanism for a CoAP client to "observe" a resource 1513 on a CoAP server: The client retrieves a representation of the 1514 resource and requests this representation be updated by the server as 1515 long as the client is interested in the resource. DOTS 1516 implementations MUST use the Observe Option for both 'mitigate' and 1517 'config' (Section 4.2). 1519 A DOTS client conveys the Observe Option set to '0' in the GET 1520 request to receive asynchronous notifications of attack mitigation 1521 status from the DOTS server. 1523 Unidirectional mitigation notifications within the bidirectional 1524 signal channel enables asynchronous notifications between the agents. 1525 [RFC7641] indicates that (1) a notification can be sent in a 1526 Confirmable or a Non-confirmable message, and (2) the message type 1527 used is typically application-dependent and may be determined by the 1528 server for each notification individually. For DOTS server 1529 application, the message type MUST always be set to Non-confirmable 1530 even if the underlying COAP library elects a notification to be sent 1531 in a Confirmable message. 1533 Due to the higher likelihood of packet loss during a DDoS attack, the 1534 DOTS server periodically sends attack mitigation status to the DOTS 1535 client and also notifies the DOTS client whenever the status of the 1536 attack mitigation changes. If the DOTS server cannot maintain an RTT 1537 estimate, it MUST NOT send more than one asynchronous notification 1538 every 3 seconds, and SHOULD use an even less aggressive rate whenever 1539 possible (case 2 in Section 3.1.3 of [RFC8085]). 1541 When conflicting requests are detected, the DOTS server enforces the 1542 corresponding policy (e.g., accept all requests, reject all requests, 1543 accept only one request but reject all the others, ...). It is 1544 assumed that this policy is supplied by the DOTS server administrator 1545 or it is a default behavior of the DOTS server implementation. Then, 1546 the DOTS server sends notification message(s) to the DOTS client(s) 1547 at the origin of the conflict (refer to the conflict parameters 1548 defined in Section 4.4.1). A conflict notification message includes 1549 information about the conflict cause, scope, and the status of the 1550 mitigation request(s). For example, 1552 o A notification message with 'status' code set to '7 (Attack 1553 mitigation is withdrawn)' and 'conflict-status' set to '1' is sent 1554 to a DOTS client to indicate that an active mitigation request is 1555 deactivated because a conflict is detected. 1557 o A notification message with 'status' code set to '1 (Attack 1558 mitigation is in progress)' and 'conflict-status' set to '2' is 1559 sent to a DOTS client to indicate that this mitigation request is 1560 in progress, but a conflict is detected. 1562 Upon receipt of a conflict notification message indicating that a 1563 mitigation request is deactivated because of a conflict, a DOTS 1564 client MUST NOT resend the same mitigation request before the expiry 1565 of 'retry-timer'. It is also recommended that DOTS clients support 1566 means to alert administrators about mitigation conflicts. 1568 A DOTS client that is no longer interested in receiving notifications 1569 from the DOTS server can simply "forget" the observation. When the 1570 DOTS server sends the next notification, the DOTS client will not 1571 recognize the token in the message and thus will return a Reset 1572 message. This causes the DOTS server to remove the associated entry. 1573 Alternatively, the DOTS client can explicitly deregister itself by 1574 issuing a GET request that has the Token field set to the token of 1575 the observation to be cancelled and includes an Observe Option with 1576 the value set to '1' (deregister). The latter is RECOMMENDED. 1578 Figure 15 shows an example of a DOTS client requesting a DOTS server 1579 to send notifications related to a mitigation request. Note that for 1580 mitigations with pre-configured scopes (i.e., 'trigger-mitigation' 1581 set to 'false'), the state will need to transition from 3 (attack- 1582 stopped) to 8 (attack-mitigation-signal-loss). 1584 +-----------+ +-----------+ 1585 |DOTS client| |DOTS server| 1586 +-----------+ +-----------+ 1587 | | 1588 | GET / | 1589 | Token: 0x4a | Registration 1590 | Observe: 0 | 1591 +----------------------------------------->| 1592 | | 1593 | 2.05 Content | 1594 | Token: 0x4a | Notification of 1595 | Observe: 12 | the current state 1596 | status: "attack-mitigation-in-progress" | 1597 | | 1598 |<-----------------------------------------+ 1599 | 2.05 Content | 1600 | Token: 0x4a | Notification upon 1601 | Observe: 44 | a state change 1602 | status: "attack-successfully-mitigated" | 1603 | | 1604 |<-----------------------------------------+ 1605 | 2.05 Content | 1606 | Token: 0x4a | Notification upon 1607 | Observe: 60 | a state change 1608 | status: "attack-stopped" | 1609 |<-----------------------------------------+ 1610 | | 1611 ... 1613 Figure 15: Notifications of Attack Mitigation Status 1615 4.4.2.2. DOTS Clients Polling for Mitigation Status 1617 The DOTS client can send the GET request at frequent intervals 1618 without the Observe Option to retrieve the configuration data of the 1619 mitigation request and non-configuration data (i.e., the attack 1620 status). DOTS clients MAY be configured with a policy indicating the 1621 frequency of polling DOTS servers to get the mitigation status. 1622 Absent such policy, the frequency of polling the DOTS server to get 1623 the mitigation status SHOULD follow the transmission guidelines in 1624 Section 3.1.3 of [RFC8085]. 1626 If the DOTS server has been able to mitigate the attack and the 1627 attack has stopped, the DOTS server indicates as such in the status. 1628 In such case, the DOTS client recalls the mitigation request by 1629 issuing a DELETE request for this mitigation request (Section 4.4.4). 1631 A DOTS client SHOULD react to the status of the attack as per the 1632 information sent by the DOTS server rather than performing its own 1633 detection that the attack has been mitigated. This ensures that the 1634 DOTS client does not recall a mitigation request prematurely because 1635 it is possible that the DOTS client does not sense the DDoS attack on 1636 its resources, but the DOTS server could be actively mitigating the 1637 attack because the attack is not completely averted. 1639 4.4.3. Efficacy Update from DOTS Clients 1641 While DDoS mitigation is in progress, due to the likelihood of packet 1642 loss, a DOTS client MAY periodically transmit DOTS mitigation 1643 efficacy updates to the relevant DOTS server. A PUT request is used 1644 to convey the mitigation efficacy update to the DOTS server. This 1645 PUT request is treated as a refresh of the current mitigation. 1647 The PUT request used for efficacy update MUST include all the 1648 parameters used in the PUT request to carry the DOTS mitigation 1649 request (Section 4.4.1) unchanged apart from the 'lifetime' parameter 1650 value. If this is not the case, the DOTS server MUST reject the 1651 request with a 4.00 (Bad Request). 1653 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1654 value is used to make the PUT request conditional on the current 1655 existence of the mitigation request. If UDP is used as transport, 1656 CoAP requests may arrive out-of-order. For example, the DOTS client 1657 may send a PUT request to convey an efficacy update to the DOTS 1658 server followed by a DELETE request to withdraw the mitigation 1659 request, but the DELETE request arrives at the DOTS server before the 1660 PUT request. To handle out-of-order delivery of requests, if an If- 1661 Match Option is present in the PUT request and the 'mid' in the 1662 request matches a mitigation request from that DOTS client, the 1663 request is processed by the DOTS server. If no match is found, the 1664 PUT request is silently ignored by the DOTS server. 1666 An example of an efficacy update message, which includes an If-Match 1667 Option with an empty value, is depicted in Figure 16. 1669 Header: PUT (Code=0.03) 1670 Uri-Path: ".well-known" 1671 Uri-Path: "dots" 1672 Uri-Path: "mitigate" 1673 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1674 Uri-Path: "mid=123" 1675 If-Match: 1676 Content-Format: "application/dots+cbor" 1678 { 1679 "ietf-dots-signal-channel:mitigation-scope": { 1680 "scope": [ 1681 { 1682 "target-prefix": [ 1683 "2001:db8:6401::1/128", 1684 "2001:db8:6401::2/128" 1685 ], 1686 "target-port-range": [ 1687 { 1688 "lower-port": 80 1689 }, 1690 { 1691 "lower-port": 443 1692 }, 1693 { 1694 "lower-port": 8080 1695 } 1696 ], 1697 "target-protocol": [ 1698 6 1699 ], 1700 "attack-status": "under-attack" 1701 } 1702 ] 1703 } 1704 } 1706 Figure 16: An Example of Efficacy Update 1708 The 'attack-status' parameter is a mandatory attribute when 1709 performing an efficacy update. The various possible values contained 1710 in the 'attack-status' parameter are described in Table 3. 1712 +-----------+-------------------------------------------------------+ 1713 | Parameter | Description | 1714 | value | | 1715 +-----------+-------------------------------------------------------+ 1716 | 1 | The DOTS client determines that it is still under | 1717 | | attack. | 1718 +-----------+-------------------------------------------------------+ 1719 | 2 | The DOTS client determines that the attack is | 1720 | | successfully mitigated (e.g., attack traffic is not | 1721 | | seen). | 1722 +-----------+-------------------------------------------------------+ 1724 Table 3: Values of 'attack-status' Parameter 1726 The DOTS server indicates the result of processing a PUT request 1727 using CoAP response codes. The response code 2.04 (Changed) is 1728 returned if the DOTS server has accepted the mitigation efficacy 1729 update. The error response code 5.03 (Service Unavailable) is 1730 returned if the DOTS server has erred or is incapable of performing 1731 the mitigation. As specified in [RFC7252], 5.03 uses Max-Age option 1732 to indicate the number of seconds after which to retry. 1734 4.4.4. Withdraw a Mitigation 1736 DELETE requests are used to withdraw DOTS mitigation requests from 1737 DOTS servers (Figure 17). 1739 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE 1740 requests. 1742 The same considerations for manipulating 'cdid' parameter by DOTS 1743 gateways, as specified in Section 4.4.1, MUST be followed for DELETE 1744 requests. Uri-Path parameters with empty values MUST NOT be present 1745 in a request. 1747 Header: DELETE (Code=0.04) 1748 Uri-Path: ".well-known" 1749 Uri-Path: "dots" 1750 Uri-Path: "mitigate" 1751 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1752 Uri-Path: "mid=123" 1754 Figure 17: Withdraw a DOTS Mitigation 1756 If the DELETE request does not include 'cuid' and 'mid' parameters, 1757 the DOTS server MUST reply with a 4.00 (Bad Request). 1759 Once the request is validated, the DOTS server immediately 1760 acknowledges a DOTS client's request to withdraw the DOTS signal 1761 using 2.02 (Deleted) response code with no response payload. A 2.02 1762 (Deleted) Response Code is returned even if the 'mid' parameter value 1763 conveyed in the DELETE request does not exist in its configuration 1764 data before the request. 1766 If the DOTS server finds the 'mid' parameter value conveyed in the 1767 DELETE request in its configuration data for the DOTS client, then to 1768 protect against route or DNS flapping caused by a DOTS client rapidly 1769 removing a mitigation, and to dampen the effect of oscillating 1770 attacks, the DOTS server MAY allow mitigation to continue for a 1771 limited period after acknowledging a DOTS client's withdrawal of a 1772 mitigation request. During this period, the DOTS server status 1773 messages SHOULD indicate that mitigation is active but terminating 1774 (Section 4.4.2). 1776 The initial active-but-terminating period SHOULD be sufficiently long 1777 to absorb latency incurred by route propagation. The active-but- 1778 terminating period SHOULD be set by default to 120 seconds. If the 1779 client requests mitigation again before the initial active-but- 1780 terminating period elapses, the DOTS server MAY exponentially 1781 increase (the base of the exponent is 2) the active-but-terminating 1782 period up to a maximum of 300 seconds (5 minutes). 1784 Once the active-but-terminating period elapses, the DOTS server MUST 1785 treat the mitigation as terminated, as the DOTS client is no longer 1786 responsible for the mitigation. 1788 If a mitigation is triggered due to a signal channel loss, the DOTS 1789 server relies upon normal triggers to stop that mitigation 1790 (typically, receipt of a valid DELETE request, expiry of the 1791 mitigation lifetime, or scrubbing the traffic to the attack target). 1792 In particular, the DOTS server MUST NOT consider the signal channel 1793 recovery as a trigger to stop the mitigation. 1795 4.5. DOTS Signal Channel Session Configuration 1797 A DOTS client can negotiate, configure, and retrieve the DOTS signal 1798 channel session behavior with its DOTS peers. The DOTS signal 1799 channel can be used, for example, to configure the following: 1801 a. Heartbeat interval (heartbeat-interval): DOTS agents regularly 1802 send heartbeats to each other after mutual authentication is 1803 successfully completed in order to keep the DOTS signal channel 1804 open. Heartbeat messages are exchanged between DOTS agents every 1805 'heartbeat-interval' seconds to detect the current status of the 1806 DOTS signal channel session. 1808 b. Missing heartbeats allowed (missing-hb-allowed): This variable 1809 indicates the maximum number of consecutive heartbeat messages 1810 for which a DOTS agent did not receive a response before 1811 concluding that the session is disconnected or defunct. 1813 c. Acceptable signal loss ratio: Maximum retransmissions, 1814 retransmission timeout value, and other message transmission 1815 parameters for the DOTS signal channel. 1817 The same or distinct configuration sets may be used during times when 1818 a mitigation is active ('mitigating-config') and when no mitigation 1819 is active ('idle-config'). This is particularly useful for DOTS 1820 servers that might want to reduce heartbeat frequency or cease 1821 heartbeat exchanges when an active DOTS client has not requested 1822 mitigation. If distinct configurations are used, DOTS agents MUST 1823 follow the appropriate configuration set as a function of the 1824 mitigation activity (e.g., if no mitigation request is active (also 1825 referred to as 'idle' time), 'idle-config'-related values must be 1826 followed). Additionally, DOTS agents MUST automatically switch to 1827 the other configuration upon a change in the mitigation activity 1828 (e.g., if an attack mitigation is launched after an 'idle' time, the 1829 DOTS agent switches from 'idle-config' to 'mitigating-config'-related 1830 values). 1832 CoAP Requests and responses are indicated for reliable delivery by 1833 marking them as Confirmable messages. DOTS signal channel session 1834 configuration requests and responses are marked as Confirmable 1835 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1836 message is retransmitted using a default timeout and exponential 1837 back-off between retransmissions, until the DOTS server sends an 1838 Acknowledgement message (ACK) with the same Message ID conveyed from 1839 the DOTS client. 1841 Message transmission parameters are defined in Section 4.8 of 1842 [RFC7252]. The DOTS server can either piggyback the response in the 1843 acknowledgement message or, if the DOTS server cannot respond 1844 immediately to a request carried in a Confirmable message, it simply 1845 responds with an Empty Acknowledgement message so that the DOTS 1846 client can stop retransmitting the request. Empty Acknowledgement 1847 messages are explained in Section 2.2 of [RFC7252]. When the 1848 response is ready, the server sends it in a new Confirmable message 1849 which in turn needs to be acknowledged by the DOTS client (see 1850 Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and responses 1851 exchanged between DOTS agents during 'idle' time are marked as 1852 Confirmable messages. 1854 Implementation Note: A DOTS client that receives a response in a 1855 Confirmable message may want to clean up the message state right 1856 after sending the ACK. If that ACK is lost and the DOTS server 1857 retransmits the Confirmable message, the DOTS client may no longer 1858 have any state that would help it correlate this response: from 1859 the DOTS client's standpoint, the retransmission message is 1860 unexpected. The DOTS client will send a Reset message so it does 1861 not receive any more retransmissions. This behavior is normal and 1862 not an indication of an error (see Section 5.3.2 of [RFC7252] for 1863 more details). 1865 4.5.1. Discover Configuration Parameters 1867 A GET request is used to obtain acceptable (e.g., minimum and maximum 1868 values) and current configuration parameters on the DOTS server for 1869 DOTS signal channel session configuration. This procedure occurs 1870 between a DOTS client and its immediate peer DOTS server. As such, 1871 this GET request MUST NOT be relayed by a DOTS gateway. 1873 Figure 18 shows how to obtain acceptable configuration parameters for 1874 the DOTS server. 1876 Header: GET (Code=0.01) 1877 Uri-Path: ".well-known" 1878 Uri-Path: "dots" 1879 Uri-Path: "config" 1881 Figure 18: GET to Retrieve Configuration 1883 The DOTS server in the 2.05 (Content) response conveys the current, 1884 minimum, and maximum attribute values acceptable by the DOTS server 1885 (Figure 19). 1887 { 1888 "ietf-dots-signal-channel:signal-config": { 1889 "mitigating-config": { 1890 "heartbeat-interval": { 1891 "max-value": number, 1892 "min-value": number, 1893 "current-value": number 1894 }, 1895 "missing-hb-allowed": { 1896 "max-value": number, 1897 "min-value": number, 1898 "current-value": number 1899 }, 1900 "max-retransmit": { 1901 "max-value": number, 1902 "min-value": number, 1903 "current-value": number 1905 }, 1906 "ack-timeout": { 1907 "max-value-decimal": "string", 1908 "min-value-decimal": "string", 1909 "current-value-decimal": "string" 1910 }, 1911 "ack-random-factor": { 1912 "max-value-decimal": "string", 1913 "min-value-decimal": "string", 1914 "current-value-decimal": "string" 1915 } 1916 }, 1917 "idle-config": { 1918 "heartbeat-interval": { 1919 "max-value": number, 1920 "min-value": number, 1921 "current-value": number 1922 }, 1923 "missing-hb-allowed": { 1924 "max-value": number, 1925 "min-value": number, 1926 "current-value": number 1927 }, 1928 "max-retransmit": { 1929 "max-value": number, 1930 "min-value": number, 1931 "current-value": number 1932 }, 1933 "ack-timeout": { 1934 "max-value-decimal": "string", 1935 "min-value-decimal": "string", 1936 "current-value-decimal": "string" 1937 }, 1938 "ack-random-factor": { 1939 "max-value-decimal": "string", 1940 "min-value-decimal": "string", 1941 "current-value-decimal": "string" 1942 } 1943 } 1944 } 1945 } 1947 Figure 19: GET Configuration Response Body Schema 1949 The parameters in Figure 19 are described below: 1951 mitigating-config: Set of configuration parameters to use when a 1952 mitigation is active. The following parameters may be included: 1954 heartbeat-interval: Time interval in seconds between two 1955 consecutive heartbeat messages. 1957 '0' is used to disable the heartbeat mechanism. 1959 This is an optional attribute. 1961 missing-hb-allowed: Maximum number of consecutive heartbeat 1962 messages for which the DOTS agent did not receive a response 1963 before concluding that the session is disconnected. 1965 This is an optional attribute. 1967 max-retransmit: Maximum number of retransmissions for a message 1968 (referred to as MAX_RETRANSMIT parameter in CoAP). 1970 This is an optional attribute. 1972 ack-timeout: Timeout value in seconds used to calculate the 1973 initial retransmission timeout value (referred to as 1974 ACK_TIMEOUT parameter in CoAP). 1976 This is an optional attribute. 1978 ack-random-factor: Random factor used to influence the timing of 1979 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1980 CoAP). 1982 This is an optional attribute. 1984 idle-config: Set of configuration parameters to use when no 1985 mitigation is active. This attribute has the same structure as 1986 'mitigating-config'. 1988 Figure 20 shows an example of acceptable and current configuration 1989 parameters on a DOTS server for DOTS signal channel session 1990 configuration. The same acceptable configuration is used during 1991 mitigation and idle times. 1993 { 1994 "ietf-dots-signal-channel:signal-config": { 1995 "mitigating-config": { 1996 "heartbeat-interval": { 1997 "max-value": 240, 1998 "min-value": 15, 1999 "current-value": 30 2000 }, 2001 "missing-hb-allowed": { 2002 "max-value": 9, 2003 "min-value": 3, 2004 "current-value": 5 2005 }, 2006 "max-retransmit": { 2007 "max-value": 15, 2008 "min-value": 2, 2009 "current-value": 3 2010 }, 2011 "ack-timeout": { 2012 "max-value-decimal": "30.00", 2013 "min-value-decimal": "1.00", 2014 "current-value-decimal": "2.00" 2015 }, 2016 "ack-random-factor": { 2017 "max-value-decimal": "4.00", 2018 "min-value-decimal": "1.10", 2019 "current-value-decimal": "1.50" 2020 } 2021 }, 2022 "idle-config": { 2023 "heartbeat-interval": { 2024 "max-value": 240, 2025 "min-value": 15, 2026 "current-value": 30 2027 }, 2028 "missing-hb-allowed": { 2029 "max-value": 9, 2030 "min-value": 3, 2031 "current-value": 5 2032 }, 2033 "max-retransmit": { 2034 "max-value": 15, 2035 "min-value": 2, 2036 "current-value": 3 2037 }, 2038 "ack-timeout": { 2039 "max-value-decimal": "30.00", 2040 "min-value-decimal": "1.00", 2041 "current-value-decimal": "2.00" 2042 }, 2043 "ack-random-factor": { 2044 "max-value-decimal": "4.00", 2045 "min-value-decimal": "1.10", 2046 "current-value-decimal": "1.50" 2047 } 2048 } 2049 } 2051 } 2053 Figure 20: Example of a Configuration Response Body 2055 4.5.2. Convey DOTS Signal Channel Session Configuration 2057 A PUT request (Figures 21 and 22) is used to convey the configuration 2058 parameters for the signal channel (e.g., heartbeat interval, maximum 2059 retransmissions). Message transmission parameters for CoAP are 2060 defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of 2061 transmission parameter values are ack-timeout (2 seconds), max- 2062 retransmit (3), ack-random-factor (1.5). In addition to those 2063 parameters, the RECOMMENDED specific DOTS transmission parameter 2064 values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' 2065 (5). 2067 Note: heartbeat-interval should be tweaked to also assist DOTS 2068 messages for NAT traversal (SIG-011 of 2069 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 2070 messages must not be sent more frequently than once every 15 2071 seconds and should use longer intervals when possible. 2072 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 2073 minutes or longer, but experience shows that sending packets every 2074 15 to 30 seconds is necessary to prevent the majority of 2075 middleboxes from losing state for UDP flows. From that 2076 standpoint, the RECOMMENDED minimum heartbeat-interval is 15 2077 seconds and the RECOMMENDED maximum heartbeat-interval is 240 2078 seconds. The recommended value of 30 seconds is selected to 2079 anticipate the expiry of NAT state. 2081 A heartbeat-interval of 30 seconds may be considered as too chatty 2082 in some deployments. For such deployments, DOTS agents may 2083 negotiate longer heartbeat-interval values to prevent any network 2084 overload with too frequent keepalives. 2086 Different heartbeat intervals can be defined for 'mitigating- 2087 config' and 'idle-config' to reduce being too chatty during idle 2088 times. If there is an on-path translator between the DOTS client 2089 (standalone or part of a DOTS gateway) and the DOTS server, the 2090 'mitigating-config' heartbeat-interval has to be smaller than the 2091 translator session timeout. It is recommended that the 'idle- 2092 config' heartbeat-interval is also smaller than the translator 2093 session timeout to prevent translator traversal issues, or 2094 disabled entirely. Means to discover the lifetime assigned by a 2095 translator are out of scope. 2097 Section 4.2 of [RFC7252] defines a "CoAP Ping" mechanism. 2098 Concretely, the DOTS agent sends an Empty Confirmable message and the 2099 peer DOTS agent will respond by sending a Reset message. 2101 When a Confirmable "CoAP Ping" is sent, and if there is no response, 2102 the "CoAP Ping" is retransmitted max-retransmit number of times by 2103 the CoAP layer using an initial timeout set to a random duration 2104 between ack-timeout and (ack-timeout*ack-random-factor) and 2105 exponential back-off between retransmissions. By choosing the 2106 recommended transmission parameters, the "CoAP Ping" will timeout 2107 after 45 seconds. If the DOTS agent does not receive any response 2108 from the peer DOTS agent for 'missing-hb-allowed' number of 2109 consecutive "CoAP Ping" Confirmable messages, it concludes that the 2110 DOTS signal channel session is disconnected. A DOTS client MUST NOT 2111 transmit a "CoAP Ping" while waiting for the previous "CoAP Ping" 2112 response from the same DOTS server. 2114 If the DOTS agent wishes to change the default values of message 2115 transmission parameters, it SHOULD follow the guidance given in 2116 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 2117 values for message transmission parameters and default values for 2118 non-negotiated message transmission parameters. 2120 The signal channel session configuration is applicable to a single 2121 DOTS signal channel session between DOTS agents, so the 'cuid' Uri- 2122 Path MUST NOT be used. 2124 Header: PUT (Code=0.03) 2125 Uri-Path: ".well-known" 2126 Uri-Path: "dots" 2127 Uri-Path: "config" 2128 Uri-Path: "sid=123" 2129 Content-Format: "application/dots+cbor" 2131 { 2132 ... 2133 } 2135 Figure 21: PUT to Convey the DOTS Signal Channel Session 2136 Configuration Data 2138 The additional Uri-Path parameter to those defined in Table 1 is as 2139 follows: 2141 sid: Session Identifier is an identifier for the DOTS signal channel 2142 session configuration data represented as an integer. This 2143 identifier MUST be generated by DOTS clients. 'sid' values MUST 2144 increase monotonically (when a new PUT is generated by a DOTS 2145 client to convey the configuration parameters for the signal 2146 channel). 2148 This is a mandatory attribute. 2150 { 2151 "ietf-dots-signal-channel:signal-config": { 2152 "mitigating-config": { 2153 "heartbeat-interval": { 2154 "current-value": number 2155 }, 2156 "missing-hb-allowed": { 2157 "current-value": number 2158 }, 2159 "max-retransmit": { 2160 "current-value": number 2161 }, 2162 "ack-timeout": { 2163 "current-value-decimal": "string" 2164 }, 2165 "ack-random-factor": { 2166 "current-value-decimal": "string" 2167 } 2168 }, 2169 "idle-config": { 2170 "heartbeat-interval": { 2171 "current-value": number 2172 }, 2173 "missing-hb-allowed": { 2174 "current-value": number 2175 }, 2176 "max-retransmit": { 2177 "current-value": number 2178 }, 2179 "ack-timeout": { 2180 "current-value-decimal": "string" 2181 }, 2182 "ack-random-factor": { 2183 "current-value-decimal": "string" 2184 } 2185 } 2186 } 2187 } 2189 Figure 22: PUT to Convey the DOTS Signal Channel Session 2190 Configuration Data (Message Body Schema) 2192 The meaning of the parameters in the CBOR body (Figure 22) is defined 2193 in Section 4.5.1. 2195 At least one of the attributes 'heartbeat-interval', 'missing-hb- 2196 allowed', 'max-retransmit', 'ack-timeout', and 'ack-random-factor' 2197 MUST be present in the PUT request. Note that 'heartbeat-interval', 2198 'missing-hb-allowed', 'max-retransmit', 'ack-timeout', and 'ack- 2199 random-factor', if present, do not need to be provided for both 2200 'mitigating-config', and 'idle-config' in a PUT request. 2202 The PUT request with a higher numeric 'sid' value overrides the DOTS 2203 signal channel session configuration data installed by a PUT request 2204 with a lower numeric 'sid' value. To avoid maintaining a long list 2205 of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be 2206 automatically deleted and no longer available at the DOTS server. 2208 Figure 23 shows a PUT request example to convey the configuration 2209 parameters for the DOTS signal channel. In this example, the 2210 heartbeat mechanism is disabled when no mitigation is active, while 2211 the heartbeat interval is set to '91' when a mitigation is active. 2213 Header: PUT (Code=0.03) 2214 Uri-Path: ".well-known" 2215 Uri-Path: "dots" 2216 Uri-Path: "config" 2217 Uri-Path: "sid=123" 2218 Content-Format: "application/dots+cbor" 2220 { 2221 "ietf-dots-signal-channel:signal-config": { 2222 "mitigating-config": { 2223 "heartbeat-interval": { 2224 "current-value": 91 2225 }, 2226 "missing-hb-allowed": { 2227 "current-value": 3 2228 }, 2229 "max-retransmit": { 2230 "current-value": 3 2231 }, 2232 "ack-timeout": { 2233 "current-value-decimal": "2.00" 2234 }, 2235 "ack-random-factor": { 2236 "current-value-decimal": "1.50" 2237 } 2238 }, 2239 "idle-config": { 2240 "heartbeat-interval": { 2241 "current-value": 0 2242 }, 2243 "max-retransmit": { 2244 "current-value": 3 2245 }, 2246 "ack-timeout": { 2247 "current-value-decimal": "2.00" 2248 }, 2249 "ack-random-factor": { 2250 "current-value-decimal": "1.50" 2251 } 2252 } 2253 } 2254 } 2256 Figure 23: PUT to Convey the Configuration Parameters 2258 The DOTS server indicates the result of processing the PUT request 2259 using CoAP response codes: 2261 o If the request is missing a mandatory attribute, does not include 2262 a 'sid' Uri-Path, or contains one or more invalid or unknown 2263 parameters, 4.00 (Bad Request) MUST be returned in the response. 2265 o If the DOTS server does not find the 'sid' parameter value 2266 conveyed in the PUT request in its configuration data and if the 2267 DOTS server has accepted the configuration parameters, then a 2268 response code 2.01 (Created) MUST be returned in the response. 2270 o If the DOTS server finds the 'sid' parameter value conveyed in the 2271 PUT request in its configuration data and if the DOTS server has 2272 accepted the updated configuration parameters, 2.04 (Changed) MUST 2273 be returned in the response. 2275 o If any of the 'heartbeat-interval', 'missing-hb-allowed', 'max- 2276 retransmit', 'target-protocol', 'ack-timeout', and 'ack-random- 2277 factor' attribute values are not acceptable to the DOTS server, 2278 4.22 (Unprocessable Entity) MUST be returned in the response. 2279 Upon receipt of this error code, the DOTS client SHOULD retrieve 2280 the maximum and minimum attribute values acceptable to the DOTS 2281 server (Section 4.5.1). 2283 The DOTS client may re-try and send the PUT request with updated 2284 attribute values acceptable to the DOTS server. 2286 A DOTS client may issue a GET message with 'sid' Uri-Path parameter 2287 to retrieve the negotiated configuration. The response does not need 2288 to include 'sid' in its message body. 2290 4.5.3. Configuration Freshness and Notifications 2292 Max-Age Option (Section 5.10.5 of [RFC7252]) SHOULD be returned by a 2293 DOTS server to associate a validity time with a configuration it 2294 sends. This feature allows the update of the configuration data if a 2295 change occurs at the DOTS server side. For example, the new 2296 configuration may instruct a DOTS client to cease heartbeats or 2297 reduce heartbeat frequency. 2299 It is NOT RECOMMENDED to return a Max-Age Option set to 0. 2301 Returning a Max-Age Option set to 2**32-1 is equivalent to 2302 associating an infinite lifetime with the configuration. 2304 If a non-zero value of Max-Age Option is received by a DOTS client, 2305 it MUST issue a GET request with 'sid' Uri-Path parameter to retrieve 2306 the current and acceptable configuration before the expiry of the 2307 value enclosed in the Max-Age option. This request is considered by 2308 the client and the server as a means to refresh the configuration 2309 parameters for the signal channel. When a DDoS attack is active, 2310 refresh requests MUST NOT be sent by DOTS clients and the DOTS server 2311 MUST NOT terminate the (D)TLS session after the expiry of the value 2312 returned in Max-Age Option. 2314 If Max-Age Option is not returned in a response, the DOTS client 2315 initiates GET requests to refresh the configuration parameters each 2316 60 seconds (Section 5.10.5 of [RFC7252]). To prevent such overload, 2317 it is RECOMMENDED that DOTS servers return a Max-Age Option in GET 2318 responses. Considerations related to which value to use and how such 2319 value is set, are implementation- and deployment-specific. 2321 If an Observe Option set to 0 is included in the configuration 2322 request, the DOTS server sends notifications of any configuration 2323 change (Section 4.2 of [RFC7641]). 2325 If a DOTS server detects that a misbehaving DOTS client does not 2326 contact the DOTS server after the expiry of Max-Age and retrieve the 2327 signal channel configuration data, it MAY terminate the (D)TLS 2328 session. A (D)TLS session is terminated by the receipt of an 2329 authenticated message that closes the connection (e.g., a fatal alert 2330 (Section 6 of [RFC8446])). 2332 4.5.4. Delete DOTS Signal Channel Session Configuration 2334 A DELETE request is used to delete the installed DOTS signal channel 2335 session configuration data (Figure 24). 2337 Header: DELETE (Code=0.04) 2338 Uri-Path: ".well-known" 2339 Uri-Path: "dots" 2340 Uri-Path: "config" 2341 Uri-Path: "sid=123" 2343 Figure 24: Delete Configuration 2345 The DOTS server resets the DOTS signal channel session configuration 2346 back to the default values and acknowledges a DOTS client's request 2347 to remove the DOTS signal channel session configuration using 2.02 2348 (Deleted) response code. 2350 Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request 2351 to set the configuration parameters to default values. Such a 2352 request does not include any 'sid'. 2354 4.6. Redirected Signaling 2356 Redirected DOTS signaling is discussed in detail in Section 3.2.2 of 2357 [I-D.ietf-dots-architecture]. 2359 If a DOTS server wants to redirect a DOTS client to an alternative 2360 DOTS server for a signal session, then the response code 5.03 2361 (Service Unavailable) will be returned in the response to the DOTS 2362 client. 2364 The DOTS server can return the error response code 5.03 in response 2365 to a request from the DOTS client or convey the error response code 2366 5.03 in a unidirectional notification response from the DOTS server. 2368 The DOTS server in the error response conveys the alternate DOTS 2369 server's FQDN, and the alternate DOTS server's IP address(es) values 2370 in the CBOR body (Figure 25). 2372 { 2373 "ietf-dots-signal-channel:redirected-signal": { 2374 "alt-server": "string", 2375 "alt-server-record": [ 2376 "string" 2377 ] 2378 } 2380 Figure 25: Redirected Server Error Response Body Schema 2382 The parameters are described below: 2384 alt-server: FQDN of an alternate DOTS server. 2386 This is a mandatory attribute. 2388 alt-server-record: A list of IP addresses of an alternate DOTS 2389 server. 2391 This is an optional attribute. 2393 The DOTS server returns the Time to live (TTL) of the alternate DOTS 2394 server in a Max-Age Option. That is, the time interval that the 2395 alternate DOTS server may be cached for use by a DOTS client. A Max- 2396 Age Option set to 2**32-1 is equivalent to receiving an infinite TTL. 2397 This value means that the alternate DOTS server is to be used until 2398 the alternate DOTS server redirects the traffic with another 5.03 2399 response which encloses an alternate server. 2401 A Max-Age Option set to '0' may be returned for redirecting 2402 mitigation requests. Such value means that the redirection applies 2403 only for the mitigation request in progress. Returning short TTL in 2404 a Max-Age Option may adversely impact DOTS clients on slow links. 2405 Returning short values should be avoided under such conditions. 2407 If the alternate DOTS server TTL has expired, the DOTS client MUST 2408 use the DOTS server(s), that was provisioned using means discussed in 2409 Section 4.1. This fall back mechanism is triggered immediately upon 2410 expiry of the TTL, except when a DDoS attack is active. 2412 Requests issued by misbehaving DOTS clients which do not honor the 2413 TTL conveyed in the Max-Age Option or react to explicit re-direct 2414 messages can be rejected by DOTS servers. 2416 Figure 26 shows a 5.03 response example to convey the DOTS alternate 2417 server 'alt-server.example' together with its IP addresses 2418 2001:db8:6401::1 and 2001:db8:6401::2. 2420 { 2421 "ietf-dots-signal-channel:redirected-signal": { 2422 "alt-server": "alt-server.example", 2423 "alt-server-record": [ 2424 "2001:db8:6401::1", 2425 "2001:db8:6401::2" 2426 ] 2427 } 2429 Figure 26: Example of Redirected Server Error Response Body 2431 When the DOTS client receives 5.03 response with an alternate server 2432 included, it considers the current request as failed, but SHOULD try 2433 re-sending the request to the alternate DOTS server. During a DDoS 2434 attack, the DNS server may be the target of another DDoS attack, 2435 alternate DOTS server's IP addresses conveyed in the 5.03 response 2436 help the DOTS client skip DNS lookup of the alternate DOTS server, at 2437 the cost of trusting the first DOTS server to provide accurate 2438 information. The DOTS client can then try to establish a UDP or a 2439 TCP session with the alternate DOTS server. The DOTS client MAY 2440 implement a method to construct IPv4-embedded IPv6 addresses 2441 [RFC6052]; this is required to handle the scenario where an IPv6-only 2442 DOTS client communicates with an IPv4-only alternate DOTS server. 2444 If the DOTS client has been redirected to a DOTS server to which it 2445 has already communicated with within the last five (5) minutes, it 2446 MUST ignore the redirection and try to contact other DOTS servers 2447 listed in the local configuration or discovered using dynamic means 2448 such as DHCP or SRV procedures [I-D.ietf-dots-server-discovery]. It 2449 is RECOMMENDED that DOTS clients support means to alert 2450 administrators about redirect loops. 2452 4.7. Heartbeat Mechanism 2454 To provide an indication of signal health and distinguish an 'idle' 2455 signal channel from a 'disconnected' or 'defunct' session, the DOTS 2456 agent sends a heartbeat over the signal channel to maintain its half 2457 of the channel (also, aligned with the "consents" recommendation in 2458 Section 6 of [RFC8085]). The DOTS agent similarly expects a 2459 heartbeat from its peer DOTS agent, and may consider a session 2460 terminated in the prolonged absence of a peer agent heartbeat. 2461 Concretely, while the communication between the DOTS agents is 2462 otherwise quiescent, the DOTS client will probe the DOTS server to 2463 ensure it has maintained cryptographic state and vice versa. Such 2464 probes can also keep firewalls and/or stateful translators bindings 2465 alive. This probing reduces the frequency of establishing a new 2466 handshake when a DOTS signal needs to be conveyed to the DOTS server. 2468 DOTS servers MAY trigger their heartbeat requests immediately after 2469 receiving heartbeat probes from peer DOTS clients. As a reminder, it 2470 is the responsibility of DOTS clients to ensure that on-path 2471 translators/firewalls are maintaining a binding so that the same 2472 external IP address and/or port number is retained for the DOTS 2473 signal channel session. 2475 In case of a massive DDoS attack that saturates the incoming link(s) 2476 to the DOTS client, all traffic from the DOTS server to the DOTS 2477 client will likely be dropped, although the DOTS server receives 2478 heartbeat requests in addition to DOTS messages sent by the DOTS 2479 client. In this scenario, the DOTS agents MUST behave differently to 2480 handle message transmission and DOTS signal channel session 2481 liveliness during link saturation: 2483 o The DOTS client MUST NOT consider the DOTS signal channel session 2484 terminated even after a maximum 'missing-hb-allowed' threshold is 2485 reached. The DOTS client SHOULD keep on using the current DOTS 2486 signal channel session to send heartbeat requests over it, so that 2487 the DOTS server knows the DOTS client has not disconnected the 2488 DOTS signal channel session. 2490 After the maximum 'missing-hb-allowed' threshold is reached, the 2491 DOTS client SHOULD try to resume the (D)TLS session. The DOTS 2492 client SHOULD send mitigation requests over the current DOTS 2493 signal channel session, and in parallel, for example, try to 2494 resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to 2495 piggyback the mitigation request in the ClientHello message. 2497 As soon as the link is no longer saturated, if traffic from the 2498 DOTS server reaches the DOTS client over the current DOTS signal 2499 channel session, the DOTS client can stop (D)TLS session 2500 resumption or if (D)TLS session resumption is successful then 2501 disconnect the current DOTS signal channel session. 2503 o If the DOTS server receives traffic from the peer DOTS client 2504 (e.g., peer DOTS client initiated heartbeats) but maximum 2505 'missing-hb-allowed' threshold is reached, the DOTS server MUST 2506 NOT consider the DOTS signal channel session disconnected. The 2507 DOTS server MUST keep on using the current DOTS signal channel 2508 session so that the DOTS client can send mitigation requests over 2509 the current DOTS signal channel session. In this case, the DOTS 2510 server can identify the DOTS client is under attack and the 2511 inbound link to the DOTS client (domain) is saturated. 2512 Furthermore, if the DOTS server does not receive a mitigation 2513 request from the DOTS client, it implies the DOTS client has not 2514 detected the attack or, if an attack mitigation is in progress, it 2515 implies the applied DDoS mitigation actions are not yet effective 2516 to handle the DDoS attack volume. 2518 o If the DOTS server does not receive any traffic from the peer DOTS 2519 client, then the DOTS server sends heartbeat requests to the DOTS 2520 client and after maximum 'missing-hb-allowed' threshold is 2521 reached, the DOTS server concludes the session is disconnected. 2522 The DOTS server can then trigger pre-configured mitigation 2523 requests for this DOTS client (if any). 2525 In DOTS over UDP, heartbeat messages MUST be exchanged between the 2526 DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of 2527 [RFC7252]. 2529 In DOTS over TCP, heartbeat messages MUST be exchanged between the 2530 DOTS agents using the Ping and Pong messages specified in Section 5.4 2531 of [RFC8323]. That is, the DOTS agent sends a Ping message and the 2532 peer DOTS agent would respond by sending a single Pong message. 2534 5. DOTS Signal Channel YANG Modules 2536 This document defines a YANG [RFC7950] module for DOTS mitigation 2537 scope, DOTS signal channel session configuration data, and DOTS 2538 redirection signaling. 2540 This YANG module (ietf-dots-signal-channel) defines the DOTS client 2541 interaction with the DOTS server as seen by the DOTS client. A DOTS 2542 server is allowed to update the non-configurable 'ro' entities in the 2543 responses. This YANG module is not intended to be used via NETCONF/ 2544 RESTCONF for DOTS server management purposes; such module is out of 2545 the scope of this document. It serves only to provide a data model 2546 and encoding, but not a management data model. 2548 A companion YANG module is defined to include a collection of types 2549 defined by IANA: "iana-dots-signal-channel" (Section 5.2). 2551 5.1. Tree Structure 2553 This document defines the YANG module "ietf-dots-signal-channel" 2554 (Section 5.3), which has the following tree structure. A DOTS signal 2555 message can be a mitigation, a configuration, or a redirect message. 2557 module: ietf-dots-signal-channel 2558 +--rw dots-signal 2559 +--rw (message-type)? 2560 +--:(mitigation-scope) 2561 | +--rw scope* [cuid mid] 2562 | +--rw cdid? string 2563 | +--rw cuid string 2564 | +--rw mid uint32 2565 | +--rw target-prefix* inet:ip-prefix 2566 | +--rw target-port-range* [lower-port] 2567 | | +--rw lower-port inet:port-number 2568 | | +--rw upper-port? inet:port-number 2569 | +--rw target-protocol* uint8 2570 | +--rw target-fqdn* inet:domain-name 2571 | +--rw target-uri* inet:uri 2572 | +--rw alias-name* string 2573 | +--rw lifetime? int32 2574 | +--rw trigger-mitigation? boolean 2575 | +--ro mitigation-start? uint64 2576 | +--ro status? iana-signal:status 2577 | +--ro conflict-information 2578 | | +--ro conflict-status? iana-signal:conflict-status 2579 | | +--ro conflict-cause? iana-signal:conflict-cause 2580 | | +--ro retry-timer? uint32 2581 | | +--ro conflict-scope 2582 | | +--ro target-prefix* inet:ip-prefix 2583 | | +--ro target-port-range* [lower-port] 2584 | | | +--ro lower-port inet:port-number 2585 | | | +--ro upper-port? inet:port-number 2586 | | +--ro target-protocol* uint8 2587 | | +--ro target-fqdn* inet:domain-name 2588 | | +--ro target-uri* inet:uri 2589 | | +--ro alias-name* string 2590 | | +--ro acl-list* [acl-name] 2591 | | | +--ro acl-name 2592 | | | | -> /ietf-data:dots-data/dots-client/acls/ 2593 | | | | acl/name 2594 | | | +--ro acl-type? 2595 | | | -> /ietf-data:dots-data/dots-client/acls/ 2596 | | | acl/type 2597 | | +--ro mid? -> ../../../mid 2598 | +--ro bytes-dropped? yang:zero-based-counter64 2599 | +--ro bps-dropped? yang:gauge64 2600 | +--ro pkts-dropped? yang:zero-based-counter64 2601 | +--ro pps-dropped? yang:gauge64 2602 | +--rw attack-status? iana-signal:attack-status 2603 +--:(signal-config) 2604 | +--rw sid uint32 2605 | +--rw mitigating-config 2606 | | +--rw heartbeat-interval 2607 | | | +--ro max-value? uint16 2608 | | | +--ro min-value? uint16 2609 | | | +--rw current-value? uint16 2610 | | +--rw missing-hb-allowed 2611 | | | +--ro max-value? uint16 2612 | | | +--ro min-value? uint16 2613 | | | +--rw current-value? uint16 2614 | | +--rw max-retransmit 2615 | | | +--ro max-value? uint16 2616 | | | +--ro min-value? uint16 2617 | | | +--rw current-value? uint16 2618 | | +--rw ack-timeout 2619 | | | +--ro max-value-decimal? decimal64 2620 | | | +--ro min-value-decimal? decimal64 2621 | | | +--rw current-value-decimal? decimal64 2622 | | +--rw ack-random-factor 2623 | | +--ro max-value-decimal? decimal64 2624 | | +--ro min-value-decimal? decimal64 2625 | | +--rw current-value-decimal? decimal64 2626 | +--rw idle-config 2627 | +--rw heartbeat-interval 2628 | | +--ro max-value? uint16 2629 | | +--ro min-value? uint16 2630 | | +--rw current-value? uint16 2631 | +--rw missing-hb-allowed 2632 | | +--ro max-value? uint16 2633 | | +--ro min-value? uint16 2634 | | +--rw current-value? uint16 2635 | +--rw max-retransmit 2636 | | +--ro max-value? uint16 2637 | | +--ro min-value? uint16 2638 | | +--rw current-value? uint16 2639 | +--rw ack-timeout 2640 | | +--ro max-value-decimal? decimal64 2641 | | +--ro min-value-decimal? decimal64 2642 | | +--rw current-value-decimal? decimal64 2643 | +--rw ack-random-factor 2644 | +--ro max-value-decimal? decimal64 2645 | +--ro min-value-decimal? decimal64 2646 | +--rw current-value-decimal? decimal64 2647 +--:(redirected-signal) 2648 +--ro alt-server string 2649 +--ro alt-server-record* inet:ip-address 2651 5.2. IANA DOTS Signal Channel YANG Module 2653 file "iana-dots-signal-channel@2019-01-17.yang" 2654 module iana-dots-signal-channel { 2655 yang-version 1.1; 2656 namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel"; 2657 prefix iana-signal; 2659 organization 2660 "IANA"; 2661 contact 2662 "Internet Assigned Numbers Authority 2664 Postal: ICANN 2665 12025 Waterfront Drive, Suite 300 2666 Los Angeles, CA 90094-2536 2667 United States of America 2668 Tel: +1 310 301 5800 2669 "; 2670 description 2671 "This module contains a collection of YANG data types defined 2672 by IANA and used for DOTS signal channel protocol. 2674 Copyright (c) 2019 IETF Trust and the persons identified as 2675 authors of the code. All rights reserved. 2677 Redistribution and use in source and binary forms, with or 2678 without modification, is permitted pursuant to, and subject 2679 to the license terms contained in, the Simplified BSD License 2680 set forth in Section 4.c of the IETF Trust's Legal Provisions 2681 Relating to IETF Documents 2682 (http://trustee.ietf.org/license-info). 2684 This version of this YANG module is part of RFC XXXX; see 2685 the RFC itself for full legal notices."; 2687 revision 2019-01-17 { 2688 description 2689 "Initial revision."; 2690 reference 2691 "RFC XXXX: Distributed Denial-of-Service Open Threat 2692 Signaling (DOTS) Signal Channel Specification"; 2693 } 2695 typedef status { 2696 type enumeration { 2697 enum attack-mitigation-in-progress { 2698 value 1; 2699 description 2700 "Attack mitigation setup is in progress (e.g., changing 2701 the network path to re-route the inbound traffic 2702 to DOTS mitigator)."; 2703 } 2704 enum attack-successfully-mitigated { 2705 value 2; 2706 description 2707 "Attack is being successfully mitigated (e.g., traffic 2708 is redirected to a DDoS mitigator and attack 2709 traffic is dropped or blackholed)."; 2710 } 2711 enum attack-stopped { 2712 value 3; 2713 description 2714 "Attack has stopped and the DOTS client can 2715 withdraw the mitigation request."; 2716 } 2717 enum attack-exceeded-capability { 2718 value 4; 2719 description 2720 "Attack has exceeded the mitigation provider 2721 capability."; 2722 } 2723 enum dots-client-withdrawn-mitigation { 2724 value 5; 2725 description 2726 "DOTS client has withdrawn the mitigation 2727 request and the mitigation is active but 2728 terminating."; 2729 } 2730 enum attack-mitigation-terminated { 2731 value 6; 2732 description 2733 "Attack mitigation is now terminated."; 2734 } 2735 enum attack-mitigation-withdrawn { 2736 value 7; 2737 description 2738 "Attack mitigation is withdrawn."; 2739 } 2740 enum attack-mitigation-signal-loss { 2741 value 8; 2742 description 2743 "Attack mitigation will be triggered 2744 for the mitigation request only when 2745 the DOTS signal channel session is lost."; 2746 } 2747 } 2748 description 2749 "Enumeration for status reported by the DOTS server."; 2750 } 2752 typedef conflict-status { 2753 type enumeration { 2754 enum request-inactive-other-active { 2755 value 1; 2756 description 2757 "DOTS Server has detected conflicting mitigation 2758 requests from different DOTS clients. 2759 This mitigation request is currently inactive 2760 until the conflicts are resolved. Another 2761 mitigation request is active."; 2762 } 2763 enum request-active { 2764 value 2; 2765 description 2766 "DOTS Server has detected conflicting mitigation 2767 requests from different DOTS clients. 2768 This mitigation request is currently active."; 2769 } 2770 enum all-requests-inactive { 2771 value 3; 2772 description 2773 "DOTS Server has detected conflicting mitigation 2774 requests from different DOTS clients. All 2775 conflicting mitigation requests are inactive."; 2776 } 2777 } 2778 description 2779 "Enumeration for conflict status."; 2780 } 2782 typedef conflict-cause { 2783 type enumeration { 2784 enum overlapping-targets { 2785 value 1; 2786 description 2787 "Overlapping targets. conflict-scope provides 2788 more details about the exact conflict."; 2789 } 2790 enum conflict-with-acceptlist { 2791 value 2; 2792 description 2793 "Conflicts with an existing accept-list. 2795 This code is returned when the DDoS mitigation 2796 detects that some of the source addresses/prefixes 2797 listed in the accept-list ACLs are actually 2798 attacking the target."; 2799 } 2800 enum cuid-collision { 2801 value 3; 2802 description 2803 "Conflicts with the cuid used by another 2804 DOTS client."; 2805 } 2806 } 2807 description 2808 "Enumeration for conflict causes."; 2809 } 2811 typedef attack-status { 2812 type enumeration { 2813 enum under-attack { 2814 value 1; 2815 description 2816 "The DOTS client determines that it is still under 2817 attack."; 2818 } 2819 enum attack-successfully-mitigated { 2820 value 2; 2821 description 2822 "The DOTS client determines that the attack is 2823 successfully mitigated."; 2824 } 2825 } 2826 description 2827 "Enumeration for attack status codes."; 2828 } 2829 } 2830 2832 5.3. IETF DOTS Signal Channel YANG Module 2834 This module uses the common YANG types defined in [RFC6991] and types 2835 defined in [I-D.ietf-dots-data-channel]. 2837 file "ietf-dots-signal-channel@2019-01-17.yang" 2838 module ietf-dots-signal-channel { 2839 yang-version 1.1; 2840 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; 2841 prefix signal; 2843 import ietf-inet-types { 2844 prefix inet; 2845 reference "Section 4 of RFC 6991"; 2846 } 2847 import ietf-yang-types { 2848 prefix yang; 2849 reference "Section 3 of RFC 6991"; 2850 } 2851 import ietf-dots-data-channel { 2852 prefix ietf-data; 2853 reference 2854 "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling 2855 (DOTS) Data Channel Specification"; 2856 } 2857 import iana-dots-signal-channel { 2858 prefix iana-signal; 2859 } 2861 organization 2862 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 2863 contact 2864 "WG Web: 2865 WG List: 2867 Editor: Konda, Tirumaleswar Reddy 2868 2870 Editor: Mohamed Boucadair 2871 2873 Author: Prashanth Patil 2874 2876 Author: Andrew Mortensen 2877 2879 Author: Nik Teague 2880 "; 2881 description 2882 "This module contains YANG definition for the signaling 2883 messages exchanged between a DOTS client and a DOTS server. 2885 Copyright (c) 2019 IETF Trust and the persons identified as 2886 authors of the code. All rights reserved. 2888 Redistribution and use in source and binary forms, with or 2889 without modification, is permitted pursuant to, and subject 2890 to the license terms contained in, the Simplified BSD License 2891 set forth in Section 4.c of the IETF Trust's Legal Provisions 2892 Relating to IETF Documents 2893 (http://trustee.ietf.org/license-info). 2895 This version of this YANG module is part of RFC XXXX; see 2896 the RFC itself for full legal notices."; 2898 revision 2019-01-17 { 2899 description 2900 "Initial revision."; 2901 reference 2902 "RFC XXXX: Distributed Denial-of-Service Open Threat 2903 Signaling (DOTS) Signal Channel Specification"; 2904 } 2906 /* 2907 * Groupings 2908 */ 2910 grouping mitigation-scope { 2911 description 2912 "Specifies the scope of the mitigation request."; 2913 list scope { 2914 key "cuid mid"; 2915 description 2916 "The scope of the request."; 2917 leaf cdid { 2918 type string; 2919 description 2920 "The cdid should be included by a server-domain 2921 DOTS gateway to propagate the client domain 2922 identification information from the 2923 gateway's client-facing-side to the gateway's 2924 server-facing-side, and from the gateway's 2925 server-facing-side to the DOTS server. 2927 It may be used by the final DOTS server 2928 for policy enforcement purposes."; 2929 } 2930 leaf cuid { 2931 type string; 2932 description 2933 "A unique identifier that is 2934 generated by a DOTS client to prevent 2935 request collisions. It is expected that the 2936 cuid will remain consistent throughout the 2937 lifetime of the DOTS client."; 2938 } 2939 leaf mid { 2940 type uint32; 2941 description 2942 "Mitigation request identifier. 2944 This identifier must be unique for each mitigation 2945 request bound to the DOTS client."; 2946 } 2947 uses ietf-data:target; 2948 leaf-list alias-name { 2949 type string; 2950 description 2951 "An alias name that points to a resource."; 2952 } 2953 leaf lifetime { 2954 type int32; 2955 units "seconds"; 2956 default "3600"; 2957 description 2958 "Indicates the lifetime of the mitigation request. 2960 A lifetime of '0' in a mitigation request is an 2961 invalid value. 2963 A lifetime of negative one (-1) indicates indefinite 2964 lifetime for the mitigation request."; 2965 } 2966 leaf trigger-mitigation { 2967 type boolean; 2968 default "true"; 2969 description 2970 "If set to 'false', DDoS mitigation will not be 2971 triggered unless the DOTS signal channel 2972 session is lost."; 2973 } 2974 leaf mitigation-start { 2975 type uint64; 2976 config false; 2977 description 2978 "Mitigation start time is represented in seconds 2979 relative to 1970-01-01T00:00:00Z in UTC time."; 2980 } 2981 leaf status { 2982 type iana-signal:status; 2983 config false; 2984 description 2985 "Indicates the status of a mitigation request. 2986 It must be included in responses only."; 2987 } 2988 container conflict-information { 2989 config false; 2990 description 2991 "Indicates that a conflict is detected. 2992 Must only be used for responses."; 2993 leaf conflict-status { 2994 type iana-signal:conflict-status; 2995 description 2996 "Indicates the conflict status."; 2997 } 2998 leaf conflict-cause { 2999 type iana-signal:conflict-cause; 3000 description 3001 "Indicates the cause of the conflict."; 3002 } 3003 leaf retry-timer { 3004 type uint32; 3005 units "seconds"; 3006 description 3007 "The DOTS client must not re-send the 3008 same request that has a conflict before the expiry of 3009 this timer."; 3010 } 3011 container conflict-scope { 3012 description 3013 "Provides more information about the conflict scope."; 3014 uses ietf-data:target { 3015 when "../conflict-cause = 'overlapping-targets'"; 3016 } 3017 leaf-list alias-name { 3018 when "../../conflict-cause = 'overlapping-targets'"; 3019 type string; 3020 description 3021 "Conflicting alias-name."; 3022 } 3023 list acl-list { 3024 when "../../conflict-cause = 'conflict-with-acceptlist'"; 3025 key "acl-name"; 3026 description 3027 "List of conflicting ACLs as defined in the DOTS data 3028 channel. These ACLs are uniquely defined by 3029 cuid and acl-name."; 3030 leaf acl-name { 3031 type leafref { 3032 path "/ietf-data:dots-data/ietf-data:dots-client/" 3033 + "ietf-data:acls/ietf-data:acl/ietf-data:name"; 3034 } 3035 description 3036 "Reference to the conflicting ACL name bound to 3037 a DOTS client."; 3038 } 3039 leaf acl-type { 3040 type leafref { 3041 path "/ietf-data:dots-data/ietf-data:dots-client/" 3042 + "ietf-data:acls/ietf-data:acl/ietf-data:type"; 3043 } 3044 description 3045 "Reference to the conflicting ACL type bound to 3046 a DOTS client."; 3047 } 3048 } 3049 leaf mid { 3050 when "../../conflict-cause = 'overlapping-targets'"; 3051 type leafref { 3052 path "../../../mid"; 3053 } 3054 description 3055 "Reference to the conflicting 'mid' bound to 3056 the same DOTS client."; 3057 } 3058 } 3059 } 3060 leaf bytes-dropped { 3061 type yang:zero-based-counter64; 3062 units "bytes"; 3063 config false; 3064 description 3065 "The total dropped byte count for the mitigation 3066 request since the attack mitigation is triggered. 3067 The count wraps around when it reaches the maximum value 3068 of counter64 for dropped bytes."; 3069 } 3070 leaf bps-dropped { 3071 type yang:gauge64; 3072 config false; 3073 description 3074 "The average number of dropped bits per second for 3075 the mitigation request since the attack 3076 mitigation is triggered. This should be over 3077 five-minute intervals (that is, measuring bytes 3078 into five-minute buckets and then averaging these 3079 buckets over the time since the mitigation was 3080 triggered)."; 3081 } 3082 leaf pkts-dropped { 3083 type yang:zero-based-counter64; 3084 config false; 3085 description 3086 "The total number of dropped packet count for the 3087 mitigation request since the attack mitigation is 3088 triggered. The count wraps around when it reaches 3089 the maximum value of counter64 for dropped packets."; 3090 } 3091 leaf pps-dropped { 3092 type yang:gauge64; 3093 config false; 3094 description 3095 "The average number of dropped packets per second 3096 for the mitigation request since the attack 3097 mitigation is triggered. This should be over 3098 five-minute intervals (that is, measuring packets 3099 into five-minute buckets and then averaging these 3100 buckets over the time since the mitigation was 3101 triggered)."; 3102 } 3103 leaf attack-status { 3104 type iana-signal:attack-status; 3105 description 3106 "Indicates the status of an attack as seen by the 3107 DOTS client."; 3108 } 3109 } 3110 } 3112 grouping config-parameters { 3113 description 3114 "Subset of DOTS signal channel session configuration."; 3115 container heartbeat-interval { 3116 description 3117 "DOTS agents regularly send heartbeats to each other 3118 after mutual authentication is successfully 3119 completed in order to keep the DOTS signal channel 3120 open."; 3121 leaf max-value { 3122 type uint16; 3123 units "seconds"; 3124 config false; 3125 description 3126 "Maximum acceptable heartbeat-interval value."; 3127 } 3128 leaf min-value { 3129 type uint16; 3130 units "seconds"; 3131 config false; 3132 description 3133 "Minimum acceptable heartbeat-interval value."; 3134 } 3135 leaf current-value { 3136 type uint16; 3137 units "seconds"; 3138 default "30"; 3139 description 3140 "Current heartbeat-interval value. 3142 '0' means that heartbeat mechanism is deactivated."; 3143 } 3144 } 3145 container missing-hb-allowed { 3146 description 3147 "Maximum number of missing heartbeats allowed."; 3148 leaf max-value { 3149 type uint16; 3150 config false; 3151 description 3152 "Maximum acceptable missing-hb-allowed value."; 3153 } 3154 leaf min-value { 3155 type uint16; 3156 config false; 3157 description 3158 "Minimum acceptable missing-hb-allowed value."; 3159 } 3160 leaf current-value { 3161 type uint16; 3162 default "5"; 3163 description 3164 "Current missing-hb-allowed value."; 3165 } 3166 } 3167 container max-retransmit { 3168 description 3169 "Maximum number of retransmissions of a Confirmable 3170 message."; 3171 leaf max-value { 3172 type uint16; 3173 config false; 3174 description 3175 "Maximum acceptable max-retransmit value."; 3176 } 3177 leaf min-value { 3178 type uint16; 3179 config false; 3180 description 3181 "Minimum acceptable max-retransmit value."; 3182 } 3183 leaf current-value { 3184 type uint16; 3185 default "3"; 3186 description 3187 "Current max-retransmit value."; 3188 } 3189 } 3190 container ack-timeout { 3191 description 3192 "Initial retransmission timeout value."; 3193 leaf max-value-decimal { 3194 type decimal64 { 3195 fraction-digits 2; 3196 } 3197 units "seconds"; 3198 config false; 3199 description 3200 "Maximum ack-timeout value."; 3201 } 3202 leaf min-value-decimal { 3203 type decimal64 { 3204 fraction-digits 2; 3205 } 3206 units "seconds"; 3207 config false; 3208 description 3209 "Minimum ack-timeout value."; 3210 } 3211 leaf current-value-decimal { 3212 type decimal64 { 3213 fraction-digits 2; 3214 } 3215 units "seconds"; 3216 default "2"; 3217 description 3218 "Current ack-timeout value."; 3219 } 3220 } 3221 container ack-random-factor { 3222 description 3223 "Random factor used to influence the timing of 3224 retransmissions."; 3225 leaf max-value-decimal { 3226 type decimal64 { 3227 fraction-digits 2; 3228 } 3229 config false; 3230 description 3231 "Maximum acceptable ack-random-factor value."; 3232 } 3233 leaf min-value-decimal { 3234 type decimal64 { 3235 fraction-digits 2; 3236 } 3237 config false; 3238 description 3239 "Minimum acceptable ack-random-factor value."; 3240 } 3241 leaf current-value-decimal { 3242 type decimal64 { 3243 fraction-digits 2; 3244 } 3245 default "1.5"; 3246 description 3247 "Current ack-random-factor value."; 3248 } 3249 } 3250 } 3252 grouping signal-config { 3253 description 3254 "DOTS signal channel session configuration."; 3255 leaf sid { 3256 type uint32; 3257 mandatory true; 3258 description 3259 "An identifier for the DOTS signal channel 3260 session configuration data."; 3261 } 3262 container mitigating-config { 3263 description 3264 "Configuration parameters to use when a mitigation 3265 is active."; 3266 uses config-parameters; 3267 } 3268 container idle-config { 3269 description 3270 "Configuration parameters to use when no mitigation 3271 is active."; 3272 uses config-parameters; 3273 } 3274 } 3276 grouping redirected-signal { 3277 description 3278 "Grouping for the redirected signaling."; 3279 leaf alt-server { 3280 type string; 3281 config false; 3282 mandatory true; 3283 description 3284 "FQDN of an alternate server."; 3285 } 3286 leaf-list alt-server-record { 3287 type inet:ip-address; 3288 config false; 3289 description 3290 "List of records for the alternate server."; 3291 } 3292 } 3294 /* 3295 * Main Container for DOTS Signal Channel 3296 */ 3298 container dots-signal { 3299 description 3300 "Main container for DOTS signal message. 3302 A DOTS signal message can be a mitigation, a configuration, 3303 or a redirected signal message."; 3304 choice message-type { 3305 description 3306 "Can be a mitigation, a configuration, or a redirect 3307 message."; 3308 case mitigation-scope { 3309 description 3310 "Mitigation scope of a mitigation message."; 3311 uses mitigation-scope; 3313 } 3314 case signal-config { 3315 description 3316 "Configuration message."; 3317 uses signal-config; 3318 } 3319 case redirected-signal { 3320 description 3321 "Redirected signaling."; 3322 uses redirected-signal; 3323 } 3324 } 3325 } 3326 } 3327 3329 6. YANG/JSON Mapping Parameters to CBOR 3331 All parameters in the payload of the DOTS signal channel MUST be 3332 mapped to CBOR types as shown in Table 4 and are assigned an integer 3333 key to save space. 3335 o Note: Implementers must check that the mapping output provided by 3336 their YANG-to-CBOR encoding schemes is aligned with the content of 3337 Table 4. 3339 The CBOR key values are divided into two types: comprehension- 3340 required and comprehension-optional. DOTS agents can safely ignore 3341 comprehension-optional values they don't understand, but cannot 3342 successfully process a request if it contains comprehension-required 3343 values that are not understood. The 4.00 response SHOULD include a 3344 diagnostic payload describing the unknown comprehension-required CBOR 3345 key values. The initial set of CBOR key values defined in this 3346 specification are of type comprehension-required. 3348 +----------------------+-------------+-----+---------------+--------+ 3349 | Parameter Name | YANG | CBOR| CBOR Major | JSON | 3350 | | Type | Key | Type & | Type | 3351 | | | | Information | | 3352 +----------------------+-------------+-----+---------------+--------+ 3353 | ietf-dots-signal-cha | | | | | 3354 | nnel:mitigation-scope| container | 1 | 5 map | Object | 3355 | scope | list | 2 | 4 array | Array | 3356 | cdid | string | 3 | 3 text string | String | 3357 | cuid | string | 4 | 3 text string | String | 3358 | mid | uint32 | 5 | 0 unsigned | Number | 3359 | target-prefix | leaf-list | 6 | 4 array | Array | 3360 | | inet: | | | | 3361 | | ip-prefix | | 3 text string | String | 3362 | target-port-range | list | 7 | 4 array | Array | 3363 | lower-port | inet: | | | | 3364 | | port-number| 8 | 0 unsigned | Number | 3365 | upper-port | inet: | | | | 3366 | | port-number| 9 | 0 unsigned | Number | 3367 | target-protocol | leaf-list | 10 | 4 array | Array | 3368 | | uint8 | | 0 unsigned | Number | 3369 | target-fqdn | leaf-list | 11 | 4 array | Array | 3370 | | inet: | | | | 3371 | | domain-name| | 3 text string | String | 3372 | target-uri | leaf-list | 12 | 4 array | Array | 3373 | | inet:uri | | 3 text string | String | 3374 | alias-name | leaf-list | 13 | 4 array | Array | 3375 | | string | | 3 text string | String | 3376 | lifetime | int32 | 14 | 0 unsigned | Number | 3377 | | | | 1 negative | Number | 3378 | mitigation-start | uint64 | 15 | 0 unsigned | String | 3379 | status | enumeration | 16 | 0 unsigned | String | 3380 | conflict-information | container | 17 | 5 map | Object | 3381 | conflict-status | enumeration | 18 | 0 unsigned | String | 3382 | conflict-cause | enumeration | 19 | 0 unsigned | String | 3383 | retry-timer | uint32 | 20 | 0 unsigned | Number | 3384 | conflict-scope | container | 21 | 5 map | Object | 3385 | acl-list | list | 22 | 4 array | Array | 3386 | acl-name | leafref | 23 | 3 text string | String | 3387 | acl-type | leafref | 24 | 3 text string | String | 3388 | bytes-dropped | yang:zero- | | | | 3389 | | based- | | | | 3390 | | counter64 | 25 | 0 unsigned | String | 3391 | bps-dropped | yang:gauge64| 26 | 0 unsigned | String | 3392 | pkts-dropped | yang:zero- | | | | 3393 | | based- | | | | 3394 | | counter64 | 27 | 0 unsigned | String | 3395 | pps-dropped | yang:gauge64| 28 | 0 unsigned | String | 3396 | attack-status | enumeration | 29 | 0 unsigned | String | 3397 | ietf-dots-signal- | | | | | 3398 | channel:signal-config| container | 30 | 5 map | Object | 3399 | sid | uint32 | 31 | 0 unsigned | Number | 3400 | mitigating-config | container | 32 | 5 map | Object | 3401 | heartbeat-interval | container | 33 | 5 map | Object | 3402 | max-value | uint16 | 34 | 0 unsigned | Number | 3403 | min-value | uint16 | 35 | 0 unsigned | Number | 3404 | current-value | uint16 | 36 | 0 unsigned | Number | 3405 | missing-hb-allowed | container | 37 | 5 map | Object | 3406 | max-retransmit | container | 38 | 5 map | Object | 3407 | ack-timeout | container | 39 | 5 map | Object | 3408 | ack-random-factor | container | 40 | 5 map | Object | 3409 | max-value-decimal | decimal64 | 41 | 6 tag 4 | | 3410 | | | | [-2, integer]| String | 3411 | min-value-decimal | decimal64 | 42 | 6 tag 4 | | 3412 | | | | [-2, integer]| String | 3413 | current-value-decimal| decimal64 | 43 | 6 tag 4 | | 3414 | | | | [-2, integer]| String | 3415 | idle-config | container | 44 | 5 map | Object | 3416 | trigger-mitigation | boolean | 45 | 7 bits 20 | False | 3417 | | | | 7 bits 21 | True | 3418 | ietf-dots-signal-cha | | | | | 3419 |nnel:redirected-signal| container | 46 | 5 map | Object | 3420 | alt-server | string | 47 | 3 text string | String | 3421 | alt-server-record | leaf-list | 48 | 4 array | Array | 3422 | | inet: | | | | 3423 | | ip-address | | 3 text string | String | 3424 +----------------------+-------------+-----+---------------+--------+ 3426 Table 4: CBOR Key Values Used in DOTS Signal Channel Messages & Their 3427 Mappings to JSON and YANG 3429 7. (D)TLS Protocol Profile and Performance Considerations 3431 7.1. (D)TLS Protocol Profile 3433 This section defines the (D)TLS protocol profile of DOTS signal 3434 channel over (D)TLS and DOTS data channel over TLS. 3436 There are known attacks on (D)TLS, such as man-in-the-middle and 3437 protocol downgrade attacks. These are general attacks on (D)TLS and, 3438 as such, they are not specific to DOTS over (D)TLS; refer to the 3439 (D)TLS RFCs for discussion of these security issues. DOTS agents 3440 MUST adhere to the (D)TLS implementation recommendations and security 3441 considerations of [RFC7525] except with respect to (D)TLS version. 3442 Since DOTS signal channel encryption relying upon (D)TLS is virtually 3443 a green-field deployment, DOTS agents MUST implement only (D)TLS 1.2 3444 or later. 3446 When a DOTS client is configured with a domain name of the DOTS 3447 server, and connects to its configured DOTS server, the server may 3448 present it with a PKIX certificate. In order to ensure proper 3449 authentication, a DOTS client MUST verify the entire certification 3450 path per [RFC5280]. Additionally, the DOTS client MUST use [RFC6125] 3451 validation techniques to compare the domain name with the certificate 3452 provided. Certification authorities that issue DOTS server 3453 certificates SHOULD support the DNS-ID and SRV-ID identifier types. 3454 DOTS server SHOULD prefer the use of DNS-ID and SRV-ID over CN-ID 3455 identifier types in certificate requests (as described in Section 2.3 3456 of [RFC6125]) and the wildcard character '*' SHOULD NOT be included 3457 in the presented identifier. DOTS doesn't use URI-IDs for server 3458 identity verification. 3460 A key challenge to deploying DOTS is the provisioning of DOTS 3461 clients, including the distribution of keying material to DOTS 3462 clients to enable the required mutual authentication of DOTS agents. 3463 Enrollment over Secure Transport (EST) [RFC7030] defines a method of 3464 certificate enrollment by which domains operating DOTS servers may 3465 provide DOTS clients with all the necessary cryptographic keying 3466 material, including a private key and a certificate to authenticate 3467 themselves. One deployment option is DOTS clients behave as EST 3468 clients for certificate enrollment from an EST server provisioned by 3469 the mitigation provider. This document does not specify which EST or 3470 other mechanism the DOTS client uses to achieve initial enrollment. 3472 The Server Name Indication (SNI) extension [RFC6066] defines a 3473 mechanism for a client to tell a (D)TLS server the name of the server 3474 it wants to contact. This is a useful extension for hosting 3475 environments where multiple virtual servers are reachable over a 3476 single IP address. The DOTS client may or may not know if it is 3477 interacting with a DOTS server in a virtual server hosting 3478 environment, so the DOTS client SHOULD include the DOTS server FQDN 3479 in the SNI extension. 3481 Implementations compliant with this profile MUST implement all of the 3482 following items: 3484 o DTLS record replay detection (Section 3.3 of [RFC6347]) or an 3485 equivalent mechanism to protect against replay attacks. 3487 o DTLS session resumption without server-side state to resume 3488 session and convey the DOTS signal. 3490 o At least one of raw public keys [RFC7250] or PSK handshake 3491 [RFC4279] with (EC)DHE key exchange which reduces the size of the 3492 ServerHello, and can be used by DOTS agents that cannot obtain 3493 certificates. 3495 Implementations compliant with this profile SHOULD implement all of 3496 the following items to reduce the delay required to deliver a DOTS 3497 signal channel message: 3499 o TLS False Start [RFC7918] which reduces round-trips by allowing 3500 the TLS client's second flight of messages (ChangeCipherSpec) to 3501 also contain the DOTS signal. TLS False Start is formally defined 3502 for use with TLS, but the same technique is applicable to DTLS as 3503 well. 3505 o Cached Information Extension [RFC7924] which avoids transmitting 3506 the server's certificate and certificate chain if the client has 3507 cached that information from a previous TLS handshake. 3509 Compared to UDP, DOTS signal channel over TCP requires an additional 3510 round-trip time (RTT) of latency to establish a TCP connection. DOTS 3511 implementations are encouraged to implement TCP Fast Open [RFC7413] 3512 to eliminate that RTT. 3514 7.2. (D)TLS 1.3 Considerations 3516 TLS 1.3 provides critical latency improvements for connection 3517 establishment over TLS 1.2. The DTLS 1.3 protocol 3518 [I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides 3519 equivalent security guarantees. (D)TLS 1.3 provides two basic 3520 handshake modes the DOTS signal channel can take advantage of: 3522 o A full handshake mode in which a DOTS client can send a DOTS 3523 mitigation request message after one round trip and the DOTS 3524 server immediately responds with a DOTS mitigation response. This 3525 assumes no packet loss is experienced. 3527 o 0-RTT mode in which the DOTS client can authenticate itself and 3528 send DOTS mitigation request messages in the first message, thus 3529 reducing handshake latency. 0-RTT only works if the DOTS client 3530 has previously communicated with that DOTS server, which is very 3531 likely with the DOTS signal channel. 3533 The DOTS client has to establish a (D)TLS session with the DOTS 3534 server during 'idle' time and share a PSK. 3536 During a DDoS attack, the DOTS client can use the (D)TLS session 3537 to convey the DOTS mitigation request message and, if there is no 3538 response from the server after multiple retries, the DOTS client 3539 can resume the (D)TLS session in 0-RTT mode using PSK. 3541 DOTS servers that support (D)TLS 1.3 MAY allow DOTS clients to 3542 send early data (0-RTT). DOTS clients MUST NOT send "CoAP Ping" 3543 as early data; such messages MUST be rejected by DOTS servers. 3544 Section 8 of [RFC8446] discusses some mechanisms to implement to 3545 limit the impact of replay attacks on 0-RTT data. If the DOTS 3546 server accepts 0-RTT, it MUST implement one of these mechanisms to 3547 prevent replay at the TLS layer. A DOTS server can reject 0-RTT 3548 by sending a TLS HelloRetryRequest. 3550 The DOTS signal channel messages sent as early data by the DOTS 3551 client are idempotent requests. As a reminder, the Message ID 3552 (Section 3 of [RFC7252]) is changed each time a new CoAP request 3553 is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized 3554 in each CoAP request. The DOTS server(s) MUST use the Message ID 3555 and the Token in the DOTS signal channel message to detect replay 3556 of early data at the application layer, and accept 0-RTT data at 3557 most once from the same DOTS client. This anti-replay defense 3558 requires sharing the Message ID and the Token in the 0-RTT data 3559 between DOTS servers in the DOTS server domain. DOTS servers do 3560 not rely on transport coordinates to identify DOTS peers. As 3561 specified in Section 4.4.1, DOTS servers couple the DOTS signal 3562 channel sessions using the DOTS client identity and optionally the 3563 'cdid' parameter value. Furthermore, 'mid' value is monotonically 3564 increased by the DOTS client for each mitigation request, 3565 attackers replaying mitigation requests with lower numeric 'mid' 3566 values and overlapping scopes with mitigation requests having 3567 higher numeric 'mid' values will be rejected systematically by the 3568 DOTS server. Likewise, 'sid' value is monotonically increased by 3569 the DOTS client for each configuration request (Section 4.5.2), 3570 attackers replaying configuration requests with lower numeric 3571 'sid' values will be rejected by the DOTS server if it maintains a 3572 higher numeric 'sid' value for this DOTS client. 3574 Owing to the aforementioned protections, all DOTS signal channel 3575 requests are safe to transmit in TLS 1.3 as early data. Refer to 3576 [I-D.boucadair-dots-earlydata] for more details. 3578 A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request 3579 message exchange is shown in Figure 27. 3581 DOTS Client DOTS Server 3583 ClientHello 3584 (0-RTT DOTS signal message) 3585 --------> 3586 ServerHello 3587 {EncryptedExtensions} 3588 {Finished} 3589 <-------- [DOTS signal message] 3590 (end_of_early_data) 3591 {Finished} --------> 3592 [DOTS signal message] <-------> [DOTS signal message] 3594 Note that: 3595 () Indicates messages protected 0-RTT keys 3596 {} Indicates messages protected using handshake keys 3597 [] Indicates messages protected using 1-RTT keys 3599 Figure 27: A Simplified TLS 1.3 Handshake with 0-RTT 3601 7.3. DTLS MTU and Fragmentation 3603 To avoid DOTS signal message fragmentation and the subsequent 3604 decreased probability of message delivery, DOTS agents MUST ensure 3605 that the DTLS record fit within a single datagram. If the PMTU 3606 cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, 3607 as IPv6 requires that every link in the Internet have an MTU of 1280 3608 octets or greater as specified in [RFC8200]. If IPv4 support on 3609 legacy or otherwise unusual networks is a consideration and the PMTU 3610 is unknown, DOTS implementations MAY assume on a PMTU of 576 bytes 3611 for IPv4 datagrams, as every IPv4 host must be capable of receiving a 3612 packet whose length is equal to 576 bytes as discussed in [RFC0791] 3613 and [RFC1122]. 3615 The DOTS client must consider the amount of record expansion expected 3616 by the DTLS processing when calculating the size of CoAP message that 3617 fits within the path MTU. Path MTU MUST be greater than or equal to 3618 [CoAP message size + DTLS 1.2 overhead of 13 octets + authentication 3619 overhead of the negotiated DTLS cipher suite + block padding] 3620 (Section 4.1.1.1 of [RFC6347]). If the total request size exceeds 3621 the path MTU then the DOTS client MUST split the DOTS signal into 3622 separate messages; for example, the list of addresses in the 'target- 3623 prefix' parameter could be split into multiple lists and each list 3624 conveyed in a new PUT request. 3626 Implementation Note: DOTS choice of message size parameters works 3627 well with IPv6 and with most of today's IPv4 paths. However, with 3628 IPv4, it is harder to safely make sure that there is no IP 3629 fragmentation. If the IPv4 path MTU is unknown, implementations may 3630 want to limit themselves to more conservative IPv4 datagram sizes 3631 such as 576 bytes, as per [RFC0791]. 3633 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 3635 (D)TLS based upon client certificate can be used for mutual 3636 authentication between DOTS agents. If, for example, a DOTS gateway 3637 is involved, DOTS clients and DOTS gateways must perform mutual 3638 authentication; only authorized DOTS clients are allowed to send DOTS 3639 signals to a DOTS gateway. The DOTS gateway and the DOTS server must 3640 perform mutual authentication; a DOTS server only allows DOTS signal 3641 channel messages from an authorized DOTS gateway, thereby creating a 3642 two-link chain of transitive authentication between the DOTS client 3643 and the DOTS server. 3645 The DOTS server should support certificate-based client 3646 authentication. The DOTS client should respond to the DOTS server's 3647 TLS CertificateRequest message with the PKIX certificate held by the 3648 DOTS client. DOTS client certificate validation must be performed as 3649 per [RFC5280] and the DOTS client certificate must conform to the 3650 [RFC5280] certificate profile. If a DOTS client does not support TLS 3651 client certificate authentication, it must support pre-shared key 3652 based or raw public key based client authentication. 3654 +-----------------------------------------------+ 3655 | example.com domain +---------+ | 3656 | | AAA | | 3657 | +---------------+ | Server | | 3658 | | Application | +------+--+ | 3659 | | server +<-----------------+ ^ | 3660 | | (DOTS client) | | | | 3661 | +---------------+ | | | 3662 | V V | example.net domain 3663 | +-----+----+--+ | +---------------+ 3664 | +--------------+ | | | | | 3665 | | Guest +<-----x----->+ DOTS +<------>+ DOTS | 3666 | | (DOTS client)| | gateway | | | server | 3667 | +--------------+ | | | | | 3668 | +----+--------+ | +---------------+ 3669 | ^ | 3670 | | | 3671 | +----------------+ | | 3672 | | DDoS detector | | | 3673 | | (DOTS client) +<---------------+ | 3674 | +----------------+ | 3675 +-----------------------------------------------+ 3677 Figure 28: Example of Authentication and Authorization of DOTS Agents 3679 In the example depicted in Figure 28, the DOTS gateway and DOTS 3680 clients within the 'example.com' domain mutually authenticate. After 3681 the DOTS gateway validates the identity of a DOTS client, it 3682 communicates with the AAA server in the 'example.com' domain to 3683 determine if the DOTS client is authorized to request DDoS 3684 mitigation. If the DOTS client is not authorized, a 4.01 3685 (Unauthorized) is returned in the response to the DOTS client. In 3686 this example, the DOTS gateway only allows the application server and 3687 DDoS attack detector to request DDoS mitigation, but does not permit 3688 the user of type 'guest' to request DDoS mitigation. 3690 Also, DOTS gateways and servers located in different domains must 3691 perform mutual authentication (e.g., using certificates). A DOTS 3692 server will only allow a DOTS gateway with a certificate for a 3693 particular domain to request mitigation for that domain. In 3694 reference to Figure 28, the DOTS server only allows the DOTS gateway 3695 to request mitigation for 'example.com' domain and not for other 3696 domains. 3698 9. IANA Considerations 3700 9.1. DOTS Signal Channel UDP and TCP Port Number 3702 IANA is requested to assign the port number TBD to the DOTS signal 3703 channel protocol for both UDP and TCP from the "Service Name and 3704 Transport Protocol Port Number Registry" available at 3705 https://www.iana.org/assignments/service-names-port-numbers/service- 3706 names-port-numbers.xhtml. 3708 The assignment of port number 4646 is strongly suggested, as 4646 is 3709 the ASCII decimal value for ".." (DOTS). 3711 9.2. Well-Known 'dots' URI 3713 This document requests IANA to register the 'dots' well-known URI 3714 (Table 5) in the Well-Known URIs registry 3715 (https://www.iana.org/assignments/well-known-uris/well-known- 3716 uris.xhtml) as defined by [RFC5785]: 3718 +----------+----------------+---------------------+-----------------+ 3719 | URI | Change | Specification | Related | 3720 | suffix | controller | document(s) | information | 3721 +----------+----------------+---------------------+-----------------+ 3722 | dots | IETF | [RFCXXXX] | None | 3723 +----------+----------------+---------------------+-----------------+ 3725 Table 5: 'dots' well-known URI 3727 9.3. Media Type Registration 3729 This document requests IANA to register the "application/dots+cbor" 3730 media type in the "Media Types" registry [IANA.MediaTypes] in the 3731 manner described in [RFC6838], which can be used to indicate that the 3732 content is a DOTS signal channel object: 3734 o Type name: application 3735 o Subtype name: dots+cbor 3736 o Required parameters: N/A 3737 o Optional parameters: N/A 3738 o Encoding considerations: binary 3739 o Security considerations: See the Security Considerations section 3740 of [RFCXXXX] 3741 o Interoperability considerations: N/A 3742 o Published specification: [RFCXXXX] 3743 o Applications that use this media type: DOTS agents sending DOTS 3744 messages over CoAP over (D)TLS. 3745 o Fragment identifier considerations: N/A 3746 o Additional information: 3748 Magic number(s): N/A 3749 File extension(s): N/A 3750 Macintosh file type code(s): N/A 3751 o Person & email address to contact for further information: 3752 IESG, iesg@ietf.org 3753 o Intended usage: COMMON 3754 o Restrictions on usage: none 3755 o Author: See Authors' Addresses section. 3756 o Change controller: IESG 3757 o Provisional registration? No 3759 9.4. CoAP Content-Formats Registration 3761 This document requests IANA to register the CoAP Content-Format ID 3762 for the "application/dots+cbor" media type in the "CoAP Content- 3763 Formats" registry [IANA.CoAP.Content-Formats] (0-255 range): 3765 o Media Type: application/dots+cbor 3766 o Encoding: - 3767 o Id: TBD1 3768 o Reference: [RFCXXXX] 3770 9.5. CBOR Tag Registration 3772 This section defines the DOTS CBOR tag as another means for 3773 applications to declare that a CBOR data structure is a DOTS signal 3774 channel object. Its use is optional and is intended for use in cases 3775 in which this information would not otherwise be known. DOTS CBOR 3776 tag is not required for DOTS signal channel protocol version 3777 specified in this document. If present, the DOTS tag MUST prefix a 3778 DOTS signal channel object. 3780 This document requests IANA to register the DOTS signal channel CBOR 3781 tag in the "CBOR Tags" registry [IANA.CBOR.Tags] using the 24-255 3782 range: 3784 o CBOR Tag: TBD2 (please assign the same value as the Content- 3785 Format) 3786 o Data Item: DDoS Open Threat Signaling (DOTS) signal channel object 3787 o Semantics: DDoS Open Threat Signaling (DOTS) signal channel 3788 object, as defined in [RFCXXXX] 3789 o Description of Semantics: [RFCXXXX] 3791 9.6. DOTS Signal Channel Protocol Registry 3793 The document requests IANA to create a new registry, entitled "DOTS 3794 Signal Channel Registry". The following sections define sub- 3795 registries. 3797 9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry 3799 The document requests IANA to create a new sub-registry, entitled 3800 "DOTS Signal Channel CBOR Key Values". 3802 The structure of this sub-registry is provided in Section 9.6.1.1. 3803 Section 9.6.1.2 provides how the registry is initially populated with 3804 the values in Table 4. 3806 9.6.1.1. Registration Template 3808 Parameter name: 3809 Parameter name as used in the DOTS signal channel. 3811 CBOR Key Value: 3812 Key value for the parameter. The key value MUST be an integer in 3813 the 1-65535 range. The key values of the comprehension-required 3814 range (0x0001 - 0x3FFF) and of the comprehension-optional range 3815 (0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of 3816 [RFC8126]). The key values of the comprehension-optional range 3817 (0x4000 - 0x7FFF) are assigned by Specification Required 3818 (Section 4.6 of [RFC8126]) and of the comprehension-optional range 3819 (0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of 3820 [RFC8126]). 3822 Registration requests for the 0x4000 - 0x7FFF range are evaluated 3823 after a three-week review period on the dots-signal-reg- 3824 review@ietf.org mailing list, on the advice of one or more 3825 Designated Experts. However, to allow for the allocation of 3826 values prior to publication, the Designated Experts may approve 3827 registration once they are satisfied that such a specification 3828 will be published. New registration requests should be sent in 3829 the form of an email to the review mailing list; the request 3830 should use an appropriate subject (e.g., "Request to register CBOR 3831 Key Value for DOTS: example"). IANA will only accept new 3832 registrations from the Designated Experts, and will check that 3833 review was requested on the mailing list in accordance with these 3834 procedures. 3836 Within the review period, the Designated Experts will either 3837 approve or deny the registration request, communicating this 3838 decision to the review list and IANA. Denials should include an 3839 explanation and, if applicable, suggestions as to how to make the 3840 request successful. Registration requests that are undetermined 3841 for a period longer than 21 days can be brought to the IESG's 3842 attention (using the iesg@ietf.org mailing list) for resolution. 3844 Criteria that should be applied by the Designated Experts includes 3845 determining whether the proposed registration duplicates existing 3846 functionality, whether it is likely to be of general applicability 3847 or whether it is useful only for a single use case, and whether 3848 the registration description is clear. IANA must only accept 3849 registry updates to the 0x4000 - 0x7FFF range from the Designated 3850 Experts and should direct all requests for registration to the 3851 review mailing list. It is suggested that multiple Designated 3852 Experts be appointed. In cases where a registration decision 3853 could be perceived as creating a conflict of interest for a 3854 particular Expert, that Expert should defer to the judgment of the 3855 other Experts. 3857 CBOR Major Type: 3858 CBOR Major type and optional tag for the parameter. 3860 Change Controller: 3861 For Standards Track RFCs, list the "IESG". For others, give the 3862 name of the responsible party. Other details (e.g., email 3863 address) may also be included. 3865 Specification Document(s): 3866 Reference to the document or documents that specify the parameter, 3867 preferably including URIs that can be used to retrieve copies of 3868 the documents. An indication of the relevant sections may also be 3869 included but is not required. 3871 9.6.1.2. Initial Sub-Registry Content 3873 +----------------------+-------+-------+------------+---------------+ 3874 | Parameter Name | CBOR | CBOR | Change | Specification | 3875 | | Key | Major | Controller | Document(s) | 3876 | | Value | Type | | | 3877 +----------------------+-------+-------+------------+---------------+ 3878 | ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] | 3879 | nel:mitigation-scope | | | | | 3880 | scope | 2 | 4 | IESG | [RFCXXXX] | 3881 | cdid | 3 | 3 | IESG | [RFCXXXX] | 3882 | cuid | 4 | 3 | IESG | [RFCXXXX] | 3883 | mid | 5 | 0 | IESG | [RFCXXXX] | 3884 | target-prefix | 6 | 4 | IESG | [RFCXXXX] | 3885 | target-port-range | 7 | 4 | IESG | [RFCXXXX] | 3886 | lower-port | 8 | 0 | IESG | [RFCXXXX] | 3887 | upper-port | 9 | 0 | IESG | [RFCXXXX] | 3888 | target-protocol | 10 | 4 | IESG | [RFCXXXX] | 3889 | target-fqdn | 11 | 4 | IESG | [RFCXXXX] | 3890 | target-uri | 12 | 4 | IESG | [RFCXXXX] | 3891 | alias-name | 13 | 4 | IESG | [RFCXXXX] | 3892 | lifetime | 14 | 0/1 | IESG | [RFCXXXX] | 3893 | mitigation-start | 15 | 0 | IESG | [RFCXXXX] | 3894 | status | 16 | 0 | IESG | [RFCXXXX] | 3895 | conflict-information | 17 | 5 | IESG | [RFCXXXX] | 3896 | conflict-status | 18 | 0 | IESG | [RFCXXXX] | 3897 | conflict-cause | 19 | 0 | IESG | [RFCXXXX] | 3898 | retry-timer | 20 | 0 | IESG | [RFCXXXX] | 3899 | conflict-scope | 21 | 5 | IESG | [RFCXXXX] | 3900 | acl-list | 22 | 4 | IESG | [RFCXXXX] | 3901 | acl-name | 23 | 3 | IESG | [RFCXXXX] | 3902 | acl-type | 24 | 3 | IESG | [RFCXXXX] | 3903 | bytes-dropped | 25 | 0 | IESG | [RFCXXXX] | 3904 | bps-dropped | 26 | 0 | IESG | [RFCXXXX] | 3905 | pkts-dropped | 27 | 0 | IESG | [RFCXXXX] | 3906 | pps-dropped | 28 | 0 | IESG | [RFCXXXX] | 3907 | attack-status | 29 | 0 | IESG | [RFCXXXX] | 3908 | ietf-dots-signal- | 30 | 5 | IESG | [RFCXXXX] | 3909 | channel:signal-config| | | | | 3910 | sid | 31 | 0 | IESG | [RFCXXXX] | 3911 | mitigating-config | 32 | 5 | IESG | [RFCXXXX] | 3912 | heartbeat-interval | 33 | 5 | IESG | [RFCXXXX] | 3913 | min-value | 34 | 0 | IESG | [RFCXXXX] | 3914 | max-value | 35 | 0 | IESG | [RFCXXXX] | 3915 | current-value | 36 | 0 | IESG | [RFCXXXX] | 3916 | missing-hb-allowed | 37 | 5 | IESG | [RFCXXXX] | 3917 | max-retransmit | 38 | 5 | IESG | [RFCXXXX] | 3918 | ack-timeout | 39 | 5 | IESG | [RFCXXXX] | 3919 | ack-random-factor | 40 | 5 | IESG | [RFCXXXX] | 3920 | min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] | 3921 | max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] | 3922 | current-value- | 43 | 6tag4 | IESG | [RFCXXXX] | 3923 | decimal | | | | | 3924 | idle-config | 44 | 5 | IESG | [RFCXXXX] | 3925 | trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | 3926 | ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] | 3927 | nel:redirected-signal| | | | | 3928 | alt-server | 47 | 3 | IESG | [RFCXXXX] | 3929 | alt-server-record | 48 | 4 | IESG | [RFCXXXX] | 3930 +----------------------+-------+-------+------------+---------------+ 3932 Table 6: Initial DOTS Signal Channel CBOR Key Values Registry 3934 9.6.2. Status Codes Sub-Registry 3936 The document requests IANA to create a new sub-registry, entitled 3937 "DOTS Signal Channel Status Codes". Codes in this registry are used 3938 as valid values of 'status' parameter. 3940 The registry is initially populated with the following values: 3942 +-----+----------------------------------+--------------+-----------+ 3943 | Cod | Label | Description | Reference | 3944 | e | | | | 3945 +-----+----------------------------------+--------------+-----------+ 3946 | 1 | attack-mitigation-in-progress | Attack | [RFCXXXX] | 3947 | | | mitigation | | 3948 | | | setup is in | | 3949 | | | progress | | 3950 | | | (e.g., | | 3951 | | | changing the | | 3952 | | | network path | | 3953 | | | to redirect | | 3954 | | | the inbound | | 3955 | | | traffic to a | | 3956 | | | DOTS | | 3957 | | | mitigator). | | 3958 | 2 | attack-successfully-mitigated | Attack is | [RFCXXXX] | 3959 | | | being | | 3960 | | | successfully | | 3961 | | | mitigated | | 3962 | | | (e.g., | | 3963 | | | traffic is | | 3964 | | | redirected | | 3965 | | | to a DDoS | | 3966 | | | mitigator | | 3967 | | | and attack | | 3968 | | | traffic is | | 3969 | | | dropped). | | 3970 | 3 | attack-stopped | Attack has | [RFCXXXX] | 3971 | | | stopped and | | 3972 | | | the DOTS | | 3973 | | | client can | | 3974 | | | withdraw the | | 3975 | | | mitigation | | 3976 | | | request. | | 3977 | 4 | attack-exceeded-capability | Attack has | [RFCXXXX] | 3978 | | | exceeded the | | 3979 | | | mitigation | | 3980 | | | provider | | 3981 | | | capability. | | 3982 | 5 | dots-client-withdrawn-mitigation | DOTS client | [RFCXXXX] | 3983 | | | has | | 3984 | | | withdrawn | | 3985 | | | the | | 3986 | | | mitigation | | 3987 | | | request and | | 3988 | | | the | | 3989 | | | mitigation | | 3990 | | | is active | | 3991 | | | but | | 3992 | | | terminating. | | 3993 | 6 | attack-mitigation-terminated | Attack | [RFCXXXX] | 3994 | | | mitigation | | 3995 | | | is now | | 3996 | | | terminated. | | 3997 | 7 | attack-mitigation-withdrawn | Attack | [RFCXXXX] | 3998 | | | mitigation | | 3999 | | | is | | 4000 | | | withdrawn. | | 4001 | 8 | attack-mitigation-signal-loss | Attack | [RFCXXXX] | 4002 | | | mitigation | | 4003 | | | will be | | 4004 | | | triggered | | 4005 | | | for the | | 4006 | | | mitigation | | 4007 | | | request only | | 4008 | | | when the | | 4009 | | | DOTS signal | | 4010 | | | channel | | 4011 | | | session is | | 4012 | | | lost. | | 4013 +-----+----------------------------------+--------------+-----------+ 4015 New codes can be assigned via Standards Action [RFC8126]. 4017 9.6.3. Conflict Status Codes Sub-Registry 4019 The document requests IANA to create a new sub-registry, entitled 4020 "DOTS Signal Channel Conflict Status Codes". Codes in this registry 4021 are used as valid values of 'conflict-status' parameter. 4023 The registry is initially populated with the following values: 4025 +------+-------------------------------+----------------+-----------+ 4026 | Code | Label | Description | Reference | 4027 +------+-------------------------------+----------------+-----------+ 4028 | 1 | request-inactive-other-active | DOTS server | [RFCXXXX] | 4029 | | | has detected | | 4030 | | | conflicting | | 4031 | | | mitigation | | 4032 | | | requests from | | 4033 | | | different DOTS | | 4034 | | | clients. This | | 4035 | | | mitigation | | 4036 | | | request is | | 4037 | | | currently | | 4038 | | | inactive until | | 4039 | | | the conflicts | | 4040 | | | are resolved. | | 4041 | | | Another | | 4042 | | | mitigation | | 4043 | | | request is | | 4044 | | | active. | | 4045 | 2 | request-active | DOTS server | [RFCXXXX] | 4046 | | | has detected | | 4047 | | | conflicting | | 4048 | | | mitigation | | 4049 | | | requests from | | 4050 | | | different DOTS | | 4051 | | | clients. This | | 4052 | | | mitigation | | 4053 | | | request is | | 4054 | | | currently | | 4055 | | | active. | | 4056 | 3 | all-requests-inactive | DOTS server | [RFCXXXX] | 4057 | | | has detected | | 4058 | | | conflicting | | 4059 | | | mitigation | | 4060 | | | requests from | | 4061 | | | different DOTS | | 4062 | | | clients. All | | 4063 | | | conflicting | | 4064 | | | mitigation | | 4065 | | | requests are | | 4066 | | | inactive. | | 4067 +------+-------------------------------+----------------+-----------+ 4069 New codes can be assigned via Standards Action [RFC8126]. 4071 9.6.4. Conflict Cause Codes Sub-Registry 4073 The document requests IANA to create a new sub-registry, entitled 4074 "DOTS Signal Channel Conflict Cause Codes". Codes in this registry 4075 are used as valid values of 'conflict-cause' parameter. 4077 The registry is initially populated with the following values: 4079 +------+--------------------------+---------------------+-----------+ 4080 | Code | Label | Description | Reference | 4081 +------+--------------------------+---------------------+-----------+ 4082 | 1 | overlapping-targets | Overlapping | [RFCXXXX] | 4083 | | | targets. | | 4084 | 2 | conflict-with-acceptlist | Conflicts with an | [RFCXXXX] | 4085 | | | existing accept- | | 4086 | | | list. This code is | | 4087 | | | returned when the | | 4088 | | | DDoS mitigation | | 4089 | | | detects source | | 4090 | | | addresses/prefixes | | 4091 | | | in the accept- | | 4092 | | | listed ACLs are | | 4093 | | | attacking the | | 4094 | | | target. | | 4095 | 3 | cuid-collision | CUID Collision. | [RFCXXXX] | 4096 | | | This code is | | 4097 | | | returned when a | | 4098 | | | DOTS client uses a | | 4099 | | | 'cuid' that is | | 4100 | | | already used by | | 4101 | | | another DOTS | | 4102 | | | client. | | 4103 +------+--------------------------+---------------------+-----------+ 4105 New codes can be assigned via Standards Action [RFC8126]. 4107 9.6.5. Attack Status Codes Sub-Registry 4109 The document requests IANA to create a new sub-registry, entitled 4110 "DOTS Signal Channel Attack Status Codes". Codes in this registry 4111 are used as valid values of 'attack-status' parameter. 4113 The registry is initially populated with the following values: 4115 +------+-------------------------------+----------------+-----------+ 4116 | Code | Label | Description | Reference | 4117 +------+-------------------------------+----------------+-----------+ 4118 | 1 | under-attack | The DOTS | [RFCXXXX] | 4119 | | | client | | 4120 | | | determines | | 4121 | | | that it is | | 4122 | | | still under | | 4123 | | | attack. | | 4124 | 2 | attack-successfully-mitigated | The DOTS | [RFCXXXX] | 4125 | | | client | | 4126 | | | determines | | 4127 | | | that the | | 4128 | | | attack is | | 4129 | | | successfully | | 4130 | | | mitigated. | | 4131 +------+-------------------------------+----------------+-----------+ 4133 New codes can be assigned via Standards Action [RFC8126]. 4135 9.7. DOTS Signal Channel YANG Modules 4137 This document requests IANA to register the following URIs in the 4138 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 4140 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 4141 Registrant Contact: The IESG. 4142 XML: N/A; the requested URI is an XML namespace. 4144 URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel 4145 Registrant Contact: IANA. 4146 XML: N/A; the requested URI is an XML namespace. 4148 This document requests IANA to register the following YANG modules in 4149 the "YANG Module Names" subregistry [RFC7950] within the "YANG 4150 Parameters" registry. 4152 Name: ietf-signal 4153 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 4154 Maintained by IANA: N 4155 Prefix: signal 4156 Reference: RFC XXXX 4158 Name: iana-signal 4159 Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel 4160 Maintained by IANA: Y 4161 Prefix: iana-signal 4162 Reference: RFC XXXX 4164 This document defines the initial version of the IANA-maintained 4165 iana-dots-signal-channel YANG module. IANA is requested to add this 4166 note: 4168 Status, conflict status, conflict cause, and attack status values 4169 must not be directly added to the iana-dots-signal-channel YANG 4170 module. They must instead be respectively added to the "DOTS 4171 Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause 4172 Codes", and "DOTS Attack Status Codes" registries. 4174 When a 'status', 'conflict-status', 'conflict-cause', or 'attack- 4175 status' value is respectively added to the "DOTS Status Codes", "DOTS 4176 Conflict Status Codes", "DOTS Conflict Cause Codes", or "DOTS Attack 4177 Status Codes" registry, a new "enum" statement must be added to the 4178 iana-dots-signal-channel YANG module. The following "enum" 4179 statement, and substatements thereof, should be defined: 4181 "enum": Replicates the label from the registry. 4183 "value": Contains the IANA-assigned value corresponding to the 4184 'status', 'conflict-status', 'conflict-cause', or 4185 'attack-status'. 4187 "description": Replicates the description from the registry. 4189 "reference": Replicates the reference from the registry and add the 4190 title of the document. 4192 When the iana-dots-signal-channel YANG module is updated, a new 4193 "revision" statement must be added in front of the existing revision 4194 statements. 4196 IANA is requested to add this note to "DOTS Status Codes", "DOTS 4197 Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack 4198 Status Codes" registries: 4200 When this registry is modified, the YANG module iana-dots-signal- 4201 channel must be updated as defined in [RFCXXXX]. 4203 10. Security Considerations 4205 High-level DOTS security considerations are documented in 4206 [I-D.ietf-dots-requirements] and [I-D.ietf-dots-architecture]. 4208 Authenticated encryption MUST be used for data confidentiality and 4209 message integrity. The interaction between the DOTS agents requires 4210 Datagram Transport Layer Security (DTLS) or Transport Layer Security 4211 (TLS) with a cipher suite offering confidentiality protection, and 4212 the guidance given in [RFC7525] MUST be followed to avoid attacks on 4213 (D)TLS. The (D)TLS protocol profile used for the DOTS signal channel 4214 is specified in Section 7. 4216 If TCP is used between DOTS agents, an attacker may be able to inject 4217 RST packets, bogus application segments, etc., regardless of whether 4218 TLS authentication is used. Because the application data is TLS 4219 protected, this will not result in the application receiving bogus 4220 data, but it will constitute a DoS on the connection. This attack 4221 can be countered by using TCP-AO [RFC5925]. Although not widely 4222 adopted, if TCP-AO is used, then any bogus packets injected by an 4223 attacker will be rejected by the TCP-AO integrity check and therefore 4224 will never reach the TLS layer. 4226 An attack vector that can be achieved if the 'cuid' is guessable is a 4227 misbehaving DOTS client from within the client's domain which uses 4228 the 'cuid' of another DOTS client of the domain to delete or alter 4229 active mitigations. For this attack vector to happen, the 4230 misbehaving client needs to pass the security validation checks by 4231 the DOTS server, and eventually the checks of a client-domain DOTS 4232 gateway. 4234 A similar attack can be achieved by a compromised DOTS client which 4235 can sniff the TLS 1.2 handshake, use the client certificate to 4236 identify the 'cuid' used by another DOTS client. This attack is not 4237 possible if algorithms such as version 4 Universally Unique 4238 IDentifiers (UUIDs) in Section 4.4 of [RFC4122] are used to generate 4239 the 'cuid' because such UUIDs are not a deterministic function of the 4240 client certificate. Likewise, this attack is not possible with TLS 4241 1.3 because most of the TLS handshake is encrypted and the client 4242 certificate is not visible to eavesdroppers. 4244 A compromised DOTS client can collude with a DDoS attacker to send 4245 mitigation request for a target resource, gets the mitigation 4246 efficacy from the DOTS server, and conveys the mitigation efficacy to 4247 the DDoS attacker to possibly change the DDoS attack strategy. 4248 Obviously, signaling an attack by the compromised DOTS client to the 4249 DOTS server will trigger attack mitigation. This attack can be 4250 prevented by monitoring and auditing DOTS clients to detect 4251 misbehavior and to deter misuse, and by only authorizing the DOTS 4252 client to request mitigation for specific target resources (e.g., an 4253 application server is authorized to request mitigation for its IP 4254 addresses but a DDoS mitigator can request mitigation for any target 4255 resource in the network). Furthermore, DOTS clients are typically 4256 co-located on network security services (e.g., firewall) and a 4257 compromised security service potentially can do a lot more damage to 4258 the network. 4260 Rate-limiting DOTS requests, including those with new 'cuid' values, 4261 from the same DOTS client defends against DoS attacks that would 4262 result in varying the 'cuid' to exhaust DOTS server resources. Rate- 4263 limit policies SHOULD be enforced on DOTS gateways (if deployed) and 4264 DOTS servers. 4266 In order to prevent leaking internal information outside a client- 4267 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 4268 the identification information that pertains to internal DOTS clients 4269 (e.g., source IP address, client's hostname) unless explicitly 4270 configured to do so. 4272 DOTS servers MUST verify that requesting DOTS clients are entitled to 4273 trigger actions on a given IP prefix. That is, only actions on IP 4274 resources that belong to the DOTS client' domain MUST be authorized 4275 by a DOTS server. The exact mechanism for the DOTS servers to 4276 validate that the target prefixes are within the scope of the DOTS 4277 client domain is deployment-specific. 4279 The presence of DOTS gateways may lead to infinite forwarding loops, 4280 which is undesirable. To prevent and detect such loops, this 4281 document uses the Hop-Limit Option. 4283 When FQDNs are used as targets, the DOTS server MUST rely upon DNS 4284 privacy enabling protocols (e.g., DNS over TLS [RFC7858] or DoH 4285 [RFC8484]) to prevent eavesdroppers from possibly identifying the 4286 target resources protected by the DDoS mitigation service, and means 4287 to ensure the target FQDN resolution is authentic (e.g., DNSSEC 4288 [RFC4034]). 4290 CoAP-specific security considerations are discussed in Section 11 of 4291 [RFC7252], while CBOR-related security considerations are discussed 4292 in Section 8 of [RFC7049]. 4294 11. Contributors 4296 The following individuals have contributed to this document: 4298 o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust 4300 o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email: 4301 mgeller@cisco.com 4303 o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States, 4304 Email: rgm@htt-consult.com 4306 o Dan Wing, Email: dwing-ietf@fuggles.com 4308 12. Acknowledgements 4310 Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael 4311 Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia, 4312 Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien 4313 Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion 4314 and comments. 4316 The authors would like to give special thanks to Kaname Nishizuka and 4317 Jon Shallow for their efforts in implementing the protocol and 4318 performing interop testing at IETF Hackathons. 4320 Thanks to the core WG for the recommendations on Hop-Limit and 4321 redirect signaling. 4323 Special thanks to Benjamin Kaduk for the detailed AD review. 4325 Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja 4326 Kuehlewind, and Alissa Cooper for the review. 4328 13. References 4330 13.1. Normative References 4332 [I-D.ietf-core-hop-limit] 4333 Boucadair, M., K, R., and J. Shallow, "Constrained 4334 Application Protocol (CoAP) Hop Limit Option", draft-ietf- 4335 core-hop-limit-03 (work in progress), February 2019. 4337 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4338 DOI 10.17487/RFC0791, September 1981, 4339 . 4341 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 4342 Communication Layers", STD 3, RFC 1122, 4343 DOI 10.17487/RFC1122, October 1989, 4344 . 4346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4347 Requirement Levels", BCP 14, RFC 2119, 4348 DOI 10.17487/RFC2119, March 1997, 4349 . 4351 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4352 DOI 10.17487/RFC3688, January 2004, 4353 . 4355 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4356 Resource Identifier (URI): Generic Syntax", STD 66, 4357 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4358 . 4360 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 4361 Ciphersuites for Transport Layer Security (TLS)", 4362 RFC 4279, DOI 10.17487/RFC4279, December 2005, 4363 . 4365 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 4366 (CIDR): The Internet Address Assignment and Aggregation 4367 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 4368 2006, . 4370 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 4371 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 4372 . 4374 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4375 (TLS) Protocol Version 1.2", RFC 5246, 4376 DOI 10.17487/RFC5246, August 2008, 4377 . 4379 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4380 Housley, R., and W. Polk, "Internet X.509 Public Key 4381 Infrastructure Certificate and Certificate Revocation List 4382 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4383 . 4385 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 4386 Uniform Resource Identifiers (URIs)", RFC 5785, 4387 DOI 10.17487/RFC5785, April 2010, 4388 . 4390 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 4391 Extensions: Extension Definitions", RFC 6066, 4392 DOI 10.17487/RFC6066, January 2011, 4393 . 4395 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 4396 Verification of Domain-Based Application Service Identity 4397 within Internet Public Key Infrastructure Using X.509 4398 (PKIX) Certificates in the Context of Transport Layer 4399 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 4400 2011, . 4402 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4403 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 4404 January 2012, . 4406 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4407 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4408 . 4410 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 4411 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 4412 October 2013, . 4414 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 4415 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 4416 Transport Layer Security (TLS) and Datagram Transport 4417 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 4418 June 2014, . 4420 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 4421 Application Protocol (CoAP)", RFC 7252, 4422 DOI 10.17487/RFC7252, June 2014, 4423 . 4425 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 4426 "Recommendations for Secure Use of Transport Layer 4427 Security (TLS) and Datagram Transport Layer Security 4428 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 4429 2015, . 4431 [RFC7641] Hartke, K., "Observing Resources in the Constrained 4432 Application Protocol (CoAP)", RFC 7641, 4433 DOI 10.17487/RFC7641, September 2015, 4434 . 4436 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 4437 Layer Security (TLS) False Start", RFC 7918, 4438 DOI 10.17487/RFC7918, August 2016, 4439 . 4441 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 4442 (TLS) Cached Information Extension", RFC 7924, 4443 DOI 10.17487/RFC7924, July 2016, 4444 . 4446 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4447 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4448 . 4450 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 4451 the Constrained Application Protocol (CoAP)", RFC 7959, 4452 DOI 10.17487/RFC7959, August 2016, 4453 . 4455 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 4456 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 4457 March 2017, . 4459 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4460 Writing an IANA Considerations Section in RFCs", BCP 26, 4461 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4462 . 4464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4466 May 2017, . 4468 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4469 (IPv6) Specification", STD 86, RFC 8200, 4470 DOI 10.17487/RFC8200, July 2017, 4471 . 4473 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 4474 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 4475 Application Protocol) over TCP, TLS, and WebSockets", 4476 RFC 8323, DOI 10.17487/RFC8323, February 2018, 4477 . 4479 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4480 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4481 . 4483 13.2. Informative References 4485 [I-D.boucadair-dots-earlydata] 4486 Boucadair, M. and R. K, "Using Early Data in DOTS", draft- 4487 boucadair-dots-earlydata-00 (work in progress), January 4488 2019. 4490 [I-D.ietf-core-comi] 4491 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 4492 Management Interface", draft-ietf-core-comi-04 (work in 4493 progress), November 2018. 4495 [I-D.ietf-core-yang-cbor] 4496 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 4497 Data Modeled with YANG", draft-ietf-core-yang-cbor-10 4498 (work in progress), April 2019. 4500 [I-D.ietf-dots-architecture] 4501 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 4502 Compton, "Distributed-Denial-of-Service Open Threat 4503 Signaling (DOTS) Architecture", draft-ietf-dots- 4504 architecture-13 (work in progress), April 2019. 4506 [I-D.ietf-dots-data-channel] 4507 Boucadair, M. and R. K, "Distributed Denial-of-Service 4508 Open Threat Signaling (DOTS) Data Channel Specification", 4509 draft-ietf-dots-data-channel-28 (work in progress), March 4510 2019. 4512 [I-D.ietf-dots-multihoming] 4513 Boucadair, M. and R. K, "Multi-homing Deployment 4514 Considerations for Distributed-Denial-of-Service Open 4515 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 4516 (work in progress), January 2019. 4518 [I-D.ietf-dots-requirements] 4519 Mortensen, A., K, R., and R. Moskowitz, "Distributed 4520 Denial of Service (DDoS) Open Threat Signaling 4521 Requirements", draft-ietf-dots-requirements-22 (work in 4522 progress), March 2019. 4524 [I-D.ietf-dots-server-discovery] 4525 Boucadair, M., K, R., and P. Patil, "Distributed-Denial- 4526 of-Service Open Threat Signaling (DOTS) Server Discovery", 4527 draft-ietf-dots-server-discovery-02 (work in progress), 4528 May 2019. 4530 [I-D.ietf-dots-use-cases] 4531 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 4532 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 4533 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 4534 in progress), January 2019. 4536 [I-D.ietf-tls-dtls13] 4537 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 4538 Datagram Transport Layer Security (DTLS) Protocol Version 4539 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 4540 2019. 4542 [IANA.CBOR.Tags] 4543 IANA, "Concise Binary Object Representation (CBOR) Tags", 4544 . 4547 [IANA.CoAP.Content-Formats] 4548 IANA, "CoAP Content-Formats", 4549 . 4552 [IANA.MediaTypes] 4553 IANA, "Media Types", 4554 . 4556 [proto_numbers] 4557 "IANA, "Protocol Numbers"", 2011, 4558 . 4560 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 4561 Address Translator (Traditional NAT)", RFC 3022, 4562 DOI 10.17487/RFC3022, January 2001, 4563 . 4565 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 4566 Rose, "Resource Records for the DNS Security Extensions", 4567 RFC 4034, DOI 10.17487/RFC4034, March 2005, 4568 . 4570 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 4571 Unique IDentifier (UUID) URN Namespace", RFC 4122, 4572 DOI 10.17487/RFC4122, July 2005, 4573 . 4575 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 4576 Congestion Control Protocol (DCCP)", RFC 4340, 4577 DOI 10.17487/RFC4340, March 2006, 4578 . 4580 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 4581 Denial-of-Service Considerations", RFC 4732, 4582 DOI 10.17487/RFC4732, December 2006, 4583 . 4585 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 4586 Translation (NAT) Behavioral Requirements for Unicast 4587 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 4588 2007, . 4590 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 4591 RFC 4960, DOI 10.17487/RFC4960, September 2007, 4592 . 4594 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 4595 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 4596 . 4598 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 4599 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 4600 DOI 10.17487/RFC5389, October 2008, 4601 . 4603 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 4604 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 4605 June 2010, . 4607 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 4608 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 4609 DOI 10.17487/RFC6052, October 2010, 4610 . 4612 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 4613 NAT64: Network Address and Protocol Translation from IPv6 4614 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 4615 April 2011, . 4617 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 4618 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 4619 DOI 10.17487/RFC6234, May 2011, 4620 . 4622 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 4623 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 4624 . 4626 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 4627 "Default Address Selection for Internet Protocol Version 6 4628 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 4629 . 4631 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 4632 Specifications and Registration Procedures", BCP 13, 4633 RFC 6838, DOI 10.17487/RFC6838, January 2013, 4634 . 4636 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 4637 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 4638 DOI 10.17487/RFC6887, April 2013, 4639 . 4641 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 4642 A., and H. Ashida, "Common Requirements for Carrier-Grade 4643 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 4644 April 2013, . 4646 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4647 "Enrollment over Secure Transport", RFC 7030, 4648 DOI 10.17487/RFC7030, October 2013, 4649 . 4651 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 4652 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 4653 . 4655 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 4656 "Architectural Considerations in Smart Object Networking", 4657 RFC 7452, DOI 10.17487/RFC7452, March 2015, 4658 . 4660 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 4661 NETCONF Protocol over Transport Layer Security (TLS) with 4662 Mutual X.509 Authentication", RFC 7589, 4663 DOI 10.17487/RFC7589, June 2015, 4664 . 4666 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 4667 and P. Hoffman, "Specification for DNS over Transport 4668 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 4669 2016, . 4671 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 4672 RFC 7951, DOI 10.17487/RFC7951, August 2016, 4673 . 4675 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 4676 Better Connectivity Using Concurrency", RFC 8305, 4677 DOI 10.17487/RFC8305, December 2017, 4678 . 4680 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 4681 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 4682 . 4684 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 4685 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 4686 . 4688 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 4689 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 4690 January 2019, . 4692 Appendix A. CUID Generation 4694 The document recommends the use of SPKI to generate the 'cuid'. This 4695 design choice is motivated by the following reasons: 4697 o SPKI is globally unique. 4699 o It is deterministic. 4701 o It allows to avoid extra cycles that may be induced by 'cuid' 4702 collision. 4704 o DOTS clients do not need to store the 'cuid' in a persistent 4705 storage. 4707 o It allows to detect compromised DOTS clients that do not adhere to 4708 the 'cuid' generation algorithm. 4710 Authors' Addresses 4712 Tirumaleswar Reddy (editor) 4713 McAfee, Inc. 4714 Embassy Golf Link Business Park 4715 Bangalore, Karnataka 560071 4716 India 4718 Email: kondtir@gmail.com 4720 Mohamed Boucadair (editor) 4721 Orange 4722 Rennes 35000 4723 France 4725 Email: mohamed.boucadair@orange.com 4726 Prashanth Patil 4727 Cisco Systems, Inc. 4729 Email: praspati@cisco.com 4731 Andrew Mortensen 4732 Arbor Networks, Inc. 4733 2727 S. State St 4734 Ann Arbor, MI 48104 4735 United States 4737 Email: andrew@moretension.com 4739 Nik Teague 4740 Verisign, Inc. 4741 United States 4743 Email: nteague@verisign.com