idnits 2.17.00 (12 Aug 2021) /tmp/idnits60665/draft-ietf-dots-signal-channel-26.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 ([I-D.ietf-dots-data-channel], [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 -- The document date (December 21, 2018) is 1246 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 3998, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-11) exists of draft-ietf-core-comi-04 == Outdated reference: draft-ietf-core-hop-limit has been published as RFC 8768 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-07 == Outdated reference: draft-ietf-dots-architecture has been published as RFC 8811 == Outdated reference: draft-ietf-dots-data-channel has been published as RFC 8783 == Outdated reference: draft-ietf-dots-requirements has been published as RFC 8612 == Outdated reference: draft-ietf-dots-use-cases has been published as RFC 8903 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 2 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: June 24, 2019 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 December 21, 2018 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel Specification 16 draft-ietf-dots-signal-channel-26 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 48 [I-D.ietf-dots-data-channel]) 50 Please update TBD statements with the port number to be assigned to 51 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 June 24, 2019. 72 Copyright Notice 74 Copyright (c) 2018 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 . . . . . . . . . 9 96 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 11 97 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 12 98 4.4.2. Retrieve Information Related to a Mitigation . . . . 27 99 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 31 100 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 34 101 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 35 102 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 37 103 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 38 104 4.5.1. Discover Configuration Parameters . . . . . . . . . . 40 105 4.5.2. Convey DOTS Signal Channel Session Configuration . . 44 106 4.5.3. Configuration Freshness and Notifications . . . . . . 49 107 4.5.4. Delete DOTS Signal Channel Session Configuration . . 50 108 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 51 109 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 53 110 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 54 111 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 54 112 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 56 113 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 60 114 6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 70 115 7. (D)TLS Protocol Profile and Performance Considerations . . . 72 116 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 72 117 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 74 118 7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 75 119 8. Mutual Authentication of DOTS Agents & Authorization of DOTS 120 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 121 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 122 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 78 123 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 78 124 9.3. Media Type Registration . . . . . . . . . . . . . . . . . 78 125 9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 78 126 9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 79 127 9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 79 128 9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 79 129 9.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 80 130 9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 80 131 9.6.1. DOTS Signal Channel CBOR Mappings Sub-Registry . . . 80 132 9.6.1.1. Registration Template . . . . . . . . . . . . . . 81 133 9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 81 134 9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 83 135 9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 84 136 9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 86 137 9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 86 138 9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 87 139 10. Security Considerations . . . . . . . . . . . . . . . . . . . 88 140 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 89 141 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 142 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 143 13.1. Normative References . . . . . . . . . . . . . . . . . . 90 144 13.2. Informative References . . . . . . . . . . . . . . . . . 92 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 147 1. Introduction 149 A distributed denial-of-service (DDoS) attack is an attempt to make 150 machines or network resources unavailable to their intended users. 151 In most cases, sufficient scale can be achieved by compromising 152 enough end-hosts and using those infected hosts to perpetrate and 153 amplify the attack. The victim in this attack can be an application 154 server, a host, a router, a firewall, or an entire network. 156 Network applications have finite resources like CPU cycles, the 157 number of processes or threads they can create and use, the maximum 158 number of simultaneous connections it can handle, the limited 159 resources of the control plane, etc. When processing network 160 traffic, such applications are supposed to use these resources to 161 offer the intended task in the most efficient manner. However, a 162 DDoS attacker may be able to prevent an application from performing 163 its intended task by making the application exhaust its finite 164 resources. 166 TCP DDoS SYN-flood, for example, is a memory-exhausting attack while 167 ACK-flood is a CPU-exhausting attack [RFC4987]. Attacks on the link 168 are carried out by sending enough traffic so that the link becomes 169 congested, thereby likely causing packet loss for legitimate traffic. 170 Stateful firewalls can also be attacked by sending traffic that 171 causes the firewall to maintain an excessive number of states that 172 may jeopardize the firewall's operation overall, besides likely 173 performance impacts. The firewall then runs out of memory, and can 174 no longer instantiate the states required to process legitimate 175 flows. Other possible DDoS attacks are discussed in [RFC4732]. 177 In many cases, it may not be possible for network administrators to 178 determine the cause(s) of an attack. They may instead just realize 179 that certain resources seem to be under attack. This document 180 defines a lightweight protocol that allows a DOTS client to request 181 mitigation from one or more DOTS servers for protection against 182 detected, suspected, or anticipated attacks. This protocol enables 183 cooperation between DOTS agents to permit a highly-automated network 184 defense that is robust, reliable, and secure. 186 An example of a network diagram that illustrates a deployment of DOTS 187 agents is shown in Figure 1. In this example, a DOTS server is 188 operating on the access network. A DOTS client is located on the LAN 189 (Local Area Network), while a DOTS gateway is embedded in the CPE 190 (Customer Premises Equipment). 192 Network 193 Resource CPE router Access network __________ 194 +-----------+ +--------------+ +-------------+ / \ 195 | |___| |____| |___ | Internet | 196 |DOTS client| | DOTS gateway | | DOTS server | | | 197 | | | | | | | | 198 +-----------+ +--------------+ +-------------+ \__________/ 200 Figure 1: Sample DOTS Deployment (1) 202 DOTS servers can also be reachable over the Internet, as depicted in 203 Figure 2. 205 Network DDoS mitigation 206 Resource CPE router __________ service 207 +-----------+ +-------------+ / \ +-------------+ 208 | |___| |____| |___ | | 209 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 210 | | | | | | | | 211 +-----------+ +-------------+ \__________/ +-------------+ 213 Figure 2: Sample DOTS Deployment (2) 215 In typical deployments, the DOTS client belongs to a different 216 administrative domain than the DOTS server. For example, the DOTS 217 client is embedded in a firewall protecting services owned and 218 operated by a customer, while the DOTS server is owned and operated 219 by a different administrative entity (service provider, typically) 220 providing DDoS mitigation services. The latter might or might not 221 provide connectivity services to the network hosting the DOTS client. 223 The DOTS server may (not) be co-located with the DOTS mitigator. In 224 typical deployments, the DOTS server belongs to the same 225 administrative domain as the mitigator. The DOTS client can 226 communicate directly with a DOTS server or indirectly via a DOTS 227 gateway. 229 The document adheres to the DOTS architecture 230 [I-D.ietf-dots-architecture]. The requirements for DOTS signal 231 channel protocol are documented in [I-D.ietf-dots-requirements]. 232 This document satisfies all the use cases discussed in 233 [I-D.ietf-dots-use-cases]. 235 This document focuses on the DOTS signal channel. This is a 236 companion document of the DOTS data channel specification 237 [I-D.ietf-dots-data-channel] that defines a configuration and a bulk 238 data exchange mechanism supporting the DOTS signal channel. 240 2. Terminology 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 244 "OPTIONAL" in this document are to be interpreted as described in BCP 245 14 [RFC2119][RFC8174] when, and only when, they appear in all 246 capitals, as shown here. 248 (D)TLS is used for statements that apply to both Transport Layer 249 Security [RFC5246][RFC8446] and Datagram Transport Layer Security 250 [RFC6347]. Specific terms are used for any statement that applies to 251 either protocol alone. 253 The reader should be familiar with the terms defined in 254 [I-D.ietf-dots-requirements]. 256 The meaning of the symbols in YANG tree diagrams is defined in 257 [RFC8340]. 259 3. Design Overview 261 The DOTS signal channel is built on top of the Constrained 262 Application Protocol (CoAP) [RFC7252], a lightweight protocol 263 originally designed for constrained devices and networks. The many 264 features of CoAP (expectation of packet loss, support for 265 asynchronous Non-confirmable messaging, congestion control, small 266 message overhead limiting the need for fragmentation, use of minimal 267 resources, and support for (D)TLS) makes it a good candidate to build 268 the DOTS signaling mechanism from. 270 The DOTS signal channel is layered on existing standards (Figure 3). 272 +---------------------+ 273 | DOTS Signal Channel | 274 +---------------------+ 275 | CoAP | 276 +----------+----------+ 277 | TLS | DTLS | 278 +----------+----------+ 279 | TCP | UDP | 280 +----------+----------+ 281 | IP | 282 +---------------------+ 284 Figure 3: Abstract Layering of DOTS Signal Channel over CoAP over 285 (D)TLS 287 By default, a DOTS signal channel MUST run over port number TBD as 288 defined in Section 9.1, for both UDP and TCP, unless the DOTS server 289 has a mutual agreement with its DOTS clients to use a different port 290 number. DOTS clients MAY alternatively support means to dynamically 291 discover the ports used by their DOTS servers. In order to use a 292 distinct port number (as opposed to TBD), DOTS clients and servers 293 SHOULD support a configurable parameter to supply the port number to 294 use. The rationale for not using the default port number 5684 295 ((D)TLS CoAP) is to allow for differentiated behaviors in 296 environments where both a DOTS gateway and an IoT gateway (e.g., 297 Figure 3 of [RFC7452]) are present. 299 The signal channel uses the "coaps" URI scheme defined in Section 6 300 of [RFC7252] and "coaps+tcp" URI scheme defined in Section 8.2 of 301 [RFC8323] to identify DOTS server resources accessible using CoAP 302 over UDP secured with DTLS and CoAP over TCP secured with TLS. 304 The signal channel is initiated by the DOTS client (Section 4.4). 305 Once the signal channel is established, the DOTS agents periodically 306 send heartbeats to keep the channel active (Section 4.7). At any 307 time, the DOTS client may send a mitigation request message to a DOTS 308 server over the active channel. While mitigation is active because 309 of the higher likelihood of packet loss during a DDoS attack, the 310 DOTS server periodically sends status messages to the client, 311 including basic mitigation feedback details. Mitigation remains 312 active until the DOTS client explicitly terminates mitigation, or the 313 mitigation lifetime expires. 315 DOTS signaling can happen with DTLS over UDP and TLS over TCP. 316 Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer 317 capabilities. A Happy Eyeballs procedure for DOTS signal channel is 318 specified in Section 4.3. 320 Messages exchanged between DOTS agents are serialized using Concise 321 Binary Object Representation (CBOR) [RFC7049], a binary encoding 322 scheme designed for small code and message size. CBOR-encoded 323 payloads are used to carry signal channel-specific payload messages 324 which convey request parameters and response information such as 325 errors. In order to allow the use of the same data models, [RFC7951] 326 specifies the JavaScript Object Notation (JSON) encoding of YANG- 327 modeled data. A similar effort for CBOR is defined in 328 [I-D.ietf-core-yang-cbor]. 330 DOTS agents determine the CBOR data structure is a DOTS signal 331 channel object from the application context, such as from the port 332 number assigned to the DOTS signal channel. The other method DOTS 333 agents use to indicate that a CBOR data structure is a DOTS signal 334 channel object is the use of the "application/dots+cbor" content type 335 (Section 9.3). 337 From that standpoint, this document specifies a YANG module for 338 representing DOTS mitigation scopes, DOTS signal channel session 339 configuration data, and DOTS redirected signalling (Section 5). 340 Representing these data as CBOR data is assumed to follow the rules 341 in [I-D.ietf-core-yang-cbor] or those in [RFC7951] combined with 342 JSON/CBOR conversion rules in [RFC7049]. All parameters in the 343 payload of the DOTS signal channel are mapped to CBOR types as 344 specified in Section 6. 346 In order to prevent fragmentation, DOTS agents must follow the 347 recommendations documented in Section 4.6 of [RFC7252]. Refer to 348 Section 7.3 for more details. 350 DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The 351 payload included in CoAP responses with 2.xx Response Codes MUST be 352 of content type "application/dots+cbor". CoAP responses with 4.xx 353 and 5.xx error Response Codes MUST include a diagnostic payload 354 (Section 5.5.2 of [RFC7252]). The Diagnostic Payload may contain 355 additional information to aid troubleshooting. 357 In deployments where multiple DOTS clients are enabled in a network 358 (owned and operated by the same entity), the DOTS server may detect 359 conflicting mitigation requests from these clients. This document 360 does not aim to specify a comprehensive list of conditions under 361 which a DOTS server will characterize two mitigation requests from 362 distinct DOTS clients as conflicting, nor recommend a DOTS server 363 behavior for processing conflicting mitigation requests. Those 364 considerations are implementation- and deployment-specific. 365 Nevertheless, the document specifies the mechanisms to notify DOTS 366 clients when conflicts occur, including the conflict cause 367 (Section 4.4). 369 In deployments where one or more translators (e.g., Traditional NAT 370 [RFC3022], CGN [RFC6888], NAT64 [RFC6146], NPTv6 [RFC6296]) are 371 enabled between the client's network and the DOTS server, DOTS signal 372 channel messages forwarded to a DOTS server MUST NOT include internal 373 IP addresses/prefixes and/or port numbers; external addresses/ 374 prefixes and/or port numbers as assigned by the translator MUST be 375 used instead. This document does not make any recommendation about 376 possible translator discovery mechanisms. The following are some 377 (non-exhaustive) deployment examples that may be considered: 379 o Port Control Protocol (PCP) [RFC6887] or Session Traversal 380 Utilities for NAT (STUN) [RFC5389] may be used to retrieve the 381 external addresses/prefixes and/or port numbers. Information 382 retrieved by means of PCP or STUN will be used to feed the DOTS 383 signal channel messages that will be sent to a DOTS server. 385 o A DOTS gateway may be co-located with the translator. The DOTS 386 gateway will need to update the DOTS messages, based upon the 387 local translator's binding table. 389 4. DOTS Signal Channel: Messages & Behaviors 391 4.1. DOTS Server(s) Discovery 393 This document assumes that DOTS clients are provisioned with the 394 reachability information of their DOTS server(s) using a variety of 395 means (e.g., local configuration, or dynamic means such as DHCP). 396 The description of such means is out of scope of this document. 398 Likewise, it is out of scope of this document to specify the behavior 399 to be followed by a DOTS client to send DOTS requests when multiple 400 DOTS servers are provisioned (e.g., contact all DOTS servers, select 401 one DOTS server among the list). 403 4.2. CoAP URIs 405 The DOTS server MUST support the use of the path-prefix of "/.well- 406 known/" as defined in [RFC5785] and the registered name of "dots". 407 Each DOTS operation is indicated by a path-suffix that indicates the 408 intended operation. The operation path (Table 1) is appended to the 409 path-prefix to form the URI used with a CoAP request to perform the 410 desired DOTS operation. 412 +-----------------------+----------------+-------------+ 413 | Operation | Operation Path | Details | 414 +-----------------------+----------------+-------------+ 415 | Mitigation | /mitigate | Section 4.4 | 416 +-----------------------+----------------+-------------+ 417 | Session configuration | /config | Section 4.5 | 418 +-----------------------+----------------+-------------+ 420 Table 1: Operations and their Corresponding URIs 422 4.3. Happy Eyeballs for DOTS Signal Channel 424 [I-D.ietf-dots-requirements] mentions that DOTS agents will have to 425 support both connectionless and connection-oriented protocols. As 426 such, the DOTS signal channel is designed to operate with DTLS over 427 UDP and TLS over TCP. Further, a DOTS client may acquire a list of 428 IPv4 and IPv6 addresses (Section 4.1), each of which can be used to 429 contact the DOTS server using UDP and TCP. The following specifies 430 the procedure to follow to select the address family and the 431 transport protocol for sending DOTS signal channel messages. 433 Such procedure is needed to avoid experiencing long connection 434 delays. For example, if an IPv4 path to reach a DOTS server is 435 found, but the DOTS server's IPv6 path is not working, a dual-stack 436 DOTS client may experience a significant connection delay compared to 437 an IPv4-only DOTS client. The other problem is that if a middlebox 438 between the DOTS client and DOTS server is configured to block UDP 439 traffic, the DOTS client will fail to establish a DTLS session with 440 the DOTS server and, as a consequence, will have to fall back to TLS 441 over TCP, thereby incurring significant connection delays. 443 To overcome these connection setup problems, the DOTS client attempts 444 to connect to its DOTS server(s) using both IPv6 and IPv4, and tries 445 both DTLS over UDP and TLS over TCP in a manner similar to the Happy 446 Eyeballs mechanism [RFC8305]. These connection attempts are 447 performed by the DOTS client when it initializes. The results of the 448 Happy Eyeballs procedure are used by the DOTS client for sending its 449 subsequent messages to the DOTS server. 451 The order of preference of the DOTS signal channel address family and 452 transport protocol (most preferred first) is: UDP over IPv6, UDP over 453 IPv4, TCP over IPv6, and finally TCP over IPv4. This order adheres 454 to the address preference order specified in [RFC6724] and the DOTS 455 signal channel preference which privileges the use of UDP over TCP 456 (to avoid TCP's head of line blocking). 458 In reference to Figure 4, the DOTS client sends two TCP SYNs and two 459 DTLS ClientHello messages at the same time over IPv6 and IPv4. In 460 this example, it is assumed that the IPv6 path is broken and UDP 461 traffic is dropped by a middlebox but has little impact to the DOTS 462 client because there is no long delay before using IPv4 and TCP. The 463 DOTS client repeats the mechanism to discover whether DOTS signal 464 channel messages with DTLS over UDP becomes available from the DOTS 465 server, so the DOTS client can migrate the DOTS signal channel from 466 TCP to UDP. Such probing SHOULD NOT be done more frequently than 467 every 24 hours and MUST NOT be done more frequently than every 5 468 minutes. 470 A single DOTS signal channel between DOTS agents can be used to 471 exchange multiple DOTS signal messages. To reduce DOTS client and 472 DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session. 474 +-----------+ +-----------+ 475 |DOTS client| |DOTS server| 476 +-----------+ +-----------+ 477 | | 478 |--DTLS ClientHello, IPv6 ---->X | 479 |--TCP SYN, IPv6-------------->X | 480 |--DTLS ClientHello, IPv4 ---->X | 481 |--TCP SYN, IPv4--------------------------------------->| 482 |--DTLS ClientHello, IPv6 ---->X | 483 |--TCP SYN, IPv6-------------->X | 484 |<-TCP SYNACK-------------------------------------------| 485 |--DTLS ClientHello, IPv4 ---->X | 486 |--TCP ACK--------------------------------------------->| 487 |<------------Establish TLS Session-------------------->| 488 |----------------DOTS signal--------------------------->| 489 | | 491 Figure 4: DOTS Happy Eyeballs 493 4.4. DOTS Mitigation Methods 495 The following methods are used by a DOTS client to request, withdraw, 496 or retrieve the status of mitigation requests: 498 PUT: DOTS clients use the PUT method to request mitigation from a 499 DOTS server (Section 4.4.1). During active mitigation, DOTS 500 clients may use PUT requests to carry mitigation efficacy 501 updates to the DOTS server (Section 4.4.3). 503 GET: DOTS clients may use the GET method to subscribe to DOTS 504 server status messages, or to retrieve the list of its 505 mitigations maintained by a DOTS server (Section 4.4.2). 507 DELETE: DOTS clients use the DELETE method to withdraw a request for 508 mitigation from a DOTS server (Section 4.4.4). 510 Mitigation request and response messages are marked as Non- 511 confirmable messages (Section 2.2 of [RFC7252]). 513 DOTS agents SHOULD follow the data transmission guidelines discussed 514 in Section 3.1.3 of [RFC8085] and control transmission behavior by 515 not sending more than one UDP datagram per round-trip time (RTT) to 516 the peer DOTS agent on average. 518 Requests marked by the DOTS client as Non-confirmable messages are 519 sent at regular intervals until a response is received from the DOTS 520 server. If the DOTS client cannot maintain an RTT estimate, it 521 SHOULD NOT send more than one Non-confirmable request every 3 522 seconds, and SHOULD use an even less aggressive rate whenever 523 possible (case 2 in Section 3.1.3 of [RFC8085]). 525 JSON diagnostic notation is used to illustrate the various methods 526 defined in the following sub-sections. 528 4.4.1. Request Mitigation 530 When a DOTS client requires mitigation for some reason, the DOTS 531 client uses the CoAP PUT method to send a mitigation request to its 532 DOTS server(s) (Figure 5). 534 If a DOTS client is entitled to solicit the DOTS service, the DOTS 535 server can enable mitigation on behalf of the DOTS client by 536 communicating the DOTS client's request to a mitigator and relaying 537 the feedback of the thus-selected mitigator to the requesting DOTS 538 client. 540 Header: PUT (Code=0.03) 541 Uri-Path: ".well-known" 542 Uri-Path: "dots" 543 Uri-Path: "mitigate" 544 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 545 Uri-Path: "mid=123" 546 Content-Type: "application/dots+cbor" 547 { 548 "ietf-dots-signal-channel:mitigation-scope": { 549 "scope": [ 550 { 551 "target-prefix": [ 552 "string" 553 ], 554 "target-port-range": [ 555 { 556 "lower-port": number, 557 "upper-port": number 558 } 559 ], 560 "target-protocol": [ 561 number 562 ], 563 "target-fqdn": [ 564 "string" 565 ], 566 "target-uri": [ 567 "string" 568 ], 569 "alias-name": [ 570 "string" 571 ], 572 "lifetime": number, 573 "trigger-mitigation": true|false 574 } 575 ] 576 } 577 } 579 Figure 5: PUT to Convey DOTS Mitigation Requests 581 The order of the Uri-Path options is important as it defines the CoAP 582 resource. In particular, 'mid' MUST follow 'cuid'. 584 The additional Uri-Path parameters to those defined in Section 4.2 585 are as follows: 587 cuid: Stands for Client Unique Identifier. A globally unique 588 identifier that is meant to prevent collisions among DOTS clients, 589 especially those from the same domain. It MUST be generated by 590 DOTS clients. 592 Implementations SHOULD use the output of a cryptographic hash 593 algorithm whose input is the Distinguished Encoding Rules (DER)- 594 encoded Abstract Syntax Notation One (ASN.1) representation of the 595 Subject Public Key Info (SPKI) of the DOTS client X.509 596 certificate [RFC5280], the DOTS client raw public key [RFC7250], 597 or the "Pre-Shared Key (PSK) identity" used by the DOTS client in 598 the TLS ClientKeyExchange message to set 'cuid'. In this version 599 of the specification, the cryptographic hash algorithm used is 600 SHA-256 [RFC6234]. The output of the cryptographic hash algorithm 601 is truncated to 16 bytes; truncation is done by stripping off the 602 final 16 bytes. The truncated output is base64url encoded. 604 The 'cuid' is intended to be stable when communicating with a 605 given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD 606 NOT change over time. Distinct 'cuid' values MAY be used per DOTS 607 server. 609 DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer 610 to notify that the 'cuid' is already in-use by another DOTS 611 client. Upon receipt of that error code, a new 'cuid' MUST be 612 generated by the DOTS peer. 614 Client-domain DOTS gateways MUST handle 'cuid' collision directly 615 and it is RECOMMENDED that 'cuid' collision is handled directly by 616 server-domain DOTS gateways. 618 DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. 619 Triggers for such rewriting are out of scope. 621 This is a mandatory Uri-Path parameter. 623 mid: Identifier for the mitigation request represented with an 624 integer. This identifier MUST be unique for each mitigation 625 request bound to the DOTS client, i.e., the 'mid' parameter value 626 in the mitigation request needs to be unique relative to the 'mid' 627 parameter values of active mitigation requests conveyed from the 628 DOTS client to the DOTS server. 630 In order to handle out-of-order delivery of mitigation requests, 631 'mid' values MUST increase monotonically. 633 If the 'mid' value has reached 3/4 of (2**32 - 1) (i.e., 634 3221225471) and it is peace-time, the DOTS client MUST reset 'mid' 635 to 0 to handle 'mid' rollover. If the DOTS client maintains 636 mitigation requests with pre-configured scopes, it MUST re-create 637 them with the 'mid' restarting at 0. 639 This identifier MUST be generated by the DOTS client. 641 This is a mandatory Uri-Path parameter. 643 'cuid' and 'mid' MUST NOT appear in the PUT request message body. 645 The parameters in the CBOR body of the PUT request are described 646 below: 648 target-prefix: A list of prefixes identifying resources under 649 attack. Prefixes are represented using Classless Inter-Domain 650 Routing (CIDR) notation [RFC4632]. 651 As a reminder, the prefix length must be less than or equal to 32 652 (resp. 128) for IPv4 (resp. IPv6). 654 The prefix list MUST NOT include broadcast, loopback, or multicast 655 addresses. These addresses are considered as invalid values. In 656 addition, the DOTS server MUST validate that target prefixes are 657 within the scope of the DOTS client's domain. Other validation 658 checks may be supported by DOTS servers. 660 This is an optional attribute. 662 target-port-range: A list of port numbers bound to resources under 663 attack. 665 A port range is defined by two bounds, a lower port number (lower- 666 port) and an upper port number (upper-port). When only 'lower- 667 port' is present, it represents a single port number. 669 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 670 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 671 [RFC4340], a range of ports can be, for example, 0-1023, 672 1024-65535, or 1024-49151. 674 This is an optional attribute. 676 target-protocol: A list of protocols involved in an attack. Values 677 are taken from the IANA protocol registry [proto_numbers]. 679 The value '0' has a special meaning for 'all protocols'. 681 This is an optional attribute. 683 target-fqdn: A list of Fully Qualified Domain Names (FQDNs) 684 identifying resources under attack. An FQDN is the full name of a 685 resource, rather than just its hostname. For example, "venera" is 686 a hostname, and "venera.isi.edu" is an FQDN [RFC1983]. 688 How a name is passed to an underlying name resolution library is 689 implementation- and deployment-specific. Nevertheless, once the 690 name is resolved into one or multiple IP addresses, DOTS servers 691 MUST apply the same validation checks as those for 'target- 692 prefix'. 694 This is an optional attribute. 696 target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986] 697 identifying resources under attack. 699 The same validation checks used for 'target-fqdn' MUST be followed 700 by DOTS servers to validate a target URI. 702 This is an optional attribute. 704 alias-name: A list of aliases of resources for which the mitigation 705 is requested. Aliases can be created using the DOTS data channel 706 (Section 6.1 of [I-D.ietf-dots-data-channel]), direct 707 configuration, or other means. 709 An alias is used in subsequent signal channel exchanges to refer 710 more efficiently to the resources under attack. 712 This is an optional attribute. 714 lifetime: Lifetime of the mitigation request in seconds. The 715 RECOMMENDED lifetime of a mitigation request is 3600 seconds -- 716 this value was chosen to be long enough so that refreshing is not 717 typically a burden on the DOTS client, while expiring the request 718 where the client has unexpectedly quit in a timely manner. DOTS 719 clients MUST include this parameter in their mitigation requests. 720 Upon the expiry of this lifetime, and if the request is not 721 refreshed, the mitigation request is removed. The request can be 722 refreshed by sending the same request again. 724 A lifetime of '0' in a mitigation request is an invalid value. 726 A lifetime of negative one (-1) indicates indefinite lifetime for 727 the mitigation request. The DOTS server MAY refuse indefinite 728 lifetime, for policy reasons; the granted lifetime value is 729 returned in the response. DOTS clients MUST be prepared to not be 730 granted mitigations with indefinite lifetimes. 732 The DOTS server MUST always indicate the actual lifetime in the 733 response and the remaining lifetime in status messages sent to the 734 DOTS client. 736 This is a mandatory attribute. 738 trigger-mitigation: If the parameter value is set to 'false', DDoS 739 mitigation will not be triggered for the mitigation request unless 740 the DOTS signal channel session is lost. 742 If the DOTS client ceases to respond to heartbeat messages, the 743 DOTS server can detect that the DOTS signal channel session is 744 lost. 746 The default value of the parameter is 'true' (that is, the 747 mitigation starts immediately). If 'trigger-mitigation' is not 748 present in a request, this is equivalent to receiving a request 749 with 'trigger-mitigation' set to 'true'. 751 This is an optional attribute. 753 In deployments where server-domain DOTS gateways are enabled, 754 identity information about the origin source client domain SHOULD be 755 supplied to the DOTS server. That information is meant to assist the 756 DOTS server to enforce some policies such as correlating DOTS clients 757 that belong to the same DOTS domain, limiting the number of DOTS 758 requests, and identifying the mitigation scope. These policies can 759 be enforced per-client, per-client domain, or both. Also, the 760 identity information may be used for auditing and debugging purposes. 762 Figure 6 shows an example of a request relayed by a server-domain 763 DOTS gateway. 765 Header: PUT (Code=0.03) 766 Uri-Path: ".well-known" 767 Uri-Path: "dots" 768 Uri-Path: "mitigate" 769 Uri-Path: "cdid=7eeaf349529eb55ed50113" 770 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 771 Uri-Path: "mid=123" 772 Content-Type: "application/dots+cbor" 773 { 774 "ietf-dots-signal-channel:mitigation-scope": { 775 "scope": [ 776 { 777 "target-prefix": [ 778 "string" 779 ], 780 "target-port-range": [ 781 { 782 "lower-port": number, 783 "upper-port": number 784 } 785 ], 786 "target-protocol": [ 787 number 788 ], 789 "target-fqdn": [ 790 "string" 791 ], 792 "target-uri": [ 793 "string" 794 ], 795 "alias-name": [ 796 "string" 797 ], 798 "lifetime": number 799 } 800 ] 801 } 802 } 804 Figure 6: PUT to Convey DOTS Mitigation Request as relayed by a 805 Server-Domain DOTS Gateway 807 A server-domain DOTS gateway SHOULD add the following Uri-Path 808 parameter: 810 cdid: Stands for Client Domain Identifier. The 'cdid' is conveyed 811 by a server-domain DOTS gateway to propagate the source domain 812 identity from the gateway's client-facing-side to the gateway's 813 server-facing-side, and from the gateway's server-facing-side to 814 the DOTS server. 'cdid' may be used by the final DOTS server for 815 policy enforcement purposes (e.g., enforce a quota on filtering 816 rules). These policies are deployment-specific. 818 Server-domain DOTS gateways SHOULD support a configuration option 819 to instruct whether 'cdid' parameter is to be inserted. 821 In order to accommodate deployments that require enforcing per- 822 client policies, per-client domain policies, or a combination 823 thereof, server-domain DOTS gateways MUST supply the SPKI hash of 824 the DOTS client X.509 certificate, the DOTS client raw public key, 825 or the hash of the "PSK identity" in the 'cdid', following the 826 same rules for generating the hash conveyed in 'cuid', which is 827 then used by the ultimate DOTS server to determine the 828 corresponding client's domain. The 'cdid' generated by a server- 829 domain gateway is likely to be the same as the 'cuid' except if 830 the DOTS message was relayed by a DOTS gateway or was generated 831 from a rogue DOTS client. 833 If a DOTS client is provisioned, for example, with distinct 834 certificates as a function of the peer server-domain DOTS gateway, 835 distinct 'cdid' values may be supplied by a server-domain DOTS 836 gateway. The ultimate DOTS server MUST treat those 'cdid' values 837 as equivalent. 839 The 'cdid' attribute MUST NOT be generated and included by DOTS 840 clients. 842 DOTS servers MUST ignore 'cdid' attributes that are directly 843 supplied by source DOTS clients or client-domain DOTS gateways. 844 This implies that first server-domain DOTS gateways MUST strip 845 'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD 846 support a configuration parameter to identify DOTS gateways that 847 are trusted to supply 'cdid' attributes. 849 Only single-valued 'cdid' are defined in this document. 851 This is an optional Uri-Path. When present, 'cdid' MUST be 852 positioned before 'cuid'. 854 A DOTS gateway MAY add the CoAP Hop-Limit Option 855 [I-D.ietf-core-hop-limit]. 857 Because of the complexity to handle partial failure cases, this 858 specification does not allow for including multiple mitigation 859 requests in the same PUT request. Concretely, a DOTS client MUST NOT 860 include multiple 'scope' parameters in the same PUT request. 862 FQDN and URI mitigation scopes may be thought of as a form of scope 863 alias, in which the addresses associated with the domain name or URI 864 represent the full scope of the mitigation. 866 In the PUT request at least one of the attributes 'target-prefix', 867 'target-fqdn','target-uri', or 'alias-name' MUST be present. 869 Attributes and Uri-Path parameters with empty values MUST NOT be 870 present in a request. 872 Figure 7 shows a PUT request example to signal that ports 80, 8080, 873 and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 servers are 874 under attack (illustrated in JSON diagnostic notation). The presence 875 of 'cdid' indicates that a server-domain DOTS gateway has modified 876 the initial PUT request sent by the DOTS client. Note that 'cdid' 877 MUST NOT appear in the PUT request message body. 879 Header: PUT (Code=0.03) 880 Uri-Path: ".well-known" 881 Uri-Path: "dots" 882 Uri-Path: "mitigate" 883 Uri-Path: "cdid=7eeaf349529eb55ed50113" 884 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 885 Uri-Path: "mid=123" 886 Content-Format: "application/dots+cbor" 887 { 888 "ietf-dots-signal-channel:mitigation-scope": { 889 "scope": [ 890 { 891 "target-prefix": [ 892 "2001:db8:6401::1/128", 893 "2001:db8:6401::2/128" 894 ], 895 "target-port-range": [ 896 { 897 "lower-port": 80 898 }, 899 { 900 "lower-port": 443 901 }, 902 { 903 "lower-port": 8080 904 } 905 ], 906 "target-protocol": [ 907 6 908 ], 909 "lifetime": 3600 910 } 911 ] 912 } 913 } 915 Figure 7: PUT for DOTS Mitigation Request 917 The corresponding CBOR encoding format is shown in Figure 8. 919 A1 # map(1) 920 01 # unsigned(1) 921 A1 # map(1) 922 02 # unsigned(2) 923 81 # array(1) 924 A3 # map(3) 925 06 # unsigned(6) 926 82 # array(2) 927 74 # text(20) 928 323030313A6462383A363430313A3A312F313238 929 74 # text(20) 930 323030313A6462383A363430313A3A322F313238 931 07 # unsigned(7) 932 83 # array(3) 933 A1 # map(1) 934 08 # unsigned(8) 935 18 50 # unsigned(80) 936 A1 # map(1) 937 08 # unsigned(8) 938 19 01BB # unsigned(443) 939 A1 # map(1) 940 08 # unsigned(8) 941 19 1F90 # unsigned(8080) 942 0A # unsigned(10) 943 81 # array(1) 944 06 # unsigned(6) 945 0E # unsigned(14) 946 19 0E10 # unsigned(3600) 948 Figure 8: PUT for DOTS Mitigation Request (CBOR) 950 In both DOTS signal and data channel sessions, the DOTS client MUST 951 authenticate itself to the DOTS server (Section 8). The DOTS server 952 MAY use the algorithm presented in Section 7 of [RFC7589] to derive 953 the DOTS client identity or username from the client certificate. 954 The DOTS client identity allows the DOTS server to accept mitigation 955 requests with scopes that the DOTS client is authorized to manage. 957 The DOTS server couples the DOTS signal and data channel sessions 958 using the DOTS client identity and optionally the 'cdid' parameter 959 value, so the DOTS server can validate whether the aliases conveyed 960 in the mitigation request were indeed created by the same DOTS client 961 using the DOTS data channel session. If the aliases were not created 962 by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in 963 the response. 965 The DOTS server couples the DOTS signal channel sessions using the 966 DOTS client identity and optionally the 'cdid' parameter value, and 967 the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to 968 detect duplicate mitigation requests. If the mitigation request 969 contains the 'alias-name' and other parameters identifying the target 970 resources (such as 'target-prefix', 'target-port-range', 'target- 971 fqdn', or 'target-uri'), the DOTS server appends the parameter values 972 in 'alias-name' with the corresponding parameter values in 'target- 973 prefix', 'target-port-range', 'target-fqdn', or 'target-uri'. 975 The DOTS server indicates the result of processing the PUT request 976 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 977 codes are some sort of invalid requests (client errors). COAP 5.xx 978 codes are returned if the DOTS server has erred or is currently 979 unavailable to provide mitigation in response to the mitigation 980 request from the DOTS client. 982 Figure 9 shows an example response to a PUT request that is 983 successfully processed by a DOTS server (i.e., CoAP 2.xx response 984 codes). This version of the specification forbids 'cuid' and 'cdid' 985 (if used) to be returned in a response message body. 987 { 988 "ietf-dots-signal-channel:mitigation-scope": { 989 "scope": [ 990 { 991 "mid": 123, 992 "lifetime": 3600 993 } 994 ] 995 } 996 } 998 Figure 9: 2.xx Response Body 1000 If the request is missing a mandatory attribute, does not include 1001 'cuid' or 'mid' Uri-Path options, includes multiple 'scope' 1002 parameters, or contains invalid or unknown parameters, the DOTS 1003 server MUST reply with 4.00 (Bad Request). DOTS agents can safely 1004 ignore Vendor-Specific parameters they don't understand. 1006 A DOTS server that receives a mitigation request with a lifetime set 1007 to '0' MUST reply with a 4.00 (Bad Request). 1009 If the DOTS server does not find the 'mid' parameter value conveyed 1010 in the PUT request in its configuration data, it MAY accept the 1011 mitigation request by sending back a 2.01 (Created) response to the 1012 DOTS client; the DOTS server will consequently try to mitigate the 1013 attack. 1015 If the DOTS server finds the 'mid' parameter value conveyed in the 1016 PUT request in its configuration data bound to that DOTS client, it 1017 MAY update the mitigation request, and a 2.04 (Changed) response is 1018 returned to indicate a successful update of the mitigation request. 1020 The relative order of two mitigation requests, having the same 1021 'trigger-mitigation' type, from a DOTS client is determined by 1022 comparing their respective 'mid' values. If two mitigation requests 1023 with the same 'trigger-mitigation' type have overlapping mitigation 1024 scopes, the mitigation request with the highest numeric 'mid' value 1025 will override the other mitigation request. Two mitigation requests 1026 from a DOTS client have overlapping scopes if there is a common IP 1027 address, IP prefix, FQDN, URI, or alias-name. To avoid maintaining a 1028 long list of overlapping mitigation requests (i.e., requests with the 1029 same 'trigger-mitigation' type and overlapping scopes) from a DOTS 1030 client and avoid error-prone provisioning of mitigation requests from 1031 a DOTS client, the overlapped lower numeric 'mid' MUST be 1032 automatically deleted and no longer available at the DOTS server. 1033 For example, if the DOTS server receives a mitigation request which 1034 overlaps with an existing mitigation with a higher numeric 'mid', the 1035 DOTS server rejects the request by returning 4.09 (Conflict) to the 1036 DOTS client. The response includes enough information for a DOTS 1037 client to recognize the source of the conflict as described below: 1039 conflict-information: Indicates that a mitigation request is 1040 conflicting with another mitigation request. This optional 1041 attribute has the following structure: 1043 conflict-cause: Indicates the cause of the conflict. The 1044 following values are defined: 1046 1: Overlapping targets. 'conflict-scope' provides more details 1047 about the conflicting target clauses. 1049 conflict-scope: Indicates the conflict scope. It may include a 1050 list of IP addresses, a list of prefixes, a list of port 1051 numbers, a list of target protocols, a list of FQDNs, a list of 1052 URIs, a list of alias-names, or a 'mid'. 1054 If the DOTS server receives a mitigation request which overlaps with 1055 an active mitigation request, but both having distinct 'trigger- 1056 mitigation' types, the DOTS server MUST deactivate (absent explicit 1057 policy/configuration otherwise) the mitigation request with 'trigger- 1058 mitigation' set to false. Particularly, if the mitigation request 1059 with 'trigger-mitigation' set to false is active, the DOTS server 1060 withdraws the mitigation request (i.e., status code is set to '7' as 1061 defined in Table 2) and transitions the status of the mitigation 1062 request to '8'. 1064 Upon DOTS signal channel session loss with a peer DOTS client, the 1065 DOTS server MUST withdraw (absent explicit policy/configuration 1066 otherwise) any active mitigation requests overlapping with mitigation 1067 requests having 'trigger-mitigation' set to false from that DOTS 1068 client. Note that active-but-terminating period is not observed for 1069 mitigations withdrawn at the initiative of the DOTS server. 1071 DOTS clients may adopt various strategies for setting the scopes of 1072 immediate and pre-configured mitigation requests to avoid potential 1073 conflicts. For example, a DOTS client may tweak pre-configured 1074 scopes so that the scope of any overlapping immediate mitigation 1075 request will be a subset of the pre-configured scopes. Also, if an 1076 immediate mitigation request overlaps with any of the pre-configured 1077 scopes, the DOTS client sets the scope of the overlapping immediate 1078 mitigation request to be a subset of the pre-configured scopes. 1080 If the request is conflicting with an existing mitigation request 1081 from a different DOTS client, the DOTS server may return 2.01 1082 (Created) or 4.09 (Conflict) to the requesting DOTS client. If the 1083 DOTS server decides to maintain the new mitigation request, the DOTS 1084 server returns 2.01 (Created) to the requesting DOTS client. If the 1085 DOTS server decides to reject the new mitigation request, the DOTS 1086 server returns 4.09 (Conflict) to the requesting DOTS client. For 1087 both 2.01 (Created) and 4.09 (Conflict) responses, the response 1088 includes enough information for a DOTS client to recognize the source 1089 of the conflict as described below: 1091 conflict-information: Indicates that a mitigation request is 1092 conflicting with another mitigation request(s) from other DOTS 1093 client(s). This optional attribute has the following structure: 1095 conflict-status: Indicates the status of a conflicting mitigation 1096 request. The following values are defined: 1098 1: DOTS server has detected conflicting mitigation requests 1099 from different DOTS clients. This mitigation request is 1100 currently inactive until the conflicts are resolved. 1101 Another mitigation request is active. 1103 2: DOTS server has detected conflicting mitigation requests 1104 from different DOTS clients. This mitigation request is 1105 currently active. 1107 3: DOTS server has detected conflicting mitigation requests 1108 from different DOTS clients. All conflicting mitigation 1109 requests are inactive. 1111 conflict-cause: Indicates the cause of the conflict. The 1112 following values are defined: 1114 1: Overlapping targets. 'conflict-scope' provides more details 1115 about the conflicting target clauses. 1117 2: Conflicts with an existing accept-list. This code is 1118 returned when the DDoS mitigation detects source addresses/ 1119 prefixes in the accept-listed ACLs are attacking the 1120 target. 1122 3: CUID Collision. This code is returned when a DOTS client 1123 uses a 'cuid' that is already used by another DOTS client. 1124 This code is an indication that the request has been 1125 rejected and a new request with a new 'cuid' is to be re- 1126 sent by the DOTS client. Note that 'conflict-status', 1127 'conflict-scope', and 'retry-timer' are not returned in the 1128 error response. 1130 conflict-scope: Indicates the conflict scope. It may include a 1131 list of IP addresses, a list of prefixes, a list of port 1132 numbers, a list of target protocols, a list of FQDNs, a list of 1133 URIs, a list of alias-names, or references to conflicting ACLs. 1135 retry-timer: Indicates, in seconds, the time after which the DOTS 1136 client may re-issue the same request. The DOTS server returns 1137 'retry-timer' only to DOTS client(s) for which a mitigation 1138 request is deactivated. Any retransmission of the same 1139 mitigation request before the expiry of this timer is likely to 1140 be rejected by the DOTS server for the same reasons. 1142 The retry-timer SHOULD be equal to the lifetime of the active 1143 mitigation request resulting in the deactivation of the 1144 conflicting mitigation request. The lifetime of the 1145 deactivated mitigation request will be updated to (retry-timer 1146 + 45 seconds), so the DOTS client can refresh the deactivated 1147 mitigation request after retry-timer seconds before expiry of 1148 lifetime and check if the conflict is resolved. 1150 As an active attack evolves, DOTS clients can adjust the scope of 1151 requested mitigation as necessary, by refining the scope of resources 1152 requiring mitigation. This can be achieved by sending a PUT request 1153 with a new 'mid' value that will override the existing one with 1154 overlapping mitigation scopes. 1156 For a mitigation request to continue beyond the initial negotiated 1157 lifetime, the DOTS client has to refresh the current mitigation 1158 request by sending a new PUT request. This PUT request MUST use the 1159 same 'mid' value, and MUST repeat all the other parameters as sent in 1160 the original mitigation request apart from a possible change to the 1161 lifetime parameter value. 1163 4.4.2. Retrieve Information Related to a Mitigation 1165 A GET request is used by a DOTS client to retrieve information 1166 (including status) of DOTS mitigations from a DOTS server. 1168 'cuid' is a mandatory Uri-Path parameter for GET requests. 1170 Uri-Path parameters with empty values MUST NOT be present in a 1171 request. 1173 The same considerations for manipulating 'cdid' parameter by server- 1174 domain DOTS gateways specified in Section 4.4.1 MUST be followed for 1175 GET requests. 1177 The 'c' (content) parameter and its permitted values defined in 1178 [I-D.ietf-core-comi] can be used to retrieve non-configuration data 1179 (attack mitigation status), configuration data, or both. The DOTS 1180 server MAY support this optional filtering capability. It can safely 1181 ignore it if not supported. If the DOTS client supports the optional 1182 filtering capability, it SHOULD use "c=n" query (to get back only the 1183 dynamically changing data) or "c=c" query (to get back the static 1184 configuration values) when the DDoS attack is active to limit the 1185 size of the response. 1187 The DOTS client can use Block-wise transfer [RFC7959] to get the list 1188 of all its mitigations maintained by a DOTS server, it can send 1189 Block2 Option in a GET request with NUM = 0 to aid in limiting the 1190 size of the response. If the representation of all the active 1191 mitigation requests associated with the DOTS client does not fit 1192 within a single datagram, the DOTS server MUST use the Block2 Option 1193 with NUM = 0 in the GET response. The Size2 Option may be conveyed 1194 in the response to indicate the total size of the resource 1195 representation. The DOTS client retrieves the rest of the 1196 representation by sending additional GET requests with Block2 Options 1197 containing NUM values greater than zero. The DOTS client MUST adhere 1198 to the block size preferences indicated by the DOTS server in the 1199 response. If the DOTS server uses the Block2 Option in the GET 1200 response and the response is for a dynamically changing resource 1201 (e.g. "c=n" or "c=a" query), the DOTS server MUST include the ETag 1202 Option in the response. The DOTS client MUST include the same ETag 1203 value in subsequent GET requests to retrieve the rest of the 1204 representation. 1206 The following examples illustrate how a DOTS client retrieves active 1207 mitigation requests from a DOTS server. In particular: 1209 o Figure 10 shows the example of a GET request to retrieve all DOTS 1210 mitigation requests signaled by a DOTS client. 1212 o Figure 11 shows the example of a GET request to retrieve a 1213 specific DOTS mitigation request signaled by a DOTS client. The 1214 configuration data to be reported in the response is formatted in 1215 the same order as was processed by the DOTS server in the original 1216 mitigation request. 1218 These two examples assume the default of "c=a"; that is, the DOTS 1219 client asks for all data to be reported by the DOTS server. 1221 Header: GET (Code=0.01) 1222 Uri-Path: ".well-known" 1223 Uri-Path: "dots" 1224 Uri-Path: "mitigate" 1225 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1226 Observe: 0 1228 Figure 10: GET to Retrieve all DOTS Mitigation Requests 1230 Header: GET (Code=0.01) 1231 Uri-Path: ".well-known" 1232 Uri-Path: "dots" 1233 Uri-Path: "mitigate" 1234 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1235 Uri-Path: "mid=12332" 1236 Observe: 0 1238 Figure 11: GET to Retrieve a Specific DOTS Mitigation Request 1240 If the DOTS server does not find the 'mid' Uri-Path value conveyed in 1241 the GET request in its configuration data for the requesting DOTS 1242 client, it MUST respond with a 4.04 (Not Found) error response code. 1243 Likewise, the same error MUST be returned as a response to a request 1244 to retrieve all mitigation records (i.e., 'mid' Uri-Path is not 1245 defined) of a given DOTS client if the DOTS server does not find any 1246 mitigation record for that DOTS client. As a reminder, a DOTS client 1247 is identified by its identity (e.g., client certificate, 'cuid') and 1248 optionally the 'cdid'. 1250 Figure 12 shows a response example of all active mitigation requests 1251 associated with the DOTS client as maintained by the DOTS server. 1252 The response indicates the mitigation status of each mitigation 1253 request. 1255 { 1256 "ietf-dots-signal-channel:mitigation-scope": { 1257 "scope": [ 1258 { 1259 "mid": 12332, 1260 "mitigation-start": "1507818434", 1261 "target-prefix": [ 1262 "2001:db8:6401::1/128", 1263 "2001:db8:6401::2/128" 1264 ], 1265 "target-protocol": [ 1266 17 1267 ], 1268 "lifetime": 1800, 1269 "status": "attack-successfully-mitigated", 1270 "bytes-dropped": "134334555", 1271 "bps-dropped": "43344", 1272 "pkts-dropped": "333334444", 1273 "pps-dropped": "432432" 1274 }, 1275 { 1276 "mid": 12333, 1277 "mitigation-start": "1507818393", 1278 "target-prefix": [ 1279 "2001:db8:6401::1/128", 1280 "2001:db8:6401::2/128" 1281 ], 1282 "target-protocol": [ 1283 6 1284 ], 1285 "lifetime": 1800, 1286 "status": "attack-stopped", 1287 "bytes-dropped": "0", 1288 "bps-dropped": "0", 1289 "pkts-dropped": "0", 1290 "pps-dropped": "0" 1291 } 1292 ] 1293 } 1294 } 1296 Figure 12: Response Body to a GET Request 1298 The mitigation status parameters are described below: 1300 mitigation-start: Mitigation start time is expressed in seconds 1301 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 1303 [RFC7049]). The CBOR encoding is modified so that the leading tag 1304 1 (epoch-based date/time) MUST be omitted. 1306 This is a mandatory attribute when an attack mitigation is 1307 triggered. Particularly, 'mitigation-start' is not returned for a 1308 mitigation with 'status' code set to 8. 1310 lifetime: The remaining lifetime of the mitigation request, in 1311 seconds. 1313 This is a mandatory attribute. 1315 status: Status of attack mitigation. The various possible values of 1316 'status' parameter are explained in Table 2. 1318 This is a mandatory attribute. 1320 bytes-dropped: The total dropped byte count for the mitigation 1321 request since the attack mitigation is triggered. The count wraps 1322 around when it reaches the maximum value of unsigned integer64. 1324 This is an optional attribute. 1326 bps-dropped: The average number of dropped bytes per second for the 1327 mitigation request since the attack mitigation is triggered. This 1328 SHOULD be a five-minute average. 1330 This is an optional attribute. 1332 pkts-dropped: The total number of dropped packet count for the 1333 mitigation request since the attack mitigation is triggered. The 1334 count wraps around when it reaches the maximum value of unsigned 1335 integer64. 1337 This is an optional attribute. 1339 pps-dropped: The average number of dropped packets per second for 1340 the mitigation request since the attack mitigation is triggered. 1341 This SHOULD be a five-minute average. 1343 This is an optional attribute. 1345 +-----------+-------------------------------------------------------+ 1346 | Parameter | Description | 1347 | Value | | 1348 +-----------+-------------------------------------------------------+ 1349 | 1 | Attack mitigation setup is in progress (e.g., | 1350 | | changing the network path to redirect the inbound | 1351 | | traffic to a DOTS mitigator). | 1352 +-----------+-------------------------------------------------------+ 1353 | 2 | Attack is being successfully mitigated (e.g., traffic | 1354 | | is redirected to a DDoS mitigator and attack traffic | 1355 | | is dropped). | 1356 +-----------+-------------------------------------------------------+ 1357 | 3 | Attack has stopped and the DOTS client can withdraw | 1358 | | the mitigation request. This status code will be | 1359 | | transmitted for immediate mitigation requests till | 1360 | | the mitigation is withdrawn or the lifetime expires. | 1361 | | For mitigation requests with pre-configured scopes | 1362 | | (i.e., 'trigger-mitigation' set to 'false'), this | 1363 | | status code will be transmitted 4 times and then | 1364 | | transition to "8". | 1365 +-----------+-------------------------------------------------------+ 1366 | 4 | Attack has exceeded the mitigation provider | 1367 | | capability. | 1368 +-----------+-------------------------------------------------------+ 1369 | 5 | DOTS client has withdrawn the mitigation request and | 1370 | | the mitigation is active but terminating. | 1371 +-----------+-------------------------------------------------------+ 1372 | 6 | Attack mitigation is now terminated. | 1373 +-----------+-------------------------------------------------------+ 1374 | 7 | Attack mitigation is withdrawn. If a mitigation | 1375 | | request with 'trigger-mitigation' set to false is | 1376 | | withdrawn because it overlaps with an immediate | 1377 | | mitigation request, this status code will be | 1378 | | transmitted 4 times and then transition to "8" for | 1379 | | the mitigation request with pre-configured scopes. | 1380 +-----------+-------------------------------------------------------+ 1381 | 8 | Attack mitigation will be triggered for the | 1382 | | mitigation request only when the DOTS signal channel | 1383 | | session is lost. | 1384 +-----------+-------------------------------------------------------+ 1386 Table 2: Values of 'status' Parameter 1388 4.4.2.1. DOTS Servers Sending Mitigation Status 1390 The Observe Option defined in [RFC7641] extends the CoAP core 1391 protocol with a mechanism for a CoAP client to "observe" a resource 1392 on a CoAP server: The client retrieves a representation of the 1393 resource and requests this representation be updated by the server as 1394 long as the client is interested in the resource. DOTS 1395 implementations MUST use the Observe Option for both 'mitigate' and 1396 'config' (Section 4.2). 1398 A DOTS client conveys the Observe Option set to '0' in the GET 1399 request to receive asynchronous notifications of attack mitigation 1400 status from the DOTS server. 1402 Unidirectional mitigation notifications within the bidirectional 1403 signal channel enables asynchronous notifications between the agents. 1404 [RFC7641] indicates that (1) a notification can be sent in a 1405 Confirmable (CON) or a Non-confirmable (NON) message, and (2) the 1406 message type used is typically application dependent and may be 1407 determined by the server for each notification individually. For 1408 DOTS server application, the message type MUST always be set to Non- 1409 confirmable even if the underlying COAP library elects a notification 1410 to be sent in a Confirmable message. 1412 Due to the higher likelihood of packet loss during a DDoS attack, the 1413 DOTS server periodically sends attack mitigation status to the DOTS 1414 client and also notifies the DOTS client whenever the status of the 1415 attack mitigation changes. If the DOTS server cannot maintain an RTT 1416 estimate, it SHOULD NOT send more than one asynchronous notification 1417 every 3 seconds, and SHOULD use an even less aggressive rate whenever 1418 possible (case 2 in Section 3.1.3 of [RFC8085]). 1420 When conflicting requests are detected, the DOTS server enforces the 1421 corresponding policy (e.g., accept all requests, reject all requests, 1422 accept only one request but reject all the others, ...). It is 1423 assumed that this policy is supplied by the DOTS server administrator 1424 or it is a default behavior of the DOTS server implementation. Then, 1425 the DOTS server sends notification message(s) to the DOTS client(s) 1426 at the origin of the conflict (refer to the conflict parameters 1427 defined in Section 4.4.1). A conflict notification message includes 1428 information about the conflict cause, scope, and the status of the 1429 mitigation request(s). For example, 1431 o A notification message with 'status' code set to '7 (Attack 1432 mitigation is withdrawn)' and 'conflict-status' set to '1' is sent 1433 to a DOTS client to indicate that an active mitigation request is 1434 deactivated because a conflict is detected. 1436 o A notification message with 'status' code set to '1 (Attack 1437 mitigation is in progress)' and 'conflict-status' set to '2' is 1438 sent to a DOTS client to indicate that this mitigation request is 1439 in progress, but a conflict is detected. 1441 Upon receipt of a conflict notification message indicating that a 1442 mitigation request is deactivated because of a conflict, a DOTS 1443 client MUST NOT resend the same mitigation request before the expiry 1444 of 'retry-timer'. It is also recommended that DOTS clients support 1445 means to alert administrators about mitigation conflicts. 1447 A DOTS client that is no longer interested in receiving notifications 1448 from the DOTS server can simply "forget" the observation. When the 1449 DOTS server sends the next notification, the DOTS client will not 1450 recognize the token in the message and thus will return a Reset 1451 message. This causes the DOTS server to remove the associated entry. 1452 Alternatively, the DOTS client can explicitly deregister itself by 1453 issuing a GET request that has the Token field set to the token of 1454 the observation to be cancelled and includes an Observe Option with 1455 the value set to '1' (deregister). 1457 Figure 13 shows an example of a DOTS client requesting a DOTS server 1458 to send notifications related to a mitigation request. Note that for 1459 mitigations with pre-configured scopes (i.e., 'trigger-mitigation' 1460 set to 'false'), the state will need to transition from 3 (attack- 1461 stopped) to 8 (attack-mitigation-signal-loss). 1463 +-----------+ +-----------+ 1464 |DOTS client| |DOTS server| 1465 +-----------+ +-----------+ 1466 | | 1467 | GET / | 1468 | Token: 0x4a | Registration 1469 | Observe: 0 | 1470 +----------------------------------------->| 1471 | | 1472 | 2.05 Content | 1473 | Token: 0x4a | Notification of 1474 | Observe: 12 | the current state 1475 | status: "attack-mitigation-in-progress" | 1476 | | 1477 |<-----------------------------------------+ 1478 | 2.05 Content | 1479 | Token: 0x4a | Notification upon 1480 | Observe: 44 | a state change 1481 | status: "attack-successfully-mitigated" | 1482 | | 1483 |<-----------------------------------------+ 1484 | 2.05 Content | 1485 | Token: 0x4a | Notification upon 1486 | Observe: 60 | a state change 1487 | status: "attack-stopped" | 1488 |<-----------------------------------------+ 1489 | | 1490 ... 1492 Figure 13: Notifications of Attack Mitigation Status 1494 4.4.2.2. DOTS Clients Polling for Mitigation Status 1496 The DOTS client can send the GET request at frequent intervals 1497 without the Observe Option to retrieve the configuration data of the 1498 mitigation request and non-configuration data (i.e., the attack 1499 status). The frequency of polling the DOTS server to get the 1500 mitigation status SHOULD follow the transmission guidelines in 1501 Section 3.1.3 of [RFC8085]. 1503 If the DOTS server has been able to mitigate the attack and the 1504 attack has stopped, the DOTS server indicates as such in the status. 1505 In such case, the DOTS client recalls the mitigation request by 1506 issuing a DELETE request for this mitigation request (Section 4.4.4). 1508 A DOTS client SHOULD react to the status of the attack as per the 1509 information sent by the DOTS server rather than acknowledging by 1510 itself, using its own means, that the attack has been mitigated. 1512 This ensures that the DOTS client does not recall a mitigation 1513 request prematurely because it is possible that the DOTS client does 1514 not sense the DDoS attack on its resources, but the DOTS server could 1515 be actively mitigating the attack because the attack is not 1516 completely averted. 1518 4.4.3. Efficacy Update from DOTS Clients 1520 While DDoS mitigation is in progress, due to the likelihood of packet 1521 loss, a DOTS client MAY periodically transmit DOTS mitigation 1522 efficacy updates to the relevant DOTS server. A PUT request is used 1523 to convey the mitigation efficacy update to the DOTS server. This 1524 PUT request is treated as a refresh of the current mitigation. 1526 The PUT request used for efficacy update MUST include all the 1527 parameters used in the PUT request to carry the DOTS mitigation 1528 request (Section 4.4.1) unchanged apart from the 'lifetime' parameter 1529 value. If this is not the case, the DOTS server MUST reject the 1530 request with a 4.00 (Bad Request). 1532 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1533 value is used to make the PUT request conditional on the current 1534 existence of the mitigation request. If UDP is used as transport, 1535 CoAP requests may arrive out-of-order. For example, the DOTS client 1536 may send a PUT request to convey an efficacy update to the DOTS 1537 server followed by a DELETE request to withdraw the mitigation 1538 request, but the DELETE request arrives at the DOTS server before the 1539 PUT request. To handle out-of-order delivery of requests, if an If- 1540 Match Option is present in the PUT request and the 'mid' in the 1541 request matches a mitigation request from that DOTS client, the 1542 request is processed by the DOTS server. If no match is found, the 1543 PUT request is silently ignored by the DOTS server. 1545 An example of an efficacy update message, which includes an If-Match 1546 Option with an empty value, is depicted in Figure 14. 1548 Header: PUT (Code=0.03) 1549 Uri-Path: ".well-known" 1550 Uri-Path: "dots" 1551 Uri-Path: "mitigate" 1552 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1553 Uri-Path: "mid=123" 1554 Content-Format: "application/dots+cbor" 1555 If-Match: 1556 { 1557 "ietf-dots-signal-channel:mitigation-scope": { 1558 "scope": [ 1559 { 1560 "target-prefix": [ 1561 "string" 1562 ], 1563 "target-port-range": [ 1564 { 1565 "lower-port": number, 1566 "upper-port": number 1567 } 1568 ], 1569 "target-protocol": [ 1570 number 1571 ], 1572 "target-fqdn": [ 1573 "string" 1574 ], 1575 "target-uri": [ 1576 "string" 1577 ], 1578 "alias-name": [ 1579 "string" 1580 ], 1581 "lifetime": number, 1582 "attack-status": "string" 1583 } 1584 ] 1585 } 1586 } 1588 Figure 14: Efficacy Update 1590 The 'attack-status' parameter is a mandatory attribute when 1591 performing an efficacy update. The various possible values contained 1592 in the 'attack-status' parameter are described in Table 3. 1594 +---------------------------------+---------------------------------+ 1595 | Parameter value | Description | 1596 +---------------------------------+---------------------------------+ 1597 | 1 (under-attack) | The DOTS client determines that | 1598 | | it is still under attack. | 1599 +---------------------------------+---------------------------------+ 1600 | 2 (attack-successfully- | The DOTS client determines that | 1601 | mitigated) | the attack is successfully | 1602 | | mitigated (e.g., attack traffic | 1603 | | is not seen). | 1604 +---------------------------------+---------------------------------+ 1606 Table 3: Values of 'attack-status' Parameter 1608 The DOTS server indicates the result of processing a PUT request 1609 using CoAP response codes. The response code 2.04 (Changed) is 1610 returned if the DOTS server has accepted the mitigation efficacy 1611 update. The error response code 5.03 (Service Unavailable) is 1612 returned if the DOTS server has erred or is incapable of performing 1613 the mitigation. 1615 4.4.4. Withdraw a Mitigation 1617 DELETE requests are used to withdraw DOTS mitigation requests from 1618 DOTS servers (Figure 15). 1620 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE 1621 requests. 1623 The same considerations for manipulating 'cdid' parameter by DOTS 1624 gateways, as specified in Section 4.4.1, MUST be followed for DELETE 1625 requests. Uri-Path parameters with empty values MUST NOT be present 1626 in a request. 1628 Header: DELETE (Code=0.04) 1629 Uri-Path: ".well-known" 1630 Uri-Path: "dots" 1631 Uri-Path: "mitigate" 1632 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1633 Uri-Path: "mid=123" 1635 Figure 15: Withdraw a DOTS Mitigation 1637 If the DELETE request does not include 'cuid' and 'mid' parameters, 1638 the DOTS server MUST reply with a 4.00 (Bad Request). 1640 Once the request is validated, the DOTS server immediately 1641 acknowledges a DOTS client's request to withdraw the DOTS signal 1642 using 2.02 (Deleted) response code with no response payload. A 2.02 1643 (Deleted) Response Code is returned even if the 'mid' parameter value 1644 conveyed in the DELETE request does not exist in its configuration 1645 data before the request. 1647 If the DOTS server finds the 'mid' parameter value conveyed in the 1648 DELETE request in its configuration data for the DOTS client, then to 1649 protect against route or DNS flapping caused by a DOTS client rapidly 1650 removing a mitigation, and to dampen the effect of oscillating 1651 attacks, the DOTS server MAY allow mitigation to continue for a 1652 limited period after acknowledging a DOTS client's withdrawal of a 1653 mitigation request. During this period, the DOTS server status 1654 messages SHOULD indicate that mitigation is active but terminating 1655 (Section 4.4.2). 1657 The initial active-but-terminating period SHOULD be sufficiently long 1658 to absorb latency incurred by route propagation. The active-but- 1659 terminating period SHOULD be set by default to 120 seconds. If the 1660 client requests mitigation again before the initial active-but- 1661 terminating period elapses, the DOTS server MAY exponentially 1662 increase the active-but-terminating period up to a maximum of 300 1663 seconds (5 minutes). 1665 Once the active-but-terminating period elapses, the DOTS server MUST 1666 treat the mitigation as terminated, as the DOTS client is no longer 1667 responsible for the mitigation. For example, if there is a financial 1668 relationship between the DOTS client and server domains, the DOTS 1669 client stops incurring cost at this point. 1671 If a mitigation is triggered due to a signal channel loss, the DOTS 1672 server relies upon normal triggers to stop that mitigation 1673 (typically, receipt of a valid DELETE request, expiry of the 1674 mitigation lifetime, or observation of traffic to the attack target). 1675 In particular, the DOTS server MUST NOT consider the signal channel 1676 recovery as a trigger to stop the mitigation. 1678 4.5. DOTS Signal Channel Session Configuration 1680 A DOTS client can negotiate, configure, and retrieve the DOTS signal 1681 channel session behavior with its DOTS peers. The DOTS signal 1682 channel can be used, for example, to configure the following: 1684 a. Heartbeat interval (heartbeat-interval): DOTS agents regularly 1685 send heartbeats (CoAP Ping/Pong) to each other after mutual 1686 authentication is successfully completed in order to keep the 1687 DOTS signal channel open. Heartbeat messages are exchanged 1688 between DOTS agents every 'heartbeat-interval' seconds to detect 1689 the current status of the DOTS signal channel session. 1691 b. Missing heartbeats allowed (missing-hb-allowed): This variable 1692 indicates the maximum number of consecutive heartbeat messages 1693 for which a DOTS agent did not receive a response before 1694 concluding that the session is disconnected or defunct. 1696 c. Acceptable signal loss ratio: Maximum retransmissions, 1697 retransmission timeout value, and other message transmission 1698 parameters for the DOTS signal channel. 1700 The same or distinct configuration sets may be used during times when 1701 a mitigation is active ('mitigating-config') and when no mitigation 1702 is active ('idle-config'). This is particularly useful for DOTS 1703 servers that might want to reduce heartbeat frequency or cease 1704 heartbeat exchanges when an active DOTS client has not requested 1705 mitigation. If distinct configurations are used, DOTS agents MUST 1706 follow the appropriate configuration set as a function of the 1707 mitigation activity (e.g., if no mitigation request is active, 'idle- 1708 config'-related values must be followed). Additionally, DOTS agents 1709 MUST automatically switch to the other configuration upon a change in 1710 the mitigation activity (e.g., if an attack mitigation is launched 1711 after a peacetime, the DOTS agent switches from 'idle-config' to 1712 'mitigating-config'-related values). 1714 Requests and responses are deemed reliable by marking them as 1715 Confirmable messages. DOTS signal channel session configuration 1716 requests and responses are marked as Confirmable messages. As 1717 explained in Section 2.1 of [RFC7252], a Confirmable message is 1718 retransmitted using a default timeout and exponential back-off 1719 between retransmissions, until the DOTS server sends an 1720 Acknowledgement message (ACK) with the same Message ID conveyed from 1721 the DOTS client. 1723 Message transmission parameters are defined in Section 4.8 of 1724 [RFC7252]. The DOTS server can either piggyback the response in the 1725 acknowledgement message or, if the DOTS server cannot respond 1726 immediately to a request carried in a Confirmable message, it simply 1727 responds with an Empty Acknowledgement message so that the DOTS 1728 client can stop retransmitting the request. Empty Acknowledgement 1729 message is explained in Section 2.2 of [RFC7252]. When the response 1730 is ready, the server sends it in a new Confirmable message which in 1731 turn needs to be acknowledged by the DOTS client (see Sections 5.2.1 1732 and 5.2.2 of [RFC7252]). Requests and responses exchanged between 1733 DOTS agents during peacetime are marked as Confirmable messages. 1735 Implementation Note: A DOTS client that receives a response in a 1736 CON message may want to clean up the message state right after 1737 sending the ACK. If that ACK is lost and the DOTS server 1738 retransmits the CON, the DOTS client may no longer have any state 1739 that would help it correlate this response: from the DOTS client's 1740 standpoint, the retransmission message is unexpected. The DOTS 1741 client will send a Reset message so it does not receive any more 1742 retransmissions. This behavior is normal and not an indication of 1743 an error (see Section 5.3.2 of [RFC7252] for more details). 1745 4.5.1. Discover Configuration Parameters 1747 A GET request is used to obtain acceptable (e.g., minimum and maximum 1748 values) and current configuration parameters on the DOTS server for 1749 DOTS signal channel session configuration. This procedure occurs 1750 between a DOTS client and its immediate peer DOTS server. As such, 1751 this GET request MUST NOT be relayed by an on-path DOTS gateway. 1753 Figure 16 shows how to obtain acceptable configuration parameters for 1754 the DOTS server. 1756 Header: GET (Code=0.01) 1757 Uri-Path: ".well-known" 1758 Uri-Path: "dots" 1759 Uri-Path: "config" 1761 Figure 16: GET to Retrieve Configuration 1763 The DOTS server in the 2.05 (Content) response conveys the current, 1764 minimum, and maximum attribute values acceptable by the DOTS server 1765 (Figure 17). 1767 Content-Format: "application/dots+cbor" 1768 { 1769 "ietf-dots-signal-channel:signal-config": { 1770 "mitigating-config": { 1771 "heartbeat-interval": { 1772 "max-value": number, 1773 "min-value": number, 1774 "current-value": number 1775 }, 1776 "missing-hb-allowed": { 1777 "max-value": number, 1778 "min-value": number, 1779 "current-value": number 1780 }, 1781 "max-retransmit": { 1782 "max-value": number, 1783 "min-value": number, 1784 "current-value": number 1785 }, 1786 "ack-timeout": { 1787 "max-value-decimal": "string", 1788 "min-value-decimal": "string", 1789 "current-value-decimal": "string" 1790 }, 1791 "ack-random-factor": { 1792 "max-value-decimal": "string", 1793 "min-value-decimal": "string", 1794 "current-value-decimal": "string" 1795 } 1796 }, 1797 "idle-config": { 1798 "heartbeat-interval": { 1799 "max-value": number, 1800 "min-value": number, 1801 "current-value": number 1802 }, 1803 "missing-hb-allowed": { 1804 "max-value": number, 1805 "min-value": number, 1806 "current-value": number 1807 }, 1808 "max-retransmit": { 1809 "max-value": number, 1810 "min-value": number, 1811 "current-value": number 1812 }, 1813 "ack-timeout": { 1814 "max-value-decimal": "string", 1815 "min-value-decimal": "string", 1816 "current-value-decimal": "string" 1817 }, 1818 "ack-random-factor": { 1819 "max-value-decimal": "string", 1820 "min-value-decimal": "string", 1821 "current-value-decimal": "string" 1822 } 1823 } 1824 } 1825 } 1827 Figure 17: GET Configuration Response Body 1829 The parameters in Figure 17 are described below: 1831 mitigating-config: Set of configuration parameters to use when a 1832 mitigation is active. The following parameters may be included: 1834 heartbeat-interval: Time interval in seconds between two 1835 consecutive heartbeat messages. 1837 '0' is used to disable the heartbeat mechanism. 1839 This is an optional attribute. 1841 missing-hb-allowed: Maximum number of consecutive heartbeat 1842 messages for which the DOTS agent did not receive a response 1843 before concluding that the session is disconnected. 1845 This is an optional attribute. 1847 max-retransmit: Maximum number of retransmissions for a message 1848 (referred to as MAX_RETRANSMIT parameter in CoAP). 1850 This is an optional attribute. 1852 ack-timeout: Timeout value in seconds used to calculate the 1853 initial retransmission timeout value (referred to as 1854 ACK_TIMEOUT parameter in CoAP). 1856 This is an optional attribute. 1858 ack-random-factor: Random factor used to influence the timing of 1859 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1860 CoAP). 1862 This is an optional attribute. 1864 idle-config: Set of configuration parameters to use when no 1865 mitigation is active. This attribute has the same structure as 1866 'mitigating-config'. 1868 Figure 18 shows an example of acceptable and current configuration 1869 parameters on a DOTS server for DOTS signal channel session 1870 configuration. The same acceptable configuration is used during 1871 attack and peace times. 1873 Content-Format: "application/dots+cbor" 1874 { 1875 "ietf-dots-signal-channel:signal-config": { 1876 "mitigating-config": { 1877 "heartbeat-interval": { 1878 "max-value": 240, 1879 "min-value": 15, 1880 "current-value": 30 1881 }, 1882 "missing-hb-allowed": { 1883 "max-value": 9, 1884 "min-value": 3, 1885 "current-value": 5 1886 }, 1887 "max-retransmit": { 1888 "max-value": 15, 1889 "min-value": 2, 1890 "current-value": 3 1891 }, 1892 "ack-timeout": { 1893 "max-value-decimal": "30.0", 1894 "min-value-decimal": "1.0", 1895 "current-value-decimal": "2.0" 1896 }, 1897 "ack-random-factor": { 1898 "max-value-decimal": "4.0", 1899 "min-value-decimal": "1.1", 1900 "current-value-decimal": "1.5" 1901 } 1902 }, 1903 "idle-config": { 1904 "heartbeat-interval": { 1905 "max-value": 240, 1906 "min-value": 15, 1907 "current-value": 30 1908 }, 1909 "missing-hb-allowed": { 1910 "max-value": 9, 1911 "min-value": 3, 1912 "current-value": 5 1913 }, 1914 "max-retransmit": { 1915 "max-value": 15, 1916 "min-value": 2, 1917 "current-value": 3 1918 }, 1919 "ack-timeout": { 1920 "max-value-decimal": "30.0", 1921 "min-value-decimal": "1.0", 1922 "current-value-decimal": "2.0" 1923 }, 1924 "ack-random-factor": { 1925 "max-value-decimal": "4.0", 1926 "min-value-decimal": "1.1", 1927 "current-value-decimal": "1.5" 1928 } 1929 } 1931 } 1932 } 1934 Figure 18: Example of a Configuration Response Body 1936 4.5.2. Convey DOTS Signal Channel Session Configuration 1938 A PUT request is used to convey the configuration parameters for the 1939 signal channel (e.g., heartbeat interval, maximum retransmissions). 1940 Message transmission parameters for CoAP are defined in Section 4.8 1941 of [RFC7252]. The RECOMMENDED values of transmission parameter 1942 values are ack-timeout (2 seconds), max-retransmit (3), ack-random- 1943 factor (1.5). In addition to those parameters, the RECOMMENDED 1944 specific DOTS transmission parameter values are 'heartbeat-interval' 1945 (30 seconds) and 'missing-hb-allowed' (5). 1947 Note: heartbeat-interval should be tweaked to also assist DOTS 1948 messages for NAT traversal (SIG-011 of 1949 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 1950 messages must not be sent more frequently than once every 15 1951 seconds and should use longer intervals when possible. 1952 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 1953 minutes or longer, but experience shows that sending packets every 1954 15 to 30 seconds is necessary to prevent the majority of 1955 middleboxes from losing state for UDP flows. From that 1956 standpoint, this specification recommends a minimum heartbeat- 1957 interval of 15 seconds and a maximum heartbeat-interval of 240 1958 seconds. The recommended value of 30 seconds is selected to 1959 anticipate the expiry of NAT state. 1961 A heartbeat-interval of 30 seconds may be considered as too chatty 1962 in some deployments. For such deployments, DOTS agents may 1963 negotiate longer heartbeat-interval values to prevent any network 1964 overload with too frequent keepalives. 1966 Different heartbeat intervals can be defined for 'mitigating- 1967 config' and 'idle-config' to reduce being too chatty during idle 1968 times. If there is an on-path translator between the DOTS client 1969 (standalone or part of a DOTS gateway) and the DOTS server, the 1970 'mitigating-config' heartbeat-interval has to be smaller than the 1971 translator session timeout. It is recommended that the 'idle- 1972 config' heartbeat-interval is also smaller than the translator 1973 session timeout to prevent translator traversal issues, or set to 1974 '0'. Means to discover the lifetime assigned by a translator are 1975 out of scope. 1977 When a Confirmable "CoAP Ping" is sent, and if there is no response, 1978 the "CoAP Ping" is retransmitted max-retransmit number of times by 1979 the CoAP layer using an initial timeout set to a random duration 1980 between ack-timeout and (ack-timeout*ack-random-factor) and 1981 exponential back-off between retransmissions. By choosing the 1982 recommended transmission parameters, the "CoAP Ping" will timeout 1983 after 45 seconds. If the DOTS agent does not receive any response 1984 from the peer DOTS agent for 'missing-hb-allowed' number of 1985 consecutive "CoAP Ping" Confirmable messages, it concludes that the 1986 DOTS signal channel session is disconnected. A DOTS client MUST NOT 1987 transmit a "CoAP Ping" while waiting for the previous "CoAP Ping" 1988 response from the same DOTS server. 1990 If the DOTS agent wishes to change the default values of message 1991 transmission parameters, it SHOULD follow the guidance given in 1992 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 1993 values for message transmission parameters and default values for 1994 non-negotiated message transmission parameters. 1996 The signal channel session configuration is applicable to a single 1997 DOTS signal channel session between DOTS agents, so the 'cuid' Uri- 1998 Path MUST NOT be used. 2000 Header: PUT (Code=0.03) 2001 Uri-Path: ".well-known" 2002 Uri-Path: "dots" 2003 Uri-Path: "config" 2004 Uri-Path: "sid=123" 2005 Content-Format: "application/dots+cbor" 2006 { 2007 "ietf-dots-signal-channel:signal-config": { 2008 "mitigating-config": { 2009 "heartbeat-interval": { 2010 "current-value": number 2011 }, 2012 "missing-hb-allowed": { 2013 "current-value": number 2014 }, 2015 "max-retransmit": { 2016 "current-value": number 2017 }, 2018 "ack-timeout": { 2019 "current-value-decimal": "string" 2020 }, 2021 "ack-random-factor": { 2022 "current-value-decimal": "string" 2023 } 2024 }, 2025 "idle-config": { 2026 "heartbeat-interval": { 2027 "current-value": number 2028 }, 2029 "missing-hb-allowed": { 2030 "current-value": number 2031 }, 2032 "max-retransmit": { 2033 "current-value": number 2034 }, 2035 "ack-timeout": { 2036 "current-value-decimal": "string" 2037 }, 2038 "ack-random-factor": { 2039 "current-value-decimal": "string" 2040 } 2041 } 2042 } 2043 } 2045 Figure 19: PUT to Convey the DOTS Signal Channel Session 2046 Configuration Data 2048 The additional Uri-Path parameter to those defined in Table 1 is as 2049 follows: 2051 sid: Session Identifier is an identifier for the DOTS signal channel 2052 session configuration data represented as an integer. This 2053 identifier MUST be generated by DOTS clients. 'sid' values MUST 2054 increase monotonically. 2056 This is a mandatory attribute. 2058 The meaning of the parameters in the CBOR body is defined in 2059 Section 4.5.1. 2061 At least one of the attributes 'heartbeat-interval', 'missing-hb- 2062 allowed', 'max-retransmit', 'ack-timeout', and 'ack-random-factor' 2063 MUST be present in the PUT request. Note that 'heartbeat-interval', 2064 'missing-hb-allowed', 'max-retransmit', 'ack-timeout', and 'ack- 2065 random-factor', if present, do not need to be provided for both 2066 'mitigating-config', and 'idle-config' in a PUT request. 2068 The PUT request with a higher numeric 'sid' value overrides the DOTS 2069 signal channel session configuration data installed by a PUT request 2070 with a lower numeric 'sid' value. To avoid maintaining a long list 2071 of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be 2072 automatically deleted and no longer available at the DOTS server. 2074 Figure 20 shows a PUT request example to convey the configuration 2075 parameters for the DOTS signal channel. In this example, the 2076 heartbeat mechanism is disabled when no mitigation is active, while 2077 the heartbeat interval is set to '91' when a mitigation is active. 2079 Header: PUT (Code=0.03) 2080 Uri-Path: ".well-known" 2081 Uri-Path: "dots" 2082 Uri-Path: "config" 2083 Uri-Path: "sid=123" 2084 Content-Format: "application/dots+cbor" 2085 { 2086 "ietf-dots-signal-channel:signal-config": { 2087 "mitigating-config": { 2088 "heartbeat-interval": { 2089 "current-value": 91 2090 }, 2091 "missing-hb-allowed": { 2092 "current-value": 3 2093 }, 2094 "max-retransmit": { 2095 "current-value": 3 2096 }, 2097 "ack-timeout": { 2098 "current-value-decimal": "2.0" 2099 }, 2100 "ack-random-factor": { 2101 "current-value-decimal": "1.5" 2102 } 2103 }, 2104 "idle-config": { 2105 "heartbeat-interval": { 2106 "current-value": 0 2107 }, 2108 "max-retransmit": { 2109 "current-value": 3 2110 }, 2111 "ack-timeout": { 2112 "current-value-decimal": "2.0" 2113 }, 2114 "ack-random-factor": { 2115 "current-value-decimal": "1.5" 2116 } 2117 } 2118 } 2119 } 2121 Figure 20: PUT to Convey the Configuration Parameters 2123 The DOTS server indicates the result of processing the PUT request 2124 using CoAP response codes: 2126 o If the request is missing a mandatory attribute, does not include 2127 a 'sid' Uri-Path, or contains one or more invalid or unknown 2128 parameters, 4.00 (Bad Request) MUST be returned in the response. 2130 o If the DOTS server does not find the 'sid' parameter value 2131 conveyed in the PUT request in its configuration data and if the 2132 DOTS server has accepted the configuration parameters, then a 2133 response code 2.01 (Created) MUST be returned in the response. 2135 o If the DOTS server finds the 'sid' parameter value conveyed in the 2136 PUT request in its configuration data and if the DOTS server has 2137 accepted the updated configuration parameters, 2.04 (Changed) MUST 2138 be returned in the response. 2140 o If any of the 'heartbeat-interval', 'missing-hb-allowed', 'max- 2141 retransmit', 'target-protocol', 'ack-timeout', and 'ack-random- 2142 factor' attribute values are not acceptable to the DOTS server, 2143 4.22 (Unprocessable Entity) MUST be returned in the response. 2144 Upon receipt of this error code, the DOTS client SHOULD request 2145 the maximum and minimum attribute values acceptable to the DOTS 2146 server (Section 4.5.1). 2148 The DOTS client may re-try and send the PUT request with updated 2149 attribute values acceptable to the DOTS server. 2151 A DOTS client may issue a GET message with 'sid' Uri-Path parameter 2152 to retrieve the negotiated configuration. The response does not need 2153 to include 'sid' in its message body. 2155 4.5.3. Configuration Freshness and Notifications 2157 Max-Age Option (Section 5.10.5 of [RFC7252]) SHOULD be returned by a 2158 DOTS server to associate a validity time with a configuration it 2159 sends. This feature allows the update of the configuration data if a 2160 change occurs at the DOTS server side. For example, the new 2161 configuration may instruct a DOTS client to cease heartbeats or 2162 reduce heartbeat frequency. 2164 It is NOT RECOMMENDED to return a Max-Age Option set to 0. 2166 Returning a Max-Age Option set to 2**32-1 is equivalent to 2167 associating an infinite lifetime with the configuration. 2169 If a non-zero value of Max-Age Option is received by a DOTS client, 2170 it MUST issue a GET request with 'sid' Uri-Path parameter to retrieve 2171 the current and acceptable configuration before the expiry of the 2172 value enclosed in the Max-Age option. This request is considered by 2173 the client and the server as a means to refresh the configuration 2174 parameters for the signal channel. When a DDoS attack is active, 2175 refresh requests MUST NOT be sent by DOTS clients and the DOTS server 2176 MUST NOT terminate the (D)TLS session after the expiry of the value 2177 returned in Max-Age Option. 2179 If Max-Age Option is not returned in a response, the DOTS client 2180 initiates GET requests to refresh the configuration parameters each 2181 60 seconds (Section 5.10.5 of [RFC7252]). To prevent such overload, 2182 it is RECOMMENDED that DOTS servers return a Max-Age Option in GET 2183 responses. Considerations related to which value to use and how such 2184 value is set, are implementation- and deployment-specific. 2186 If an Observe Option set to 0 is included in the configuration 2187 request, the DOTS server sends notifications of any configuration 2188 change (Section 4.2 of [RFC7641]). 2190 If a DOTS server detects that a misbehaving DOTS client does not 2191 contact the DOTS server after the expiry of Max-Age, in order to 2192 retrieve the signal channel configuration data, it MAY terminate the 2193 (D)TLS session. A (D)TLS session is terminated by the receipt of an 2194 authenticated message that closes the connection (e.g., a fatal alert 2195 (Section 6 of [RFC8446])). 2197 4.5.4. Delete DOTS Signal Channel Session Configuration 2199 A DELETE request is used to delete the installed DOTS signal channel 2200 session configuration data (Figure 21). 2202 Header: DELETE (Code=0.04) 2203 Uri-Path: ".well-known" 2204 Uri-Path: "dots" 2205 Uri-Path: "config" 2206 Uri-Path: "sid=123" 2208 Figure 21: Delete Configuration 2210 The DOTS server resets the DOTS signal channel session configuration 2211 back to the default values and acknowledges a DOTS client's request 2212 to remove the DOTS signal channel session configuration using 2.02 2213 (Deleted) response code. 2215 Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request 2216 to set the configuration parameters to default values. Such a 2217 request does not include any 'sid'. 2219 4.6. Redirected Signaling 2221 Redirected DOTS signaling is discussed in detail in Section 3.2.2 of 2222 [I-D.ietf-dots-architecture]. 2224 If a DOTS server wants to redirect a DOTS client to an alternative 2225 DOTS server for a signal session, then the response code 5.03 2226 (Service Unavailable) will be returned in the response to the DOTS 2227 client. 2229 The DOTS server can return the error response code 5.03 in response 2230 to a request from the DOTS client or convey the error response code 2231 5.03 in a unidirectional notification response from the DOTS server. 2233 The DOTS server in the error response conveys the alternate DOTS 2234 server's FQDN, and the alternate DOTS server's IP address(es) values 2235 in the CBOR body (Figure 22). 2237 { 2238 "ietf-dots-signal-channel:redirected-signal": { 2239 "alt-server": "string", 2240 "alt-server-record": [ 2241 "string" 2242 ] 2243 } 2245 Figure 22: Redirected Server Error Response Body 2247 The parameters are described below: 2249 alt-server: FQDN of an alternate DOTS server. 2251 This is a mandatory attribute. 2253 alt-server-record: A list of IP addresses of an alternate DOTS 2254 server. 2256 This is an optional attribute. 2258 The DOTS server returns the Time to live (TTL) of the alternate DOTS 2259 server in a Max-Age Option. That is, the time interval that the 2260 alternate DOTS server may be cached for use by a DOTS client. A Max- 2261 Age Option set to 2**32-1 is equivalent to receiving an infinite TTL. 2262 This value means that the alternate DOTS server is to be used until 2263 the alternate DOTS server redirects the traffic with another 5.03 2264 response which encloses an alternate server. 2266 A Max-Age Option set to '0' may be returned for redirecting 2267 mitigation requests. Such value means that the redirection applies 2268 only for the mitigation request in progress. Returning short TTL in 2269 a Max-Age Option may adversely impact DOTS clients on slow links. 2270 Returning short values should be avoided under such conditions. 2272 If the alternate DOTS server TTL has expired, the DOTS client MUST 2273 use the DOTS server(s), that was provisioned using means discussed in 2274 Section 4.1. This fall back mechanism is triggered immediately upon 2275 expiry of the TTL, except when a DDoS attack is active. 2277 Requests issued by misbehaving DOTS clients which do not honor the 2278 TTL conveyed in the Max-Age Option or react to explicit re-direct 2279 messages can be rejected by DOTS servers. 2281 Figure 23 shows a 5.03 response example to convey the DOTS alternate 2282 server 'alt-server.example' together with its IP addresses 2283 2001:db8:6401::1 and 2001:db8:6401::2. 2285 { 2286 "ietf-dots-signal-channel:redirected-signal": { 2287 "alt-server": "alt-server.example", 2288 "alt-server-record": [ 2289 "2001:db8:6401::1", 2290 "2001:db8:6401::2" 2291 ] 2292 } 2294 Figure 23: Example of Redirected Server Error Response Body 2296 When the DOTS client receives 5.03 response with an alternate server 2297 included, it considers the current request as failed, but SHOULD try 2298 re-sending the request to the alternate DOTS server. During a DDoS 2299 attack, the DNS server may be the target of another DDoS attack, 2300 alternate DOTS server's IP addresses conveyed in the 5.03 response 2301 help the DOTS client skip DNS lookup of the alternate DOTS server. 2302 The DOTS client can then try to establish a UDP or a TCP session with 2303 the alternate DOTS server. The DOTS client MAY implement a method to 2304 construct IPv4-embedded IPv6 addresses [RFC6052]; this is required to 2305 handle the scenario where an IPv6-only DOTS client communicates with 2306 an IPv4-only alternate DOTS server. 2308 If the DOTS client has been redirected to a DOTS server to which it 2309 has already communicated with within the last five (5) minutes, it 2310 MUST ignore the redirection and try to contact other DOTS servers 2311 listed in the local configuration or discovered using dynamic means 2312 such as DHCP or SRV procedures. It is RECOMMENDED that DOTS clients 2313 support means to alert administrators about redirect loops. 2315 4.7. Heartbeat Mechanism 2317 To provide an indication of signal health and distinguish an 'idle' 2318 signal channel from a 'disconnected' or 'defunct' session, the DOTS 2319 agent sends a heartbeat over the signal channel to maintain its half 2320 of the channel. The DOTS agent similarly expects a heartbeat from 2321 its peer DOTS agent, and may consider a session terminated in the 2322 prolonged absence of a peer agent heartbeat. 2324 While the communication between the DOTS agents is quiescent, the 2325 DOTS client will probe the DOTS server to ensure it has maintained 2326 cryptographic state and vice versa. Such probes can also keep 2327 firewalls and/or stateful translators bindings alive. This probing 2328 reduces the frequency of establishing a new handshake when a DOTS 2329 signal needs to be conveyed to the DOTS server. 2331 DOTS servers MAY trigger their heartbeat requests immediately after 2332 receiving heartbeat probes from peer DOTS clients. As a reminder, it 2333 is the responsibility of DOTS clients to ensure that on-path 2334 translators/firewalls are maintaining a binding so that the same 2335 external IP address and/or port number is retained for the DOTS 2336 signal channel session. 2338 In case of a massive DDoS attack that saturates the incoming link(s) 2339 to the DOTS client, all traffic from the DOTS server to the DOTS 2340 client will likely be dropped, although the DOTS server receives 2341 heartbeat requests in addition to DOTS messages sent by the DOTS 2342 client. In this scenario, the DOTS agents MUST behave differently to 2343 handle message transmission and DOTS signal channel session 2344 liveliness during link saturation: 2346 o The DOTS client MUST NOT consider the DOTS signal channel session 2347 terminated even after a maximum 'missing-hb-allowed' threshold is 2348 reached. The DOTS client SHOULD keep on using the current DOTS 2349 signal channel session to send heartbeat requests over it, so that 2350 the DOTS server knows the DOTS client has not disconnected the 2351 DOTS signal channel session. 2353 After the maximum 'missing-hb-allowed' threshold is reached, the 2354 DOTS client SHOULD try to resume the (D)TLS session. The DOTS 2355 client SHOULD send mitigation requests over the current DOTS 2356 signal channel session, and in parallel, for example, try to 2357 resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to 2358 piggyback the mitigation request in the ClientHello message. 2360 As soon as the link is no longer saturated, if traffic from the 2361 DOTS server reaches the DOTS client over the current DOTS signal 2362 channel session, the DOTS client can stop (D)TLS session 2363 resumption or if (D)TLS session resumption is successful then 2364 disconnect the current DOTS signal channel session. 2366 o If the DOTS server does not receive any traffic from the peer DOTS 2367 client, then the DOTS server sends heartbeat requests to the DOTS 2368 client and after maximum 'missing-hb-allowed' threshold is 2369 reached, the DOTS server concludes the session is disconnected. 2371 In DOTS over UDP, heartbeat messages MUST be exchanged between the 2372 DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of 2373 [RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable 2374 message and the peer DOTS agent will respond by sending a Reset 2375 message. 2377 In DOTS over TCP, heartbeat messages MUST be exchanged between the 2378 DOTS agents using the Ping and Pong messages specified in Section 4.4 2379 of [RFC8323]. That is, the DOTS agent sends a Ping message and the 2380 peer DOTS agent would respond by sending a single Pong message. 2382 5. DOTS Signal Channel YANG Modules 2384 This document defines a YANG [RFC7950] module for DOTS mitigation 2385 scope, DOTS signal channel session configuration data, and DOTS 2386 redirected signalling. 2388 This YANG module (ietf-dots-signal-channel) defines the DOTS client 2389 interaction with the DOTS server as seen by the DOTS client. A DOTS 2390 server is allowed to update the non-configurable 'ro' entities in the 2391 responses. This YANG module is not intended to be used for DOTS 2392 server management purposes. Such module is out of the scope of this 2393 document. 2395 A companion YANG module is defined to include a collection of types 2396 defined by IANA: "iana-dots-signal-channel" (Section 5.2). 2398 5.1. Tree Structure 2400 This document defines the YANG module "ietf-dots-signal-channel" 2401 (Section 5.3), which has the following tree structure. A DOTS signal 2402 message can either be a mitigation or a configuration message. 2404 module: ietf-dots-signal-channel 2405 +--rw dots-signal 2406 +--rw (message-type)? 2407 +--:(mitigation-scope) 2408 | +--rw scope* [cuid mid] 2409 | +--rw cdid? string 2410 | +--rw cuid string 2411 | +--rw mid uint32 2412 | +--rw target-prefix* inet:ip-prefix 2413 | +--rw target-port-range* [lower-port upper-port] 2414 | | +--rw lower-port inet:port-number 2415 | | +--rw upper-port inet:port-number 2416 | +--rw target-protocol* uint8 2417 | +--rw target-fqdn* inet:domain-name 2418 | +--rw target-uri* inet:uri 2419 | +--rw alias-name* string 2420 | +--rw lifetime? int32 2421 | +--rw trigger-mitigation? boolean 2422 | +--ro mitigation-start? uint64 2423 | +--ro status? iana-signal:status 2424 | +--ro conflict-information 2425 | | +--ro conflict-status? iana-signal:conflict-status 2426 | | +--ro conflict-cause? iana-signal:conflict-cause 2427 | | +--ro retry-timer? uint32 2428 | | +--ro conflict-scope 2429 | | +--ro target-prefix* inet:ip-prefix 2430 | | +--ro target-port-range* [lower-port upper-port] 2431 | | | +--ro lower-port inet:port-number 2432 | | | +--ro upper-port inet:port-number 2433 | | +--ro target-protocol* uint8 2434 | | +--ro target-fqdn* inet:domain-name 2435 | | +--ro target-uri* inet:uri 2436 | | +--ro alias-name* string 2437 | | +--ro acl-list* [acl-name] 2438 | | | +--ro acl-name 2439 | | | | -> /ietf-data:dots-data/dots-client/acls/ 2440 | | | | acl/name 2441 | | | +--ro acl-type? 2442 | | | -> /ietf-data:dots-data/dots-client/acls/ 2443 | | | acl/type 2444 | | +--ro mid? -> ../../../mid 2445 | +--ro bytes-dropped? yang:zero-based-counter64 2446 | +--ro bps-dropped? yang:zero-based-counter64 2447 | +--ro pkts-dropped? yang:zero-based-counter64 2448 | +--ro pps-dropped? yang:zero-based-counter64 2449 | +--rw attack-status? iana-signal:attack-status 2450 +--:(signal-config) 2451 | +--rw sid uint32 2452 | +--rw mitigating-config 2453 | | +--rw heartbeat-interval 2454 | | | +--ro max-value? uint16 2455 | | | +--ro min-value? uint16 2456 | | | +--rw current-value? uint16 2457 | | +--rw missing-hb-allowed 2458 | | | +--ro max-value? uint16 2459 | | | +--ro min-value? uint16 2460 | | | +--rw current-value? uint16 2461 | | +--rw max-retransmit 2462 | | | +--ro max-value? uint16 2463 | | | +--ro min-value? uint16 2464 | | | +--rw current-value? uint16 2465 | | +--rw ack-timeout 2466 | | | +--ro max-value-decimal? decimal64 2467 | | | +--ro min-value-decimal? decimal64 2468 | | | +--rw current-value-decimal? decimal64 2469 | | +--rw ack-random-factor 2470 | | +--ro max-value-decimal? decimal64 2471 | | +--ro min-value-decimal? decimal64 2472 | | +--rw current-value-decimal? decimal64 2473 | +--rw idle-config 2474 | +--rw heartbeat-interval 2475 | | +--ro max-value? uint16 2476 | | +--ro min-value? uint16 2477 | | +--rw current-value? uint16 2478 | +--rw missing-hb-allowed 2479 | | +--ro max-value? uint16 2480 | | +--ro min-value? uint16 2481 | | +--rw current-value? uint16 2482 | +--rw max-retransmit 2483 | | +--ro max-value? uint16 2484 | | +--ro min-value? uint16 2485 | | +--rw current-value? uint16 2486 | +--rw ack-timeout 2487 | | +--ro max-value-decimal? decimal64 2488 | | +--ro min-value-decimal? decimal64 2489 | | +--rw current-value-decimal? decimal64 2490 | +--rw ack-random-factor 2491 | +--ro max-value-decimal? decimal64 2492 | +--ro min-value-decimal? decimal64 2493 | +--rw current-value-decimal? decimal64 2494 +--:(redirected-signal) 2495 +--ro alt-server string 2496 +--ro alt-server-record* inet:ip-address 2498 5.2. IANA DOTS Signal Channel YANG Module 2500 file "iana-dots-signal-channel@2018-10-17.yang" 2501 module iana-dots-signal-channel { 2502 yang-version 1.1; 2503 namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel"; 2504 prefix iana-signal; 2506 organization 2507 "IANA"; 2508 contact 2509 "Internet Assigned Numbers Authority 2511 Postal: ICANN 2512 12025 Waterfront Drive, Suite 300 2513 Los Angeles, CA 90094-2536 2514 United States of America 2515 Tel: +1 310 301 5800 2516 "; 2517 description 2518 "This module contains a collection of YANG data types defined 2519 by IANA and used for DOTS signal channel protocol. 2521 Copyright (c) 2018 IETF Trust and the persons identified as 2522 authors of the code. All rights reserved. 2524 Redistribution and use in source and binary forms, with or 2525 without modification, is permitted pursuant to, and subject 2526 to the license terms contained in, the Simplified BSD License 2527 set forth in Section 4.c of the IETF Trust's Legal Provisions 2528 Relating to IETF Documents 2529 (http://trustee.ietf.org/license-info). 2531 This version of this YANG module is part of RFC XXXX; see 2532 the RFC itself for full legal notices."; 2534 revision 2018-10-17 { 2535 description 2536 "Initial revision."; 2537 reference 2538 "RFC XXXX: Distributed Denial-of-Service Open Threat 2539 Signaling (DOTS) Signal Channel Specification"; 2540 } 2542 typedef status { 2543 type enumeration { 2544 enum attack-mitigation-in-progress { 2545 value 1; 2546 description 2547 "Attack mitigation setup is in progress (e.g., changing 2548 the network path to re-route the inbound traffic 2549 to DOTS mitigator)."; 2550 } 2551 enum attack-successfully-mitigated { 2552 value 2; 2553 description 2554 "Attack is being successfully mitigated (e.g., traffic 2555 is redirected to a DDoS mitigator and attack 2556 traffic is dropped or blackholed)."; 2557 } 2558 enum attack-stopped { 2559 value 3; 2560 description 2561 "Attack has stopped and the DOTS client can 2562 withdraw the mitigation request."; 2563 } 2564 enum attack-exceeded-capability { 2565 value 4; 2566 description 2567 "Attack has exceeded the mitigation provider 2568 capability."; 2569 } 2570 enum dots-client-withdrawn-mitigation { 2571 value 5; 2572 description 2573 "DOTS client has withdrawn the mitigation 2574 request and the mitigation is active but 2575 terminating."; 2576 } 2577 enum attack-mitigation-terminated { 2578 value 6; 2579 description 2580 "Attack mitigation is now terminated."; 2581 } 2582 enum attack-mitigation-withdrawn { 2583 value 7; 2584 description 2585 "Attack mitigation is withdrawn."; 2586 } 2587 enum attack-mitigation-signal-loss { 2588 value 8; 2589 description 2590 "Attack mitigation will be triggered 2591 for the mitigation request only when 2592 the DOTS signal channel session is lost."; 2593 } 2594 } 2595 description 2596 "Enumeration for status reported by the DOTS server."; 2597 } 2599 typedef conflict-status { 2600 type enumeration { 2601 enum request-inactive-other-active { 2602 value 1; 2603 description 2604 "DOTS Server has detected conflicting mitigation 2605 requests from different DOTS clients. 2606 This mitigation request is currently inactive 2607 until the conflicts are resolved. Another 2608 mitigation request is active."; 2609 } 2610 enum request-active { 2611 value 2; 2612 description 2613 "DOTS Server has detected conflicting mitigation 2614 requests from different DOTS clients. 2615 This mitigation request is currently active."; 2616 } 2617 enum all-requests-inactive { 2618 value 3; 2619 description 2620 "DOTS Server has detected conflicting mitigation 2621 requests from different DOTS clients. All 2622 conflicting mitigation requests are inactive."; 2623 } 2624 } 2625 description 2626 "Enumeration for conflict status."; 2627 } 2629 typedef conflict-cause { 2630 type enumeration { 2631 enum overlapping-targets { 2632 value 1; 2633 description 2634 "Overlapping targets. conflict-scope provides 2635 more details about the exact conflict."; 2636 } 2637 enum conflict-with-acceptlist { 2638 value 2; 2639 description 2640 "Conflicts with an existing accept-list. 2642 This code is returned when the DDoS mitigation 2643 detects that some of the source addresses/prefixes 2644 listed in the accept-list ACLs are actually 2645 attacking the target."; 2646 } 2647 enum cuid-collision { 2648 value 3; 2649 description 2650 "Conflicts with the cuid used by another 2651 DOTS client."; 2652 } 2653 } 2654 description 2655 "Enumeration for conflict causes."; 2656 } 2658 typedef attack-status { 2659 type enumeration { 2660 enum under-attack { 2661 value 1; 2662 description 2663 "The DOTS client determines that it is still under 2664 attack."; 2665 } 2666 enum attack-successfully-mitigated { 2667 value 2; 2668 description 2669 "The DOTS client determines that the attack is 2670 successfully mitigated."; 2671 } 2672 } 2673 description 2674 "Enumeration for attack status codes."; 2675 } 2676 } 2677 2679 5.3. IETF DOTS Signal Channel YANG Module 2681 This module uses the common YANG types defined in [RFC6991] and types 2682 defined in [I-D.ietf-dots-data-channel]. 2684 file "ietf-dots-signal-channel@2018-10-17.yang" 2685 module ietf-dots-signal-channel { 2686 yang-version 1.1; 2687 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; 2688 prefix signal; 2690 import ietf-inet-types { 2691 prefix inet; 2692 reference "Section 4 of RFC 6991"; 2693 } 2694 import ietf-yang-types { 2695 prefix yang; 2696 reference "Section 3 of RFC 6991"; 2697 } 2698 import ietf-dots-data-channel { 2699 prefix ietf-data; 2700 reference 2701 "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling 2702 (DOTS) Data Channel Specification"; 2703 } 2704 import iana-dots-signal-channel { 2705 prefix iana-signal; 2706 } 2708 organization 2709 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 2710 contact 2711 "WG Web: 2712 WG List: 2714 Editor: Konda, Tirumaleswar Reddy 2715 2717 Editor: Mohamed Boucadair 2718 2720 Author: Prashanth Patil 2721 2723 Author: Andrew Mortensen 2724 2726 Author: Nik Teague 2727 "; 2728 description 2729 "This module contains YANG definition for the signaling 2730 messages exchanged between a DOTS client and a DOTS server. 2732 Copyright (c) 2018 IETF Trust and the persons identified as 2733 authors of the code. All rights reserved. 2735 Redistribution and use in source and binary forms, with or 2736 without modification, is permitted pursuant to, and subject 2737 to the license terms contained in, the Simplified BSD License 2738 set forth in Section 4.c of the IETF Trust's Legal Provisions 2739 Relating to IETF Documents 2740 (http://trustee.ietf.org/license-info). 2742 This version of this YANG module is part of RFC XXXX; see 2743 the RFC itself for full legal notices."; 2745 revision 2018-10-17 { 2746 description 2747 "Initial revision."; 2748 reference 2749 "RFC XXXX: Distributed Denial-of-Service Open Threat 2750 Signaling (DOTS) Signal Channel Specification"; 2751 } 2753 /* 2754 * Groupings 2755 */ 2757 grouping mitigation-scope { 2758 description 2759 "Specifies the scope of the mitigation request."; 2760 list scope { 2761 key "cuid mid"; 2762 description 2763 "The scope of the request."; 2764 leaf cdid { 2765 type string; 2766 description 2767 "The cdid should be included by a server-domain 2768 DOTS gateway to propagate the client domain 2769 identification information from the 2770 gateway's client-facing-side to the gateway's 2771 server-facing-side, and from the gateway's 2772 server-facing-side to the DOTS server. 2774 It may be used by the final DOTS server 2775 for policy enforcement purposes."; 2776 } 2777 leaf cuid { 2778 type string; 2779 description 2780 "A unique identifier that is randomly 2781 generated by a DOTS client to prevent 2782 request collisions. It is expected that the 2783 cuid will remain consistent throughout the 2784 lifetime of the DOTS client."; 2785 } 2786 leaf mid { 2787 type uint32; 2788 description 2789 "Mitigation request identifier. 2791 This identifier must be unique for each mitigation 2792 request bound to the DOTS client."; 2793 } 2794 uses ietf-data:target; 2795 leaf-list alias-name { 2796 type string; 2797 description 2798 "An alias name that points to a resource."; 2799 } 2800 leaf lifetime { 2801 type int32; 2802 units "seconds"; 2803 default "3600"; 2804 description 2805 "Indicates the lifetime of the mitigation request. 2807 A lifetime of '0' in a mitigation request is an 2808 invalid value. 2810 A lifetime of negative one (-1) indicates indefinite 2811 lifetime for the mitigation request."; 2812 } 2813 leaf trigger-mitigation { 2814 type boolean; 2815 default "true"; 2816 description 2817 "If set to 'false', DDoS mitigation will not be 2818 triggered unless the DOTS signal channel 2819 session is lost."; 2820 } 2821 leaf mitigation-start { 2822 type uint64; 2823 config false; 2824 description 2825 "Mitigation start time is represented in seconds 2826 relative to 1970-01-01T00:00:00Z in UTC time."; 2827 } 2828 leaf status { 2829 type iana-signal:status; 2830 config false; 2831 description 2832 "Indicates the status of a mitigation request. 2833 It must be included in responses only."; 2834 } 2835 container conflict-information { 2836 config false; 2837 description 2838 "Indicates that a conflict is detected. 2839 Must only be used for responses."; 2840 leaf conflict-status { 2841 type iana-signal:conflict-status; 2842 description 2843 "Indicates the conflict status."; 2844 } 2845 leaf conflict-cause { 2846 type iana-signal:conflict-cause; 2847 description 2848 "Indicates the cause of the conflict."; 2849 } 2850 leaf retry-timer { 2851 type uint32; 2852 units "seconds"; 2853 description 2854 "The DOTS client must not re-send the 2855 same request that has a conflict before the expiry of 2856 this timer."; 2857 } 2858 container conflict-scope { 2859 description 2860 "Provides more information about the conflict scope."; 2861 uses ietf-data:target { 2862 when "../conflict-cause = 'overlapping-targets'"; 2863 } 2864 leaf-list alias-name { 2865 when "../../conflict-cause = 'overlapping-targets'"; 2866 type string; 2867 description 2868 "Conflicting alias-name."; 2869 } 2870 list acl-list { 2871 when "../../conflict-cause = 'conflict-with-acceptlist'"; 2872 key "acl-name"; 2873 description 2874 "List of conflicting ACLs as defined in the DOTS data 2875 channel. These ACLs are uniquely defined by 2876 cuid and acl-name."; 2877 leaf acl-name { 2878 type leafref { 2879 path "/ietf-data:dots-data/ietf-data:dots-client/" 2880 +"ietf-data:acls/ietf-data:acl/ietf-data:name"; 2881 } 2882 description 2883 "Reference to the conflicting ACL name bound to 2884 a DOTS client."; 2885 } 2886 leaf acl-type { 2887 type leafref { 2888 path "/ietf-data:dots-data/ietf-data:dots-client/" 2889 +ietf-data:acls/ietf-data:acl/ietf-data:type"; 2890 } 2891 description 2892 "Reference to the conflicting ACL type bound to 2893 a DOTS client."; 2894 } 2895 } 2896 leaf mid { 2897 when "../../conflict-cause = 'overlapping-targets'"; 2898 type leafref { 2899 path "../../../mid"; 2900 } 2901 description 2902 "Reference to the conflicting 'mid' bound to 2903 the same DOTS client."; 2904 } 2905 } 2906 } 2907 leaf bytes-dropped { 2908 type yang:zero-based-counter64; 2909 units "bytes"; 2910 config false; 2911 description 2912 "The total dropped byte count for the mitigation 2913 request since the attack mitigation is triggered. 2914 The count wraps around when it reaches the maximum value 2915 of counter64 for dropped bytes."; 2916 } 2917 leaf bps-dropped { 2918 type yang:zero-based-counter64; 2919 config false; 2920 description 2921 "The average number of dropped bits per second for 2922 the mitigation request since the attack 2923 mitigation is triggered. This should be a 2924 five-minute average."; 2925 } 2926 leaf pkts-dropped { 2927 type yang:zero-based-counter64; 2928 config false; 2929 description 2930 "The total number of dropped packet count for the 2931 mitigation request since the attack mitigation is 2932 triggered. The count wraps around when it reaches 2933 the maximum value of counter64 for dropped packets."; 2934 } 2935 leaf pps-dropped { 2936 type yang:zero-based-counter64; 2937 config false; 2938 description 2939 "The average number of dropped packets per second 2940 for the mitigation request since the attack 2941 mitigation is triggered. This should be a 2942 five-minute average."; 2943 } 2944 leaf attack-status { 2945 type iana-signal:attack-status; 2946 description 2947 "Indicates the status of an attack as seen by the 2948 DOTS client."; 2949 } 2950 } 2951 } 2953 grouping config-parameters { 2954 description 2955 "Subset of DOTS signal channel session configuration."; 2956 container heartbeat-interval { 2957 description 2958 "DOTS agents regularly send heartbeats to each other 2959 after mutual authentication is successfully 2960 completed in order to keep the DOTS signal channel 2961 open."; 2962 leaf max-value { 2963 type uint16; 2964 units "seconds"; 2965 config false; 2966 description 2967 "Maximum acceptable heartbeat-interval value."; 2968 } 2969 leaf min-value { 2970 type uint16; 2971 units "seconds"; 2972 config false; 2973 description 2974 "Minimum acceptable heartbeat-interval value."; 2975 } 2976 leaf current-value { 2977 type uint16; 2978 units "seconds"; 2979 default "30"; 2980 description 2981 "Current heartbeat-interval value. 2983 '0' means that heartbeat mechanism is deactivated."; 2984 } 2985 } 2986 container missing-hb-allowed { 2987 description 2988 "Maximum number of missing heartbeats allowed."; 2989 leaf max-value { 2990 type uint16; 2991 config false; 2992 description 2993 "Maximum acceptable missing-hb-allowed value."; 2994 } 2995 leaf min-value { 2996 type uint16; 2997 config false; 2998 description 2999 "Minimum acceptable missing-hb-allowed value."; 3000 } 3001 leaf current-value { 3002 type uint16; 3003 default "5"; 3004 description 3005 "Current missing-hb-allowed value."; 3006 } 3007 } 3008 container max-retransmit { 3009 description 3010 "Maximum number of retransmissions of a Confirmable 3011 message."; 3012 leaf max-value { 3013 type uint16; 3014 config false; 3015 description 3016 "Maximum acceptable max-retransmit value."; 3017 } 3018 leaf min-value { 3019 type uint16; 3020 config false; 3021 description 3022 "Minimum acceptable max-retransmit value."; 3023 } 3024 leaf current-value { 3025 type uint16; 3026 default "3"; 3027 description 3028 "Current max-retransmit value."; 3029 } 3030 } 3031 container ack-timeout { 3032 description 3033 "Initial retransmission timeout value."; 3034 leaf max-value-decimal { 3035 type decimal64 { 3036 fraction-digits 2; 3037 } 3038 units "seconds"; 3039 config false; 3040 description 3041 "Maximum ack-timeout value."; 3042 } 3043 leaf min-value-decimal { 3044 type decimal64 { 3045 fraction-digits 2; 3046 } 3047 units "seconds"; 3048 config false; 3049 description 3050 "Minimum ack-timeout value."; 3051 } 3052 leaf current-value-decimal { 3053 type decimal64 { 3054 fraction-digits 2; 3055 } 3056 units "seconds"; 3057 default "2"; 3058 description 3059 "Current ack-timeout value."; 3060 } 3061 } 3062 container ack-random-factor { 3063 description 3064 "Random factor used to influence the timing of 3065 retransmissions."; 3066 leaf max-value-decimal { 3067 type decimal64 { 3068 fraction-digits 2; 3069 } 3070 config false; 3071 description 3072 "Maximum acceptable ack-random-factor value."; 3073 } 3074 leaf min-value-decimal { 3075 type decimal64 { 3076 fraction-digits 2; 3077 } 3078 config false; 3079 description 3080 "Minimum acceptable ack-random-factor value."; 3081 } 3082 leaf current-value-decimal { 3083 type decimal64 { 3084 fraction-digits 2; 3085 } 3086 default "1.5"; 3087 description 3088 "Current ack-random-factor value."; 3089 } 3090 } 3091 } 3093 grouping signal-config { 3094 description 3095 "DOTS signal channel session configuration."; 3096 leaf sid { 3097 type uint32; 3098 mandatory true; 3099 description 3100 "An identifier for the DOTS signal channel 3101 session configuration data."; 3102 } 3103 container mitigating-config { 3104 description 3105 "Configuration parameters to use when a mitigation 3106 is active."; 3107 uses config-parameters; 3108 } 3109 container idle-config { 3110 description 3111 "Configuration parameters to use when no mitigation 3112 is active."; 3113 uses config-parameters; 3114 } 3115 } 3117 grouping redirected-signal { 3118 description 3119 "Grouping for the redirected signaling."; 3120 leaf alt-server { 3121 type string; 3122 config false; 3123 mandatory true; 3124 description 3125 "FQDN of an alternate server."; 3126 } 3127 leaf-list alt-server-record { 3128 type inet:ip-address; 3129 config false; 3130 description 3131 "List of records for the alternate server."; 3132 } 3133 } 3135 /* 3136 * Main Container for DOTS Signal Channel 3137 */ 3139 container dots-signal { 3140 description 3141 "Main container for DOTS signal message. 3143 A DOTS signal message can be a mitigation, a configuration, 3144 or a redirected signal message."; 3145 choice message-type { 3146 description 3147 "Can be a mitigation, a configuration, or a redirect 3148 message."; 3149 case mitigation-scope { 3150 description 3151 "Mitigation scope of a mitigation message."; 3152 uses mitigation-scope; 3153 } 3154 case signal-config { 3155 description 3156 "Configuration message."; 3157 uses signal-config; 3158 } 3159 case redirected-signal { 3160 description 3161 "Redirected signaling."; 3162 uses redirected-signal; 3163 } 3164 } 3165 } 3166 } 3168 3170 6. Mapping Parameters to CBOR 3172 All parameters in the payload of the DOTS signal channel MUST be 3173 mapped to CBOR types as shown in Table 4 and are assigned an integer 3174 key to save space. The CBOR key values are divided into two types: 3175 comprehension-required and comprehension-optional. DOTS agents can 3176 safely ignore comprehension-optional values they don't understand, 3177 but cannot successfully process a request if it contains 3178 comprehension-required values that are not understood. The 4.00 3179 response SHOULD include a diagnostic payload describing the unknown 3180 comprehension-required CBOR key values. The initial set of CBOR key 3181 values defined in this specification are of type comprehension- 3182 required. 3184 +----------------------+-------------+-----+---------------+--------+ 3185 | Parameter Name | YANG | CBOR| CBOR Major | JSON | 3186 | | Type | Key | Type & | Type | 3187 | | | | Information | | 3188 +----------------------+-------------+-----+---------------+--------+ 3189 | ietf-dots-signal-cha | | | | | 3190 | nnel:mitigation-scope| container | 1 | 5 map | Object | 3191 | scope | list | 2 | 4 array | Array | 3192 | cdid | string | 3 | 3 text string | String | 3193 | cuid | string | 4 | 3 text string | String | 3194 | mid | uint32 | 5 | 0 unsigned | Number | 3195 | target-prefix | leaf-list | 6 | 4 array | Array | 3196 | | inet: | | | | 3197 | | ip-prefix | | 3 text string | String | 3198 | target-port-range | list | 7 | 4 array | Array | 3199 | lower-port | inet: | | | | 3200 | | port-number| 8 | 0 unsigned | Number | 3201 | upper-port | inet: | | | | 3202 | | port-number| 9 | 0 unsigned | Number | 3203 | target-protocol | leaf-list | 10 | 4 array | Array | 3204 | | uint8 | | 0 unsigned | Number | 3205 | target-fqdn | leaf-list | 11 | 4 array | Array | 3206 | | inet: | | | | 3207 | | domain-name| | 3 text string | String | 3208 | target-uri | leaf-list | 12 | 4 array | Array | 3209 | | inet:uri | | 3 text string | String | 3210 | alias-name | leaf-list | 13 | 4 array | Array | 3211 | | string | | 3 text string | String | 3212 | lifetime | int32 | 14 | 0 unsigned | Number | 3213 | | | | 1 negative | Number | 3214 | mitigation-start | uint64 | 15 | 0 unsigned | String | 3215 | status | enumeration | 16 | 0 unsigned | String | 3216 | conflict-information | container | 17 | 5 map | Object | 3217 | conflict-status | enumeration | 18 | 0 unsigned | String | 3218 | conflict-cause | enumeration | 19 | 0 unsigned | String | 3219 | retry-timer | uint32 | 20 | 0 unsigned | Number | 3220 | conflict-scope | container | 21 | 5 map | Object | 3221 | acl-list | list | 22 | 4 array | Array | 3222 | acl-name | leafref | 23 | 3 text string | String | 3223 | acl-type | leafref | 24 | 3 text string | String | 3224 | bytes-dropped | yang:zero- | | | | 3225 | | based- | | | | 3226 | | counter64 | 25 | 0 unsigned | String | 3227 | bps-dropped | yang:zero- | | | | 3228 | | based- | | | | 3229 | | counter64 | 26 | 0 unsigned | String | 3230 | pkts-dropped | yang:zero- | | | | 3231 | | based- | | | | 3232 | | counter64 | 27 | 0 unsigned | String | 3233 | pps-dropped | yang:zero- | | | | 3234 | | based- | | | | 3235 | | counter64 | 28 | 0 unsigned | String | 3236 | attack-status | enumeration | 29 | 0 unsigned | String | 3237 | ietf-dots-signal- | | | | | 3238 | channel:signal-config| container | 30 | 5 map | Object | 3239 | sid | uint32 | 31 | 0 unsigned | Number | 3240 | mitigating-config | container | 32 | 5 map | Object | 3241 | heartbeat-interval | container | 33 | 5 map | Object | 3242 | max-value | uint16 | 34 | 0 unsigned | Number | 3243 | min-value | uint16 | 35 | 0 unsigned | Number | 3244 | current-value | uint16 | 36 | 0 unsigned | Number | 3245 | missing-hb-allowed | container | 37 | 5 map | Object | 3246 | max-retransmit | container | 38 | 5 map | Object | 3247 | ack-timeout | container | 39 | 5 map | Object | 3248 | ack-random-factor | container | 40 | 5 map | Object | 3249 | max-value-decimal | decimal64 | 41 | 6 tag 4 | | 3250 | | | | [-2, integer]| String | 3251 | min-value-decimal | decimal64 | 42 | 6 tag 4 | | 3252 | | | | [-2, integer]| String | 3253 | current-value-decimal| decimal64 | 43 | 6 tag 4 | | 3254 | | | | [-2, integer]| String | 3255 | idle-config | container | 44 | 5 map | Object | 3256 | trigger-mitigation | boolean | 45 | 7 bits 20 | False | 3257 | | | | 7 bits 21 | True | 3258 | ietf-dots-signal-cha | | | | | 3259 |nnel:redirected-signal| container | 46 | 5 map | Object | 3260 | alt-server | string | 47 | 3 text string | String | 3261 | alt-server-record | leaf-list | 48 | 4 array | Array | 3262 | | inet: | | | | 3263 | | ip-address | | 3 text string | String | 3264 +----------------------+-------------+-----+---------------+--------+ 3266 Table 4: CBOR Mappings Used in DOTS Signal Channel Messages 3268 7. (D)TLS Protocol Profile and Performance Considerations 3270 7.1. (D)TLS Protocol Profile 3272 This section defines the (D)TLS protocol profile of DOTS signal 3273 channel over (D)TLS and DOTS data channel over TLS. 3275 There are known attacks on (D)TLS, such as man-in-the-middle and 3276 protocol downgrade attacks. These are general attacks on (D)TLS and, 3277 as such, they are not specific to DOTS over (D)TLS; refer to the 3278 (D)TLS RFCs for discussion of these security issues. DOTS agents 3279 MUST adhere to the (D)TLS implementation recommendations and security 3280 considerations of [RFC7525] except with respect to (D)TLS version. 3281 Since DOTS signal channel encryption relies upon (D)TLS is virtually 3282 a green-field deployment, DOTS agents MUST implement only (D)TLS 1.2 3283 or later. 3285 When a DOTS client is configured with a domain name of the DOTS 3286 server, and connects to its configured DOTS server, the server may 3287 present it with a PKIX certificate. In order to ensure proper 3288 authentication, a DOTS client MUST verify the entire certification 3289 path per [RFC5280]. The DOTS client additionally uses [RFC6125] 3290 validation techniques to compare the domain name with the certificate 3291 provided. 3293 A key challenge to deploying DOTS is the provisioning of DOTS 3294 clients, including the distribution of keying material to DOTS 3295 clients to enable the required mutual authentication of DOTS agents. 3296 EST defines a method of certificate enrollment by which domains 3297 operating DOTS servers may provide DOTS clients with all the 3298 necessary cryptographic keying material, including a private key and 3299 a certificate to authenticate themselves. One deployment option is 3300 DOTS clients behave as EST clients for certificate enrollment from an 3301 EST server provisioned by the mitigation provider. This document 3302 does not specify which EST mechanism the DOTS client uses to achieve 3303 initial enrollment. 3305 The Server Name Indication (SNI) extension [RFC6066] defines a 3306 mechanism for a client to tell a (D)TLS server the name of the server 3307 it wants to contact. This is a useful extension for hosting 3308 environments where multiple virtual servers are reachable over a 3309 single IP address. The DOTS client may or may not know if it is 3310 interacting with a DOTS server in a virtual server hosting 3311 environment, so the DOTS client SHOULD include the DOTS server FQDN 3312 in the SNI extension. 3314 Implementations compliant with this profile MUST implement all of the 3315 following items: 3317 o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect 3318 against replay attacks. 3320 o DTLS session resumption without server-side state to resume 3321 session and convey the DOTS signal. 3323 o Raw public keys [RFC7250] or PSK handshake [RFC4279] with (EC)DHE 3324 key exchange which reduces the size of the ServerHello, and can be 3325 used by DOTS agents that cannot obtain certificates. 3327 Implementations compliant with this profile SHOULD implement all of 3328 the following items to reduce the delay required to deliver a DOTS 3329 signal channel message: 3331 o TLS False Start [RFC7918] which reduces round-trips by allowing 3332 the TLS second flight of messages (ChangeCipherSpec) to also 3333 contain the DOTS signal. 3335 o Cached Information Extension [RFC7924] which avoids transmitting 3336 the server's certificate and certificate chain if the client has 3337 cached that information from a previous TLS handshake. 3339 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 3340 convey DOTS signal channel message. 3342 7.2. (D)TLS 1.3 Considerations 3344 TLS 1.3 provides critical latency improvements for connection 3345 establishment over TLS 1.2. The DTLS 1.3 protocol 3346 [I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides 3347 equivalent security guarantees. (D)TLS 1.3 provides two basic 3348 handshake modes the DOTS signal channel can take advantage of: 3350 o A full handshake mode in which a DOTS client can send a DOTS 3351 mitigation request message after one round trip and the DOTS 3352 server immediately responds with a DOTS mitigation response. This 3353 assumes no packet loss is experienced. 3355 o 0-RTT mode in which the DOTS client can authenticate itself and 3356 send DOTS mitigation request messages in the first message, thus 3357 reducing handshake latency. 0-RTT only works if the DOTS client 3358 has previously communicated with that DOTS server, which is very 3359 likely with the DOTS signal channel. 3361 The DOTS client has to establish a (D)TLS session with the DOTS 3362 server during peacetime and share a PSK. 3364 During a DDoS attack, the DOTS client can use the (D)TLS session 3365 to convey the DOTS mitigation request message and, if there is no 3366 response from the server after multiple retries, the DOTS client 3367 can resume the (D)TLS session in 0-RTT mode using PSK. 3369 Section 8 of [RFC8446] discusses some mechanisms to implement to 3370 limit the impact of replay attacks on 0-RTT data. If the DOTS 3371 server accepts 0-RTT, it MUST implement one of these mechanisms. 3372 A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest. 3374 A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request 3375 message exchange is shown in Figure 24. 3377 DOTS Client DOTS Server 3379 ClientHello 3380 (Finished) 3381 (0-RTT DOTS signal message) 3382 (end_of_early_data) --------> 3383 ServerHello 3384 {EncryptedExtensions} 3385 {ServerConfiguration} 3386 {Certificate} 3387 {CertificateVerify} 3388 {Finished} 3389 <-------- [DOTS signal message] 3390 {Finished} --------> 3392 [DOTS signal message] <-------> [DOTS signal message] 3394 Figure 24: TLS 1.3 Handshake with 0-RTT 3396 7.3. MTU and Fragmentation 3398 To avoid DOTS signal message fragmentation and the subsequent 3399 decreased probability of message delivery, DOTS agents MUST ensure 3400 that the DTLS record MUST fit within a single datagram. If the path 3401 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 3402 be assumed. If UDP is used to convey the DOTS signal messages then 3403 the DOTS client must consider the amount of record expansion expected 3404 by the DTLS processing when calculating the size of CoAP message that 3405 fits within the path MTU. Path MTU MUST be greater than or equal to 3406 [CoAP message size + DTLS overhead of 13 octets + authentication 3407 overhead of the negotiated DTLS cipher suite + block padding] 3408 (Section 4.1.1.1 of [RFC6347]). If the request size exceeds the path 3409 MTU then the DOTS client MUST split the DOTS signal into separate 3410 messages, for example the list of addresses in the 'target-prefix' 3411 parameter could be split into multiple lists and each list conveyed 3412 in a new PUT request. 3414 Implementation Note: DOTS choice of message size parameters works 3415 well with IPv6 and with most of today's IPv4 paths. However, with 3416 IPv4, it is harder to safely make sure that there is no IP 3417 fragmentation. If IPv4 path MTU is unknown, implementations may want 3418 to limit themselves to more conservative IPv4 datagram sizes such as 3419 576 bytes, as per [RFC0791]. IP packets whose size does not exceed 3420 576 bytes should never need to be fragmented: therefore, sending a 3421 maximum of 500 bytes of DOTS signal over a UDP datagram will 3422 generally avoid IP fragmentation. 3424 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 3426 (D)TLS based upon client certificate can be used for mutual 3427 authentication between DOTS agents. If a DOTS gateway is involved, 3428 DOTS clients and DOTS gateways MUST perform mutual authentication; 3429 only authorized DOTS clients are allowed to send DOTS signals to a 3430 DOTS gateway. The DOTS gateway and the DOTS server MUST perform 3431 mutual authentication; a DOTS server only allows DOTS signal channel 3432 messages from an authorized DOTS gateway, thereby creating a two-link 3433 chain of transitive authentication between the DOTS client and the 3434 DOTS server. 3436 The DOTS server SHOULD support certificate-based client 3437 authentication. The DOTS client SHOULD respond to the DOTS server's 3438 TLS certificate request message with the PKIX certificate held by the 3439 DOTS client. DOTS client certificate validation MUST be performed as 3440 per [RFC5280] and the DOTS client certificate MUST conform to the 3441 [RFC5280] certificate profile. If a DOTS client does not support TLS 3442 client certificate authentication, it MUST support pre-shared key 3443 based or raw public key based client authentication. 3445 +-----------------------------------------------+ 3446 | example.com domain +---------+ | 3447 | | AAA | | 3448 | +---------------+ | Server | | 3449 | | Application | +------+--+ | 3450 | | server +<-----------------+ ^ | 3451 | | (DOTS client) | | | | 3452 | +---------------+ | | | 3453 | V V | example.net domain 3454 | +-----+----+--+ | +---------------+ 3455 | +--------------+ | | | | | 3456 | | Guest +<-----x----->+ DOTS +<------>+ DOTS | 3457 | | (DOTS client)| | gateway | | | server | 3458 | +--------------+ | | | | | 3459 | +----+--------+ | +---------------+ 3460 | ^ | 3461 | | | 3462 | +----------------+ | | 3463 | | DDoS detector | | | 3464 | | (DOTS client) +<---------------+ | 3465 | +----------------+ | 3466 +-----------------------------------------------+ 3468 Figure 25: Example of Authentication and Authorization of DOTS Agents 3470 In the example depicted in Figure 25, the DOTS gateway and DOTS 3471 clients within the 'example.com' domain mutually authenticate. After 3472 the DOTS gateway validates the identity of a DOTS client, it 3473 communicates with the AAA server in the 'example.com' domain to 3474 determine if the DOTS client is authorized to request DDoS 3475 mitigation. If the DOTS client is not authorized, a 4.01 3476 (Unauthorized) is returned in the response to the DOTS client. In 3477 this example, the DOTS gateway only allows the application server and 3478 DDoS attack detector to request DDoS mitigation, but does not permit 3479 the user of type 'guest' to request DDoS mitigation. 3481 Also, DOTS gateways and servers located in different domains MUST 3482 perform mutual authentication (e.g., using certificates). A DOTS 3483 server will only allow a DOTS gateway with a certificate for a 3484 particular domain to request mitigation for that domain. In 3485 reference to Figure 25, the DOTS server only allows the DOTS gateway 3486 to request mitigation for 'example.com' domain and not for other 3487 domains. 3489 9. IANA Considerations 3491 This specification registers a service port (Section 9.1), a URI 3492 suffix in the Well-Known URIs registry (Section 9.2), and two YANG 3493 modules (Section 9.7). It also creates a new registry for DOTS 3494 signal channel protocol (Section 9.6). 3496 9.1. DOTS Signal Channel UDP and TCP Port Number 3498 IANA is requested to assign the port number TBD to the DOTS signal 3499 channel protocol for both UDP and TCP from the "Service Name and 3500 Transport Protocol Port Number Registry" available at 3501 https://www.iana.org/assignments/service-names-port-numbers/service- 3502 names-port-numbers.xhtml. 3504 The assignment of port number 4646 is strongly suggested, as 4646 is 3505 the ASCII decimal value for ".." (DOTS). 3507 9.2. Well-Known 'dots' URI 3509 This document requests IANA to register the 'dots' well-known URI 3510 (Table 5) in the Well-Known URIs registry 3511 (https://www.iana.org/assignments/well-known-uris/well-known- 3512 uris.xhtml) as defined by [RFC5785]: 3514 +----------+----------------+---------------------+-----------------+ 3515 | URI | Change | Specification | Related | 3516 | suffix | controller | document(s) | information | 3517 +----------+----------------+---------------------+-----------------+ 3518 | dots | IETF | [RFCXXXX] | None | 3519 +----------+----------------+---------------------+-----------------+ 3521 Table 5: 'dots' well-known URI 3523 9.3. Media Type Registration 3525 This section registers the "application/dots+cbor" media type in the 3526 "Media Types" registry [IANA.MediaTypes] in the manner described in 3527 RFC 6838 [RFC6838], which can be used to indicate that the content is 3528 a DOTS signal channel object. 3530 9.3.1. Registry Contents 3532 o Type name: application 3533 o Subtype name: dots+cbor 3534 o Required parameters: N/A 3535 o Optional parameters: N/A 3536 o Encoding considerations: binary 3537 o Security considerations: See the Security Considerations section 3538 of [RFCXXXX] 3539 o Interoperability considerations: N/A 3540 o Published specification: [RFCXXXX] 3541 o Applications that use this media type: DOTS agents sending DOTS 3542 messages over CoAP over (D)TLS. 3543 o Fragment identifier considerations: N/A 3544 o Additional information: 3546 Magic number(s): N/A 3547 File extension(s): N/A 3548 Macintosh file type code(s): N/A 3549 o Person & email address to contact for further information: 3550 IESG, iesg@ietf.org 3551 o Intended usage: COMMON 3552 o Restrictions on usage: none 3553 o Author: Tirumaleswar Reddy, kondtir@gmail.com 3554 o Change controller: IESG 3555 o Provisional registration? No 3557 9.4. CoAP Content-Formats Registration 3559 This section registers the CoAP Content-Format ID for the 3560 "application/dots+cbor" media type in the "CoAP Content-Formats" 3561 registry [IANA.CoAP.Content-Formats]. 3563 9.4.1. Registry Contents 3565 o Media Type: application/dots+cbor 3566 o Encoding: - 3567 o Id: TBD 3568 o Reference: [RFCXXXX] 3570 9.5. CBOR Tag Registration 3572 This section defines the DOTS CBOR tag as another means for 3573 applications to declare that a CBOR data structure is a DOTS signal 3574 channel object. Its use is optional and is intended for use in cases 3575 in which this information would not otherwise be known. DOTS CBOR 3576 tag is not required for DOTS signal channel protocol version 3577 specified in this document. If present, the DOTS tag MUST prefix a 3578 DOTS signal channel object. 3580 This section registers the DOTS signal channel CBOR tag in the "CBOR 3581 Tags" registry [IANA.CBOR.Tags]. 3583 9.5.1. Registry Contents 3585 o CBOR Tag: TBD (please assign the same value as the Content-Format) 3586 o Data Item: DDoS Open Threat Signaling (DOTS) signal channel object 3587 o Semantics: DDoS Open Threat Signaling (DOTS) signal channel 3588 object, as defined in [RFCXXXX] 3589 o Description of Semantics: [RFCXXXX] 3590 o Point of Contact: Tirumaleswar Reddy, kondtir@gmail.com 3592 9.6. DOTS Signal Channel Protocol Registry 3594 The document requests IANA to create a new registry, entitled "DOTS 3595 Signal Channel Registry". The following sections creates new sub- 3596 registries. 3598 9.6.1. DOTS Signal Channel CBOR Mappings Sub-Registry 3600 The document requests IANA to create a new sub-registry, entitled 3601 "DOTS Signal Channel CBOR Mappings". 3603 The structure of this sub-registry is provided in Section 9.6.1.1. 3604 Registration requests are evaluated using the criteria described in 3605 the CBOR Key Value instructions in the registration template below 3606 after a three-week review period on the dots-signal-reg- 3607 review@ietf.org mailing list, on the advice of one or more Designated 3608 Experts [RFC8126]. However, to allow for the allocation of values 3609 prior to publication, the Designated Experts may approve registration 3610 once they are satisfied that such a specification will be published. 3611 [[ Note to the RFC Editor: The name of the mailing list should be 3612 determined in consultation with the IESG and IANA. Suggested name: 3613 dots-signal-reg-review@ietf.org. ]] 3615 Registration requests sent to the mailing list for review should use 3616 an appropriate subject (e.g., "Request to register parameter: 3617 example"). Registration requests that are undetermined for a period 3618 longer than 21 days can be brought to the IESG's attention (using the 3619 iesg@ietf.org mailing list) for resolution. 3621 Criteria that should be applied by the Designated Experts includes 3622 determining whether the proposed registration duplicates existing 3623 functionality, whether it is likely to be of general applicability or 3624 whether it is useful only for a single application, and whether the 3625 registration description is clear. 3627 IANA must only accept registry updates from the Designated Experts 3628 and should direct all requests for registration to the review mailing 3629 list. 3631 It is suggested that multiple Designated Experts be appointed who are 3632 able to represent the perspectives of different applications using 3633 this specification in order to enable broadly informed review of 3634 registration decisions. In cases where a registration decision could 3635 be perceived as creating a conflict of interest for a particular 3636 Expert, that Expert should defer to the judgment of the other 3637 Experts. 3639 The registry is initially populated with the values in Table 6. 3641 9.6.1.1. Registration Template 3643 Parameter name: 3644 Parameter name as used in the DOTS signal channel. 3646 CBOR Key Value: 3647 Key value for the parameter. The key value MUST be an integer in 3648 the 1-65535 range. The key values of the comprehension-required 3649 range (0x0001 - 0x3FFF) and of the comprehension-optional range 3650 (0x8000 - 0xBFFF) are assigned by IETF Review [RFC8126]. The key 3651 values of the comprehension-optional range (0x4000 - 0x7FFF) are 3652 assigned by Designated Expert [RFC8126] and of the comprehension- 3653 optional range (0xC000 - 0xFFFF) are reserved for Private Use 3654 [RFC8126]. 3656 CBOR Major Type: 3657 CBOR Major type and optional tag for the parameter. 3659 Change Controller: 3660 For Standards Track RFCs, list the "IESG". For others, give the 3661 name of the responsible party. Other details (e.g., postal 3662 address, email address, home page URI) may also be included. 3664 Specification Document(s): 3665 Reference to the document or documents that specify the parameter, 3666 preferably including URIs that can be used to retrieve copies of 3667 the documents. An indication of the relevant sections may also be 3668 included but is not required. 3670 9.6.1.2. Initial Sub-Registry Content 3672 +----------------------+-------+-------+------------+---------------+ 3673 | Parameter Name | CBOR | CBOR | Change | Specification | 3674 | | Key | Major | Controller | Document(s) | 3675 | | Value | Type | | | 3676 +----------------------+-------+-------+------------+---------------+ 3677 | ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] | 3678 | nel:mitigation-scope | | | | | 3679 | scope | 2 | 4 | IESG | [RFCXXXX] | 3680 | cdid | 3 | 3 | IESG | [RFCXXXX] | 3681 | cuid | 4 | 3 | IESG | [RFCXXXX] | 3682 | mid | 5 | 0 | IESG | [RFCXXXX] | 3683 | target-prefix | 6 | 4 | IESG | [RFCXXXX] | 3684 | target-port-range | 7 | 4 | IESG | [RFCXXXX] | 3685 | lower-port | 8 | 0 | IESG | [RFCXXXX] | 3686 | upper-port | 9 | 0 | IESG | [RFCXXXX] | 3687 | target-protocol | 10 | 4 | IESG | [RFCXXXX] | 3688 | target-fqdn | 11 | 4 | IESG | [RFCXXXX] | 3689 | target-uri | 12 | 4 | IESG | [RFCXXXX] | 3690 | alias-name | 13 | 4 | IESG | [RFCXXXX] | 3691 | lifetime | 14 | 0/1 | IESG | [RFCXXXX] | 3692 | mitigation-start | 15 | 0 | IESG | [RFCXXXX] | 3693 | status | 16 | 0 | IESG | [RFCXXXX] | 3694 | conflict-information | 17 | 5 | IESG | [RFCXXXX] | 3695 | conflict-status | 18 | 0 | IESG | [RFCXXXX] | 3696 | conflict-cause | 19 | 0 | IESG | [RFCXXXX] | 3697 | retry-timer | 20 | 0 | IESG | [RFCXXXX] | 3698 | conflict-scope | 21 | 5 | IESG | [RFCXXXX] | 3699 | acl-list | 22 | 4 | IESG | [RFCXXXX] | 3700 | acl-name | 23 | 3 | IESG | [RFCXXXX] | 3701 | acl-type | 24 | 3 | IESG | [RFCXXXX] | 3702 | bytes-dropped | 25 | 0 | IESG | [RFCXXXX] | 3703 | bps-dropped | 26 | 0 | IESG | [RFCXXXX] | 3704 | pkts-dropped | 27 | 0 | IESG | [RFCXXXX] | 3705 | pps-dropped | 28 | 0 | IESG | [RFCXXXX] | 3706 | attack-status | 29 | 0 | IESG | [RFCXXXX] | 3707 | ietf-dots-signal- | 30 | 5 | IESG | [RFCXXXX] | 3708 | channel:signal-config| | | | | 3709 | sid | 31 | 0 | IESG | [RFCXXXX] | 3710 | mitigating-config | 32 | 5 | IESG | [RFCXXXX] | 3711 | heartbeat-interval | 33 | 5 | IESG | [RFCXXXX] | 3712 | min-value | 34 | 0 | IESG | [RFCXXXX] | 3713 | max-value | 35 | 0 | IESG | [RFCXXXX] | 3714 | current-value | 36 | 0 | IESG | [RFCXXXX] | 3715 | missing-hb-allowed | 37 | 5 | IESG | [RFCXXXX] | 3716 | max-retransmit | 38 | 5 | IESG | [RFCXXXX] | 3717 | ack-timeout | 39 | 5 | IESG | [RFCXXXX] | 3718 | ack-random-factor | 40 | 5 | IESG | [RFCXXXX] | 3719 | min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] | 3720 | max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] | 3721 | current-value- | 43 | 6tag4 | IESG | [RFCXXXX] | 3722 | decimal | | | | | 3723 | idle-config | 44 | 5 | IESG | [RFCXXXX] | 3724 | trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | 3725 | ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] | 3726 | nel:redirected-signal| | | | | 3727 | alt-server | 47 | 3 | IESG | [RFCXXXX] | 3728 | alt-server-record | 48 | 4 | IESG | [RFCXXXX] | 3729 +----------------------+-------+-------+------------+---------------+ 3731 Table 6: Initial DOTS Signal Channel CBOR Mappings Registry 3733 9.6.2. Status Codes Sub-Registry 3735 The document requests IANA to create a new sub-registry, entitled 3736 "DOTS Signal Channel Status Codes". Codes in this registry are used 3737 as valid values of 'status' parameter. 3739 The registry is initially populated with the following values: 3741 +-----+----------------------------------+--------------+-----------+ 3742 | Cod | Label | Description | Reference | 3743 | e | | | | 3744 +-----+----------------------------------+--------------+-----------+ 3745 | 1 | attack-mitigation-in-progress | Attack | [RFCXXXX] | 3746 | | | mitigation | | 3747 | | | setup is in | | 3748 | | | progress | | 3749 | | | (e.g., | | 3750 | | | changing the | | 3751 | | | network path | | 3752 | | | to redirect | | 3753 | | | the inbound | | 3754 | | | traffic to a | | 3755 | | | DOTS | | 3756 | | | mitigator). | | 3757 | 2 | attack-successfully-mitigated | Attack is | [RFCXXXX] | 3758 | | | being | | 3759 | | | successfully | | 3760 | | | mitigated | | 3761 | | | (e.g., | | 3762 | | | traffic is | | 3763 | | | redirected | | 3764 | | | to a DDoS | | 3765 | | | mitigator | | 3766 | | | and attack | | 3767 | | | traffic is | | 3768 | | | dropped). | | 3769 | 3 | attack-stopped | Attack has | [RFCXXXX] | 3770 | | | stopped and | | 3771 | | | the DOTS | | 3772 | | | client can | | 3773 | | | withdraw the | | 3774 | | | mitigation | | 3775 | | | request. | | 3776 | 4 | attack-exceeded-capability | Attack has | [RFCXXXX] | 3777 | | | exceeded the | | 3778 | | | mitigation | | 3779 | | | provider | | 3780 | | | capability. | | 3781 | 5 | dots-client-withdrawn-mitigation | DOTS client | [RFCXXXX] | 3782 | | | has | | 3783 | | | withdrawn | | 3784 | | | the | | 3785 | | | mitigation | | 3786 | | | request and | | 3787 | | | the | | 3788 | | | mitigation | | 3789 | | | is active | | 3790 | | | but | | 3791 | | | terminating. | | 3792 | 6 | attack-mitigation-terminated | Attack | [RFCXXXX] | 3793 | | | mitigation | | 3794 | | | is now | | 3795 | | | terminated. | | 3796 | 7 | attack-mitigation-withdrawn | Attack | [RFCXXXX] | 3797 | | | mitigation | | 3798 | | | is | | 3799 | | | withdrawn. | | 3800 | 8 | attack-mitigation-signal-loss | Attack | [RFCXXXX] | 3801 | | | mitigation | | 3802 | | | will be | | 3803 | | | triggered | | 3804 | | | for the | | 3805 | | | mitigation | | 3806 | | | request only | | 3807 | | | when the | | 3808 | | | DOTS signal | | 3809 | | | channel | | 3810 | | | session is | | 3811 | | | lost. | | 3812 +-----+----------------------------------+--------------+-----------+ 3814 New codes can be assigned via Standards Action [RFC8126]. 3816 9.6.3. Conflict Status Codes Sub-Registry 3818 The document requests IANA to create a new sub-registry, entitled 3819 "DOTS Signal Channel Conflict Status Codes". Codes in this registry 3820 are used as valid values of 'conflict-status' parameter. 3822 The registry is initially populated with the following values: 3824 +------+-------------------------------+----------------+-----------+ 3825 | Code | Label | Description | Reference | 3826 +------+-------------------------------+----------------+-----------+ 3827 | 1 | request-inactive-other-active | DOTS server | [RFCXXXX] | 3828 | | | has detected | | 3829 | | | conflicting | | 3830 | | | mitigation | | 3831 | | | requests from | | 3832 | | | different DOTS | | 3833 | | | clients. This | | 3834 | | | mitigation | | 3835 | | | request is | | 3836 | | | currently | | 3837 | | | inactive until | | 3838 | | | the conflicts | | 3839 | | | are resolved. | | 3840 | | | Another | | 3841 | | | mitigation | | 3842 | | | request is | | 3843 | | | active. | | 3844 | 2 | request-active | DOTS server | [RFCXXXX] | 3845 | | | has detected | | 3846 | | | conflicting | | 3847 | | | mitigation | | 3848 | | | requests from | | 3849 | | | different DOTS | | 3850 | | | clients. This | | 3851 | | | mitigation | | 3852 | | | request is | | 3853 | | | currently | | 3854 | | | active. | | 3855 | 3 | all-requests-inactive | DOTS server | [RFCXXXX] | 3856 | | | has detected | | 3857 | | | conflicting | | 3858 | | | mitigation | | 3859 | | | requests from | | 3860 | | | different DOTS | | 3861 | | | clients. All | | 3862 | | | conflicting | | 3863 | | | mitigation | | 3864 | | | requests are | | 3865 | | | inactive. | | 3866 +------+-------------------------------+----------------+-----------+ 3868 New codes can be assigned via Standards Action [RFC8126]. 3870 9.6.4. Conflict Cause Codes Sub-Registry 3872 The document requests IANA to create a new sub-registry, entitled 3873 "DOTS Signal Channel Conflict Cause Codes". Codes in this registry 3874 are used as valid values of 'conflict-cause' parameter. 3876 The registry is initially populated with the following values: 3878 +------+--------------------------+---------------------+-----------+ 3879 | Code | Label | Description | Reference | 3880 +------+--------------------------+---------------------+-----------+ 3881 | 1 | overlapping-targets | Overlapping | [RFCXXXX] | 3882 | | | targets. | | 3883 | 2 | conflict-with-acceptlist | Conflicts with an | [RFCXXXX] | 3884 | | | existing accept- | | 3885 | | | list. This code is | | 3886 | | | returned when the | | 3887 | | | DDoS mitigation | | 3888 | | | detects source | | 3889 | | | addresses/prefixes | | 3890 | | | in the accept- | | 3891 | | | listed ACLs are | | 3892 | | | attacking the | | 3893 | | | target. | | 3894 | 3 | cuid-collision | CUID Collision. | [RFCXXXX] | 3895 | | | This code is | | 3896 | | | returned when a | | 3897 | | | DOTS client uses a | | 3898 | | | 'cuid' that is | | 3899 | | | already used by | | 3900 | | | another DOTS | | 3901 | | | client. | | 3902 +------+--------------------------+---------------------+-----------+ 3904 New codes can be assigned via Standards Action [RFC8126]. 3906 9.6.5. Attack Status Codes Sub-Registry 3908 The document requests IANA to create a new sub-registry, entitled 3909 "DOTS Signal Channel Attack Status Codes". Codes in this registry 3910 are used as valid values of 'attack-status' parameter. 3912 The registry is initially populated with the following values: 3914 +------+-------------------------------+----------------+-----------+ 3915 | Code | Label | Description | Reference | 3916 +------+-------------------------------+----------------+-----------+ 3917 | 1 | under-attack | The DOTS | [RFCXXXX] | 3918 | | | client | | 3919 | | | determines | | 3920 | | | that it is | | 3921 | | | still under | | 3922 | | | attack. | | 3923 | 2 | attack-successfully-mitigated | The DOTS | [RFCXXXX] | 3924 | | | client | | 3925 | | | determines | | 3926 | | | that the | | 3927 | | | attack is | | 3928 | | | successfully | | 3929 | | | mitigated. | | 3930 +------+-------------------------------+----------------+-----------+ 3932 New codes can be assigned via Standards Action [RFC8126]. 3934 9.7. DOTS Signal Channel YANG Modules 3936 This document requests IANA to register the following URIs in the 3937 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 3939 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 3940 Registrant Contact: The IESG. 3941 XML: N/A; the requested URI is an XML namespace. 3943 URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel 3944 Registrant Contact: IANA. 3945 XML: N/A; the requested URI is an XML namespace. 3947 This document requests IANA to register the following YANG modules in 3948 the "YANG Module Names" subregistry [RFC7950] within the "YANG 3949 Parameters" registry. 3951 name: ietf-signal 3952 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 3953 prefix: signal 3954 reference: RFC XXXX 3956 name: iana-signal 3957 namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel 3958 prefix: iana-signal 3959 reference: RFC XXXX 3961 This document defines the initial version of the IANA-maintained 3962 iana-dots-signal-channel YANG module. IANA is requested to add this 3963 note: 3965 Status, conflict status, conflict cause, and attack status values 3966 must not be directly added to the iana-dots-signal-channel YANG 3967 module. They must instead be respectively added to the "DOTS 3968 Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause 3969 Codes", and "DOTS Attack Status Codes" registries. 3971 When a 'status', 'conflict-status', 'conflict-cause', or 'attack- 3972 status' value is respectively added to the "DOTS Status Codes", "DOTS 3973 Conflict Status Codes", "DOTS Conflict Cause Codes", or "DOTS Attack 3974 Status Codes" registry, a new "enum" statement must be added to the 3975 iana-dots-signal-channel YANG module. The following "enum" 3976 statement, and substatements thereof, should be defined: 3978 "enum": Replicates the label from the registry. 3980 "value": Contains the IANA-assigned value corresponding to the 3981 'status', 'conflict-status', 'conflict-cause', or 3982 'attack-status'. 3984 "description": Replicates the description from the registry. 3986 "reference": Replicates the reference from the registry and add the 3987 title of the document. 3989 When the iana-dots-signal-channel YANG module is updated, a new 3990 "revision" statement must be added in front of the existing revision 3991 statements. 3993 IANA is requested to add this note to "DOTS Status Codes", "DOTS 3994 Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack 3995 Status Codes" registries: 3997 When this registry is modified, the YANG module iana-dots-signal- 3998 channel must be updated as defined in [RFCXXXX]. 4000 10. Security Considerations 4002 Authenticated encryption MUST be used for data confidentiality and 4003 message integrity. The interaction between the DOTS agents requires 4004 Datagram Transport Layer Security (DTLS) and Transport Layer Security 4005 (TLS) with a cipher suite offering confidentiality protection and the 4006 guidance given in [RFC7525] MUST be followed to avoid attacks on 4007 (D)TLS. The (D)TLS protocol profile for DOTS signal channel is 4008 specified in Section 7. 4010 If TCP is used between DOTS agents, an attacker may be able to inject 4011 RST packets, bogus application segments, etc., regardless of whether 4012 TLS authentication is used. Because the application data is TLS 4013 protected, this will not result in the application receiving bogus 4014 data, but it will constitute a DoS on the connection. This attack 4015 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 4016 any bogus packets injected by an attacker will be rejected by the 4017 TCP-AO integrity check and therefore will never reach the TLS layer. 4019 Rate-limiting DOTS requests, including those with new 'cuid' values, 4020 from the same DOTS client defends against DoS attacks that would 4021 result in varying the 'cuid' to exhaust DOTS server resources. Rate- 4022 limit policies SHOULD be enforced on DOTS gateways (if deployed) and 4023 DOTS servers. 4025 In order to prevent leaking internal information outside a client- 4026 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 4027 the identification information that pertains to internal DOTS clients 4028 (e.g., source IP address, client's hostname) unless explicitly 4029 configured to do so. 4031 DOTS servers MUST verify that requesting DOTS clients are entitled to 4032 trigger actions on a given IP prefix. That is, only actions on IP 4033 resources that belong to the DOTS client' domain MUST be authorized 4034 by a DOTS server. The exact mechanism for the DOTS servers to 4035 validate that the target prefixes are within the scope of the DOTS 4036 client's domain is deployment-specific. 4038 The presence of DOTS gateways may lead to infinite forwarding loops, 4039 which is undesirable. To prevent and detect such loops, this 4040 document uses the Hop-Limit Option. 4042 CoAP-specific security considerations are discussed in Section 11 of 4043 [RFC7252], while CBOR-related security considerations are discussed 4044 in Section 8 of [RFC7049]. 4046 11. Contributors 4048 The following individuals have contributed to this document: 4050 o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust 4052 o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email: 4053 mgeller@cisco.com 4055 o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States, 4056 Email: rgm@htt-consult.com 4058 o Dan Wing, Email: dwing-ietf@fuggles.com 4060 12. Acknowledgements 4062 Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, 4063 Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang 4064 Xia, Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke and 4065 Nesredien Suleiman for the discussion and comments. 4067 Thanks to the core WG for the recommendations on Hop-Limit and 4068 redirect signaling. 4070 13. References 4072 13.1. Normative References 4074 [IANA.CBOR.Tags] 4075 IANA, "Concise Binary Object Representation (CBOR) Tags", 4076 . 4079 [IANA.CoAP.Content-Formats] 4080 IANA, "CoAP Content-Formats", 4081 . 4084 [IANA.MediaTypes] 4085 IANA, "Media Types", 4086 . 4088 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4089 Requirement Levels", BCP 14, RFC 2119, 4090 DOI 10.17487/RFC2119, March 1997, 4091 . 4093 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4094 DOI 10.17487/RFC3688, January 2004, 4095 . 4097 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 4098 Ciphersuites for Transport Layer Security (TLS)", 4099 RFC 4279, DOI 10.17487/RFC4279, December 2005, 4100 . 4102 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4103 (TLS) Protocol Version 1.2", RFC 5246, 4104 DOI 10.17487/RFC5246, August 2008, 4105 . 4107 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4108 Housley, R., and W. Polk, "Internet X.509 Public Key 4109 Infrastructure Certificate and Certificate Revocation List 4110 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4111 . 4113 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 4114 Uniform Resource Identifiers (URIs)", RFC 5785, 4115 DOI 10.17487/RFC5785, April 2010, 4116 . 4118 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 4119 Extensions: Extension Definitions", RFC 6066, 4120 DOI 10.17487/RFC6066, January 2011, 4121 . 4123 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 4124 Verification of Domain-Based Application Service Identity 4125 within Internet Public Key Infrastructure Using X.509 4126 (PKIX) Certificates in the Context of Transport Layer 4127 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 4128 2011, . 4130 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4131 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 4132 January 2012, . 4134 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4135 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4136 . 4138 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 4139 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 4140 October 2013, . 4142 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 4143 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 4144 Transport Layer Security (TLS) and Datagram Transport 4145 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 4146 June 2014, . 4148 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 4149 Application Protocol (CoAP)", RFC 7252, 4150 DOI 10.17487/RFC7252, June 2014, 4151 . 4153 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 4154 "Recommendations for Secure Use of Transport Layer 4155 Security (TLS) and Datagram Transport Layer Security 4156 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 4157 2015, . 4159 [RFC7641] Hartke, K., "Observing Resources in the Constrained 4160 Application Protocol (CoAP)", RFC 7641, 4161 DOI 10.17487/RFC7641, September 2015, 4162 . 4164 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4165 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4166 . 4168 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 4169 the Constrained Application Protocol (CoAP)", RFC 7959, 4170 DOI 10.17487/RFC7959, August 2016, 4171 . 4173 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 4174 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 4175 March 2017, . 4177 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4178 Writing an IANA Considerations Section in RFCs", BCP 26, 4179 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4180 . 4182 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4183 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4184 May 2017, . 4186 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 4187 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 4188 Application Protocol) over TCP, TLS, and WebSockets", 4189 RFC 8323, DOI 10.17487/RFC8323, February 2018, 4190 . 4192 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4193 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4194 . 4196 13.2. Informative References 4198 [I-D.ietf-core-comi] 4199 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 4200 Management Interface", draft-ietf-core-comi-04 (work in 4201 progress), November 2018. 4203 [I-D.ietf-core-hop-limit] 4204 Boucadair, M., K, R., and J. Shallow, "Constrained 4205 Application Protocol (CoAP) Hop Limit Option", draft-ietf- 4206 core-hop-limit-02 (work in progress), December 2018. 4208 [I-D.ietf-core-yang-cbor] 4209 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 4210 Minaburo, "CBOR Encoding of Data Modeled with YANG", 4211 draft-ietf-core-yang-cbor-07 (work in progress), September 4212 2018. 4214 [I-D.ietf-dots-architecture] 4215 Mortensen, A., Andreasen, F., K, R., Teague, N., Compton, 4216 R., and c. christopher_gray3@cable.comcast.com, 4217 "Distributed-Denial-of-Service Open Threat Signaling 4218 (DOTS) Architecture", draft-ietf-dots-architecture-10 4219 (work in progress), December 2018. 4221 [I-D.ietf-dots-data-channel] 4222 Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P., 4223 Mortensen, A., and N. Teague, "Distributed Denial-of- 4224 Service Open Threat Signaling (DOTS) Data Channel 4225 Specification", draft-ietf-dots-data-channel-23 (work in 4226 progress), November 2018. 4228 [I-D.ietf-dots-requirements] 4229 Mortensen, A., Moskowitz, R., and R. K, "Distributed 4230 Denial of Service (DDoS) Open Threat Signaling 4231 Requirements", draft-ietf-dots-requirements-16 (work in 4232 progress), October 2018. 4234 [I-D.ietf-dots-use-cases] 4235 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 4236 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 4237 Open Threat Signaling", draft-ietf-dots-use-cases-16 (work 4238 in progress), July 2018. 4240 [I-D.ietf-tls-dtls13] 4241 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 4242 Datagram Transport Layer Security (DTLS) Protocol Version 4243 1.3", draft-ietf-tls-dtls13-30 (work in progress), 4244 November 2018. 4246 [proto_numbers] 4247 "IANA, "Protocol Numbers"", 2011, 4248 . 4250 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4251 DOI 10.17487/RFC0791, September 1981, 4252 . 4254 [RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18, 4255 RFC 1983, DOI 10.17487/RFC1983, August 1996, 4256 . 4258 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 4259 Address Translator (Traditional NAT)", RFC 3022, 4260 DOI 10.17487/RFC3022, January 2001, 4261 . 4263 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4264 Resource Identifier (URI): Generic Syntax", STD 66, 4265 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4266 . 4268 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 4269 Congestion Control Protocol (DCCP)", RFC 4340, 4270 DOI 10.17487/RFC4340, March 2006, 4271 . 4273 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 4274 (CIDR): The Internet Address Assignment and Aggregation 4275 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 4276 2006, . 4278 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 4279 Denial-of-Service Considerations", RFC 4732, 4280 DOI 10.17487/RFC4732, December 2006, 4281 . 4283 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 4284 Translation (NAT) Behavioral Requirements for Unicast 4285 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 4286 2007, . 4288 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 4289 RFC 4960, DOI 10.17487/RFC4960, September 2007, 4290 . 4292 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 4293 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 4294 . 4296 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 4297 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 4298 DOI 10.17487/RFC5389, October 2008, 4299 . 4301 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 4302 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 4303 June 2010, . 4305 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 4306 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 4307 DOI 10.17487/RFC6052, October 2010, 4308 . 4310 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 4311 NAT64: Network Address and Protocol Translation from IPv6 4312 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 4313 April 2011, . 4315 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 4316 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 4317 DOI 10.17487/RFC6234, May 2011, 4318 . 4320 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 4321 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 4322 . 4324 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 4325 "Default Address Selection for Internet Protocol Version 6 4326 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 4327 . 4329 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 4330 Specifications and Registration Procedures", BCP 13, 4331 RFC 6838, DOI 10.17487/RFC6838, January 2013, 4332 . 4334 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 4335 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 4336 DOI 10.17487/RFC6887, April 2013, 4337 . 4339 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 4340 A., and H. Ashida, "Common Requirements for Carrier-Grade 4341 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 4342 April 2013, . 4344 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 4345 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 4346 . 4348 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 4349 "Architectural Considerations in Smart Object Networking", 4350 RFC 7452, DOI 10.17487/RFC7452, March 2015, 4351 . 4353 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 4354 NETCONF Protocol over Transport Layer Security (TLS) with 4355 Mutual X.509 Authentication", RFC 7589, 4356 DOI 10.17487/RFC7589, June 2015, 4357 . 4359 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 4360 Layer Security (TLS) False Start", RFC 7918, 4361 DOI 10.17487/RFC7918, August 2016, 4362 . 4364 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 4365 (TLS) Cached Information Extension", RFC 7924, 4366 DOI 10.17487/RFC7924, July 2016, 4367 . 4369 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 4370 RFC 7951, DOI 10.17487/RFC7951, August 2016, 4371 . 4373 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 4374 Better Connectivity Using Concurrency", RFC 8305, 4375 DOI 10.17487/RFC8305, December 2017, 4376 . 4378 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 4379 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 4380 . 4382 Authors' Addresses 4383 Tirumaleswar Reddy (editor) 4384 McAfee, Inc. 4385 Embassy Golf Link Business Park 4386 Bangalore, Karnataka 560071 4387 India 4389 Email: kondtir@gmail.com 4391 Mohamed Boucadair (editor) 4392 Orange 4393 Rennes 35000 4394 France 4396 Email: mohamed.boucadair@orange.com 4398 Prashanth Patil 4399 Cisco Systems, Inc. 4401 Email: praspati@cisco.com 4403 Andrew Mortensen 4404 Arbor Networks, Inc. 4405 2727 S. State St 4406 Ann Arbor, MI 48104 4407 United States 4409 Email: amortensen@arbor.net 4411 Nik Teague 4412 Verisign, Inc. 4413 United States 4415 Email: nteague@verisign.com