idnits 2.17.1 draft-ietf-dots-signal-channel-34.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 2568 has weird spacing: '...er-port ine...' -- The document date (May 16, 2019) is 1807 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 4202, 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 17, 2019 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Iron Mountain Data Centers 12 May 16, 2019 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel Specification 16 draft-ietf-dots-signal-channel-34 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 17, 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 599 clients, especially those from the same domain. It MUST be 600 generated by DOTS clients. 602 For the reasons discussed in Appendix A, implementations SHOULD 603 set 'cuid' to the output of a cryptographic hash algorithm 604 whose input is the Distinguished Encoding Rules (DER)-encoded 605 Abstract Syntax Notation One (ASN.1) representation of the 606 Subject Public Key Info (SPKI) of the DOTS client X.509 607 certificate [RFC5280], the DOTS client raw public key 608 [RFC7250], or the "Pre-Shared Key (PSK) identity" used by the 609 DOTS client in the TLS ClientKeyExchange message. In this 610 version of the specification, the cryptographic hash algorithm 611 used is SHA-256 [RFC6234]. The output of the cryptographic 612 hash algorithm is truncated to 16 bytes; truncation is done by 613 stripping off the final 16 bytes. The truncated output is 614 base64url encoded (Section 5 of [RFC4648]) with the trailing 615 "=" removed from the encoding. 617 The 'cuid' is intended to be stable when communicating with a 618 given DOTS server, i.e., the 'cuid' used by a DOTS client 619 SHOULD NOT change over time. Distinct 'cuid' values MAY be 620 used by a single DOTS client per DOTS server. 622 If a DOTS client has to change its 'cuid' for some reason, it 623 MUST NOT do so when mitigations are still active for the old 624 'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS 625 signal message fragmentation over UDP. Furthermore, if that 626 DOTS client created aliases and filtering entries at the DOTS 627 server by means of the DOTS data channel, it MUST delete all 628 the entries bound to the old 'cuid' and re-install them using 629 the new 'cuid'. 631 DOTS servers MUST return 4.09 (Conflict) error code to a DOTS 632 peer to notify that the 'cuid' is already in-use by another 633 DOTS client. Upon receipt of that error code, a new 'cuid' 634 MUST be generated by the DOTS peer (e.g., using [RFC4122]). 636 Client-domain DOTS gateways MUST handle 'cuid' collision 637 directly and it is RECOMMENDED that 'cuid' collision is handled 638 directly by server-domain DOTS gateways. 640 DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. 641 Triggers for such rewriting are out of scope. 643 This is a mandatory Uri-Path parameter. 645 mid: Identifier for the mitigation request represented with an 646 integer. This identifier MUST be unique for each mitigation 647 request bound to the DOTS client, i.e., the 'mid' parameter 648 value in the mitigation request needs to be unique (per 'cuid' 649 and DOTS server) relative to the 'mid' parameter values of 650 active mitigation requests conveyed from the DOTS client to the 651 DOTS server. 653 In order to handle out-of-order delivery of mitigation 654 requests, 'mid' values MUST increase monotonically. 656 If the 'mid' value has reached 3/4 of (2**32 - 1) (i.e., 657 3221225471) and no attack is detected, the DOTS client MUST 658 reset 'mid' to 0 to handle 'mid' rollover. If the DOTS client 659 maintains mitigation requests with pre-configured scopes, it 660 MUST re-create them with the 'mid' restarting at 0. 662 This identifier MUST be generated by the DOTS client. 664 This is a mandatory Uri-Path parameter. 666 'cuid' and 'mid' MUST NOT appear in the PUT request message body 667 (Figure 6). The schema in Figure 6 uses the types defined in 668 Section 6. Note that this figure (and other similar figures 669 depicting a schema) are non-normative sketches of the structure of 670 the message. 672 { 673 "ietf-dots-signal-channel:mitigation-scope": { 674 "scope": [ 675 { 676 "target-prefix": [ 677 "string" 678 ], 679 "target-port-range": [ 680 { 681 "lower-port": number, 682 "upper-port": number 683 } 684 ], 685 "target-protocol": [ 686 number 687 ], 688 "target-fqdn": [ 689 "string" 690 ], 691 "target-uri": [ 692 "string" 693 ], 694 "alias-name": [ 695 "string" 696 ], 697 "lifetime": number, 698 "trigger-mitigation": true|false 699 } 700 ] 701 } 702 } 704 Figure 6: PUT to Convey DOTS Mitigation Requests (Message Body 705 Schema) 707 The parameters in the CBOR body (Figure 6) of the PUT request are 708 described below: 710 target-prefix: A list of prefixes identifying resources under 711 attack. Prefixes are represented using Classless Inter-Domain 712 Routing (CIDR) notation [RFC4632]. 713 As a reminder, the prefix length must be less than or equal to 32 714 (or 128) for IPv4 (or IPv6). 716 The prefix list MUST NOT include broadcast, loopback, or multicast 717 addresses. These addresses are considered as invalid values. In 718 addition, the DOTS server MUST validate that target prefixes are 719 within the scope of the DOTS client domain. Other validation 720 checks may be supported by DOTS servers. 722 This is an optional attribute. 724 target-port-range: A list of port numbers bound to resources under 725 attack. 727 A port range is defined by two bounds, a lower port number (lower- 728 port) and an upper port number (upper-port). When only 'lower- 729 port' is present, it represents a single port number. 731 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 732 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 733 [RFC4340], a range of ports can be, for example, 0-1023, 734 1024-65535, or 1024-49151. 736 This is an optional attribute. 738 target-protocol: A list of protocols involved in an attack. Values 739 are taken from the IANA protocol registry [proto_numbers]. 741 If 'target-protocol' is not specified, then the request applies to 742 any protocol. 744 This is an optional attribute. 746 target-fqdn: A list of Fully Qualified Domain Names (FQDNs) 747 identifying resources under attack [RFC8499]. 749 How a name is passed to an underlying name resolution library is 750 implementation- and deployment-specific. Nevertheless, once the 751 name is resolved into one or multiple IP addresses, DOTS servers 752 MUST apply the same validation checks as those for 'target- 753 prefix'. 755 The use of FQDNs may be suboptimal because: 757 * It induces both an extra load and increased delays on the DOTS 758 server to handle and manage DNS resolution requests. 760 * It does not guarantee that the DOTS server will resolve a name 761 to the same IP addresses that the DOTS client does. 763 This is an optional attribute. 765 target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986] 766 identifying resources under attack. 768 The same validation checks used for 'target-fqdn' MUST be followed 769 by DOTS servers to validate a target URI. 771 This is an optional attribute. 773 alias-name: A list of aliases of resources for which the mitigation 774 is requested. Aliases can be created using the DOTS data channel 775 (Section 6.1 of [I-D.ietf-dots-data-channel]), direct 776 configuration, or other means. 778 An alias is used in subsequent signal channel exchanges to refer 779 more efficiently to the resources under attack. 781 This is an optional attribute. 783 lifetime: Lifetime of the mitigation request in seconds. The 784 RECOMMENDED lifetime of a mitigation request is 3600 seconds -- 785 this value was chosen to be long enough so that refreshing is not 786 typically a burden on the DOTS client, while still making the 787 request expire in a timely manner when the client has unexpectedly 788 quit. DOTS clients MUST include this parameter in their 789 mitigation requests. Upon the expiry of this lifetime, and if the 790 request is not refreshed, the mitigation request is removed. The 791 request can be refreshed by sending the same request again. 793 A lifetime of '0' in a mitigation request is an invalid value. 795 A lifetime of negative one (-1) indicates indefinite lifetime for 796 the mitigation request. The DOTS server MAY refuse indefinite 797 lifetime, for policy reasons; the granted lifetime value is 798 returned in the response. DOTS clients MUST be prepared to not be 799 granted mitigations with indefinite lifetimes. 801 The DOTS server MUST always indicate the actual lifetime in the 802 response and the remaining lifetime in status messages sent to the 803 DOTS client. 805 This is a mandatory attribute. 807 trigger-mitigation: If the parameter value is set to 'false', DDoS 808 mitigation will not be triggered for the mitigation request unless 809 the DOTS signal channel session is lost. 811 If the DOTS client ceases to respond to heartbeat messages, the 812 DOTS server can detect that the DOTS signal channel session is 813 lost. More details are discussed in Section 4.7. 815 The default value of the parameter is 'true' (that is, the 816 mitigation starts immediately). If 'trigger-mitigation' is not 817 present in a request, this is equivalent to receiving a request 818 with 'trigger-mitigation' set to 'true'. 820 This is an optional attribute. 822 In deployments where server-domain DOTS gateways are enabled, 823 identity information about the origin source client domain ('cdid') 824 SHOULD be propagated to the DOTS server. That information is meant 825 to assist the DOTS server to enforce some policies such as grouping 826 DOTS clients that belong to the same DOTS domain, limiting the number 827 of DOTS requests, and identifying the mitigation scope. These 828 policies can be enforced per-client, per-client domain, or both. 829 Also, the identity information may be used for auditing and debugging 830 purposes. 832 Figure 7 shows an example of a request relayed by a server-domain 833 DOTS gateway. 835 Header: PUT (Code=0.03) 836 Uri-Path: ".well-known" 837 Uri-Path: "dots" 838 Uri-Path: "mitigate" 839 Uri-Path: "cdid=7eeaf349529eb55ed50113" 840 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 841 Uri-Path: "mid=123" 842 Content-Format: "application/dots+cbor" 844 { 845 ... 846 } 848 Figure 7: PUT for DOTS Mitigation Request as Relayed by a DOTS 849 Gateway 851 A server-domain DOTS gateway SHOULD add the following Uri-Path 852 parameter: 854 cdid: Stands for Client Domain Identifier. The 'cdid' is conveyed by 855 a server-domain DOTS gateway to propagate the source domain 856 identity from the gateway's client-facing-side to the gateway's 857 server-facing-side, and from the gateway's server-facing-side 858 to the DOTS server. 'cdid' may be used by the final DOTS server 859 for policy enforcement purposes (e.g., enforce a quota on 860 filtering rules). These policies are deployment-specific. 862 Server-domain DOTS gateways SHOULD support a configuration 863 option to instruct whether 'cdid' parameter is to be inserted. 865 In order to accommodate deployments that require enforcing per- 866 client policies, per-client domain policies, or a combination 867 thereof, server-domain DOTS gateways instructed to insert the 868 'cdid' parameter MUST supply the SPKI hash of the DOTS client 869 X.509 certificate, the DOTS client raw public key, or the hash 870 of the "PSK identity" in the 'cdid', following the same rules 871 for generating the hash conveyed in 'cuid', which is then used 872 by the ultimate DOTS server to determine the corresponding 873 client's domain. The 'cdid' generated by a server-domain 874 gateway is likely to be the same as the 'cuid' except if the 875 DOTS message was relayed by a client-domain DOTS gateway or the 876 'cuid' was generated from a rogue DOTS client. 878 If a DOTS client is provisioned, for example, with distinct 879 certificates as a function of the peer server-domain DOTS 880 gateway, distinct 'cdid' values may be supplied by a server- 881 domain DOTS gateway. The ultimate DOTS server MUST treat those 882 'cdid' values as equivalent. 884 The 'cdid' attribute MUST NOT be generated and included by DOTS 885 clients. 887 DOTS servers MUST ignore 'cdid' attributes that are directly 888 supplied by source DOTS clients or client-domain DOTS gateways. 889 This implies that first server-domain DOTS gateways MUST strip 890 'cdid' attributes supplied by DOTS clients. DOTS servers 891 SHOULD support a configuration parameter to identify DOTS 892 gateways that are trusted to supply 'cdid' attributes. 894 Only single-valued 'cdid' are defined in this document. That 895 is, only the first on-path server-domain DOTS gateway can 896 insert a 'cdid' value. This specification does not allow 897 multiple server-domain DOTS gateways, whenever involved in the 898 path, to insert a 'cdid' value for each server-domain gateway. 900 This is an optional Uri-Path. When present, 'cdid' MUST be 901 positioned before 'cuid'. 903 A DOTS gateway MAY add the CoAP Hop-Limit Option 904 [I-D.ietf-core-hop-limit]. 906 Because of the complexity to handle partial failure cases, this 907 specification does not allow for including multiple mitigation 908 requests in the same PUT request. Concretely, a DOTS client MUST NOT 909 include multiple entries in the 'scope' array of the same PUT 910 request. 912 FQDN and URI mitigation scopes may be thought of as a form of scope 913 alias, in which the addresses associated with the domain name or URI 914 (as resolved by the DOTS server) represent the scope of the 915 mitigation. Particularly, the IP addresses to which the host 916 subcomponent of authority component of an URI resolves represent the 917 'target-prefix', the URI scheme represents the 'target-protocol', the 918 port subcomponent of authority component of an URI represents the 919 'target-port-range'. If the optional port information is not present 920 in the authority component, the default port defined for the URI 921 scheme represents the 'target-port'. 923 In the PUT request at least one of the attributes 'target-prefix', 924 'target-fqdn','target-uri', or 'alias-name' MUST be present. 926 Attributes and Uri-Path parameters with empty values MUST NOT be 927 present in a request and render the entire request invalid. 929 Figure 8 shows a PUT request example to signal that TCP port numbers 930 80, 8080, and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 931 servers are under attack. The presence of 'cdid' indicates that a 932 server-domain DOTS gateway has modified the initial PUT request sent 933 by the DOTS client. Note that 'cdid' MUST NOT appear in the PUT 934 request message body. 936 Header: PUT (Code=0.03) 937 Uri-Path: ".well-known" 938 Uri-Path: "dots" 939 Uri-Path: "mitigate" 940 Uri-Path: "cdid=7eeaf349529eb55ed50113" 941 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 942 Uri-Path: "mid=123" 943 Content-Format: "application/dots+cbor" 945 { 946 "ietf-dots-signal-channel:mitigation-scope": { 947 "scope": [ 948 { 949 "target-prefix": [ 950 "2001:db8:6401::1/128", 951 "2001:db8:6401::2/128" 952 ], 953 "target-port-range": [ 954 { 955 "lower-port": 80 956 }, 957 { 958 "lower-port": 443 959 }, 960 { 961 "lower-port": 8080 962 } 963 ], 964 "target-protocol": [ 965 6 966 ], 967 "lifetime": 3600 968 } 969 ] 970 } 971 } 973 Figure 8: PUT for DOTS Mitigation Request (An Example) 975 The corresponding CBOR encoding format for the payload is shown in 976 Figure 9. 978 A1 # map(1) 979 01 # unsigned(1) 980 A1 # map(1) 981 02 # unsigned(2) 982 81 # array(1) 983 A3 # map(3) 984 06 # unsigned(6) 985 82 # array(2) 986 74 # text(20) 987 323030313A6462383A363430313A3A312F313238 988 74 # text(20) 989 323030313A6462383A363430313A3A322F313238 990 07 # unsigned(7) 991 83 # array(3) 992 A1 # map(1) 993 08 # unsigned(8) 994 18 50 # unsigned(80) 995 A1 # map(1) 996 08 # unsigned(8) 997 19 01BB # unsigned(443) 998 A1 # map(1) 999 08 # unsigned(8) 1000 19 1F90 # unsigned(8080) 1001 0A # unsigned(10) 1002 81 # array(1) 1003 06 # unsigned(6) 1004 0E # unsigned(14) 1005 19 0E10 # unsigned(3600) 1007 Figure 9: PUT for DOTS Mitigation Request (CBOR) 1009 In both DOTS signal and data channel sessions, the DOTS client MUST 1010 authenticate itself to the DOTS server (Section 8). The DOTS server 1011 MAY use the algorithm presented in Section 7 of [RFC7589] to derive 1012 the DOTS client identity or username from the client certificate. 1013 The DOTS client identity allows the DOTS server to accept mitigation 1014 requests with scopes that the DOTS client is authorized to manage. 1016 The DOTS server couples the DOTS signal and data channel sessions 1017 using the DOTS client identity and optionally the 'cdid' parameter 1018 value, so the DOTS server can validate whether the aliases conveyed 1019 in the mitigation request were indeed created by the same DOTS client 1020 using the DOTS data channel session. If the aliases were not created 1021 by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in 1022 the response. 1024 The DOTS server couples the DOTS signal channel sessions using the 1025 DOTS client identity and optionally the 'cdid' parameter value, and 1026 the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to 1027 detect duplicate mitigation requests. If the mitigation request 1028 contains the 'alias-name' and other parameters identifying the target 1029 resources (such as 'target-prefix', 'target-port-range', 'target- 1030 fqdn', or 'target-uri'), the DOTS server appends the parameter values 1031 in 'alias-name' with the corresponding parameter values in 'target- 1032 prefix', 'target-port-range', 'target-fqdn', or 'target-uri'. 1034 The DOTS server indicates the result of processing the PUT request 1035 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 1036 codes are some sort of invalid requests (client errors). COAP 5.xx 1037 codes are returned if the DOTS server is in an error state or is 1038 currently unavailable to provide mitigation in response to the 1039 mitigation request from the DOTS client. 1041 Figure 10 shows an example response to a PUT request that is 1042 successfully processed by a DOTS server (i.e., CoAP 2.xx response 1043 codes). This version of the specification forbids 'cuid' and 'cdid' 1044 (if used) to be returned in a response message body. 1046 { 1047 "ietf-dots-signal-channel:mitigation-scope": { 1048 "scope": [ 1049 { 1050 "mid": 123, 1051 "lifetime": 3600 1052 } 1053 ] 1054 } 1055 } 1057 Figure 10: 2.xx Response Body 1059 If the request is missing a mandatory attribute, does not include 1060 'cuid' or 'mid' Uri-Path options, includes multiple 'scope' 1061 parameters, or contains invalid or unknown parameters, the DOTS 1062 server MUST reply with 4.00 (Bad Request). DOTS agents can safely 1063 ignore comprehension-optional parameters they don't understand 1064 (Section 9.6.1.1). 1066 A DOTS server that receives a mitigation request with a lifetime set 1067 to '0' MUST reply with a 4.00 (Bad Request). 1069 If the DOTS server does not find the 'mid' parameter value conveyed 1070 in the PUT request in its configuration data, it MAY accept the 1071 mitigation request by sending back a 2.01 (Created) response to the 1072 DOTS client; the DOTS server will consequently try to mitigate the 1073 attack. A DOTS server could reject mitigation requests when it is 1074 near capacity or needs to rate-limit a particular client, for 1075 example. 1077 The relative order of two mitigation requests, having the same 1078 'trigger-mitigation' type, from a DOTS client is determined by 1079 comparing their respective 'mid' values. If two mitigation requests 1080 with the same 'trigger-mitigation' type have overlapping mitigation 1081 scopes, the mitigation request with the highest numeric 'mid' value 1082 will override the other mitigation request. Two mitigation requests 1083 from a DOTS client have overlapping scopes if there is a common IP 1084 address, IP prefix, FQDN, URI, or alias-name. To avoid maintaining a 1085 long list of overlapping mitigation requests (i.e., requests with the 1086 same 'trigger-mitigation' type and overlapping scopes) from a DOTS 1087 client and avoid error-prone provisioning of mitigation requests from 1088 a DOTS client, the overlapped lower numeric 'mid' MUST be 1089 automatically deleted and no longer available at the DOTS server. 1090 For example, if the DOTS server receives a mitigation request which 1091 overlaps with an existing mitigation with a higher numeric 'mid', the 1092 DOTS server rejects the request by returning 4.09 (Conflict) to the 1093 DOTS client. The response includes enough information for a DOTS 1094 client to recognize the source of the conflict as described below in 1095 the 'conflict-information' subtree with only the relevant nodes 1096 listed: 1098 conflict-information: Indicates that a mitigation request is 1099 conflicting with another mitigation request. This optional 1100 attribute has the following structure: 1102 conflict-cause: Indicates the cause of the conflict. The 1103 following values are defined: 1105 1: Overlapping targets. 'conflict-scope' provides more details 1106 about the conflicting target clauses. 1108 conflict-scope: Characterizes the exact conflict scope. It may 1109 include a list of IP addresses, a list of prefixes, a list of 1110 port numbers, a list of target protocols, a list of FQDNs, a 1111 list of URIs, a list of alias-names, or a 'mid'. 1113 If the DOTS server receives a mitigation request which overlaps with 1114 an active mitigation request, but both having distinct 'trigger- 1115 mitigation' types, the DOTS server SHOULD deactivate (absent explicit 1116 policy/configuration otherwise) the mitigation request with 'trigger- 1117 mitigation' set to false. Particularly, if the mitigation request 1118 with 'trigger-mitigation' set to false is active, the DOTS server 1119 withdraws the mitigation request (i.e., status code is set to '7' as 1120 defined in Table 2) and transitions the status of the mitigation 1121 request to '8'. 1123 Upon DOTS signal channel session loss with a peer DOTS client, the 1124 DOTS server SHOULD withdraw (absent explicit policy/configuration 1125 otherwise) any active mitigation requests overlapping with mitigation 1126 requests having 'trigger-mitigation' set to false from that DOTS 1127 client, as the loss of the session implictily activates these 1128 preconfigured mitigation requests and they take precedence. Note 1129 that active-but-terminating period is not observed for mitigations 1130 withdrawn at the initiative of the DOTS server. 1132 DOTS clients may adopt various strategies for setting the scopes of 1133 immediate and pre-configured mitigation requests to avoid potential 1134 conflicts. For example, a DOTS client may tweak pre-configured 1135 scopes so that the scope of any overlapping immediate mitigation 1136 request will be a subset of the pre-configured scopes. Also, if an 1137 immediate mitigation request overlaps with any of the pre-configured 1138 scopes, the DOTS client sets the scope of the overlapping immediate 1139 mitigation request to be a subset of the pre-configured scopes, so as 1140 to get a broad mitigation when the DOTS signal channel collapses and 1141 maximize the chance of recovery. 1143 If the request is conflicting with an existing mitigation request 1144 from a different DOTS client, the DOTS server may return 2.01 1145 (Created) or 4.09 (Conflict) to the requesting DOTS client. If the 1146 DOTS server decides to maintain the new mitigation request, the DOTS 1147 server returns 2.01 (Created) to the requesting DOTS client. If the 1148 DOTS server decides to reject the new mitigation request, the DOTS 1149 server returns 4.09 (Conflict) to the requesting DOTS client. For 1150 both 2.01 (Created) and 4.09 (Conflict) responses, the response 1151 includes enough information for a DOTS client to recognize the source 1152 of the conflict as described below: 1154 conflict-information: Indicates that a mitigation request is 1155 conflicting with another mitigation request(s) from other DOTS 1156 client(s). This optional attribute has the following structure: 1158 conflict-status: Indicates the status of a conflicting mitigation 1159 request. The following values are defined: 1161 1: DOTS server has detected conflicting mitigation requests 1162 from different DOTS clients. This mitigation request is 1163 currently inactive until the conflicts are resolved. 1164 Another mitigation request is active. 1166 2: DOTS server has detected conflicting mitigation requests 1167 from different DOTS clients. This mitigation request is 1168 currently active. 1170 3: DOTS server has detected conflicting mitigation requests 1171 from different DOTS clients. All conflicting mitigation 1172 requests are inactive. 1174 conflict-cause: Indicates the cause of the conflict. The 1175 following values are defined: 1177 1: Overlapping targets. 'conflict-scope' provides more details 1178 about the conflicting target clauses. 1180 2: Conflicts with an existing accept-list. This code is 1181 returned when the DDoS mitigation detects source addresses/ 1182 prefixes in the accept-listed ACLs are attacking the 1183 target. 1185 3: CUID Collision. This code is returned when a DOTS client 1186 uses a 'cuid' that is already used by another DOTS client. 1187 This code is an indication that the request has been 1188 rejected and a new request with a new 'cuid' is to be re- 1189 sent by the DOTS client (see the example shown in 1190 Figure 11). Note that 'conflict-status', 'conflict-scope', 1191 and 'retry-timer' MUST NOT be returned in the error 1192 response. 1194 conflict-scope: Characterizes the exact conflict scope. It may 1195 include a list of IP addresses, a list of prefixes, a list of 1196 port numbers, a list of target protocols, a list of FQDNs, a 1197 list of URIs, a list of alias-names, or references to 1198 conflicting ACLs (by an 'acl-name', typically 1199 [I-D.ietf-dots-data-channel]). 1201 retry-timer: Indicates, in seconds, the time after which the DOTS 1202 client may re-issue the same request. The DOTS server returns 1203 'retry-timer' only to DOTS client(s) for which a mitigation 1204 request is deactivated. Any retransmission of the same 1205 mitigation request before the expiry of this timer is likely to 1206 be rejected by the DOTS server for the same reasons. 1208 The retry-timer SHOULD be equal to the lifetime of the active 1209 mitigation request resulting in the deactivation of the 1210 conflicting mitigation request. 1212 If the DOTS server decides to maintain a state for the 1213 deactivated mitigation request, the DOTS server updates the 1214 lifetime of the deactivated mitigation request to (retry-timer 1215 + 45 seconds) so that the DOTS client can refresh the 1216 deactivated mitigation request after 'retry-timer' seconds, but 1217 before the expiry of the lifetime, and check if the conflict is 1218 resolved. 1220 Header: PUT (Code=0.03) 1221 Uri-Path: ".well-known" 1222 Uri-Path: "dots" 1223 Uri-Path: "mitigate" 1224 Uri-Path: "cuid=7eeaf349529eb55ed50113" 1225 Uri-Path: "mid=12" 1227 (1) Request with a conflicting 'cuid' 1229 { 1230 "ietf-dots-signal-channel:mitigation-scope": { 1231 "scope": [ 1232 { 1233 "conflict-information": { 1234 "conflict-cause": "cuid-collision" 1235 } 1236 } 1237 ] 1238 } 1239 } 1241 (2) Message body of the 4.09 (Conflict) response 1242 from the DOTS server 1244 Header: PUT (Code=0.03) 1245 Uri-Path: ".well-known" 1246 Uri-Path: "dots" 1247 Uri-Path: "mitigate" 1248 Uri-Path: "cuid=f30d281ce6b64fc5a0b91e" 1249 Uri-Path: "mid=12" 1251 (3) Request with a new 'cuid' 1253 Figure 11: Example of Generating a New 'cuid' 1255 As an active attack evolves, DOTS clients can adjust the scope of 1256 requested mitigation as necessary, by refining the scope of resources 1257 requiring mitigation. This can be achieved by sending a PUT request 1258 with a new 'mid' value that will override the existing one with 1259 overlapping mitigation scopes. 1261 For a mitigation request to continue beyond the initial negotiated 1262 lifetime, the DOTS client has to refresh the current mitigation 1263 request by sending a new PUT request. This PUT request MUST use the 1264 same 'mid' value, and MUST repeat all the other parameters as sent in 1265 the original mitigation request apart from a possible change to the 1266 lifetime parameter value. In such case, the DOTS server MAY update 1267 the mitigation request, and a 2.04 (Changed) response is returned to 1268 indicate a successful update of the mitigation request. If this is 1269 not the case, the DOTS server MUST reject the request with a 4.00 1270 (Bad Request). 1272 4.4.2. Retrieve Information Related to a Mitigation 1274 A GET request is used by a DOTS client to retrieve information 1275 (including status) of DOTS mitigations from a DOTS server. 1277 'cuid' is a mandatory Uri-Path parameter for GET requests. 1279 Uri-Path parameters with empty values MUST NOT be present in a 1280 request. 1282 The same considerations for manipulating 'cdid' parameter by server- 1283 domain DOTS gateways specified in Section 4.4.1 MUST be followed for 1284 GET requests. 1286 The 'c' Uri-Query option is used to control selection of 1287 configuration and non-configuration data nodes. Concretely, the 'c' 1288 (content) parameter and its permitted values defined in the following 1289 table [I-D.ietf-core-comi] can be used to retrieve non-configuration 1290 data (attack mitigation status), configuration data, or both. The 1291 DOTS server MAY support this optional filtering capability. It can 1292 safely ignore it if not supported. If the DOTS client supports the 1293 optional filtering capability, it SHOULD use "c=n" query (to get back 1294 only the dynamically changing data) or "c=c" query (to get back the 1295 static configuration values) when the DDoS attack is active to limit 1296 the size of the response. 1298 +-------+-----------------------------------------------------+ 1299 | Value | Description | 1300 +-------+-----------------------------------------------------+ 1301 | c | Return only configuration descendant data nodes | 1302 | n | Return only non-configuration descendant data nodes | 1303 | a | Return all descendant data nodes | 1304 +-------+-----------------------------------------------------+ 1306 The DOTS client can use Block-wise transfer [RFC7959] to get the list 1307 of all its mitigations maintained by a DOTS server, it can send 1308 Block2 Option in a GET request with NUM = 0 to aid in limiting the 1309 size of the response. If the representation of all the active 1310 mitigation requests associated with the DOTS client does not fit 1311 within a single datagram, the DOTS server MUST use the Block2 Option 1312 with NUM = 0 in the GET response. The Size2 Option may be conveyed 1313 in the response to indicate the total size of the resource 1314 representation. The DOTS client retrieves the rest of the 1315 representation by sending additional GET requests with Block2 Options 1316 containing NUM values greater than zero. The DOTS client MUST adhere 1317 to the block size preferences indicated by the DOTS server in the 1318 response. If the DOTS server uses the Block2 Option in the GET 1319 response and the response is for a dynamically changing resource 1320 (e.g., "c=n" or "c=a" query), the DOTS server MUST include the ETag 1321 Option in the response. The DOTS client MUST include the same ETag 1322 value in subsequent GET requests to retrieve the rest of the 1323 representation. 1325 The following examples illustrate how a DOTS client retrieves active 1326 mitigation requests from a DOTS server. In particular: 1328 o Figure 12 shows the example of a GET request to retrieve all DOTS 1329 mitigation requests signaled by a DOTS client. 1331 o Figure 13 shows the example of a GET request to retrieve a 1332 specific DOTS mitigation request signaled by a DOTS client. The 1333 configuration data to be reported in the response is formatted in 1334 the same order as was processed by the DOTS server in the original 1335 mitigation request. 1337 These two examples assume the default of "c=a"; that is, the DOTS 1338 client asks for all data to be reported by the DOTS server. 1340 Header: GET (Code=0.01) 1341 Uri-Path: ".well-known" 1342 Uri-Path: "dots" 1343 Uri-Path: "mitigate" 1344 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1345 Observe: 0 1347 Figure 12: GET to Retrieve all DOTS Mitigation Requests 1349 Header: GET (Code=0.01) 1350 Uri-Path: ".well-known" 1351 Uri-Path: "dots" 1352 Uri-Path: "mitigate" 1353 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1354 Uri-Path: "mid=12332" 1355 Observe: 0 1357 Figure 13: GET to Retrieve a Specific DOTS Mitigation Request 1359 If the DOTS server does not find the 'mid' Uri-Path value conveyed in 1360 the GET request in its configuration data for the requesting DOTS 1361 client, it MUST respond with a 4.04 (Not Found) error response code. 1362 Likewise, the same error MUST be returned as a response to a request 1363 to retrieve all mitigation records (i.e., 'mid' Uri-Path is not 1364 defined) of a given DOTS client if the DOTS server does not find any 1365 mitigation record for that DOTS client. As a reminder, a DOTS client 1366 is identified by its identity (e.g., client certificate, 'cuid') and 1367 optionally the 'cdid'. 1369 Figure 14 shows a response example of all active mitigation requests 1370 associated with the DOTS client as maintained by the DOTS server. 1371 The response indicates the mitigation status of each mitigation 1372 request. 1374 { 1375 "ietf-dots-signal-channel:mitigation-scope": { 1376 "scope": [ 1377 { 1378 "mid": 12332, 1379 "mitigation-start": "1507818434", 1380 "target-prefix": [ 1381 "2001:db8:6401::1/128", 1382 "2001:db8:6401::2/128" 1383 ], 1384 "target-protocol": [ 1385 17 1386 ], 1387 "lifetime": 1756, 1388 "status": "attack-successfully-mitigated", 1389 "bytes-dropped": "134334555", 1390 "bps-dropped": "43344", 1391 "pkts-dropped": "333334444", 1392 "pps-dropped": "432432" 1393 }, 1394 { 1395 "mid": 12333, 1396 "mitigation-start": "1507818393", 1397 "target-prefix": [ 1398 "2001:db8:6401::1/128", 1399 "2001:db8:6401::2/128" 1400 ], 1401 "target-protocol": [ 1402 6 1403 ], 1404 "lifetime": 1755, 1405 "status": "attack-stopped", 1406 "bytes-dropped": "0", 1407 "bps-dropped": "0", 1408 "pkts-dropped": "0", 1409 "pps-dropped": "0" 1410 } 1411 ] 1412 } 1413 } 1415 Figure 14: Response Body to a GET Request 1417 The mitigation status parameters are described below: 1419 mitigation-start: Mitigation start time is expressed in seconds 1420 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 1422 [RFC7049]). The CBOR encoding is modified so that the leading tag 1423 1 (epoch-based date/time) MUST be omitted. 1425 This is a mandatory attribute when an attack mitigation is active. 1426 Particularly, 'mitigation-start' is not returned for a mitigation 1427 with 'status' code set to 8. 1429 lifetime: The remaining lifetime of the mitigation request, in 1430 seconds. 1432 This is a mandatory attribute. 1434 status: Status of attack mitigation. The various possible values of 1435 'status' parameter are explained in Table 2. 1437 This is a mandatory attribute. 1439 bytes-dropped: The total dropped byte count for the mitigation 1440 request since the attack mitigation is triggered. The count wraps 1441 around when it reaches the maximum value of unsigned integer64. 1443 This is an optional attribute. 1445 bps-dropped: The average number of dropped bytes per second for the 1446 mitigation request since the attack mitigation is triggered. This 1447 average SHOULD be over five-minute intervals (that is, measuring 1448 bytes into five-minute buckets and then averaging these buckets 1449 over the time since the mitigation was triggered). 1451 This is an optional attribute. 1453 pkts-dropped: The total number of dropped packet count for the 1454 mitigation request since the attack mitigation is triggered. The 1455 count wraps around when it reaches the maximum value of unsigned 1456 integer64. 1458 This is an optional attribute. 1460 pps-dropped: The average number of dropped packets per second for 1461 the mitigation request since the attack mitigation is triggered. 1462 This average SHOULD be over five-minute intervals (that is, 1463 measuring packets into five-minute buckets and then averaging 1464 these buckets over the time since the mitigation was triggered). 1466 This is an optional attribute. 1468 +-----------+-------------------------------------------------------+ 1469 | Parameter | Description | 1470 | Value | | 1471 +-----------+-------------------------------------------------------+ 1472 | 1 | Attack mitigation setup is in progress (e.g., | 1473 | | changing the network path to redirect the inbound | 1474 | | traffic to a DOTS mitigator). | 1475 +-----------+-------------------------------------------------------+ 1476 | 2 | Attack is being successfully mitigated (e.g., traffic | 1477 | | is redirected to a DDoS mitigator and attack traffic | 1478 | | is dropped). | 1479 +-----------+-------------------------------------------------------+ 1480 | 3 | Attack has stopped and the DOTS client can withdraw | 1481 | | the mitigation request. This status code will be | 1482 | | transmitted for immediate mitigation requests till | 1483 | | the mitigation is withdrawn or the lifetime expires. | 1484 | | For mitigation requests with pre-configured scopes | 1485 | | (i.e., 'trigger-mitigation' set to 'false'), this | 1486 | | status code will be transmitted 4 times and then | 1487 | | transition to "8". | 1488 +-----------+-------------------------------------------------------+ 1489 | 4 | Attack has exceeded the mitigation provider | 1490 | | capability. | 1491 +-----------+-------------------------------------------------------+ 1492 | 5 | DOTS client has withdrawn the mitigation request and | 1493 | | the mitigation is active but terminating. | 1494 +-----------+-------------------------------------------------------+ 1495 | 6 | Attack mitigation is now terminated. | 1496 +-----------+-------------------------------------------------------+ 1497 | 7 | Attack mitigation is withdrawn (by the DOTS server). | 1498 | | If a mitigation request with 'trigger-mitigation' set | 1499 | | to false is withdrawn because it overlaps with an | 1500 | | immediate mitigation request, this status code will | 1501 | | be transmitted 4 times and then transition to "8" for | 1502 | | the mitigation request with pre-configured scopes. | 1503 +-----------+-------------------------------------------------------+ 1504 | 8 | Attack mitigation will be triggered for the | 1505 | | mitigation request only when the DOTS signal channel | 1506 | | session is lost. | 1507 +-----------+-------------------------------------------------------+ 1509 Table 2: Values of 'status' Parameter 1511 4.4.2.1. DOTS Servers Sending Mitigation Status 1513 The Observe Option defined in [RFC7641] extends the CoAP core 1514 protocol with a mechanism for a CoAP client to "observe" a resource 1515 on a CoAP server: The client retrieves a representation of the 1516 resource and requests this representation be updated by the server as 1517 long as the client is interested in the resource. DOTS 1518 implementations MUST use the Observe Option for both 'mitigate' and 1519 'config' (Section 4.2). 1521 A DOTS client conveys the Observe Option set to '0' in the GET 1522 request to receive asynchronous notifications of attack mitigation 1523 status from the DOTS server. 1525 Unidirectional mitigation notifications within the bidirectional 1526 signal channel enables asynchronous notifications between the agents. 1527 [RFC7641] indicates that (1) a notification can be sent in a 1528 Confirmable or a Non-confirmable message, and (2) the message type 1529 used is typically application-dependent and may be determined by the 1530 server for each notification individually. For DOTS server 1531 application, the message type MUST always be set to Non-confirmable 1532 even if the underlying COAP library elects a notification to be sent 1533 in a Confirmable message. 1535 Due to the higher likelihood of packet loss during a DDoS attack, the 1536 DOTS server periodically sends attack mitigation status to the DOTS 1537 client and also notifies the DOTS client whenever the status of the 1538 attack mitigation changes. If the DOTS server cannot maintain an RTT 1539 estimate, it MUST NOT send more than one asynchronous notification 1540 every 3 seconds, and SHOULD use an even less aggressive rate whenever 1541 possible (case 2 in Section 3.1.3 of [RFC8085]). 1543 When conflicting requests are detected, the DOTS server enforces the 1544 corresponding policy (e.g., accept all requests, reject all requests, 1545 accept only one request but reject all the others, ...). It is 1546 assumed that this policy is supplied by the DOTS server administrator 1547 or it is a default behavior of the DOTS server implementation. Then, 1548 the DOTS server sends notification message(s) to the DOTS client(s) 1549 at the origin of the conflict (refer to the conflict parameters 1550 defined in Section 4.4.1). A conflict notification message includes 1551 information about the conflict cause, scope, and the status of the 1552 mitigation request(s). For example, 1554 o A notification message with 'status' code set to '7 (Attack 1555 mitigation is withdrawn)' and 'conflict-status' set to '1' is sent 1556 to a DOTS client to indicate that an active mitigation request is 1557 deactivated because a conflict is detected. 1559 o A notification message with 'status' code set to '1 (Attack 1560 mitigation is in progress)' and 'conflict-status' set to '2' is 1561 sent to a DOTS client to indicate that this mitigation request is 1562 in progress, but a conflict is detected. 1564 Upon receipt of a conflict notification message indicating that a 1565 mitigation request is deactivated because of a conflict, a DOTS 1566 client MUST NOT resend the same mitigation request before the expiry 1567 of 'retry-timer'. It is also recommended that DOTS clients support 1568 means to alert administrators about mitigation conflicts. 1570 A DOTS client that is no longer interested in receiving notifications 1571 from the DOTS server can simply "forget" the observation. When the 1572 DOTS server sends the next notification, the DOTS client will not 1573 recognize the token in the message and thus will return a Reset 1574 message. This causes the DOTS server to remove the associated entry. 1575 Alternatively, the DOTS client can explicitly deregister itself by 1576 issuing a GET request that has the Token field set to the token of 1577 the observation to be cancelled and includes an Observe Option with 1578 the value set to '1' (deregister). The latter is RECOMMENDED. 1580 Figure 15 shows an example of a DOTS client requesting a DOTS server 1581 to send notifications related to a mitigation request. Note that for 1582 mitigations with pre-configured scopes (i.e., 'trigger-mitigation' 1583 set to 'false'), the state will need to transition from 3 (attack- 1584 stopped) to 8 (attack-mitigation-signal-loss). 1586 +-----------+ +-----------+ 1587 |DOTS client| |DOTS server| 1588 +-----------+ +-----------+ 1589 | | 1590 | GET / | 1591 | Token: 0x4a | Registration 1592 | Observe: 0 | 1593 +----------------------------------------->| 1594 | | 1595 | 2.05 Content | 1596 | Token: 0x4a | Notification of 1597 | Observe: 12 | the current state 1598 | status: "attack-mitigation-in-progress" | 1599 | | 1600 |<-----------------------------------------+ 1601 | 2.05 Content | 1602 | Token: 0x4a | Notification upon 1603 | Observe: 44 | a state change 1604 | status: "attack-successfully-mitigated" | 1605 | | 1606 |<-----------------------------------------+ 1607 | 2.05 Content | 1608 | Token: 0x4a | Notification upon 1609 | Observe: 60 | a state change 1610 | status: "attack-stopped" | 1611 |<-----------------------------------------+ 1612 | | 1613 ... 1615 Figure 15: Notifications of Attack Mitigation Status 1617 4.4.2.2. DOTS Clients Polling for Mitigation Status 1619 The DOTS client can send the GET request at frequent intervals 1620 without the Observe Option to retrieve the configuration data of the 1621 mitigation request and non-configuration data (i.e., the attack 1622 status). DOTS clients MAY be configured with a policy indicating the 1623 frequency of polling DOTS servers to get the mitigation status. 1624 Absent such policy, the frequency of polling the DOTS server to get 1625 the mitigation status SHOULD follow the transmission guidelines in 1626 Section 3.1.3 of [RFC8085]. 1628 If the DOTS server has been able to mitigate the attack and the 1629 attack has stopped, the DOTS server indicates as such in the status. 1630 In such case, the DOTS client recalls the mitigation request by 1631 issuing a DELETE request for this mitigation request (Section 4.4.4). 1633 A DOTS client SHOULD react to the status of the attack as per the 1634 information sent by the DOTS server rather than performing its own 1635 detection that the attack has been mitigated. This ensures that the 1636 DOTS client does not recall a mitigation request prematurely because 1637 it is possible that the DOTS client does not sense the DDoS attack on 1638 its resources, but the DOTS server could be actively mitigating the 1639 attack because the attack is not completely averted. 1641 4.4.3. Efficacy Update from DOTS Clients 1643 While DDoS mitigation is in progress, due to the likelihood of packet 1644 loss, a DOTS client MAY periodically transmit DOTS mitigation 1645 efficacy updates to the relevant DOTS server. A PUT request is used 1646 to convey the mitigation efficacy update to the DOTS server. This 1647 PUT request is treated as a refresh of the current mitigation. 1649 The PUT request used for efficacy update MUST include all the 1650 parameters used in the PUT request to carry the DOTS mitigation 1651 request (Section 4.4.1) unchanged apart from the 'lifetime' parameter 1652 value. If this is not the case, the DOTS server MUST reject the 1653 request with a 4.00 (Bad Request). 1655 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1656 value is used to make the PUT request conditional on the current 1657 existence of the mitigation request. If UDP is used as transport, 1658 CoAP requests may arrive out-of-order. For example, the DOTS client 1659 may send a PUT request to convey an efficacy update to the DOTS 1660 server followed by a DELETE request to withdraw the mitigation 1661 request, but the DELETE request arrives at the DOTS server before the 1662 PUT request. To handle out-of-order delivery of requests, if an If- 1663 Match Option is present in the PUT request and the 'mid' in the 1664 request matches a mitigation request from that DOTS client, the 1665 request is processed by the DOTS server. If no match is found, the 1666 PUT request is silently ignored by the DOTS server. 1668 An example of an efficacy update message, which includes an If-Match 1669 Option with an empty value, is depicted in Figure 16. 1671 Header: PUT (Code=0.03) 1672 Uri-Path: ".well-known" 1673 Uri-Path: "dots" 1674 Uri-Path: "mitigate" 1675 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1676 Uri-Path: "mid=123" 1677 If-Match: 1678 Content-Format: "application/dots+cbor" 1680 { 1681 "ietf-dots-signal-channel:mitigation-scope": { 1682 "scope": [ 1683 { 1684 "target-prefix": [ 1685 "2001:db8:6401::1/128", 1686 "2001:db8:6401::2/128" 1687 ], 1688 "target-port-range": [ 1689 { 1690 "lower-port": 80 1691 }, 1692 { 1693 "lower-port": 443 1694 }, 1695 { 1696 "lower-port": 8080 1697 } 1698 ], 1699 "target-protocol": [ 1700 6 1701 ], 1702 "attack-status": "under-attack" 1703 } 1704 ] 1705 } 1706 } 1708 Figure 16: An Example of Efficacy Update 1710 The 'attack-status' parameter is a mandatory attribute when 1711 performing an efficacy update. The various possible values contained 1712 in the 'attack-status' parameter are described in Table 3. 1714 +-----------+-------------------------------------------------------+ 1715 | Parameter | Description | 1716 | value | | 1717 +-----------+-------------------------------------------------------+ 1718 | 1 | The DOTS client determines that it is still under | 1719 | | attack. | 1720 +-----------+-------------------------------------------------------+ 1721 | 2 | The DOTS client determines that the attack is | 1722 | | successfully mitigated (e.g., attack traffic is not | 1723 | | seen). | 1724 +-----------+-------------------------------------------------------+ 1726 Table 3: Values of 'attack-status' Parameter 1728 The DOTS server indicates the result of processing a PUT request 1729 using CoAP response codes. The response code 2.04 (Changed) is 1730 returned if the DOTS server has accepted the mitigation efficacy 1731 update. The error response code 5.03 (Service Unavailable) is 1732 returned if the DOTS server has erred or is incapable of performing 1733 the mitigation. As specified in [RFC7252], 5.03 uses Max-Age option 1734 to indicate the number of seconds after which to retry. 1736 4.4.4. Withdraw a Mitigation 1738 DELETE requests are used to withdraw DOTS mitigation requests from 1739 DOTS servers (Figure 17). 1741 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE 1742 requests. 1744 The same considerations for manipulating 'cdid' parameter by DOTS 1745 gateways, as specified in Section 4.4.1, MUST be followed for DELETE 1746 requests. Uri-Path parameters with empty values MUST NOT be present 1747 in a request. 1749 Header: DELETE (Code=0.04) 1750 Uri-Path: ".well-known" 1751 Uri-Path: "dots" 1752 Uri-Path: "mitigate" 1753 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1754 Uri-Path: "mid=123" 1756 Figure 17: Withdraw a DOTS Mitigation 1758 If the DELETE request does not include 'cuid' and 'mid' parameters, 1759 the DOTS server MUST reply with a 4.00 (Bad Request). 1761 Once the request is validated, the DOTS server immediately 1762 acknowledges a DOTS client's request to withdraw the DOTS signal 1763 using 2.02 (Deleted) response code with no response payload. A 2.02 1764 (Deleted) Response Code is returned even if the 'mid' parameter value 1765 conveyed in the DELETE request does not exist in its configuration 1766 data before the request. 1768 If the DOTS server finds the 'mid' parameter value conveyed in the 1769 DELETE request in its configuration data for the DOTS client, then to 1770 protect against route or DNS flapping caused by a DOTS client rapidly 1771 removing a mitigation, and to dampen the effect of oscillating 1772 attacks, the DOTS server MAY allow mitigation to continue for a 1773 limited period after acknowledging a DOTS client's withdrawal of a 1774 mitigation request. During this period, the DOTS server status 1775 messages SHOULD indicate that mitigation is active but terminating 1776 (Section 4.4.2). 1778 The initial active-but-terminating period SHOULD be sufficiently long 1779 to absorb latency incurred by route propagation. The active-but- 1780 terminating period SHOULD be set by default to 120 seconds. If the 1781 client requests mitigation again before the initial active-but- 1782 terminating period elapses, the DOTS server MAY exponentially 1783 increase (the base of the exponent is 2) the active-but-terminating 1784 period up to a maximum of 300 seconds (5 minutes). 1786 Once the active-but-terminating period elapses, the DOTS server MUST 1787 treat the mitigation as terminated, as the DOTS client is no longer 1788 responsible for the mitigation. 1790 If a mitigation is triggered due to a signal channel loss, the DOTS 1791 server relies upon normal triggers to stop that mitigation 1792 (typically, receipt of a valid DELETE request, expiry of the 1793 mitigation lifetime, or scrubbing the traffic to the attack target). 1794 In particular, the DOTS server MUST NOT consider the signal channel 1795 recovery as a trigger to stop the mitigation. 1797 4.5. DOTS Signal Channel Session Configuration 1799 A DOTS client can negotiate, configure, and retrieve the DOTS signal 1800 channel session behavior with its DOTS peers. The DOTS signal 1801 channel can be used, for example, to configure the following: 1803 a. Heartbeat interval (heartbeat-interval): DOTS agents regularly 1804 send heartbeats to each other after mutual authentication is 1805 successfully completed in order to keep the DOTS signal channel 1806 open. Heartbeat messages are exchanged between DOTS agents every 1807 'heartbeat-interval' seconds to detect the current status of the 1808 DOTS signal channel session. 1810 b. Missing heartbeats allowed (missing-hb-allowed): This variable 1811 indicates the maximum number of consecutive heartbeat messages 1812 for which a DOTS agent did not receive a response before 1813 concluding that the session is disconnected or defunct. 1815 c. Acceptable signal loss ratio: Maximum retransmissions, 1816 retransmission timeout value, and other message transmission 1817 parameters for the DOTS signal channel. 1819 The same or distinct configuration sets may be used during times when 1820 a mitigation is active ('mitigating-config') and when no mitigation 1821 is active ('idle-config'). This is particularly useful for DOTS 1822 servers that might want to reduce heartbeat frequency or cease 1823 heartbeat exchanges when an active DOTS client has not requested 1824 mitigation. If distinct configurations are used, DOTS agents MUST 1825 follow the appropriate configuration set as a function of the 1826 mitigation activity (e.g., if no mitigation request is active (also 1827 referred to as 'idle' time), 'idle-config'-related values must be 1828 followed). Additionally, DOTS agents MUST automatically switch to 1829 the other configuration upon a change in the mitigation activity 1830 (e.g., if an attack mitigation is launched after an 'idle' time, the 1831 DOTS agent switches from 'idle-config' to 'mitigating-config'-related 1832 values). 1834 CoAP Requests and responses are indicated for reliable delivery by 1835 marking them as Confirmable messages. DOTS signal channel session 1836 configuration requests and responses are marked as Confirmable 1837 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1838 message is retransmitted using a default timeout and exponential 1839 back-off between retransmissions, until the DOTS server sends an 1840 Acknowledgement message (ACK) with the same Message ID conveyed from 1841 the DOTS client. 1843 Message transmission parameters are defined in Section 4.8 of 1844 [RFC7252]. The DOTS server can either piggyback the response in the 1845 acknowledgement message or, if the DOTS server cannot respond 1846 immediately to a request carried in a Confirmable message, it simply 1847 responds with an Empty Acknowledgement message so that the DOTS 1848 client can stop retransmitting the request. Empty Acknowledgement 1849 messages are explained in Section 2.2 of [RFC7252]. When the 1850 response is ready, the server sends it in a new Confirmable message 1851 which in turn needs to be acknowledged by the DOTS client (see 1852 Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and responses 1853 exchanged between DOTS agents during 'idle' time are marked as 1854 Confirmable messages. 1856 Implementation Note: A DOTS client that receives a response in a 1857 Confirmable message may want to clean up the message state right 1858 after sending the ACK. If that ACK is lost and the DOTS server 1859 retransmits the Confirmable message, the DOTS client may no longer 1860 have any state that would help it correlate this response: from 1861 the DOTS client's standpoint, the retransmission message is 1862 unexpected. The DOTS client will send a Reset message so it does 1863 not receive any more retransmissions. This behavior is normal and 1864 not an indication of an error (see Section 5.3.2 of [RFC7252] for 1865 more details). 1867 4.5.1. Discover Configuration Parameters 1869 A GET request is used to obtain acceptable (e.g., minimum and maximum 1870 values) and current configuration parameters on the DOTS server for 1871 DOTS signal channel session configuration. This procedure occurs 1872 between a DOTS client and its immediate peer DOTS server. As such, 1873 this GET request MUST NOT be relayed by a DOTS gateway. 1875 Figure 18 shows how to obtain acceptable configuration parameters for 1876 the DOTS server. 1878 Header: GET (Code=0.01) 1879 Uri-Path: ".well-known" 1880 Uri-Path: "dots" 1881 Uri-Path: "config" 1883 Figure 18: GET to Retrieve Configuration 1885 The DOTS server in the 2.05 (Content) response conveys the current, 1886 minimum, and maximum attribute values acceptable by the DOTS server 1887 (Figure 19). 1889 { 1890 "ietf-dots-signal-channel:signal-config": { 1891 "mitigating-config": { 1892 "heartbeat-interval": { 1893 "max-value": number, 1894 "min-value": number, 1895 "current-value": number 1896 }, 1897 "missing-hb-allowed": { 1898 "max-value": number, 1899 "min-value": number, 1900 "current-value": number 1901 }, 1902 "max-retransmit": { 1903 "max-value": number, 1904 "min-value": number, 1905 "current-value": number 1907 }, 1908 "ack-timeout": { 1909 "max-value-decimal": "string", 1910 "min-value-decimal": "string", 1911 "current-value-decimal": "string" 1912 }, 1913 "ack-random-factor": { 1914 "max-value-decimal": "string", 1915 "min-value-decimal": "string", 1916 "current-value-decimal": "string" 1917 } 1918 }, 1919 "idle-config": { 1920 "heartbeat-interval": { 1921 "max-value": number, 1922 "min-value": number, 1923 "current-value": number 1924 }, 1925 "missing-hb-allowed": { 1926 "max-value": number, 1927 "min-value": number, 1928 "current-value": number 1929 }, 1930 "max-retransmit": { 1931 "max-value": number, 1932 "min-value": number, 1933 "current-value": number 1934 }, 1935 "ack-timeout": { 1936 "max-value-decimal": "string", 1937 "min-value-decimal": "string", 1938 "current-value-decimal": "string" 1939 }, 1940 "ack-random-factor": { 1941 "max-value-decimal": "string", 1942 "min-value-decimal": "string", 1943 "current-value-decimal": "string" 1944 } 1945 } 1946 } 1947 } 1949 Figure 19: GET Configuration Response Body Schema 1951 The parameters in Figure 19 are described below: 1953 mitigating-config: Set of configuration parameters to use when a 1954 mitigation is active. The following parameters may be included: 1956 heartbeat-interval: Time interval in seconds between two 1957 consecutive heartbeat messages. 1959 '0' is used to disable the heartbeat mechanism. 1961 This is an optional attribute. 1963 missing-hb-allowed: Maximum number of consecutive heartbeat 1964 messages for which the DOTS agent did not receive a response 1965 before concluding that the session is disconnected. 1967 This is an optional attribute. 1969 max-retransmit: Maximum number of retransmissions for a message 1970 (referred to as MAX_RETRANSMIT parameter in CoAP). 1972 This is an optional attribute. 1974 ack-timeout: Timeout value in seconds used to calculate the 1975 initial retransmission timeout value (referred to as 1976 ACK_TIMEOUT parameter in CoAP). 1978 This is an optional attribute. 1980 ack-random-factor: Random factor used to influence the timing of 1981 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1982 CoAP). 1984 This is an optional attribute. 1986 idle-config: Set of configuration parameters to use when no 1987 mitigation is active. This attribute has the same structure as 1988 'mitigating-config'. 1990 Figure 20 shows an example of acceptable and current configuration 1991 parameters on a DOTS server for DOTS signal channel session 1992 configuration. The same acceptable configuration is used during 1993 mitigation and idle times. 1995 { 1996 "ietf-dots-signal-channel:signal-config": { 1997 "mitigating-config": { 1998 "heartbeat-interval": { 1999 "max-value": 240, 2000 "min-value": 15, 2001 "current-value": 30 2002 }, 2003 "missing-hb-allowed": { 2004 "max-value": 9, 2005 "min-value": 3, 2006 "current-value": 5 2007 }, 2008 "max-retransmit": { 2009 "max-value": 15, 2010 "min-value": 2, 2011 "current-value": 3 2012 }, 2013 "ack-timeout": { 2014 "max-value-decimal": "30.00", 2015 "min-value-decimal": "1.00", 2016 "current-value-decimal": "2.00" 2017 }, 2018 "ack-random-factor": { 2019 "max-value-decimal": "4.00", 2020 "min-value-decimal": "1.10", 2021 "current-value-decimal": "1.50" 2022 } 2023 }, 2024 "idle-config": { 2025 "heartbeat-interval": { 2026 "max-value": 240, 2027 "min-value": 15, 2028 "current-value": 30 2029 }, 2030 "missing-hb-allowed": { 2031 "max-value": 9, 2032 "min-value": 3, 2033 "current-value": 5 2034 }, 2035 "max-retransmit": { 2036 "max-value": 15, 2037 "min-value": 2, 2038 "current-value": 3 2039 }, 2040 "ack-timeout": { 2041 "max-value-decimal": "30.00", 2042 "min-value-decimal": "1.00", 2043 "current-value-decimal": "2.00" 2044 }, 2045 "ack-random-factor": { 2046 "max-value-decimal": "4.00", 2047 "min-value-decimal": "1.10", 2048 "current-value-decimal": "1.50" 2049 } 2050 } 2051 } 2053 } 2055 Figure 20: Example of a Configuration Response Body 2057 4.5.2. Convey DOTS Signal Channel Session Configuration 2059 A PUT request (Figures 21 and 22) is used to convey the configuration 2060 parameters for the signal channel (e.g., heartbeat interval, maximum 2061 retransmissions). Message transmission parameters for CoAP are 2062 defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of 2063 transmission parameter values are ack-timeout (2 seconds), max- 2064 retransmit (3), ack-random-factor (1.5). In addition to those 2065 parameters, the RECOMMENDED specific DOTS transmission parameter 2066 values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' 2067 (5). 2069 Note: heartbeat-interval should be tweaked to also assist DOTS 2070 messages for NAT traversal (SIG-011 of 2071 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 2072 messages must not be sent more frequently than once every 15 2073 seconds and should use longer intervals when possible. 2074 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 2075 minutes or longer, but experience shows that sending packets every 2076 15 to 30 seconds is necessary to prevent the majority of 2077 middleboxes from losing state for UDP flows. From that 2078 standpoint, the RECOMMENDED minimum heartbeat-interval is 15 2079 seconds and the RECOMMENDED maximum heartbeat-interval is 240 2080 seconds. The recommended value of 30 seconds is selected to 2081 anticipate the expiry of NAT state. 2083 A heartbeat-interval of 30 seconds may be considered as too chatty 2084 in some deployments. For such deployments, DOTS agents may 2085 negotiate longer heartbeat-interval values to prevent any network 2086 overload with too frequent keepalives. 2088 Different heartbeat intervals can be defined for 'mitigating- 2089 config' and 'idle-config' to reduce being too chatty during idle 2090 times. If there is an on-path translator between the DOTS client 2091 (standalone or part of a DOTS gateway) and the DOTS server, the 2092 'mitigating-config' heartbeat-interval has to be smaller than the 2093 translator session timeout. It is recommended that the 'idle- 2094 config' heartbeat-interval is also smaller than the translator 2095 session timeout to prevent translator traversal issues, or 2096 disabled entirely. Means to discover the lifetime assigned by a 2097 translator are out of scope. 2099 Section 4.2 of [RFC7252] defines a "CoAP Ping" mechanism. 2100 Concretely, the DOTS agent sends an Empty Confirmable message and the 2101 peer DOTS agent will respond by sending a Reset message. 2103 When a Confirmable "CoAP Ping" is sent, and if there is no response, 2104 the "CoAP Ping" is retransmitted max-retransmit number of times by 2105 the CoAP layer using an initial timeout set to a random duration 2106 between ack-timeout and (ack-timeout*ack-random-factor) and 2107 exponential back-off between retransmissions. By choosing the 2108 recommended transmission parameters, the "CoAP Ping" will timeout 2109 after 45 seconds. If the DOTS agent does not receive any response 2110 from the peer DOTS agent for 'missing-hb-allowed' number of 2111 consecutive "CoAP Ping" Confirmable messages, it concludes that the 2112 DOTS signal channel session is disconnected. A DOTS client MUST NOT 2113 transmit a "CoAP Ping" while waiting for the previous "CoAP Ping" 2114 response from the same DOTS server. 2116 If the DOTS agent wishes to change the default values of message 2117 transmission parameters, it SHOULD follow the guidance given in 2118 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 2119 values for message transmission parameters and default values for 2120 non-negotiated message transmission parameters. 2122 The signal channel session configuration is applicable to a single 2123 DOTS signal channel session between DOTS agents, so the 'cuid' Uri- 2124 Path MUST NOT be used. 2126 Header: PUT (Code=0.03) 2127 Uri-Path: ".well-known" 2128 Uri-Path: "dots" 2129 Uri-Path: "config" 2130 Uri-Path: "sid=123" 2131 Content-Format: "application/dots+cbor" 2133 { 2134 ... 2135 } 2137 Figure 21: PUT to Convey the DOTS Signal Channel Session 2138 Configuration Data 2140 The additional Uri-Path parameter to those defined in Table 1 is as 2141 follows: 2143 sid: Session Identifier is an identifier for the DOTS signal channel 2144 session configuration data represented as an integer. This 2145 identifier MUST be generated by DOTS clients. 'sid' values MUST 2146 increase monotonically (when a new PUT is generated by a DOTS 2147 client to convey the configuration parameters for the signal 2148 channel). 2150 This is a mandatory attribute. 2152 { 2153 "ietf-dots-signal-channel:signal-config": { 2154 "mitigating-config": { 2155 "heartbeat-interval": { 2156 "current-value": number 2157 }, 2158 "missing-hb-allowed": { 2159 "current-value": number 2160 }, 2161 "max-retransmit": { 2162 "current-value": number 2163 }, 2164 "ack-timeout": { 2165 "current-value-decimal": "string" 2166 }, 2167 "ack-random-factor": { 2168 "current-value-decimal": "string" 2169 } 2170 }, 2171 "idle-config": { 2172 "heartbeat-interval": { 2173 "current-value": number 2174 }, 2175 "missing-hb-allowed": { 2176 "current-value": number 2177 }, 2178 "max-retransmit": { 2179 "current-value": number 2180 }, 2181 "ack-timeout": { 2182 "current-value-decimal": "string" 2183 }, 2184 "ack-random-factor": { 2185 "current-value-decimal": "string" 2186 } 2187 } 2188 } 2189 } 2191 Figure 22: PUT to Convey the DOTS Signal Channel Session 2192 Configuration Data (Message Body Schema) 2194 The meaning of the parameters in the CBOR body (Figure 22) is defined 2195 in Section 4.5.1. 2197 At least one of the attributes 'heartbeat-interval', 'missing-hb- 2198 allowed', 'max-retransmit', 'ack-timeout', and 'ack-random-factor' 2199 MUST be present in the PUT request. Note that 'heartbeat-interval', 2200 'missing-hb-allowed', 'max-retransmit', 'ack-timeout', and 'ack- 2201 random-factor', if present, do not need to be provided for both 2202 'mitigating-config', and 'idle-config' in a PUT request. 2204 The PUT request with a higher numeric 'sid' value overrides the DOTS 2205 signal channel session configuration data installed by a PUT request 2206 with a lower numeric 'sid' value. To avoid maintaining a long list 2207 of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be 2208 automatically deleted and no longer available at the DOTS server. 2210 Figure 23 shows a PUT request example to convey the configuration 2211 parameters for the DOTS signal channel. In this example, the 2212 heartbeat mechanism is disabled when no mitigation is active, while 2213 the heartbeat interval is set to '91' when a mitigation is active. 2215 Header: PUT (Code=0.03) 2216 Uri-Path: ".well-known" 2217 Uri-Path: "dots" 2218 Uri-Path: "config" 2219 Uri-Path: "sid=123" 2220 Content-Format: "application/dots+cbor" 2222 { 2223 "ietf-dots-signal-channel:signal-config": { 2224 "mitigating-config": { 2225 "heartbeat-interval": { 2226 "current-value": 91 2227 }, 2228 "missing-hb-allowed": { 2229 "current-value": 3 2230 }, 2231 "max-retransmit": { 2232 "current-value": 3 2233 }, 2234 "ack-timeout": { 2235 "current-value-decimal": "2.00" 2236 }, 2237 "ack-random-factor": { 2238 "current-value-decimal": "1.50" 2239 } 2240 }, 2241 "idle-config": { 2242 "heartbeat-interval": { 2243 "current-value": 0 2244 }, 2245 "max-retransmit": { 2246 "current-value": 3 2247 }, 2248 "ack-timeout": { 2249 "current-value-decimal": "2.00" 2250 }, 2251 "ack-random-factor": { 2252 "current-value-decimal": "1.50" 2253 } 2254 } 2255 } 2256 } 2258 Figure 23: PUT to Convey the Configuration Parameters 2260 The DOTS server indicates the result of processing the PUT request 2261 using CoAP response codes: 2263 o If the request is missing a mandatory attribute, does not include 2264 a 'sid' Uri-Path, or contains one or more invalid or unknown 2265 parameters, 4.00 (Bad Request) MUST be returned in the response. 2267 o If the DOTS server does not find the 'sid' parameter value 2268 conveyed in the PUT request in its configuration data and if the 2269 DOTS server has accepted the configuration parameters, then a 2270 response code 2.01 (Created) MUST be returned in the response. 2272 o If the DOTS server finds the 'sid' parameter value conveyed in the 2273 PUT request in its configuration data and if the DOTS server has 2274 accepted the updated configuration parameters, 2.04 (Changed) MUST 2275 be returned in the response. 2277 o If any of the 'heartbeat-interval', 'missing-hb-allowed', 'max- 2278 retransmit', 'target-protocol', 'ack-timeout', and 'ack-random- 2279 factor' attribute values are not acceptable to the DOTS server, 2280 4.22 (Unprocessable Entity) MUST be returned in the response. 2281 Upon receipt of this error code, the DOTS client SHOULD retrieve 2282 the maximum and minimum attribute values acceptable to the DOTS 2283 server (Section 4.5.1). 2285 The DOTS client may re-try and send the PUT request with updated 2286 attribute values acceptable to the DOTS server. 2288 A DOTS client may issue a GET message with 'sid' Uri-Path parameter 2289 to retrieve the negotiated configuration. The response does not need 2290 to include 'sid' in its message body. 2292 4.5.3. Configuration Freshness and Notifications 2294 Max-Age Option (Section 5.10.5 of [RFC7252]) SHOULD be returned by a 2295 DOTS server to associate a validity time with a configuration it 2296 sends. This feature allows the update of the configuration data if a 2297 change occurs at the DOTS server side. For example, the new 2298 configuration may instruct a DOTS client to cease heartbeats or 2299 reduce heartbeat frequency. 2301 It is NOT RECOMMENDED to return a Max-Age Option set to 0. 2303 Returning a Max-Age Option set to 2**32-1 is equivalent to 2304 associating an infinite lifetime with the configuration. 2306 If a non-zero value of Max-Age Option is received by a DOTS client, 2307 it MUST issue a GET request with 'sid' Uri-Path parameter to retrieve 2308 the current and acceptable configuration before the expiry of the 2309 value enclosed in the Max-Age option. This request is considered by 2310 the client and the server as a means to refresh the configuration 2311 parameters for the signal channel. When a DDoS attack is active, 2312 refresh requests MUST NOT be sent by DOTS clients and the DOTS server 2313 MUST NOT terminate the (D)TLS session after the expiry of the value 2314 returned in Max-Age Option. 2316 If Max-Age Option is not returned in a response, the DOTS client 2317 initiates GET requests to refresh the configuration parameters each 2318 60 seconds (Section 5.10.5 of [RFC7252]). To prevent such overload, 2319 it is RECOMMENDED that DOTS servers return a Max-Age Option in GET 2320 responses. Considerations related to which value to use and how such 2321 value is set, are implementation- and deployment-specific. 2323 If an Observe Option set to 0 is included in the configuration 2324 request, the DOTS server sends notifications of any configuration 2325 change (Section 4.2 of [RFC7641]). 2327 If a DOTS server detects that a misbehaving DOTS client does not 2328 contact the DOTS server after the expiry of Max-Age and retrieve the 2329 signal channel configuration data, it MAY terminate the (D)TLS 2330 session. A (D)TLS session is terminated by the receipt of an 2331 authenticated message that closes the connection (e.g., a fatal alert 2332 (Section 6 of [RFC8446])). 2334 4.5.4. Delete DOTS Signal Channel Session Configuration 2336 A DELETE request is used to delete the installed DOTS signal channel 2337 session configuration data (Figure 24). 2339 Header: DELETE (Code=0.04) 2340 Uri-Path: ".well-known" 2341 Uri-Path: "dots" 2342 Uri-Path: "config" 2343 Uri-Path: "sid=123" 2345 Figure 24: Delete Configuration 2347 The DOTS server resets the DOTS signal channel session configuration 2348 back to the default values and acknowledges a DOTS client's request 2349 to remove the DOTS signal channel session configuration using 2.02 2350 (Deleted) response code. 2352 Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request 2353 to set the configuration parameters to default values. Such a 2354 request does not include any 'sid'. 2356 4.6. Redirected Signaling 2358 Redirected DOTS signaling is discussed in detail in Section 3.2.2 of 2359 [I-D.ietf-dots-architecture]. 2361 If a DOTS server wants to redirect a DOTS client to an alternative 2362 DOTS server for a signal session, then the response code 5.03 2363 (Service Unavailable) will be returned in the response to the DOTS 2364 client. 2366 The DOTS server can return the error response code 5.03 in response 2367 to a request from the DOTS client or convey the error response code 2368 5.03 in a unidirectional notification response from the DOTS server. 2370 The DOTS server in the error response conveys the alternate DOTS 2371 server's FQDN, and the alternate DOTS server's IP address(es) values 2372 in the CBOR body (Figure 25). 2374 { 2375 "ietf-dots-signal-channel:redirected-signal": { 2376 "alt-server": "string", 2377 "alt-server-record": [ 2378 "string" 2379 ] 2380 } 2382 Figure 25: Redirected Server Error Response Body Schema 2384 The parameters are described below: 2386 alt-server: FQDN of an alternate DOTS server. 2388 This is a mandatory attribute. 2390 alt-server-record: A list of IP addresses of an alternate DOTS 2391 server. 2393 This is an optional attribute. 2395 The DOTS server returns the Time to live (TTL) of the alternate DOTS 2396 server in a Max-Age Option. That is, the time interval that the 2397 alternate DOTS server may be cached for use by a DOTS client. A Max- 2398 Age Option set to 2**32-1 is equivalent to receiving an infinite TTL. 2399 This value means that the alternate DOTS server is to be used until 2400 the alternate DOTS server redirects the traffic with another 5.03 2401 response which encloses an alternate server. 2403 A Max-Age Option set to '0' may be returned for redirecting 2404 mitigation requests. Such value means that the redirection applies 2405 only for the mitigation request in progress. Returning short TTL in 2406 a Max-Age Option may adversely impact DOTS clients on slow links. 2407 Returning short values should be avoided under such conditions. 2409 If the alternate DOTS server TTL has expired, the DOTS client MUST 2410 use the DOTS server(s), that was provisioned using means discussed in 2411 Section 4.1. This fall back mechanism is triggered immediately upon 2412 expiry of the TTL, except when a DDoS attack is active. 2414 Requests issued by misbehaving DOTS clients which do not honor the 2415 TTL conveyed in the Max-Age Option or react to explicit re-direct 2416 messages can be rejected by DOTS servers. 2418 Figure 26 shows a 5.03 response example to convey the DOTS alternate 2419 server 'alt-server.example' together with its IP addresses 2420 2001:db8:6401::1 and 2001:db8:6401::2. 2422 { 2423 "ietf-dots-signal-channel:redirected-signal": { 2424 "alt-server": "alt-server.example", 2425 "alt-server-record": [ 2426 "2001:db8:6401::1", 2427 "2001:db8:6401::2" 2428 ] 2429 } 2431 Figure 26: Example of Redirected Server Error Response Body 2433 When the DOTS client receives 5.03 response with an alternate server 2434 included, it considers the current request as failed, but SHOULD try 2435 re-sending the request to the alternate DOTS server. During a DDoS 2436 attack, the DNS server may be the target of another DDoS attack, 2437 alternate DOTS server's IP addresses conveyed in the 5.03 response 2438 help the DOTS client skip DNS lookup of the alternate DOTS server, at 2439 the cost of trusting the first DOTS server to provide accurate 2440 information. The DOTS client can then try to establish a UDP or a 2441 TCP session with the alternate DOTS server. The DOTS client MAY 2442 implement a method to construct IPv4-embedded IPv6 addresses 2443 [RFC6052]; this is required to handle the scenario where an IPv6-only 2444 DOTS client communicates with an IPv4-only alternate DOTS server. 2446 If the DOTS client has been redirected to a DOTS server to which it 2447 has already communicated with within the last five (5) minutes, it 2448 MUST ignore the redirection and try to contact other DOTS servers 2449 listed in the local configuration or discovered using dynamic means 2450 such as DHCP or SRV procedures [I-D.ietf-dots-server-discovery]. It 2451 is RECOMMENDED that DOTS clients support means to alert 2452 administrators about redirect loops. 2454 4.7. Heartbeat Mechanism 2456 To provide an indication of signal health and distinguish an 'idle' 2457 signal channel from a 'disconnected' or 'defunct' session, the DOTS 2458 agent sends a heartbeat over the signal channel to maintain its half 2459 of the channel (also, aligned with the "consents" recommendation in 2460 Section 6 of [RFC8085]). The DOTS agent similarly expects a 2461 heartbeat from its peer DOTS agent, and may consider a session 2462 terminated in the prolonged absence of a peer agent heartbeat. 2463 Concretely, while the communication between the DOTS agents is 2464 otherwise quiescent, the DOTS client will probe the DOTS server to 2465 ensure it has maintained cryptographic state and vice versa. Such 2466 probes can also keep firewalls and/or stateful translators bindings 2467 alive. This probing reduces the frequency of establishing a new 2468 handshake when a DOTS signal needs to be conveyed to the DOTS server. 2470 DOTS servers MAY trigger their heartbeat requests immediately after 2471 receiving heartbeat probes from peer DOTS clients. As a reminder, it 2472 is the responsibility of DOTS clients to ensure that on-path 2473 translators/firewalls are maintaining a binding so that the same 2474 external IP address and/or port number is retained for the DOTS 2475 signal channel session. 2477 In case of a massive DDoS attack that saturates the incoming link(s) 2478 to the DOTS client, all traffic from the DOTS server to the DOTS 2479 client will likely be dropped, although the DOTS server receives 2480 heartbeat requests in addition to DOTS messages sent by the DOTS 2481 client. In this scenario, DOTS clients MUST behave differently to 2482 handle message transmission and DOTS signal channel session 2483 liveliness during link saturation: 2485 The DOTS client MUST NOT consider the DOTS signal channel session 2486 terminated even after a maximum 'missing-hb-allowed' threshold is 2487 reached. The DOTS client SHOULD keep on using the current DOTS 2488 signal channel session to send heartbeat requests over it, so that 2489 the DOTS server knows the DOTS client has not disconnected the 2490 DOTS signal channel session. 2492 After the maximum 'missing-hb-allowed' threshold is reached, the 2493 DOTS client SHOULD try to resume the (D)TLS session. The DOTS 2494 client SHOULD send mitigation requests over the current DOTS 2495 signal channel session, and in parallel, for example, try to 2496 resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to 2497 piggyback the mitigation request in the ClientHello message. 2499 As soon as the link is no longer saturated, if traffic from the 2500 DOTS server reaches the DOTS client over the current DOTS signal 2501 channel session, the DOTS client can stop (D)TLS session 2502 resumption or if (D)TLS session resumption is successful then 2503 disconnect the current DOTS signal channel session. 2505 If the DOTS server receives traffic from the peer DOTS client (e.g., 2506 peer DOTS client initiated heartbeats) but maximum 'missing-hb- 2507 allowed' threshold is reached, the DOTS server MUST NOT consider the 2508 DOTS signal channel session disconnected. The DOTS server MUST keep 2509 on using the current DOTS signal channel session so that the DOTS 2510 client can send mitigation requests over the current DOTS signal 2511 channel session. In this case, the DOTS server can identify the DOTS 2512 client is under attack and the inbound link to the DOTS client 2513 (domain) is saturated. Furthermore, if the DOTS server does not 2514 receive a mitigation request from the DOTS client, it implies the 2515 DOTS client has not detected the attack or, if an attack mitigation 2516 is in progress, it implies the applied DDoS mitigation actions are 2517 not yet effective to handle the DDoS attack volume. 2519 If the DOTS server does not receive any traffic from the peer DOTS 2520 client, then the DOTS server sends heartbeat requests to the DOTS 2521 client and after maximum 'missing-hb-allowed' threshold is reached, 2522 the DOTS server concludes the session is disconnected. The DOTS 2523 server can then trigger pre-configured mitigation requests for this 2524 DOTS client (if any). 2526 In DOTS over UDP, heartbeat messages MUST be exchanged between the 2527 DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of 2528 [RFC7252]. 2530 In DOTS over TCP, heartbeat messages MUST be exchanged between the 2531 DOTS agents using the Ping and Pong messages specified in Section 5.4 2532 of [RFC8323]. That is, the DOTS agent sends a Ping message and the 2533 peer DOTS agent would respond by sending a single Pong message. 2535 5. DOTS Signal Channel YANG Modules 2537 This document defines a YANG [RFC7950] module for DOTS mitigation 2538 scope, DOTS signal channel session configuration data, and DOTS 2539 redirection signaling. 2541 This YANG module (ietf-dots-signal-channel) defines the DOTS client 2542 interaction with the DOTS server as seen by the DOTS client. A DOTS 2543 server is allowed to update the non-configurable 'ro' entities in the 2544 responses. This YANG module is not intended to be used via NETCONF/ 2545 RESTCONF for DOTS server management purposes; such module is out of 2546 the scope of this document. It serves only to provide a data model 2547 and encoding, but not a management data model. 2549 A companion YANG module is defined to include a collection of types 2550 defined by IANA: "iana-dots-signal-channel" (Section 5.2). 2552 5.1. Tree Structure 2554 This document defines the YANG module "ietf-dots-signal-channel" 2555 (Section 5.3), which has the following tree structure. A DOTS signal 2556 message can be a mitigation, a configuration, or a redirect message. 2558 module: ietf-dots-signal-channel 2559 +--rw dots-signal 2560 +--rw (message-type)? 2561 +--:(mitigation-scope) 2562 | +--rw scope* [cuid mid] 2563 | +--rw cdid? string 2564 | +--rw cuid string 2565 | +--rw mid uint32 2566 | +--rw target-prefix* inet:ip-prefix 2567 | +--rw target-port-range* [lower-port] 2568 | | +--rw lower-port inet:port-number 2569 | | +--rw upper-port? inet:port-number 2570 | +--rw target-protocol* uint8 2571 | +--rw target-fqdn* inet:domain-name 2572 | +--rw target-uri* inet:uri 2573 | +--rw alias-name* string 2574 | +--rw lifetime? int32 2575 | +--rw trigger-mitigation? boolean 2576 | +--ro mitigation-start? uint64 2577 | +--ro status? iana-signal:status 2578 | +--ro conflict-information 2579 | | +--ro conflict-status? iana-signal:conflict-status 2580 | | +--ro conflict-cause? iana-signal:conflict-cause 2581 | | +--ro retry-timer? uint32 2582 | | +--ro conflict-scope 2583 | | +--ro target-prefix* inet:ip-prefix 2584 | | +--ro target-port-range* [lower-port] 2585 | | | +--ro lower-port inet:port-number 2586 | | | +--ro upper-port? inet:port-number 2587 | | +--ro target-protocol* uint8 2588 | | +--ro target-fqdn* inet:domain-name 2589 | | +--ro target-uri* inet:uri 2590 | | +--ro alias-name* string 2591 | | +--ro acl-list* [acl-name] 2592 | | | +--ro acl-name 2593 | | | | -> /ietf-data:dots-data/dots-client/acls/ 2594 | | | | acl/name 2595 | | | +--ro acl-type? 2596 | | | -> /ietf-data:dots-data/dots-client/acls/ 2597 | | | acl/type 2598 | | +--ro mid? -> ../../../mid 2599 | +--ro bytes-dropped? yang:zero-based-counter64 2600 | +--ro bps-dropped? yang:gauge64 2601 | +--ro pkts-dropped? yang:zero-based-counter64 2602 | +--ro pps-dropped? yang:gauge64 2603 | +--rw attack-status? iana-signal:attack-status 2604 +--:(signal-config) 2605 | +--rw sid uint32 2606 | +--rw mitigating-config 2607 | | +--rw heartbeat-interval 2608 | | | +--ro max-value? uint16 2609 | | | +--ro min-value? uint16 2610 | | | +--rw current-value? uint16 2611 | | +--rw missing-hb-allowed 2612 | | | +--ro max-value? uint16 2613 | | | +--ro min-value? uint16 2614 | | | +--rw current-value? uint16 2615 | | +--rw max-retransmit 2616 | | | +--ro max-value? uint16 2617 | | | +--ro min-value? uint16 2618 | | | +--rw current-value? uint16 2619 | | +--rw ack-timeout 2620 | | | +--ro max-value-decimal? decimal64 2621 | | | +--ro min-value-decimal? decimal64 2622 | | | +--rw current-value-decimal? decimal64 2623 | | +--rw ack-random-factor 2624 | | +--ro max-value-decimal? decimal64 2625 | | +--ro min-value-decimal? decimal64 2626 | | +--rw current-value-decimal? decimal64 2627 | +--rw idle-config 2628 | +--rw heartbeat-interval 2629 | | +--ro max-value? uint16 2630 | | +--ro min-value? uint16 2631 | | +--rw current-value? uint16 2632 | +--rw missing-hb-allowed 2633 | | +--ro max-value? uint16 2634 | | +--ro min-value? uint16 2635 | | +--rw current-value? uint16 2636 | +--rw max-retransmit 2637 | | +--ro max-value? uint16 2638 | | +--ro min-value? uint16 2639 | | +--rw current-value? uint16 2640 | +--rw ack-timeout 2641 | | +--ro max-value-decimal? decimal64 2642 | | +--ro min-value-decimal? decimal64 2643 | | +--rw current-value-decimal? decimal64 2644 | +--rw ack-random-factor 2645 | +--ro max-value-decimal? decimal64 2646 | +--ro min-value-decimal? decimal64 2647 | +--rw current-value-decimal? decimal64 2648 +--:(redirected-signal) 2649 +--ro alt-server string 2650 +--ro alt-server-record* inet:ip-address 2652 5.2. IANA DOTS Signal Channel YANG Module 2654 file "iana-dots-signal-channel@2019-01-17.yang" 2655 module iana-dots-signal-channel { 2656 yang-version 1.1; 2657 namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel"; 2658 prefix iana-signal; 2660 organization 2661 "IANA"; 2662 contact 2663 "Internet Assigned Numbers Authority 2665 Postal: ICANN 2666 12025 Waterfront Drive, Suite 300 2667 Los Angeles, CA 90094-2536 2668 United States of America 2669 Tel: +1 310 301 5800 2670 "; 2671 description 2672 "This module contains a collection of YANG data types defined 2673 by IANA and used for DOTS signal channel protocol. 2675 Copyright (c) 2019 IETF Trust and the persons identified as 2676 authors of the code. All rights reserved. 2678 Redistribution and use in source and binary forms, with or 2679 without modification, is permitted pursuant to, and subject 2680 to the license terms contained in, the Simplified BSD License 2681 set forth in Section 4.c of the IETF Trust's Legal Provisions 2682 Relating to IETF Documents 2683 (http://trustee.ietf.org/license-info). 2685 This version of this YANG module is part of RFC XXXX; see 2686 the RFC itself for full legal notices."; 2688 revision 2019-01-17 { 2689 description 2690 "Initial revision."; 2691 reference 2692 "RFC XXXX: Distributed Denial-of-Service Open Threat 2693 Signaling (DOTS) Signal Channel Specification"; 2694 } 2696 typedef status { 2697 type enumeration { 2698 enum attack-mitigation-in-progress { 2699 value 1; 2700 description 2701 "Attack mitigation setup is in progress (e.g., changing 2702 the network path to re-route the inbound traffic 2703 to DOTS mitigator)."; 2704 } 2705 enum attack-successfully-mitigated { 2706 value 2; 2707 description 2708 "Attack is being successfully mitigated (e.g., traffic 2709 is redirected to a DDoS mitigator and attack 2710 traffic is dropped or blackholed)."; 2711 } 2712 enum attack-stopped { 2713 value 3; 2714 description 2715 "Attack has stopped and the DOTS client can 2716 withdraw the mitigation request."; 2717 } 2718 enum attack-exceeded-capability { 2719 value 4; 2720 description 2721 "Attack has exceeded the mitigation provider 2722 capability."; 2723 } 2724 enum dots-client-withdrawn-mitigation { 2725 value 5; 2726 description 2727 "DOTS client has withdrawn the mitigation 2728 request and the mitigation is active but 2729 terminating."; 2730 } 2731 enum attack-mitigation-terminated { 2732 value 6; 2733 description 2734 "Attack mitigation is now terminated."; 2735 } 2736 enum attack-mitigation-withdrawn { 2737 value 7; 2738 description 2739 "Attack mitigation is withdrawn."; 2740 } 2741 enum attack-mitigation-signal-loss { 2742 value 8; 2743 description 2744 "Attack mitigation will be triggered 2745 for the mitigation request only when 2746 the DOTS signal channel session is lost."; 2747 } 2748 } 2749 description 2750 "Enumeration for status reported by the DOTS server."; 2751 } 2753 typedef conflict-status { 2754 type enumeration { 2755 enum request-inactive-other-active { 2756 value 1; 2757 description 2758 "DOTS Server has detected conflicting mitigation 2759 requests from different DOTS clients. 2760 This mitigation request is currently inactive 2761 until the conflicts are resolved. Another 2762 mitigation request is active."; 2763 } 2764 enum request-active { 2765 value 2; 2766 description 2767 "DOTS Server has detected conflicting mitigation 2768 requests from different DOTS clients. 2769 This mitigation request is currently active."; 2770 } 2771 enum all-requests-inactive { 2772 value 3; 2773 description 2774 "DOTS Server has detected conflicting mitigation 2775 requests from different DOTS clients. All 2776 conflicting mitigation requests are inactive."; 2777 } 2778 } 2779 description 2780 "Enumeration for conflict status."; 2781 } 2783 typedef conflict-cause { 2784 type enumeration { 2785 enum overlapping-targets { 2786 value 1; 2787 description 2788 "Overlapping targets. conflict-scope provides 2789 more details about the exact conflict."; 2790 } 2791 enum conflict-with-acceptlist { 2792 value 2; 2793 description 2794 "Conflicts with an existing accept-list. 2796 This code is returned when the DDoS mitigation 2797 detects that some of the source addresses/prefixes 2798 listed in the accept-list ACLs are actually 2799 attacking the target."; 2800 } 2801 enum cuid-collision { 2802 value 3; 2803 description 2804 "Conflicts with the cuid used by another 2805 DOTS client."; 2806 } 2807 } 2808 description 2809 "Enumeration for conflict causes."; 2810 } 2812 typedef attack-status { 2813 type enumeration { 2814 enum under-attack { 2815 value 1; 2816 description 2817 "The DOTS client determines that it is still under 2818 attack."; 2819 } 2820 enum attack-successfully-mitigated { 2821 value 2; 2822 description 2823 "The DOTS client determines that the attack is 2824 successfully mitigated."; 2825 } 2826 } 2827 description 2828 "Enumeration for attack status codes."; 2829 } 2830 } 2831 2833 5.3. IETF DOTS Signal Channel YANG Module 2835 This module uses the common YANG types defined in [RFC6991] and types 2836 defined in [I-D.ietf-dots-data-channel]. 2838 file "ietf-dots-signal-channel@2019-01-17.yang" 2839 module ietf-dots-signal-channel { 2840 yang-version 1.1; 2841 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; 2842 prefix signal; 2844 import ietf-inet-types { 2845 prefix inet; 2846 reference "Section 4 of RFC 6991"; 2847 } 2848 import ietf-yang-types { 2849 prefix yang; 2850 reference "Section 3 of RFC 6991"; 2851 } 2852 import ietf-dots-data-channel { 2853 prefix ietf-data; 2854 reference 2855 "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling 2856 (DOTS) Data Channel Specification"; 2857 } 2858 import iana-dots-signal-channel { 2859 prefix iana-signal; 2860 } 2862 organization 2863 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 2864 contact 2865 "WG Web: 2866 WG List: 2868 Editor: Konda, Tirumaleswar Reddy 2869 2871 Editor: Mohamed Boucadair 2872 2874 Author: Prashanth Patil 2875 2877 Author: Andrew Mortensen 2878 2880 Author: Nik Teague 2881 "; 2882 description 2883 "This module contains YANG definition for the signaling 2884 messages exchanged between a DOTS client and a DOTS server. 2886 Copyright (c) 2019 IETF Trust and the persons identified as 2887 authors of the code. All rights reserved. 2889 Redistribution and use in source and binary forms, with or 2890 without modification, is permitted pursuant to, and subject 2891 to the license terms contained in, the Simplified BSD License 2892 set forth in Section 4.c of the IETF Trust's Legal Provisions 2893 Relating to IETF Documents 2894 (http://trustee.ietf.org/license-info). 2896 This version of this YANG module is part of RFC XXXX; see 2897 the RFC itself for full legal notices."; 2899 revision 2019-01-17 { 2900 description 2901 "Initial revision."; 2902 reference 2903 "RFC XXXX: Distributed Denial-of-Service Open Threat 2904 Signaling (DOTS) Signal Channel Specification"; 2905 } 2907 /* 2908 * Groupings 2909 */ 2911 grouping mitigation-scope { 2912 description 2913 "Specifies the scope of the mitigation request."; 2914 list scope { 2915 key "cuid mid"; 2916 description 2917 "The scope of the request."; 2918 leaf cdid { 2919 type string; 2920 description 2921 "The cdid should be included by a server-domain 2922 DOTS gateway to propagate the client domain 2923 identification information from the 2924 gateway's client-facing-side to the gateway's 2925 server-facing-side, and from the gateway's 2926 server-facing-side to the DOTS server. 2928 It may be used by the final DOTS server 2929 for policy enforcement purposes."; 2930 } 2931 leaf cuid { 2932 type string; 2933 description 2934 "A unique identifier that is 2935 generated by a DOTS client to prevent 2936 request collisions. It is expected that the 2937 cuid will remain consistent throughout the 2938 lifetime of the DOTS client."; 2939 } 2940 leaf mid { 2941 type uint32; 2942 description 2943 "Mitigation request identifier. 2945 This identifier must be unique for each mitigation 2946 request bound to the DOTS client."; 2947 } 2948 uses ietf-data:target; 2949 leaf-list alias-name { 2950 type string; 2951 description 2952 "An alias name that points to a resource."; 2953 } 2954 leaf lifetime { 2955 type int32; 2956 units "seconds"; 2957 default "3600"; 2958 description 2959 "Indicates the lifetime of the mitigation request. 2961 A lifetime of '0' in a mitigation request is an 2962 invalid value. 2964 A lifetime of negative one (-1) indicates indefinite 2965 lifetime for the mitigation request."; 2966 } 2967 leaf trigger-mitigation { 2968 type boolean; 2969 default "true"; 2970 description 2971 "If set to 'false', DDoS mitigation will not be 2972 triggered unless the DOTS signal channel 2973 session is lost."; 2974 } 2975 leaf mitigation-start { 2976 type uint64; 2977 config false; 2978 description 2979 "Mitigation start time is represented in seconds 2980 relative to 1970-01-01T00:00:00Z in UTC time."; 2981 } 2982 leaf status { 2983 type iana-signal:status; 2984 config false; 2985 description 2986 "Indicates the status of a mitigation request. 2987 It must be included in responses only."; 2988 } 2989 container conflict-information { 2990 config false; 2991 description 2992 "Indicates that a conflict is detected. 2993 Must only be used for responses."; 2994 leaf conflict-status { 2995 type iana-signal:conflict-status; 2996 description 2997 "Indicates the conflict status."; 2998 } 2999 leaf conflict-cause { 3000 type iana-signal:conflict-cause; 3001 description 3002 "Indicates the cause of the conflict."; 3003 } 3004 leaf retry-timer { 3005 type uint32; 3006 units "seconds"; 3007 description 3008 "The DOTS client must not re-send the 3009 same request that has a conflict before the expiry of 3010 this timer."; 3011 } 3012 container conflict-scope { 3013 description 3014 "Provides more information about the conflict scope."; 3015 uses ietf-data:target { 3016 when "../conflict-cause = 'overlapping-targets'"; 3017 } 3018 leaf-list alias-name { 3019 when "../../conflict-cause = 'overlapping-targets'"; 3020 type string; 3021 description 3022 "Conflicting alias-name."; 3023 } 3024 list acl-list { 3025 when "../../conflict-cause = 'conflict-with-acceptlist'"; 3026 key "acl-name"; 3027 description 3028 "List of conflicting ACLs as defined in the DOTS data 3029 channel. These ACLs are uniquely defined by 3030 cuid and acl-name."; 3031 leaf acl-name { 3032 type leafref { 3033 path "/ietf-data:dots-data/ietf-data:dots-client/" 3034 + "ietf-data:acls/ietf-data:acl/ietf-data:name"; 3035 } 3036 description 3037 "Reference to the conflicting ACL name bound to 3038 a DOTS client."; 3039 } 3040 leaf acl-type { 3041 type leafref { 3042 path "/ietf-data:dots-data/ietf-data:dots-client/" 3043 + "ietf-data:acls/ietf-data:acl/ietf-data:type"; 3044 } 3045 description 3046 "Reference to the conflicting ACL type bound to 3047 a DOTS client."; 3048 } 3049 } 3050 leaf mid { 3051 when "../../conflict-cause = 'overlapping-targets'"; 3052 type leafref { 3053 path "../../../mid"; 3054 } 3055 description 3056 "Reference to the conflicting 'mid' bound to 3057 the same DOTS client."; 3058 } 3059 } 3060 } 3061 leaf bytes-dropped { 3062 type yang:zero-based-counter64; 3063 units "bytes"; 3064 config false; 3065 description 3066 "The total dropped byte count for the mitigation 3067 request since the attack mitigation is triggered. 3068 The count wraps around when it reaches the maximum value 3069 of counter64 for dropped bytes."; 3070 } 3071 leaf bps-dropped { 3072 type yang:gauge64; 3073 config false; 3074 description 3075 "The average number of dropped bits per second for 3076 the mitigation request since the attack 3077 mitigation is triggered. This should be over 3078 five-minute intervals (that is, measuring bytes 3079 into five-minute buckets and then averaging these 3080 buckets over the time since the mitigation was 3081 triggered)."; 3082 } 3083 leaf pkts-dropped { 3084 type yang:zero-based-counter64; 3085 config false; 3086 description 3087 "The total number of dropped packet count for the 3088 mitigation request since the attack mitigation is 3089 triggered. The count wraps around when it reaches 3090 the maximum value of counter64 for dropped packets."; 3091 } 3092 leaf pps-dropped { 3093 type yang:gauge64; 3094 config false; 3095 description 3096 "The average number of dropped packets per second 3097 for the mitigation request since the attack 3098 mitigation is triggered. This should be over 3099 five-minute intervals (that is, measuring packets 3100 into five-minute buckets and then averaging these 3101 buckets over the time since the mitigation was 3102 triggered)."; 3103 } 3104 leaf attack-status { 3105 type iana-signal:attack-status; 3106 description 3107 "Indicates the status of an attack as seen by the 3108 DOTS client."; 3109 } 3110 } 3111 } 3113 grouping config-parameters { 3114 description 3115 "Subset of DOTS signal channel session configuration."; 3116 container heartbeat-interval { 3117 description 3118 "DOTS agents regularly send heartbeats to each other 3119 after mutual authentication is successfully 3120 completed in order to keep the DOTS signal channel 3121 open."; 3122 leaf max-value { 3123 type uint16; 3124 units "seconds"; 3125 config false; 3126 description 3127 "Maximum acceptable heartbeat-interval value."; 3128 } 3129 leaf min-value { 3130 type uint16; 3131 units "seconds"; 3132 config false; 3133 description 3134 "Minimum acceptable heartbeat-interval value."; 3135 } 3136 leaf current-value { 3137 type uint16; 3138 units "seconds"; 3139 default "30"; 3140 description 3141 "Current heartbeat-interval value. 3143 '0' means that heartbeat mechanism is deactivated."; 3144 } 3145 } 3146 container missing-hb-allowed { 3147 description 3148 "Maximum number of missing heartbeats allowed."; 3149 leaf max-value { 3150 type uint16; 3151 config false; 3152 description 3153 "Maximum acceptable missing-hb-allowed value."; 3154 } 3155 leaf min-value { 3156 type uint16; 3157 config false; 3158 description 3159 "Minimum acceptable missing-hb-allowed value."; 3160 } 3161 leaf current-value { 3162 type uint16; 3163 default "5"; 3164 description 3165 "Current missing-hb-allowed value."; 3166 } 3167 } 3168 container max-retransmit { 3169 description 3170 "Maximum number of retransmissions of a Confirmable 3171 message."; 3172 leaf max-value { 3173 type uint16; 3174 config false; 3175 description 3176 "Maximum acceptable max-retransmit value."; 3177 } 3178 leaf min-value { 3179 type uint16; 3180 config false; 3181 description 3182 "Minimum acceptable max-retransmit value."; 3183 } 3184 leaf current-value { 3185 type uint16; 3186 default "3"; 3187 description 3188 "Current max-retransmit value."; 3189 } 3190 } 3191 container ack-timeout { 3192 description 3193 "Initial retransmission timeout value."; 3194 leaf max-value-decimal { 3195 type decimal64 { 3196 fraction-digits 2; 3197 } 3198 units "seconds"; 3199 config false; 3200 description 3201 "Maximum ack-timeout value."; 3202 } 3203 leaf min-value-decimal { 3204 type decimal64 { 3205 fraction-digits 2; 3206 } 3207 units "seconds"; 3208 config false; 3209 description 3210 "Minimum ack-timeout value."; 3211 } 3212 leaf current-value-decimal { 3213 type decimal64 { 3214 fraction-digits 2; 3215 } 3216 units "seconds"; 3217 default "2"; 3218 description 3219 "Current ack-timeout value."; 3220 } 3221 } 3222 container ack-random-factor { 3223 description 3224 "Random factor used to influence the timing of 3225 retransmissions."; 3226 leaf max-value-decimal { 3227 type decimal64 { 3228 fraction-digits 2; 3229 } 3230 config false; 3231 description 3232 "Maximum acceptable ack-random-factor value."; 3233 } 3234 leaf min-value-decimal { 3235 type decimal64 { 3236 fraction-digits 2; 3237 } 3238 config false; 3239 description 3240 "Minimum acceptable ack-random-factor value."; 3241 } 3242 leaf current-value-decimal { 3243 type decimal64 { 3244 fraction-digits 2; 3245 } 3246 default "1.5"; 3247 description 3248 "Current ack-random-factor value."; 3249 } 3250 } 3251 } 3253 grouping signal-config { 3254 description 3255 "DOTS signal channel session configuration."; 3256 leaf sid { 3257 type uint32; 3258 mandatory true; 3259 description 3260 "An identifier for the DOTS signal channel 3261 session configuration data."; 3262 } 3263 container mitigating-config { 3264 description 3265 "Configuration parameters to use when a mitigation 3266 is active."; 3267 uses config-parameters; 3268 } 3269 container idle-config { 3270 description 3271 "Configuration parameters to use when no mitigation 3272 is active."; 3273 uses config-parameters; 3274 } 3275 } 3277 grouping redirected-signal { 3278 description 3279 "Grouping for the redirected signaling."; 3280 leaf alt-server { 3281 type string; 3282 config false; 3283 mandatory true; 3284 description 3285 "FQDN of an alternate server."; 3286 } 3287 leaf-list alt-server-record { 3288 type inet:ip-address; 3289 config false; 3290 description 3291 "List of records for the alternate server."; 3292 } 3293 } 3295 /* 3296 * Main Container for DOTS Signal Channel 3297 */ 3299 container dots-signal { 3300 description 3301 "Main container for DOTS signal message. 3303 A DOTS signal message can be a mitigation, a configuration, 3304 or a redirected signal message."; 3305 choice message-type { 3306 description 3307 "Can be a mitigation, a configuration, or a redirect 3308 message."; 3309 case mitigation-scope { 3310 description 3311 "Mitigation scope of a mitigation message."; 3312 uses mitigation-scope; 3314 } 3315 case signal-config { 3316 description 3317 "Configuration message."; 3318 uses signal-config; 3319 } 3320 case redirected-signal { 3321 description 3322 "Redirected signaling."; 3323 uses redirected-signal; 3324 } 3325 } 3326 } 3327 } 3328 3330 6. YANG/JSON Mapping Parameters to CBOR 3332 All parameters in the payload of the DOTS signal channel MUST be 3333 mapped to CBOR types as shown in Table 4 and are assigned an integer 3334 key to save space. 3336 o Note: Implementers must check that the mapping output provided by 3337 their YANG-to-CBOR encoding schemes is aligned with the content of 3338 Table 4. 3340 The CBOR key values are divided into two types: comprehension- 3341 required and comprehension-optional. DOTS agents can safely ignore 3342 comprehension-optional values they don't understand, but cannot 3343 successfully process a request if it contains comprehension-required 3344 values that are not understood. The 4.00 response SHOULD include a 3345 diagnostic payload describing the unknown comprehension-required CBOR 3346 key values. The initial set of CBOR key values defined in this 3347 specification are of type comprehension-required. 3349 +----------------------+-------------+-----+---------------+--------+ 3350 | Parameter Name | YANG | CBOR| CBOR Major | JSON | 3351 | | Type | Key | Type & | Type | 3352 | | | | Information | | 3353 +----------------------+-------------+-----+---------------+--------+ 3354 | ietf-dots-signal-cha | | | | | 3355 | nnel:mitigation-scope| container | 1 | 5 map | Object | 3356 | scope | list | 2 | 4 array | Array | 3357 | cdid | string | 3 | 3 text string | String | 3358 | cuid | string | 4 | 3 text string | String | 3359 | mid | uint32 | 5 | 0 unsigned | Number | 3360 | target-prefix | leaf-list | 6 | 4 array | Array | 3361 | | inet: | | | | 3362 | | ip-prefix | | 3 text string | String | 3363 | target-port-range | list | 7 | 4 array | Array | 3364 | lower-port | inet: | | | | 3365 | | port-number| 8 | 0 unsigned | Number | 3366 | upper-port | inet: | | | | 3367 | | port-number| 9 | 0 unsigned | Number | 3368 | target-protocol | leaf-list | 10 | 4 array | Array | 3369 | | uint8 | | 0 unsigned | Number | 3370 | target-fqdn | leaf-list | 11 | 4 array | Array | 3371 | | inet: | | | | 3372 | | domain-name| | 3 text string | String | 3373 | target-uri | leaf-list | 12 | 4 array | Array | 3374 | | inet:uri | | 3 text string | String | 3375 | alias-name | leaf-list | 13 | 4 array | Array | 3376 | | string | | 3 text string | String | 3377 | lifetime | int32 | 14 | 0 unsigned | Number | 3378 | | | | 1 negative | Number | 3379 | mitigation-start | uint64 | 15 | 0 unsigned | String | 3380 | status | enumeration | 16 | 0 unsigned | String | 3381 | conflict-information | container | 17 | 5 map | Object | 3382 | conflict-status | enumeration | 18 | 0 unsigned | String | 3383 | conflict-cause | enumeration | 19 | 0 unsigned | String | 3384 | retry-timer | uint32 | 20 | 0 unsigned | Number | 3385 | conflict-scope | container | 21 | 5 map | Object | 3386 | acl-list | list | 22 | 4 array | Array | 3387 | acl-name | leafref | 23 | 3 text string | String | 3388 | acl-type | leafref | 24 | 3 text string | String | 3389 | bytes-dropped | yang:zero- | | | | 3390 | | based- | | | | 3391 | | counter64 | 25 | 0 unsigned | String | 3392 | bps-dropped | yang:gauge64| 26 | 0 unsigned | String | 3393 | pkts-dropped | yang:zero- | | | | 3394 | | based- | | | | 3395 | | counter64 | 27 | 0 unsigned | String | 3396 | pps-dropped | yang:gauge64| 28 | 0 unsigned | String | 3397 | attack-status | enumeration | 29 | 0 unsigned | String | 3398 | ietf-dots-signal- | | | | | 3399 | channel:signal-config| container | 30 | 5 map | Object | 3400 | sid | uint32 | 31 | 0 unsigned | Number | 3401 | mitigating-config | container | 32 | 5 map | Object | 3402 | heartbeat-interval | container | 33 | 5 map | Object | 3403 | max-value | uint16 | 34 | 0 unsigned | Number | 3404 | min-value | uint16 | 35 | 0 unsigned | Number | 3405 | current-value | uint16 | 36 | 0 unsigned | Number | 3406 | missing-hb-allowed | container | 37 | 5 map | Object | 3407 | max-retransmit | container | 38 | 5 map | Object | 3408 | ack-timeout | container | 39 | 5 map | Object | 3409 | ack-random-factor | container | 40 | 5 map | Object | 3410 | max-value-decimal | decimal64 | 41 | 6 tag 4 | | 3411 | | | | [-2, integer]| String | 3412 | min-value-decimal | decimal64 | 42 | 6 tag 4 | | 3413 | | | | [-2, integer]| String | 3414 | current-value-decimal| decimal64 | 43 | 6 tag 4 | | 3415 | | | | [-2, integer]| String | 3416 | idle-config | container | 44 | 5 map | Object | 3417 | trigger-mitigation | boolean | 45 | 7 bits 20 | False | 3418 | | | | 7 bits 21 | True | 3419 | ietf-dots-signal-cha | | | | | 3420 |nnel:redirected-signal| container | 46 | 5 map | Object | 3421 | alt-server | string | 47 | 3 text string | String | 3422 | alt-server-record | leaf-list | 48 | 4 array | Array | 3423 | | inet: | | | | 3424 | | ip-address | | 3 text string | String | 3425 +----------------------+-------------+-----+---------------+--------+ 3427 Table 4: CBOR Key Values Used in DOTS Signal Channel Messages & Their 3428 Mappings to JSON and YANG 3430 7. (D)TLS Protocol Profile and Performance Considerations 3432 7.1. (D)TLS Protocol Profile 3434 This section defines the (D)TLS protocol profile of DOTS signal 3435 channel over (D)TLS and DOTS data channel over TLS. 3437 There are known attacks on (D)TLS, such as man-in-the-middle and 3438 protocol downgrade attacks. These are general attacks on (D)TLS and, 3439 as such, they are not specific to DOTS over (D)TLS; refer to the 3440 (D)TLS RFCs for discussion of these security issues. DOTS agents 3441 MUST adhere to the (D)TLS implementation recommendations and security 3442 considerations of [RFC7525] except with respect to (D)TLS version. 3443 Since DOTS signal channel encryption relying upon (D)TLS is virtually 3444 a green-field deployment, DOTS agents MUST implement only (D)TLS 1.2 3445 or later. 3447 When a DOTS client is configured with a domain name of the DOTS 3448 server, and connects to its configured DOTS server, the server may 3449 present it with a PKIX certificate. In order to ensure proper 3450 authentication, a DOTS client MUST verify the entire certification 3451 path per [RFC5280]. Additionally, the DOTS client MUST use [RFC6125] 3452 validation techniques to compare the domain name with the certificate 3453 provided. Certification authorities that issue DOTS server 3454 certificates SHOULD support the DNS-ID and SRV-ID identifier types. 3455 DOTS server SHOULD prefer the use of DNS-ID and SRV-ID over CN-ID 3456 identifier types in certificate requests (as described in Section 2.3 3457 of [RFC6125]) and the wildcard character '*' SHOULD NOT be included 3458 in the presented identifier. DOTS doesn't use URI-IDs for server 3459 identity verification. 3461 A key challenge to deploying DOTS is the provisioning of DOTS 3462 clients, including the distribution of keying material to DOTS 3463 clients to enable the required mutual authentication of DOTS agents. 3464 Enrollment over Secure Transport (EST) [RFC7030] defines a method of 3465 certificate enrollment by which domains operating DOTS servers may 3466 provide DOTS clients with all the necessary cryptographic keying 3467 material, including a private key and a certificate to authenticate 3468 themselves. One deployment option is DOTS clients behave as EST 3469 clients for certificate enrollment from an EST server provisioned by 3470 the mitigation provider. This document does not specify which EST or 3471 other mechanism the DOTS client uses to achieve initial enrollment. 3473 The Server Name Indication (SNI) extension [RFC6066] defines a 3474 mechanism for a client to tell a (D)TLS server the name of the server 3475 it wants to contact. This is a useful extension for hosting 3476 environments where multiple virtual servers are reachable over a 3477 single IP address. The DOTS client may or may not know if it is 3478 interacting with a DOTS server in a virtual server hosting 3479 environment, so the DOTS client SHOULD include the DOTS server FQDN 3480 in the SNI extension. 3482 Implementations compliant with this profile MUST implement all of the 3483 following items: 3485 o DTLS record replay detection (Section 3.3 of [RFC6347]) or an 3486 equivalent mechanism to protect against replay attacks. 3488 o DTLS session resumption without server-side state to resume 3489 session and convey the DOTS signal. 3491 o At least one of raw public keys [RFC7250] or PSK handshake 3492 [RFC4279] with (EC)DHE key exchange which reduces the size of the 3493 ServerHello, and can be used by DOTS agents that cannot obtain 3494 certificates. 3496 Implementations compliant with this profile SHOULD implement all of 3497 the following items to reduce the delay required to deliver a DOTS 3498 signal channel message: 3500 o TLS False Start [RFC7918] which reduces round-trips by allowing 3501 the TLS client's second flight of messages (ChangeCipherSpec) to 3502 also contain the DOTS signal. TLS False Start is formally defined 3503 for use with TLS, but the same technique is applicable to DTLS as 3504 well. 3506 o Cached Information Extension [RFC7924] which avoids transmitting 3507 the server's certificate and certificate chain if the client has 3508 cached that information from a previous TLS handshake. 3510 Compared to UDP, DOTS signal channel over TCP requires an additional 3511 round-trip time (RTT) of latency to establish a TCP connection. DOTS 3512 implementations are encouraged to implement TCP Fast Open [RFC7413] 3513 to eliminate that RTT. 3515 7.2. (D)TLS 1.3 Considerations 3517 TLS 1.3 provides critical latency improvements for connection 3518 establishment over TLS 1.2. The DTLS 1.3 protocol 3519 [I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides 3520 equivalent security guarantees. (D)TLS 1.3 provides two basic 3521 handshake modes the DOTS signal channel can take advantage of: 3523 o A full handshake mode in which a DOTS client can send a DOTS 3524 mitigation request message after one round trip and the DOTS 3525 server immediately responds with a DOTS mitigation response. This 3526 assumes no packet loss is experienced. 3528 o 0-RTT mode in which the DOTS client can authenticate itself and 3529 send DOTS mitigation request messages in the first message, thus 3530 reducing handshake latency. 0-RTT only works if the DOTS client 3531 has previously communicated with that DOTS server, which is very 3532 likely with the DOTS signal channel. 3534 The DOTS client has to establish a (D)TLS session with the DOTS 3535 server during 'idle' time and share a PSK. 3537 During a DDoS attack, the DOTS client can use the (D)TLS session 3538 to convey the DOTS mitigation request message and, if there is no 3539 response from the server after multiple retries, the DOTS client 3540 can resume the (D)TLS session in 0-RTT mode using PSK. 3542 DOTS servers that support (D)TLS 1.3 MAY allow DOTS clients to 3543 send early data (0-RTT). DOTS clients MUST NOT send "CoAP Ping" 3544 as early data; such messages MUST be rejected by DOTS servers. 3545 Section 8 of [RFC8446] discusses some mechanisms to implement to 3546 limit the impact of replay attacks on 0-RTT data. If the DOTS 3547 server accepts 0-RTT, it MUST implement one of these mechanisms to 3548 prevent replay at the TLS layer. A DOTS server can reject 0-RTT 3549 by sending a TLS HelloRetryRequest. 3551 The DOTS signal channel messages sent as early data by the DOTS 3552 client are idempotent requests. As a reminder, the Message ID 3553 (Section 3 of [RFC7252]) is changed each time a new CoAP request 3554 is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized 3555 in each CoAP request. The DOTS server(s) MUST use the Message ID 3556 and the Token in the DOTS signal channel message to detect replay 3557 of early data at the application layer, and accept 0-RTT data at 3558 most once from the same DOTS client. This anti-replay defense 3559 requires sharing the Message ID and the Token in the 0-RTT data 3560 between DOTS servers in the DOTS server domain. DOTS servers do 3561 not rely on transport coordinates to identify DOTS peers. As 3562 specified in Section 4.4.1, DOTS servers couple the DOTS signal 3563 channel sessions using the DOTS client identity and optionally the 3564 'cdid' parameter value. Furthermore, 'mid' value is monotonically 3565 increased by the DOTS client for each mitigation request, 3566 attackers replaying mitigation requests with lower numeric 'mid' 3567 values and overlapping scopes with mitigation requests having 3568 higher numeric 'mid' values will be rejected systematically by the 3569 DOTS server. Likewise, 'sid' value is monotonically increased by 3570 the DOTS client for each configuration request (Section 4.5.2), 3571 attackers replaying configuration requests with lower numeric 3572 'sid' values will be rejected by the DOTS server if it maintains a 3573 higher numeric 'sid' value for this DOTS client. 3575 Owing to the aforementioned protections, all DOTS signal channel 3576 requests are safe to transmit in TLS 1.3 as early data. Refer to 3577 [I-D.boucadair-dots-earlydata] for more details. 3579 A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request 3580 message exchange is shown in Figure 27. 3582 DOTS Client DOTS Server 3584 ClientHello 3585 (0-RTT DOTS signal message) 3586 --------> 3587 ServerHello 3588 {EncryptedExtensions} 3589 {Finished} 3590 <-------- [DOTS signal message] 3591 (end_of_early_data) 3592 {Finished} --------> 3593 [DOTS signal message] <-------> [DOTS signal message] 3595 Note that: 3596 () Indicates messages protected 0-RTT keys 3597 {} Indicates messages protected using handshake keys 3598 [] Indicates messages protected using 1-RTT keys 3600 Figure 27: A Simplified TLS 1.3 Handshake with 0-RTT 3602 7.3. DTLS MTU and Fragmentation 3604 To avoid DOTS signal message fragmentation and the subsequent 3605 decreased probability of message delivery, DOTS agents MUST ensure 3606 that the DTLS record fit within a single datagram. If the PMTU 3607 cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, 3608 as IPv6 requires that every link in the Internet have an MTU of 1280 3609 octets or greater as specified in [RFC8200]. If IPv4 support on 3610 legacy or otherwise unusual networks is a consideration and the PMTU 3611 is unknown, DOTS implementations MAY assume on a PMTU of 576 bytes 3612 for IPv4 datagrams, as every IPv4 host must be capable of receiving a 3613 packet whose length is equal to 576 bytes as discussed in [RFC0791] 3614 and [RFC1122]. 3616 The DOTS client must consider the amount of record expansion expected 3617 by the DTLS processing when calculating the size of CoAP message that 3618 fits within the path MTU. Path MTU MUST be greater than or equal to 3619 [CoAP message size + DTLS 1.2 overhead of 13 octets + authentication 3620 overhead of the negotiated DTLS cipher suite + block padding] 3621 (Section 4.1.1.1 of [RFC6347]). If the total request size exceeds 3622 the path MTU then the DOTS client MUST split the DOTS signal into 3623 separate messages; for example, the list of addresses in the 'target- 3624 prefix' parameter could be split into multiple lists and each list 3625 conveyed in a new PUT request. 3627 Implementation Note: DOTS choice of message size parameters works 3628 well with IPv6 and with most of today's IPv4 paths. However, with 3629 IPv4, it is harder to safely make sure that there is no IP 3630 fragmentation. If the IPv4 path MTU is unknown, implementations may 3631 want to limit themselves to more conservative IPv4 datagram sizes 3632 such as 576 bytes, as per [RFC0791]. 3634 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 3636 (D)TLS based upon client certificate can be used for mutual 3637 authentication between DOTS agents. If, for example, a DOTS gateway 3638 is involved, DOTS clients and DOTS gateways must perform mutual 3639 authentication; only authorized DOTS clients are allowed to send DOTS 3640 signals to a DOTS gateway. The DOTS gateway and the DOTS server must 3641 perform mutual authentication; a DOTS server only allows DOTS signal 3642 channel messages from an authorized DOTS gateway, thereby creating a 3643 two-link chain of transitive authentication between the DOTS client 3644 and the DOTS server. 3646 The DOTS server should support certificate-based client 3647 authentication. The DOTS client should respond to the DOTS server's 3648 TLS CertificateRequest message with the PKIX certificate held by the 3649 DOTS client. DOTS client certificate validation must be performed as 3650 per [RFC5280] and the DOTS client certificate must conform to the 3651 [RFC5280] certificate profile. If a DOTS client does not support TLS 3652 client certificate authentication, it must support pre-shared key 3653 based or raw public key based client authentication. 3655 +---------------------------------------------+ 3656 | example.com domain +---------+ | 3657 | | AAA | | 3658 | +---------------+ | Server | | 3659 | | Application | +------+--+ | 3660 | | server +<---------------+ ^ | 3661 | | (DOTS client) | | | | 3662 | +---------------+ | | | 3663 | V V | example.net domain 3664 | +-----+----+--+ | +---------------+ 3665 | +--------------+ | | | | | 3666 | | Guest +<----x---->+ DOTS +<------>+ DOTS | 3667 | | (DOTS client)| | gateway | | | server | 3668 | +--------------+ | | | | | 3669 | +----+--------+ | +---------------+ 3670 | ^ | 3671 | | | 3672 | +----------------+ | | 3673 | | DDoS detector | | | 3674 | | (DOTS client) +<-------------+ | 3675 | +----------------+ | 3676 +---------------------------------------------+ 3678 Figure 28: Example of Authentication and Authorization of DOTS Agents 3680 In the example depicted in Figure 28, the DOTS gateway and DOTS 3681 clients within the 'example.com' domain mutually authenticate. After 3682 the DOTS gateway validates the identity of a DOTS client, it 3683 communicates with the AAA server in the 'example.com' domain to 3684 determine if the DOTS client is authorized to request DDoS 3685 mitigation. If the DOTS client is not authorized, a 4.01 3686 (Unauthorized) is returned in the response to the DOTS client. In 3687 this example, the DOTS gateway only allows the application server and 3688 DDoS attack detector to request DDoS mitigation, but does not permit 3689 the user of type 'guest' to request DDoS mitigation. 3691 Also, DOTS gateways and servers located in different domains must 3692 perform mutual authentication (e.g., using certificates). A DOTS 3693 server will only allow a DOTS gateway with a certificate for a 3694 particular domain to request mitigation for that domain. In 3695 reference to Figure 28, the DOTS server only allows the DOTS gateway 3696 to request mitigation for 'example.com' domain and not for other 3697 domains. 3699 9. IANA Considerations 3701 9.1. DOTS Signal Channel UDP and TCP Port Number 3703 IANA is requested to assign the port number TBD to the DOTS signal 3704 channel protocol for both UDP and TCP from the "Service Name and 3705 Transport Protocol Port Number Registry" available at 3706 https://www.iana.org/assignments/service-names-port-numbers/service- 3707 names-port-numbers.xhtml. 3709 The assignment of port number 4646 is strongly suggested, as 4646 is 3710 the ASCII decimal value for ".." (DOTS). 3712 9.2. Well-Known 'dots' URI 3714 This document requests IANA to register the 'dots' well-known URI 3715 (Table 5) in the Well-Known URIs registry 3716 (https://www.iana.org/assignments/well-known-uris/well-known- 3717 uris.xhtml) as defined by [RFC5785]: 3719 +----------+----------------+---------------------+-----------------+ 3720 | URI | Change | Specification | Related | 3721 | suffix | controller | document(s) | information | 3722 +----------+----------------+---------------------+-----------------+ 3723 | dots | IETF | [RFCXXXX] | None | 3724 +----------+----------------+---------------------+-----------------+ 3726 Table 5: 'dots' well-known URI 3728 9.3. Media Type Registration 3730 This document requests IANA to register the "application/dots+cbor" 3731 media type in the "Media Types" registry [IANA.MediaTypes] in the 3732 manner described in [RFC6838], which can be used to indicate that the 3733 content is a DOTS signal channel object: 3735 o Type name: application 3736 o Subtype name: dots+cbor 3737 o Required parameters: N/A 3738 o Optional parameters: N/A 3739 o Encoding considerations: binary 3740 o Security considerations: See the Security Considerations section 3741 of [RFCXXXX] 3742 o Interoperability considerations: N/A 3743 o Published specification: [RFCXXXX] 3744 o Applications that use this media type: DOTS agents sending DOTS 3745 messages over CoAP over (D)TLS. 3746 o Fragment identifier considerations: N/A 3747 o Additional information: 3749 Magic number(s): N/A 3750 File extension(s): N/A 3751 Macintosh file type code(s): N/A 3752 o Person & email address to contact for further information: 3753 IESG, iesg@ietf.org 3754 o Intended usage: COMMON 3755 o Restrictions on usage: none 3756 o Author: See Authors' Addresses section. 3757 o Change controller: IESG 3758 o Provisional registration? No 3760 9.4. CoAP Content-Formats Registration 3762 This document requests IANA to register the CoAP Content-Format ID 3763 for the "application/dots+cbor" media type in the "CoAP Content- 3764 Formats" registry [IANA.CoAP.Content-Formats] (0-255 range): 3766 o Media Type: application/dots+cbor 3767 o Encoding: - 3768 o Id: TBD1 3769 o Reference: [RFCXXXX] 3771 9.5. CBOR Tag Registration 3773 This section defines the DOTS CBOR tag as another means for 3774 applications to declare that a CBOR data structure is a DOTS signal 3775 channel object. Its use is optional and is intended for use in cases 3776 in which this information would not otherwise be known. DOTS CBOR 3777 tag is not required for DOTS signal channel protocol version 3778 specified in this document. If present, the DOTS tag MUST prefix a 3779 DOTS signal channel object. 3781 This document requests IANA to register the DOTS signal channel CBOR 3782 tag in the "CBOR Tags" registry [IANA.CBOR.Tags] using the 24-255 3783 range: 3785 o CBOR Tag: TBD2 (please assign the same value as the Content- 3786 Format) 3787 o Data Item: DDoS Open Threat Signaling (DOTS) signal channel object 3788 o Semantics: DDoS Open Threat Signaling (DOTS) signal channel 3789 object, as defined in [RFCXXXX] 3790 o Description of Semantics: [RFCXXXX] 3792 9.6. DOTS Signal Channel Protocol Registry 3794 The document requests IANA to create a new registry, entitled "DOTS 3795 Signal Channel Registry". The following sections define sub- 3796 registries. 3798 9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry 3800 The document requests IANA to create a new sub-registry, entitled 3801 "DOTS Signal Channel CBOR Key Values". 3803 The structure of this sub-registry is provided in Section 9.6.1.1. 3804 Section 9.6.1.2 provides how the registry is initially populated with 3805 the values in Table 4. 3807 9.6.1.1. Registration Template 3809 Parameter name: 3810 Parameter name as used in the DOTS signal channel. 3812 CBOR Key Value: 3813 Key value for the parameter. The key value MUST be an integer in 3814 the 1-65535 range. The key values of the comprehension-required 3815 range (0x0001 - 0x3FFF) and of the comprehension-optional range 3816 (0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of 3817 [RFC8126]). The key values of the comprehension-optional range 3818 (0x4000 - 0x7FFF) are assigned by Specification Required 3819 (Section 4.6 of [RFC8126]) and of the comprehension-optional range 3820 (0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of 3821 [RFC8126]). 3823 Registration requests for the 0x4000 - 0x7FFF range are evaluated 3824 after a three-week review period on the dots-signal-reg- 3825 review@ietf.org mailing list, on the advice of one or more 3826 Designated Experts. However, to allow for the allocation of 3827 values prior to publication, the Designated Experts may approve 3828 registration once they are satisfied that such a specification 3829 will be published. New registration requests should be sent in 3830 the form of an email to the review mailing list; the request 3831 should use an appropriate subject (e.g., "Request to register CBOR 3832 Key Value for DOTS: example"). IANA will only accept new 3833 registrations from the Designated Experts, and will check that 3834 review was requested on the mailing list in accordance with these 3835 procedures. 3837 Within the review period, the Designated Experts will either 3838 approve or deny the registration request, communicating this 3839 decision to the review list and IANA. Denials should include an 3840 explanation and, if applicable, suggestions as to how to make the 3841 request successful. Registration requests that are undetermined 3842 for a period longer than 21 days can be brought to the IESG's 3843 attention (using the iesg@ietf.org mailing list) for resolution. 3845 Criteria that should be applied by the Designated Experts includes 3846 determining whether the proposed registration duplicates existing 3847 functionality, whether it is likely to be of general applicability 3848 or whether it is useful only for a single use case, and whether 3849 the registration description is clear. IANA must only accept 3850 registry updates to the 0x4000 - 0x7FFF range from the Designated 3851 Experts and should direct all requests for registration to the 3852 review mailing list. It is suggested that multiple Designated 3853 Experts be appointed. In cases where a registration decision 3854 could be perceived as creating a conflict of interest for a 3855 particular Expert, that Expert should defer to the judgment of the 3856 other Experts. 3858 CBOR Major Type: 3859 CBOR Major type and optional tag for the parameter. 3861 Change Controller: 3862 For Standards Track RFCs, list the "IESG". For others, give the 3863 name of the responsible party. Other details (e.g., email 3864 address) may also be included. 3866 Specification Document(s): 3867 Reference to the document or documents that specify the parameter, 3868 preferably including URIs that can be used to retrieve copies of 3869 the documents. An indication of the relevant sections may also be 3870 included but is not required. 3872 9.6.1.2. Initial Sub-Registry Content 3874 +----------------------+-------+-------+------------+---------------+ 3875 | Parameter Name | CBOR | CBOR | Change | Specification | 3876 | | Key | Major | Controller | Document(s) | 3877 | | Value | Type | | | 3878 +----------------------+-------+-------+------------+---------------+ 3879 | ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] | 3880 | nel:mitigation-scope | | | | | 3881 | scope | 2 | 4 | IESG | [RFCXXXX] | 3882 | cdid | 3 | 3 | IESG | [RFCXXXX] | 3883 | cuid | 4 | 3 | IESG | [RFCXXXX] | 3884 | mid | 5 | 0 | IESG | [RFCXXXX] | 3885 | target-prefix | 6 | 4 | IESG | [RFCXXXX] | 3886 | target-port-range | 7 | 4 | IESG | [RFCXXXX] | 3887 | lower-port | 8 | 0 | IESG | [RFCXXXX] | 3888 | upper-port | 9 | 0 | IESG | [RFCXXXX] | 3889 | target-protocol | 10 | 4 | IESG | [RFCXXXX] | 3890 | target-fqdn | 11 | 4 | IESG | [RFCXXXX] | 3891 | target-uri | 12 | 4 | IESG | [RFCXXXX] | 3892 | alias-name | 13 | 4 | IESG | [RFCXXXX] | 3893 | lifetime | 14 | 0/1 | IESG | [RFCXXXX] | 3894 | mitigation-start | 15 | 0 | IESG | [RFCXXXX] | 3895 | status | 16 | 0 | IESG | [RFCXXXX] | 3896 | conflict-information | 17 | 5 | IESG | [RFCXXXX] | 3897 | conflict-status | 18 | 0 | IESG | [RFCXXXX] | 3898 | conflict-cause | 19 | 0 | IESG | [RFCXXXX] | 3899 | retry-timer | 20 | 0 | IESG | [RFCXXXX] | 3900 | conflict-scope | 21 | 5 | IESG | [RFCXXXX] | 3901 | acl-list | 22 | 4 | IESG | [RFCXXXX] | 3902 | acl-name | 23 | 3 | IESG | [RFCXXXX] | 3903 | acl-type | 24 | 3 | IESG | [RFCXXXX] | 3904 | bytes-dropped | 25 | 0 | IESG | [RFCXXXX] | 3905 | bps-dropped | 26 | 0 | IESG | [RFCXXXX] | 3906 | pkts-dropped | 27 | 0 | IESG | [RFCXXXX] | 3907 | pps-dropped | 28 | 0 | IESG | [RFCXXXX] | 3908 | attack-status | 29 | 0 | IESG | [RFCXXXX] | 3909 | ietf-dots-signal- | 30 | 5 | IESG | [RFCXXXX] | 3910 | channel:signal-config| | | | | 3911 | sid | 31 | 0 | IESG | [RFCXXXX] | 3912 | mitigating-config | 32 | 5 | IESG | [RFCXXXX] | 3913 | heartbeat-interval | 33 | 5 | IESG | [RFCXXXX] | 3914 | min-value | 34 | 0 | IESG | [RFCXXXX] | 3915 | max-value | 35 | 0 | IESG | [RFCXXXX] | 3916 | current-value | 36 | 0 | IESG | [RFCXXXX] | 3917 | missing-hb-allowed | 37 | 5 | IESG | [RFCXXXX] | 3918 | max-retransmit | 38 | 5 | IESG | [RFCXXXX] | 3919 | ack-timeout | 39 | 5 | IESG | [RFCXXXX] | 3920 | ack-random-factor | 40 | 5 | IESG | [RFCXXXX] | 3921 | min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] | 3922 | max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] | 3923 | current-value- | 43 | 6tag4 | IESG | [RFCXXXX] | 3924 | decimal | | | | | 3925 | idle-config | 44 | 5 | IESG | [RFCXXXX] | 3926 | trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | 3927 | ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] | 3928 | nel:redirected-signal| | | | | 3929 | alt-server | 47 | 3 | IESG | [RFCXXXX] | 3930 | alt-server-record | 48 | 4 | IESG | [RFCXXXX] | 3931 +----------------------+-------+-------+------------+---------------+ 3933 Table 6: Initial DOTS Signal Channel CBOR Key Values Registry 3935 9.6.2. Status Codes Sub-Registry 3937 The document requests IANA to create a new sub-registry, entitled 3938 "DOTS Signal Channel Status Codes". Codes in this registry are used 3939 as valid values of 'status' parameter. 3941 The registry is initially populated with the following values: 3943 +-----+----------------------------------+--------------+-----------+ 3944 | Cod | Label | Description | Reference | 3945 | e | | | | 3946 +-----+----------------------------------+--------------+-----------+ 3947 | 1 | attack-mitigation-in-progress | Attack | [RFCXXXX] | 3948 | | | mitigation | | 3949 | | | setup is in | | 3950 | | | progress | | 3951 | | | (e.g., | | 3952 | | | changing the | | 3953 | | | network path | | 3954 | | | to redirect | | 3955 | | | the inbound | | 3956 | | | traffic to a | | 3957 | | | DOTS | | 3958 | | | mitigator). | | 3959 | 2 | attack-successfully-mitigated | Attack is | [RFCXXXX] | 3960 | | | being | | 3961 | | | successfully | | 3962 | | | mitigated | | 3963 | | | (e.g., | | 3964 | | | traffic is | | 3965 | | | redirected | | 3966 | | | to a DDoS | | 3967 | | | mitigator | | 3968 | | | and attack | | 3969 | | | traffic is | | 3970 | | | dropped). | | 3971 | 3 | attack-stopped | Attack has | [RFCXXXX] | 3972 | | | stopped and | | 3973 | | | the DOTS | | 3974 | | | client can | | 3975 | | | withdraw the | | 3976 | | | mitigation | | 3977 | | | request. | | 3978 | 4 | attack-exceeded-capability | Attack has | [RFCXXXX] | 3979 | | | exceeded the | | 3980 | | | mitigation | | 3981 | | | provider | | 3982 | | | capability. | | 3983 | 5 | dots-client-withdrawn-mitigation | DOTS client | [RFCXXXX] | 3984 | | | has | | 3985 | | | withdrawn | | 3986 | | | the | | 3987 | | | mitigation | | 3988 | | | request and | | 3989 | | | the | | 3990 | | | mitigation | | 3991 | | | is active | | 3992 | | | but | | 3993 | | | terminating. | | 3994 | 6 | attack-mitigation-terminated | Attack | [RFCXXXX] | 3995 | | | mitigation | | 3996 | | | is now | | 3997 | | | terminated. | | 3998 | 7 | attack-mitigation-withdrawn | Attack | [RFCXXXX] | 3999 | | | mitigation | | 4000 | | | is | | 4001 | | | withdrawn. | | 4002 | 8 | attack-mitigation-signal-loss | Attack | [RFCXXXX] | 4003 | | | mitigation | | 4004 | | | will be | | 4005 | | | triggered | | 4006 | | | for the | | 4007 | | | mitigation | | 4008 | | | request only | | 4009 | | | when the | | 4010 | | | DOTS signal | | 4011 | | | channel | | 4012 | | | session is | | 4013 | | | lost. | | 4014 +-----+----------------------------------+--------------+-----------+ 4016 New codes can be assigned via Standards Action [RFC8126]. 4018 9.6.3. Conflict Status Codes Sub-Registry 4020 The document requests IANA to create a new sub-registry, entitled 4021 "DOTS Signal Channel Conflict Status Codes". Codes in this registry 4022 are used as valid values of 'conflict-status' parameter. 4024 The registry is initially populated with the following values: 4026 +------+-------------------------------+----------------+-----------+ 4027 | Code | Label | Description | Reference | 4028 +------+-------------------------------+----------------+-----------+ 4029 | 1 | request-inactive-other-active | DOTS server | [RFCXXXX] | 4030 | | | has detected | | 4031 | | | conflicting | | 4032 | | | mitigation | | 4033 | | | requests from | | 4034 | | | different DOTS | | 4035 | | | clients. This | | 4036 | | | mitigation | | 4037 | | | request is | | 4038 | | | currently | | 4039 | | | inactive until | | 4040 | | | the conflicts | | 4041 | | | are resolved. | | 4042 | | | Another | | 4043 | | | mitigation | | 4044 | | | request is | | 4045 | | | active. | | 4046 | 2 | request-active | DOTS server | [RFCXXXX] | 4047 | | | has detected | | 4048 | | | conflicting | | 4049 | | | mitigation | | 4050 | | | requests from | | 4051 | | | different DOTS | | 4052 | | | clients. This | | 4053 | | | mitigation | | 4054 | | | request is | | 4055 | | | currently | | 4056 | | | active. | | 4057 | 3 | all-requests-inactive | DOTS server | [RFCXXXX] | 4058 | | | has detected | | 4059 | | | conflicting | | 4060 | | | mitigation | | 4061 | | | requests from | | 4062 | | | different DOTS | | 4063 | | | clients. All | | 4064 | | | conflicting | | 4065 | | | mitigation | | 4066 | | | requests are | | 4067 | | | inactive. | | 4068 +------+-------------------------------+----------------+-----------+ 4070 New codes can be assigned via Standards Action [RFC8126]. 4072 9.6.4. Conflict Cause Codes Sub-Registry 4074 The document requests IANA to create a new sub-registry, entitled 4075 "DOTS Signal Channel Conflict Cause Codes". Codes in this registry 4076 are used as valid values of 'conflict-cause' parameter. 4078 The registry is initially populated with the following values: 4080 +------+--------------------------+---------------------+-----------+ 4081 | Code | Label | Description | Reference | 4082 +------+--------------------------+---------------------+-----------+ 4083 | 1 | overlapping-targets | Overlapping | [RFCXXXX] | 4084 | | | targets. | | 4085 | 2 | conflict-with-acceptlist | Conflicts with an | [RFCXXXX] | 4086 | | | existing accept- | | 4087 | | | list. This code is | | 4088 | | | returned when the | | 4089 | | | DDoS mitigation | | 4090 | | | detects source | | 4091 | | | addresses/prefixes | | 4092 | | | in the accept- | | 4093 | | | listed ACLs are | | 4094 | | | attacking the | | 4095 | | | target. | | 4096 | 3 | cuid-collision | CUID Collision. | [RFCXXXX] | 4097 | | | This code is | | 4098 | | | returned when a | | 4099 | | | DOTS client uses a | | 4100 | | | 'cuid' that is | | 4101 | | | already used by | | 4102 | | | another DOTS | | 4103 | | | client. | | 4104 +------+--------------------------+---------------------+-----------+ 4106 New codes can be assigned via Standards Action [RFC8126]. 4108 9.6.5. Attack Status Codes Sub-Registry 4110 The document requests IANA to create a new sub-registry, entitled 4111 "DOTS Signal Channel Attack Status Codes". Codes in this registry 4112 are used as valid values of 'attack-status' parameter. 4114 The registry is initially populated with the following values: 4116 +------+-------------------------------+----------------+-----------+ 4117 | Code | Label | Description | Reference | 4118 +------+-------------------------------+----------------+-----------+ 4119 | 1 | under-attack | The DOTS | [RFCXXXX] | 4120 | | | client | | 4121 | | | determines | | 4122 | | | that it is | | 4123 | | | still under | | 4124 | | | attack. | | 4125 | 2 | attack-successfully-mitigated | The DOTS | [RFCXXXX] | 4126 | | | client | | 4127 | | | determines | | 4128 | | | that the | | 4129 | | | attack is | | 4130 | | | successfully | | 4131 | | | mitigated. | | 4132 +------+-------------------------------+----------------+-----------+ 4134 New codes can be assigned via Standards Action [RFC8126]. 4136 9.7. DOTS Signal Channel YANG Modules 4138 This document requests IANA to register the following URIs in the 4139 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 4141 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 4142 Registrant Contact: The IESG. 4143 XML: N/A; the requested URI is an XML namespace. 4145 URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel 4146 Registrant Contact: IANA. 4147 XML: N/A; the requested URI is an XML namespace. 4149 This document requests IANA to register the following YANG modules in 4150 the "YANG Module Names" subregistry [RFC7950] within the "YANG 4151 Parameters" registry. 4153 Name: ietf-signal 4154 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 4155 Maintained by IANA: N 4156 Prefix: signal 4157 Reference: RFC XXXX 4159 Name: iana-signal 4160 Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel 4161 Maintained by IANA: Y 4162 Prefix: iana-signal 4163 Reference: RFC XXXX 4165 This document defines the initial version of the IANA-maintained 4166 iana-dots-signal-channel YANG module. IANA is requested to add this 4167 note: 4169 Status, conflict status, conflict cause, and attack status values 4170 must not be directly added to the iana-dots-signal-channel YANG 4171 module. They must instead be respectively added to the "DOTS 4172 Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause 4173 Codes", and "DOTS Attack Status Codes" registries. 4175 When a 'status', 'conflict-status', 'conflict-cause', or 'attack- 4176 status' value is respectively added to the "DOTS Status Codes", "DOTS 4177 Conflict Status Codes", "DOTS Conflict Cause Codes", or "DOTS Attack 4178 Status Codes" registry, a new "enum" statement must be added to the 4179 iana-dots-signal-channel YANG module. The following "enum" 4180 statement, and substatements thereof, should be defined: 4182 "enum": Replicates the label from the registry. 4184 "value": Contains the IANA-assigned value corresponding to the 4185 'status', 'conflict-status', 'conflict-cause', or 4186 'attack-status'. 4188 "description": Replicates the description from the registry. 4190 "reference": Replicates the reference from the registry and add the 4191 title of the document. 4193 When the iana-dots-signal-channel YANG module is updated, a new 4194 "revision" statement must be added in front of the existing revision 4195 statements. 4197 IANA is requested to add this note to "DOTS Status Codes", "DOTS 4198 Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack 4199 Status Codes" registries: 4201 When this registry is modified, the YANG module iana-dots-signal- 4202 channel must be updated as defined in [RFCXXXX]. 4204 10. Security Considerations 4206 High-level DOTS security considerations are documented in 4207 [I-D.ietf-dots-requirements] and [I-D.ietf-dots-architecture]. 4209 Authenticated encryption MUST be used for data confidentiality and 4210 message integrity. The interaction between the DOTS agents requires 4211 Datagram Transport Layer Security (DTLS) or Transport Layer Security 4212 (TLS) with a cipher suite offering confidentiality protection, and 4213 the guidance given in [RFC7525] MUST be followed to avoid attacks on 4214 (D)TLS. The (D)TLS protocol profile used for the DOTS signal channel 4215 is specified in Section 7. 4217 If TCP is used between DOTS agents, an attacker may be able to inject 4218 RST packets, bogus application segments, etc., regardless of whether 4219 TLS authentication is used. Because the application data is TLS 4220 protected, this will not result in the application receiving bogus 4221 data, but it will constitute a DoS on the connection. This attack 4222 can be countered by using TCP-AO [RFC5925]. Although not widely 4223 adopted, if TCP-AO is used, then any bogus packets injected by an 4224 attacker will be rejected by the TCP-AO integrity check and therefore 4225 will never reach the TLS layer. 4227 An attack vector that can be achieved if the 'cuid' is guessable is a 4228 misbehaving DOTS client from within the client's domain which uses 4229 the 'cuid' of another DOTS client of the domain to delete or alter 4230 active mitigations. For this attack vector to happen, the 4231 misbehaving client needs to pass the security validation checks by 4232 the DOTS server, and eventually the checks of a client-domain DOTS 4233 gateway. 4235 A similar attack can be achieved by a compromised DOTS client which 4236 can sniff the TLS 1.2 handshake, use the client certificate to 4237 identify the 'cuid' used by another DOTS client. This attack is not 4238 possible if algorithms such as version 4 Universally Unique 4239 IDentifiers (UUIDs) in Section 4.4 of [RFC4122] are used to generate 4240 the 'cuid' because such UUIDs are not a deterministic function of the 4241 client certificate. Likewise, this attack is not possible with TLS 4242 1.3 because most of the TLS handshake is encrypted and the client 4243 certificate is not visible to eavesdroppers. 4245 A compromised DOTS client can collude with a DDoS attacker to send 4246 mitigation request for a target resource, gets the mitigation 4247 efficacy from the DOTS server, and conveys the mitigation efficacy to 4248 the DDoS attacker to possibly change the DDoS attack strategy. 4249 Obviously, signaling an attack by the compromised DOTS client to the 4250 DOTS server will trigger attack mitigation. This attack can be 4251 prevented by monitoring and auditing DOTS clients to detect 4252 misbehavior and to deter misuse, and by only authorizing the DOTS 4253 client to request mitigation for specific target resources (e.g., an 4254 application server is authorized to request mitigation for its IP 4255 addresses but a DDoS mitigator can request mitigation for any target 4256 resource in the network). Furthermore, DOTS clients are typically 4257 co-located on network security services (e.g., firewall) and a 4258 compromised security service potentially can do a lot more damage to 4259 the network. 4261 Rate-limiting DOTS requests, including those with new 'cuid' values, 4262 from the same DOTS client defends against DoS attacks that would 4263 result in varying the 'cuid' to exhaust DOTS server resources. Rate- 4264 limit policies SHOULD be enforced on DOTS gateways (if deployed) and 4265 DOTS servers. 4267 In order to prevent leaking internal information outside a client- 4268 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 4269 the identification information that pertains to internal DOTS clients 4270 (e.g., source IP address, client's hostname) unless explicitly 4271 configured to do so. 4273 DOTS servers MUST verify that requesting DOTS clients are entitled to 4274 trigger actions on a given IP prefix. That is, only actions on IP 4275 resources that belong to the DOTS client' domain MUST be authorized 4276 by a DOTS server. The exact mechanism for the DOTS servers to 4277 validate that the target prefixes are within the scope of the DOTS 4278 client domain is deployment-specific. 4280 The presence of DOTS gateways may lead to infinite forwarding loops, 4281 which is undesirable. To prevent and detect such loops, this 4282 document uses the Hop-Limit Option. 4284 When FQDNs are used as targets, the DOTS server MUST rely upon DNS 4285 privacy enabling protocols (e.g., DNS over TLS [RFC7858] or DoH 4286 [RFC8484]) to prevent eavesdroppers from possibly identifying the 4287 target resources protected by the DDoS mitigation service, and means 4288 to ensure the target FQDN resolution is authentic (e.g., DNSSEC 4289 [RFC4034]). 4291 CoAP-specific security considerations are discussed in Section 11 of 4292 [RFC7252], while CBOR-related security considerations are discussed 4293 in Section 8 of [RFC7049]. 4295 11. Contributors 4297 The following individuals have contributed to this document: 4299 o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust 4301 o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email: 4302 mgeller@cisco.com 4304 o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States, 4305 Email: rgm@htt-consult.com 4307 o Dan Wing, Email: dwing-ietf@fuggles.com 4309 12. Acknowledgements 4311 Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael 4312 Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia, 4313 Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien 4314 Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion 4315 and comments. 4317 The authors would like to give special thanks to Kaname Nishizuka and 4318 Jon Shallow for their efforts in implementing the protocol and 4319 performing interop testing at IETF Hackathons. 4321 Thanks to the core WG for the recommendations on Hop-Limit and 4322 redirect signaling. 4324 Special thanks to Benjamin Kaduk for the detailed AD review. 4326 Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja 4327 Kuehlewind, and Alissa Cooper for the review. 4329 13. References 4331 13.1. Normative References 4333 [I-D.ietf-core-hop-limit] 4334 Boucadair, M., K, R., and J. Shallow, "Constrained 4335 Application Protocol (CoAP) Hop Limit Option", draft-ietf- 4336 core-hop-limit-03 (work in progress), February 2019. 4338 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4339 DOI 10.17487/RFC0791, September 1981, 4340 . 4342 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 4343 Communication Layers", STD 3, RFC 1122, 4344 DOI 10.17487/RFC1122, October 1989, 4345 . 4347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4348 Requirement Levels", BCP 14, RFC 2119, 4349 DOI 10.17487/RFC2119, March 1997, 4350 . 4352 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4353 DOI 10.17487/RFC3688, January 2004, 4354 . 4356 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4357 Resource Identifier (URI): Generic Syntax", STD 66, 4358 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4359 . 4361 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 4362 Ciphersuites for Transport Layer Security (TLS)", 4363 RFC 4279, DOI 10.17487/RFC4279, December 2005, 4364 . 4366 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 4367 (CIDR): The Internet Address Assignment and Aggregation 4368 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 4369 2006, . 4371 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 4372 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 4373 . 4375 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4376 (TLS) Protocol Version 1.2", RFC 5246, 4377 DOI 10.17487/RFC5246, August 2008, 4378 . 4380 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4381 Housley, R., and W. Polk, "Internet X.509 Public Key 4382 Infrastructure Certificate and Certificate Revocation List 4383 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4384 . 4386 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 4387 Uniform Resource Identifiers (URIs)", RFC 5785, 4388 DOI 10.17487/RFC5785, April 2010, 4389 . 4391 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 4392 Extensions: Extension Definitions", RFC 6066, 4393 DOI 10.17487/RFC6066, January 2011, 4394 . 4396 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 4397 Verification of Domain-Based Application Service Identity 4398 within Internet Public Key Infrastructure Using X.509 4399 (PKIX) Certificates in the Context of Transport Layer 4400 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 4401 2011, . 4403 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4404 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 4405 January 2012, . 4407 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4408 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4409 . 4411 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 4412 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 4413 October 2013, . 4415 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 4416 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 4417 Transport Layer Security (TLS) and Datagram Transport 4418 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 4419 June 2014, . 4421 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 4422 Application Protocol (CoAP)", RFC 7252, 4423 DOI 10.17487/RFC7252, June 2014, 4424 . 4426 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 4427 "Recommendations for Secure Use of Transport Layer 4428 Security (TLS) and Datagram Transport Layer Security 4429 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 4430 2015, . 4432 [RFC7641] Hartke, K., "Observing Resources in the Constrained 4433 Application Protocol (CoAP)", RFC 7641, 4434 DOI 10.17487/RFC7641, September 2015, 4435 . 4437 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 4438 Layer Security (TLS) False Start", RFC 7918, 4439 DOI 10.17487/RFC7918, August 2016, 4440 . 4442 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 4443 (TLS) Cached Information Extension", RFC 7924, 4444 DOI 10.17487/RFC7924, July 2016, 4445 . 4447 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4448 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4449 . 4451 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 4452 the Constrained Application Protocol (CoAP)", RFC 7959, 4453 DOI 10.17487/RFC7959, August 2016, 4454 . 4456 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 4457 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 4458 March 2017, . 4460 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4461 Writing an IANA Considerations Section in RFCs", BCP 26, 4462 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4463 . 4465 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4466 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4467 May 2017, . 4469 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4470 (IPv6) Specification", STD 86, RFC 8200, 4471 DOI 10.17487/RFC8200, July 2017, 4472 . 4474 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 4475 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 4476 Application Protocol) over TCP, TLS, and WebSockets", 4477 RFC 8323, DOI 10.17487/RFC8323, February 2018, 4478 . 4480 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4481 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4482 . 4484 13.2. Informative References 4486 [I-D.boucadair-dots-earlydata] 4487 Boucadair, M. and R. K, "Using Early Data in DOTS", draft- 4488 boucadair-dots-earlydata-00 (work in progress), January 4489 2019. 4491 [I-D.ietf-core-comi] 4492 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 4493 Management Interface", draft-ietf-core-comi-04 (work in 4494 progress), November 2018. 4496 [I-D.ietf-core-yang-cbor] 4497 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 4498 Data Modeled with YANG", draft-ietf-core-yang-cbor-10 4499 (work in progress), April 2019. 4501 [I-D.ietf-dots-architecture] 4502 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 4503 Compton, "Distributed-Denial-of-Service Open Threat 4504 Signaling (DOTS) Architecture", draft-ietf-dots- 4505 architecture-13 (work in progress), April 2019. 4507 [I-D.ietf-dots-data-channel] 4508 Boucadair, M. and R. K, "Distributed Denial-of-Service 4509 Open Threat Signaling (DOTS) Data Channel Specification", 4510 draft-ietf-dots-data-channel-28 (work in progress), March 4511 2019. 4513 [I-D.ietf-dots-multihoming] 4514 Boucadair, M. and R. K, "Multi-homing Deployment 4515 Considerations for Distributed-Denial-of-Service Open 4516 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 4517 (work in progress), January 2019. 4519 [I-D.ietf-dots-requirements] 4520 Mortensen, A., K, R., and R. Moskowitz, "Distributed 4521 Denial of Service (DDoS) Open Threat Signaling 4522 Requirements", draft-ietf-dots-requirements-22 (work in 4523 progress), March 2019. 4525 [I-D.ietf-dots-server-discovery] 4526 Boucadair, M., K, R., and P. Patil, "Distributed-Denial- 4527 of-Service Open Threat Signaling (DOTS) Server Discovery", 4528 draft-ietf-dots-server-discovery-02 (work in progress), 4529 May 2019. 4531 [I-D.ietf-dots-use-cases] 4532 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 4533 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 4534 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 4535 in progress), January 2019. 4537 [I-D.ietf-tls-dtls13] 4538 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 4539 Datagram Transport Layer Security (DTLS) Protocol Version 4540 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 4541 2019. 4543 [IANA.CBOR.Tags] 4544 IANA, "Concise Binary Object Representation (CBOR) Tags", 4545 . 4548 [IANA.CoAP.Content-Formats] 4549 IANA, "CoAP Content-Formats", 4550 . 4553 [IANA.MediaTypes] 4554 IANA, "Media Types", 4555 . 4557 [proto_numbers] 4558 "IANA, "Protocol Numbers"", 2011, 4559 . 4561 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 4562 Address Translator (Traditional NAT)", RFC 3022, 4563 DOI 10.17487/RFC3022, January 2001, 4564 . 4566 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 4567 Rose, "Resource Records for the DNS Security Extensions", 4568 RFC 4034, DOI 10.17487/RFC4034, March 2005, 4569 . 4571 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 4572 Unique IDentifier (UUID) URN Namespace", RFC 4122, 4573 DOI 10.17487/RFC4122, July 2005, 4574 . 4576 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 4577 Congestion Control Protocol (DCCP)", RFC 4340, 4578 DOI 10.17487/RFC4340, March 2006, 4579 . 4581 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 4582 Denial-of-Service Considerations", RFC 4732, 4583 DOI 10.17487/RFC4732, December 2006, 4584 . 4586 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 4587 Translation (NAT) Behavioral Requirements for Unicast 4588 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 4589 2007, . 4591 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 4592 RFC 4960, DOI 10.17487/RFC4960, September 2007, 4593 . 4595 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 4596 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 4597 . 4599 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 4600 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 4601 DOI 10.17487/RFC5389, October 2008, 4602 . 4604 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 4605 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 4606 June 2010, . 4608 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 4609 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 4610 DOI 10.17487/RFC6052, October 2010, 4611 . 4613 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 4614 NAT64: Network Address and Protocol Translation from IPv6 4615 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 4616 April 2011, . 4618 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 4619 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 4620 DOI 10.17487/RFC6234, May 2011, 4621 . 4623 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 4624 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 4625 . 4627 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 4628 "Default Address Selection for Internet Protocol Version 6 4629 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 4630 . 4632 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 4633 Specifications and Registration Procedures", BCP 13, 4634 RFC 6838, DOI 10.17487/RFC6838, January 2013, 4635 . 4637 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 4638 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 4639 DOI 10.17487/RFC6887, April 2013, 4640 . 4642 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 4643 A., and H. Ashida, "Common Requirements for Carrier-Grade 4644 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 4645 April 2013, . 4647 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4648 "Enrollment over Secure Transport", RFC 7030, 4649 DOI 10.17487/RFC7030, October 2013, 4650 . 4652 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 4653 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 4654 . 4656 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 4657 "Architectural Considerations in Smart Object Networking", 4658 RFC 7452, DOI 10.17487/RFC7452, March 2015, 4659 . 4661 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 4662 NETCONF Protocol over Transport Layer Security (TLS) with 4663 Mutual X.509 Authentication", RFC 7589, 4664 DOI 10.17487/RFC7589, June 2015, 4665 . 4667 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 4668 and P. Hoffman, "Specification for DNS over Transport 4669 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 4670 2016, . 4672 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 4673 RFC 7951, DOI 10.17487/RFC7951, August 2016, 4674 . 4676 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 4677 Better Connectivity Using Concurrency", RFC 8305, 4678 DOI 10.17487/RFC8305, December 2017, 4679 . 4681 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 4682 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 4683 . 4685 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 4686 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 4687 . 4689 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 4690 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 4691 January 2019, . 4693 Appendix A. CUID Generation 4695 The document recommends the use of SPKI to generate the 'cuid'. This 4696 design choice is motivated by the following reasons: 4698 o SPKI is globally unique. 4700 o It is deterministic. 4702 o It allows to avoid extra cycles that may be induced by 'cuid' 4703 collision. 4705 o DOTS clients do not need to store the 'cuid' in a persistent 4706 storage. 4708 o It allows to detect compromised DOTS clients that do not adhere to 4709 the 'cuid' generation algorithm. 4711 Authors' Addresses 4713 Tirumaleswar Reddy (editor) 4714 McAfee, Inc. 4715 Embassy Golf Link Business Park 4716 Bangalore, Karnataka 560071 4717 India 4719 Email: kondtir@gmail.com 4721 Mohamed Boucadair (editor) 4722 Orange 4723 Rennes 35000 4724 France 4726 Email: mohamed.boucadair@orange.com 4727 Prashanth Patil 4728 Cisco Systems, Inc. 4730 Email: praspati@cisco.com 4732 Andrew Mortensen 4733 Arbor Networks, Inc. 4734 2727 S. State St 4735 Ann Arbor, MI 48104 4736 United States 4738 Email: andrew@moretension.com 4740 Nik Teague 4741 Iron Mountain Data Centers 4742 United Kingdom 4744 Email: nteague@ironmountain.co.uk