idnits 2.17.1 draft-ietf-dots-signal-channel-15.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([RFCXXXX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2161 has weird spacing: '...er-port ine...' == Line 2162 has weird spacing: '...er-port ine...' == Line 2177 has weird spacing: '...er-port ine...' == Line 2178 has weird spacing: '...er-port ine...' == Line 2240 has weird spacing: '...rw addr ine...' -- The document date (January 10, 2018) is 2270 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 3289, 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 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-02 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-05 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-05 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-11 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-10 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-09 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-04 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-22 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-22 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 8 errors (**), 0 flaws (~~), 16 warnings (==), 7 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: July 14, 2018 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 January 10, 2018 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel 16 draft-ietf-dots-signal-channel-15 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 with the RFC number to be assigned to 32 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"; 39 o "| 3.00 | Alternate server | [RFCXXXX] |" 41 o reference: RFC XXXX 43 o This RFC 45 Please update TBD statements with the port number to be assigned to 46 DOTS Signal Channel Protocol. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at https://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on July 14, 2018. 65 Copyright Notice 67 Copyright (c) 2018 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (https://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 2. Notational Conventions and Terminology . . . . . . . . . . . 5 84 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 85 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8 86 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8 87 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8 88 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9 89 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10 90 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11 91 4.4.2. Retrieve Information Related to a Mitigation . . . . 22 92 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 31 93 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 33 94 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 34 95 4.5.1. Discover Configuration Parameters . . . . . . . . . . 36 96 4.5.2. Convey DOTS Signal Channel Session Configuration . . 39 97 4.5.3. Delete DOTS Signal Channel Session Configuration . . 45 98 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 46 99 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 47 100 5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 49 101 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 49 102 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 51 103 6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 66 104 7. (D)TLS Protocol Profile and Performance Considerations . . . 67 105 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 67 106 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 69 107 7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 70 108 8. Mutual Authentication of DOTS Agents & Authorization of DOTS 109 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 111 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 72 112 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 72 113 9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 73 114 9.4. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 73 115 9.4.1. Registration Template . . . . . . . . . . . . . . . . 73 116 9.4.2. Initial Registry Contents . . . . . . . . . . . . . . 74 117 9.5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 80 118 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 80 119 10.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 81 120 11. Security Considerations . . . . . . . . . . . . . . . . . . . 81 121 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 82 122 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82 123 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 124 14.1. Normative References . . . . . . . . . . . . . . . . . . 82 125 14.2. Informative References . . . . . . . . . . . . . . . . . 85 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 128 1. Introduction 130 A distributed denial-of-service (DDoS) attack is an attempt to make 131 machines or network resources unavailable to their intended users. 132 In most cases, sufficient scale can be achieved by compromising 133 enough end-hosts and using those infected hosts to perpetrate and 134 amplify the attack. The victim in this attack can be an application 135 server, a host, a router, a firewall, or an entire network. 137 Network applications have finite resources like CPU cycles, the 138 number of processes or threads they can create and use, the maximum 139 number of simultaneous connections it can handle, the limited 140 resources of the control plane, etc. When processing network 141 traffic, such applications are supposed to use these resources to 142 offer the intended task in the most efficient manner. However, a 143 DDoS attacker may be able to prevent an application from performing 144 its intended task by making the application exhaust its finite 145 resources. 147 TCP DDoS SYN-flood, for example, is a memory-exhausting attack while 148 ACK-flood is a CPU-exhausting attack [RFC4987]. Attacks on the link 149 are carried out by sending enough traffic so that the link becomes 150 congested, thereby likely causing packet loss for legitimate traffic. 151 Stateful firewalls can also be attacked by sending traffic that 152 causes the firewall to maintain an excessive number of states that 153 may jeopardize the firewall's operation overall, besides like 154 performance impacts. The firewall then runs out of memory, and can 155 no longer instantiate the states required to process legitimate 156 flows. Other possible DDoS attacks are discussed in [RFC4732]. 158 In many cases, it may not be possible for network administrators to 159 determine the cause(s) of an attack. They may instead just realize 160 that certain resources seem to be under attack. This document 161 defines a lightweight protocol that allows a DOTS client to request 162 mitigation from one or more DOTS servers for protection against 163 detected, suspected, or anticipated attacks. This protocol enables 164 cooperation between DOTS agents to permit a highly-automated network 165 defense that is robust, reliable, and secure. 167 An example of a network diagram that illustrates a deployment of DOTS 168 agents is shown in Figure 1. In this example, a DOTS server is 169 operating on the access network. A DOTS client is located on the LAN 170 (Local Area Network), while a DOTS gateway is embedded in the CPE 171 (Customer Premises Equipment). 173 Network 174 Resource CPE router Access network __________ 175 +-----------+ +--------------+ +-------------+ / \ 176 | |___| |____| |___ | Internet | 177 |DOTS client| | DOTS gateway | | DOTS server | | | 178 | | | | | | | | 179 +-----------+ +--------------+ +-------------+ \__________/ 181 Figure 1: Sample DOTS Deployment (1) 183 DOTS servers can also be reachable over the Internet, as depicted in 184 Figure 2. 186 Network DDoS mitigation 187 Resource CPE router __________ service 188 +-----------+ +-------------+ / \ +-------------+ 189 | |___| |____| |___ | | 190 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 191 | | | | | | | | 192 +-----------+ +-------------+ \__________/ +-------------+ 194 Figure 2: Sample DOTS Deployment (2) 196 In typical deployments, the DOTS client belongs to a different 197 administrative domain than the DOTS server. For example, the DOTS 198 client is embedded in a firewall protecting services owned and 199 operated by a domain, while the DOTS server is owned and operated by 200 a different domain providing DDoS mitigation services. The latter 201 might or might not provide connectivity services to the network 202 hosting the DOTS client. 204 The DOTS server may (not) be co-located with the DOTS mitigator. In 205 typical deployments, the DOTS server belongs to the same 206 administrative domain as the mitigator. The DOTS client can 207 communicate directly with a DOTS server or indirectly via a DOTS 208 gateway. 210 The document adheres to the DOTS architecture 211 [I-D.ietf-dots-architecture]. The requirements for DOTS signal 212 channel protocol are documented in [I-D.ietf-dots-requirements]. 213 This document satisfies all the use cases discussed in 214 [I-D.ietf-dots-use-cases]. 216 This document focuses on the DOTS signal channel. This is a 217 companion document of the DOTS data channel specification 218 [I-D.ietf-dots-data-channel] that defines a configuration and a bulk 219 data exchange mechanism supporting the DOTS signal channel. 221 2. Notational Conventions and Terminology 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in 226 [RFC2119]. 228 (D)TLS is used for statements that apply to both Transport Layer 229 Security [RFC5246] and Datagram Transport Layer Security [RFC6347]. 230 Specific terms are used for any statement that applies to either 231 protocol alone. 233 The reader should be familiar with the terms defined in 234 [I-D.ietf-dots-architecture]. 236 The meaning of the symbols in YANG tree diagrams is defined in 237 [I-D.ietf-netmod-yang-tree-diagrams]. 239 3. Design Overview 241 The DOTS signal channel is built on top of the Constrained 242 Application Protocol (CoAP) [RFC7252], a lightweight protocol 243 originally designed for constrained devices and networks. The many 244 features of CoAP (expectation of packet loss, support for 245 asynchronous non-confirmable messaging, congestion control, small 246 message overhead limiting the need for fragmentation, use of minimal 247 resources, and support for (D)TLS) makes it a good candidate to build 248 the DOTS signaling mechanism from. 250 The DOTS signal channel is layered on existing standards (Figure 3). 252 +---------------------+ 253 | DOTS Signal Channel | 254 +---------------------+ 255 | CoAP | 256 +----------+----------+ 257 | TLS | DTLS | 258 +----------+----------+ 259 | TCP | UDP | 260 +----------+----------+ 261 | IP | 262 +---------------------+ 264 Figure 3: Abstract Layering of DOTS Signal Channel over CoAP over 265 (D)TLS 267 By default, a DOTS signal channel MUST run over port number TBD as 268 defined in Section 9.1, for both UDP and TCP, unless the DOTS server 269 has a mutual agreement with its DOTS clients to use a different port 270 number. DOTS clients may alternatively support means to dynamically 271 discover the ports used by their DOTS servers. In order to use a 272 distinct port number (as opposed to TBD), DOTS clients and servers 273 should support a configurable parameter to supply the port number to 274 use. The rationale for not using the default port number 5684 275 ((D)TLS CoAP) is to allow for differentiated behaviors in 276 environments where both a DOTS gateway and an IoT gateway (e.g., 277 Figure 3 of [RFC7452]) are present. 279 The signal channel is initiated by the DOTS client (Section 4.4). 280 Once the signal channel is established, the DOTS agents periodically 281 send heartbeats to keep the channel active (Section 4.7). At any 282 time, the DOTS client may send a mitigation request message to a DOTS 283 server over the active channel. While mitigation is active because 284 of the higher likelihood of packet loss during a DDoS attack, the 285 DOTS server periodically sends status messages to the client, 286 including basic mitigation feedback details. Mitigation remains 287 active until the DOTS client explicitly terminates mitigation, or the 288 mitigation lifetime expires. 290 DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS 291 [RFC5246] over TCP. Likewise, DOTS requests may be sent using IPv4 292 or IPv6 transfer capabilities. A Happy Eyeballs procedure for DOTS 293 signal channel is specified in Section 4.3. 295 Messages exchanged between DOTS agents are serialized using Concise 296 Binary Object Representation (CBOR) [RFC7049], CBOR is a binary 297 encoding scheme designed for small code and message size. CBOR- 298 encoded payloads are used to carry signal channel-specific payload 299 messages which convey request parameters and response information 300 such as errors. In order to allow the use of the same data models, 301 [RFC7951] specifies the JSON encoding of YANG-modeled data. A 302 similar effort for CBOR is defined in [I-D.ietf-core-yang-cbor]. All 303 parameters in the payload of the DOTS signal channel are mapped to 304 CBOR types as specified in Section 6. 306 From that standpoint, this document specifies a YANG data model for 307 representing mitigation scopes and DOTS signal channel session 308 configuration data (Section 5). Representing these data as CBOR data 309 is assumed to follow the rules in [I-D.ietf-core-yang-cbor] or those 310 in [RFC7951] combined with JSON/CBOR conversion rules in [RFC7049]. 312 In order to prevent fragmentation, DOTS agents must follow the 313 recommendations documented in Section 4.6 of [RFC7252]. Refer to 314 Section 7.3 for more details. 316 DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The 317 payload included in CoAP responses with 2.xx and 3.xx Response Codes 318 MUST be of content type "application/cbor" (Section 5.5.1 of 319 [RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes 320 MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The 321 Diagnostic Payload may contain additional information to aid 322 troubleshooting. 324 In deployments where multiple DOTS clients are enabled in a network 325 (owned and operated by the same entity), the DOTS server may detect 326 conflicting mitigation requests from these clients. This document 327 does not aim to specify a comprehensive list of conditions under 328 which a DOTS server will characterize two mitigation requests from 329 distinct DOTS clients as conflicting, nor recommend a DOTS server 330 behavior for processing conflicting mitigation requests. Those 331 considerations are implementation- and deployment-specific. 332 Nevertheless, the document specifies the mechanisms to notify DOTS 333 clients when conflicts occur, including the conflict cause 334 (Section 4.4). 336 In deployments where one or more translators (e.g., Traditional NAT 337 [RFC3022], CGN [RFC6888], NAT64 [RFC6146], NPTv6 [RFC6296]) are 338 enabled between the client's network and the DOTS server, DOTS signal 339 channel messages forwarded to a DOTS server must not include internal 340 IP addresses/prefixes and/or port numbers; external addresses/ 341 prefixes and/or port numbers as assigned by the translator must be 342 used instead. This document does not make any recommendation about 343 possible translator discovery mechanisms. The following are some 344 (non-exhaustive) deployment examples that may be considered: 346 o Port Control Protocol (PCP) [RFC6887] or Session Traversal 347 Utilities for NAT (STUN) [RFC5389] may be used to retrieve the 348 external addresses/prefixes and/or port numbers. Information 349 retrieved by means of PCP or STUN will be used to feed the DOTS 350 signal channel messages that will be sent to a DOTS server. 352 o A DOTS gateway may be co-located with the translator. The DOTS 353 gateway will need to update the DOTS messages, based upon the 354 local translator's binding table. 356 4. DOTS Signal Channel: Messages & Behaviors 358 4.1. DOTS Server(s) Discovery 360 This document assumes that DOTS clients are provisioned with the 361 reachability information of their DOTS server(s) using a variety of 362 means (e.g., local configuration, or dynamic means such as DHCP). 363 These means are out of scope of this document. 365 Likewise, it is out of scope of this document to specify the behavior 366 of a DOTS client when it sends requests (e.g., contact all servers, 367 select one server among the list) when multiple DOTS servers are 368 provisioned. 370 4.2. CoAP URIs 372 The DOTS server MUST support the use of the path-prefix of "/.well- 373 known/" as defined in [RFC5785] and the registered name of "dots". 374 Each DOTS operation is indicated by a path-suffix that indicates the 375 intended operation. The operation path (Table 1) is appended to the 376 path-prefix to form the URI used with a CoAP request to perform the 377 desired DOTS operation. 379 +-----------------------+----------------+-------------+ 380 | Operation | Operation path | Details | 381 +-----------------------+----------------+-------------+ 382 | Mitigation | /v1/mitigate | Section 4.4 | 383 +-----------------------+----------------+-------------+ 384 | Session configuration | /v1/config | Section 4.5 | 385 +-----------------------+----------------+-------------+ 387 Table 1: Operations and their Corresponding URIs 389 4.3. Happy Eyeballs for DOTS Signal Channel 391 [I-D.ietf-dots-requirements] mentions that DOTS agents will have to 392 support both connectionless and connection-oriented protocols. As 393 such, the DOTS signal channel is designed to operate with DTLS over 394 UDP and TLS over TCP. Further, a DOTS client may acquire a list of 395 IPv4 and IPv6 addresses (Section 4.1), each of which can be used to 396 contact the DOTS server using UDP and TCP. The following specifies 397 the procedure to follow to select the address family and the 398 transport protocol for sending DOTS signal channel messages. 400 Such procedure is needed to avoid experiencing long connection 401 delays. For example, if an IPv4 path to reach a DOTS server is 402 found, but the DOTS server's IPv6 path is not working, a dual-stack 403 DOTS client may experience a significant connection delay compared to 404 an IPv4-only DOTS client. The other problem is that if a middlebox 405 between the DOTS client and DOTS server is configured to block UDP 406 traffic, the DOTS client will fail to establish a DTLS session with 407 the DOTS server and, as a consequence, will have to fall back to TLS 408 over TCP, thereby incurring significant connection delays. 410 To overcome these connection setup problems, the DOTS client attempts 411 to connect to its DOTS server(s) using both IPv6 and IPv4, and tries 412 both DTLS over UDP and TLS over TCP in a manner similar to the Happy 413 Eyeballs mechanism [RFC6555]. These connection attempts are 414 performed by the DOTS client when it initializes. The results of the 415 Happy Eyeballs procedure are used by the DOTS client for sending its 416 subsequent messages to the DOTS server. 418 The order of preference of DOTS signal channel address family and 419 transport protocol (most preferred first) is: UDP over IPv6, UDP over 420 IPv4, TCP over IPv6, and finally TCP over IPv4. This order adheres 421 to the address preference order specified in [RFC6724] and the DOTS 422 signal channel preference which privileges the use of UDP over TCP 423 (to avoid TCP's head of line blocking). 425 In reference to Figure 4, the DOTS client sends two TCP SYNs and two 426 DTLS ClientHello messages at the same time over IPv6 and IPv4. In 427 this example, it is assumed that the IPv6 path is broken and UDP 428 traffic is dropped by a middlebox but has little impact to the DOTS 429 client because there is no long delay before using IPv4 and TCP. The 430 DOTS client repeats the mechanism to discover whether DOTS signal 431 channel messages with DTLS over UDP becomes available from the DOTS 432 server, so the DOTS client can migrate the DOTS signal channel from 433 TCP to UDP. Such probing SHOULD NOT be done more frequently than 434 every 24 hours and MUST NOT be done more frequently than every 5 435 minutes. 437 +-----------+ +-----------+ 438 |DOTS client| |DOTS server| 439 +-----------+ +-----------+ 440 | | 441 |--DTLS ClientHello, IPv6 ---->X | 442 |--TCP SYN, IPv6-------------->X | 443 |--DTLS ClientHello, IPv4 ---->X | 444 |--TCP SYN, IPv4--------------------------------------->| 445 |--DTLS ClientHello, IPv6 ---->X | 446 |--TCP SYN, IPv6-------------->X | 447 |<-TCP SYNACK-------------------------------------------| 448 |--DTLS ClientHello, IPv4 ---->X | 449 |--TCP ACK--------------------------------------------->| 450 |<------------Establish TLS Session-------------------->| 451 |----------------DOTS signal--------------------------->| 452 | | 454 Figure 4: DOTS Happy Eyeballs 456 4.4. DOTS Mitigation Methods 458 The following methods are used by a DOTS client to request, withdraw, 459 or retrieve the status of mitigation requests: 461 PUT: DOTS clients use the PUT method to request mitigation from a 462 DOTS server (Section 4.4.1). During active mitigation, DOTS 463 clients may use PUT requests to carry mitigation efficacy 464 updates to the DOTS server (Section 4.4.3). 466 GET: DOTS clients may use the GET method to subscribe to DOTS 467 server status messages, or to retrieve the list of its 468 mitigations maintained by a DOTS server (Section 4.4.2). 470 DELETE: DOTS clients use the DELETE method to withdraw a request for 471 mitigation from a DOTS server (Section 4.4.4). 473 Mitigation request and response messages are marked as Non- 474 confirmable messages (Section 2.2 of [RFC7252]). 476 DOTS agents SHOULD follow the data transmission guidelines discussed 477 in Section 3.1.3 of [RFC8085] and control transmission behavior by 478 not sending more than one UDP datagram per RTT to the peer DOTS agent 479 on average. 481 Requests marked by the DOTS client as Non-confirmable messages are 482 sent at regular intervals until a response is received from the DOTS 483 server. If the DOTS client cannot maintain an RTT estimate, it 484 SHOULD NOT send more than one Non-confirmable request every 3 485 seconds, and SHOULD use an even less aggressive rate whenever 486 possible (case 2 in Section 3.1.3 of [RFC8085]). 488 4.4.1. Request Mitigation 490 When a DOTS client requires mitigation for some reason, the DOTS 491 client uses the CoAP PUT method to send a mitigation request to its 492 DOTS server(s) (Figure 5, illustrated in JSON diagnostic notation). 494 If this DOTS client is entitled to solicit the DOTS service, the DOTS 495 server can enable mitigation on behalf of the DOTS client by 496 communicating the DOTS client's request to the mitigator and relaying 497 selected mitigator feedback to the requesting DOTS client. 499 Header: PUT (Code=0.03) 500 Uri-Host: "host" 501 Uri-Path: ".well-known" 502 Uri-Path: "dots" 503 Uri-Path: "version" 504 Uri-Path: "mitigate" 505 Uri-Path: "cuid=xyz" 506 Content-Type: "application/cbor" 507 { 508 "mitigation-scope": { 509 "scope": [ 510 { 511 "mitigation-id": integer, 512 "target-prefix": [ 513 "string" 514 ], 515 "target-port-range": [ 516 { 517 "lower-port": integer, 518 "upper-port": integer 519 } 520 ], 521 "target-protocol": [ 522 integer 523 ], 524 "target-fqdn": [ 525 "string" 526 ], 527 "target-uri": [ 528 "string" 529 ], 530 "alias-name": [ 531 "string" 532 ], 533 "lifetime": integer 534 } 535 ] 536 } 537 } 539 Figure 5: PUT to Convey DOTS Mitigation Requests 541 The parameters are described below: 543 cuid: Stands for Client Unique Identifier. A unique identifier that 544 is meant to prevent collisions among DOTS clients from the same 545 domain. It MUST be generated by DOTS clients. A variety of 546 methods can be used to generate such identifier, e.g., 547 cryptographic means [RFC4086], mimic the algorithm in [RFC4941], 548 prepend a timestamp to a randomly generated identifier, etc. 549 Implementations MAY use the form "identifier@host", for example 550 "7dec-11d0-a765-00a0c91e6bf6@foo.bar.example". 552 The CUID is intended to be stable when communicating with a given 553 DOTS server, i.e., the CUID used by a DOTS client SHOULD NOT 554 change over time. Distinct CUIDs MAY be used per DOTS server. 556 DOTS servers MUST treat CUIDs as opaque values and MUST only 557 compare CUIDs for equality. That is, DOTS servers must not 558 interpret CUIDs. DOTS servers MUST return 4.09 (Conflict) error 559 code to a DOTS peer to notify that the CUID is already in-use by 560 another DOTS client of the same domain. Upon receipt of that 561 error code, a new CUID MUST be generated by the DOTS peer. 563 Client-domain DOTS gateways MAY rewrite the CUIDs used by internal 564 DOTS clients. Triggers for such rewriting are out of scope. 566 This is a mandatory attribute. 568 mitigation-id: Identifier for the mitigation request represented 569 with an integer. This identifier MUST be unique for each 570 mitigation request bound to the DOTS client, i.e., the 571 'mitigation-id' parameter value in the mitigation request needs to 572 be unique relative to the 'mitigation-id' parameter values of 573 active mitigation requests conveyed from the DOTS client to the 574 DOTS server. This identifier MUST be generated by the DOTS 575 client. This document does not make any assumption about how this 576 identifier is generated. 578 This is a mandatory attribute. 580 target-prefix: A list of prefixes identifying resources under 581 attack. Prefixes are represented using Classless Inter-Domain 582 Routing (CIDR) notation [RFC4632]. 583 As a reminder, the prefix length must be less than or equal to 32 584 (resp. 128) for IPv4 (resp. IPv6). 586 This is an optional attribute. 588 target-port-range: A list of port numbers bound to resources under 589 attack. 591 The port range is defined by two bounds, a lower port number 592 (lower-port) and an upper port number (upper-port). When only 593 'lower-port' is present, it represents a single port number. For 594 TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], 595 or Datagram Congestion Control Protocol (DCCP) [RFC4340], the 596 range of ports can be, for example, 1024-65535. 598 This is an optional attribute. 600 target-protocol: A list of protocols involved in an attack. Values 601 are taken from the IANA protocol registry [proto_numbers]. 603 The value '0' has a special meaning for 'all protocols'. 605 This is an optional attribute. 607 target-fqdn: A list of Fully Qualified Domain Names (FQDNs) 608 identifying resources under attack. An FQDN is the full name of a 609 resource, rather than just its hostname. For example, "venera" is 610 a hostname, and "venera.isi.edu" is an FQDN. 612 This is an optional attribute. 614 target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986] 615 identifying resources under attack. 617 This is an optional attribute. 619 alias-name: A list of aliases of resources for which the mitigation 620 is requested. Aliases can be created using the DOTS data channel 621 (Section 6.1 of [I-D.ietf-dots-data-channel]), direct 622 configuration, or other means. An alias is used in subsequent 623 signal channel exchanges to refer more efficiently to the 624 resources under attack. 626 This is an optional attribute. 628 lifetime: Lifetime of the mitigation request in seconds. The 629 RECOMMENDED lifetime of a mitigation request is 3600 seconds (60 630 minutes) -- this value was chosen to be long enough so that 631 refreshing is not typically a burden on the DOTS client, while 632 expiring the request where the client has unexpectedly quit in a 633 timely manner. DOTS clients MUST include this parameter in their 634 mitigation requests. Upon the expiry of this lifetime, and if the 635 request is not refreshed, the mitigation request is removed. The 636 request can be refreshed by sending the same request again. 638 A lifetime of '0' in a mitigation request is an invalid value. 640 A lifetime of negative one (-1) indicates indefinite lifetime for 641 the mitigation request. The DOTS server MAY refuse indefinite 642 lifetime, for policy reasons; the granted lifetime value is 643 returned in the response. DOTS clients MUST be prepared to not be 644 granted mitigations with indefinite lifetimes. 646 The DOTS server MUST always indicate the actual lifetime in the 647 response and the remaining lifetime in status messages sent to the 648 DOTS client. 650 This is a mandatory attribute. 652 In deployments where server-domain DOTS gateways are enabled, 653 identity information about the origin source client domain has to be 654 supplied to the DOTS server. That information is meant to assist the 655 DOTS server to enforce some policies. Figure 6 shows an example of a 656 request relayed by a server-domain DOTS gateway. 658 Header: PUT (Code=0.03) 659 Uri-Host: "host" 660 Uri-Path: ".well-known" 661 Uri-Path: "dots" 662 Uri-Path: "version" 663 Uri-Path: "mitigate" 664 Uri-Path: "cuid=xyz" 665 Content-Type: "application/cbor" 666 { 667 "mitigation-scope": { 668 "client-domain-hash": "string", 669 "scope": [ 670 { 671 "mitigation-id": integer, 672 "target-prefix": [ 673 "string" 674 ], 675 "target-port-range": [ 676 { 677 "lower-port": integer, 678 "upper-port": integer 679 } 680 ], 681 "target-protocol": [ 682 integer 683 ], 684 "target-fqdn": [ 685 "string" 686 ], 687 "target-uri": [ 688 "string" 689 ], 690 "alias-name": [ 691 "string" 692 ], 693 "lifetime": integer 694 } 695 ] 696 } 697 } 699 Figure 6: PUT to Convey DOTS Mitigation Request as relayed by a 700 Server-Domain DOTS Gateway 702 The DOTS gateway may add the following parameter: 704 client-domain-hash: The client identifier MAY be conveyed by a 705 server-domain DOTS gateway to propagate the source domain identity 706 from the gateway's client-side to the gateway's server-side, and 707 from the gateway's server-side to the DOTS server. 'client-domain- 708 hash' MAY be used by the final DOTS server for policy enforcement 709 purposes (e.g., enforce a quota on filtering rules). 711 The 'client-domain-hash' value MUST be assigned by the server- 712 domain DOTS gateway in a manner that ensures that there is zero 713 probability that the same value will be assigned to a different 714 client domain. 716 If the DOTS client is using the certificate provisioned by the 717 Enrollment over Secure Transport (EST) server [RFC7030] in the 718 DOTS gateway-domain to authenticate itself to the DOTS gateway, 719 the 'client-domain-hash' value may be the output of a 720 cryptographic hash algorithm whose input is the DER-encoded ASN.1 721 representation of the Subject Public Key Info (SPKI) of an X.509 722 certificate. In this version of the specification, the 723 cryptographic hash algorithm used is SHA-256 [RFC6234]. The 724 output of the cryptographic hash algorithm is truncated to 16 725 bytes; truncation is done by stripping off the final 16 bytes. 726 The truncated output is base64url encoded. 728 The 'client-domain-hash' attribute MUST NOT be generated and 729 included by DOTS clients. 731 DOTS servers MUST ignore 'client-domain-hash' attributes that are 732 directly supplied by source DOTS clients or client-domain DOTS 733 gateways. This implies that first server-domain DOTS gateways 734 MUST strip 'client-domain-hash' attributes supplied by DOTS 735 clients. DOTS servers MAY support a configuration parameter to 736 identify DOTS gateways that are trusted to supply 'client-domain- 737 hash' attributes. 739 Only singe-valued 'client-domain-hash' are defined in this 740 document. 742 This is an optional attribute. 744 Because of the complexity to handle partial failure cases, this 745 specification does not allow for including multiple mitigation 746 requests in the same PUT request. Concretely, a DOTS client MUST NOT 747 include multiple 'scope' parameters in the same PUT request. 749 The CBOR key values for the parameters are defined in Section 6. 750 Section 9 defines how the CBOR key values can be allocated to 751 standard bodies and vendors. 753 FQDN and URI mitigation scopes may be thought of as a form of scope 754 alias, in which the addresses to which the domain name or URI resolve 755 represent the full scope of the mitigation. 757 In the PUT request at least one of the attributes 'target-prefix' or 758 'target-fqdn' or 'target-uri 'or 'alias-name' MUST be present. 759 Attributes with empty values MUST NOT be present in a request. 761 The relative order of two mitigation requests from a DOTS client is 762 determined by comparing their respective 'mitigation-id' values. If 763 two mitigation requests have overlapping mitigation scopes, the 764 mitigation request with the highest numeric 'mitigation-id' value 765 will override the other mitigation request. Two mitigation-ids from 766 a DOTS client are overlapping if there is a common IP address, IP 767 prefix, FQDN, URI, or alias-name. To avoid maintaining a long list 768 of overlapping mitigation requests from a DOTS client and avoid 769 error-prone provisioning of mitigation requests from a DOTS client, 770 the overlapped lower numeric 'mitigation-id' MUST be automatically 771 deleted and no longer available at the DOTS server. 773 The Uri-Path option carries a major and minor version nomenclature to 774 manage versioning and DOTS signal channel in this specification uses 775 v1 major version. 777 Figure 7 shows a PUT request example to signal that ports 80, 8080, 778 and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 servers are 779 under attack (illustrated in JSON diagnostic notation). The presence 780 of 'client-domain-hash' indicates that a server-domain DOTS gateway 781 has modified the initial PUT request sent by the DOTS client. 783 Header: PUT (Code=0.03) 784 Uri-Host: "www.example.com" 785 Uri-Path: ".well-known" 786 Uri-Path: "dots" 787 Uri-Path: "v1" 788 Uri-Path: "mitigate" 789 Uri-Path: "cuid=xyz" 790 Content-Format: "application/cbor" 791 { 792 "mitigation-scope": { 793 "client-domain-hash": "dz6pHjaADkaFTbjr0JGBpw", 794 "scope": [ 795 { 796 "mitigation-id": 12332, 797 "target-prefix": [ 798 "2001:db8:6401::1/128", 799 "2001:db8:6401::2/128" 800 ], 801 "target-port-range": [ 802 { 803 "lower-port": 80 804 }, 805 { 806 "lower-port": 443 807 }, 808 { 809 "lower-port": 8080 810 } 811 ], 812 "target-protocol": [ 813 6 814 ] 815 } 816 ] 817 } 818 } 820 Figure 7: PUT for DOTS Mitigation Request 822 The corresponding CBOR encoding format is shown in Figure 8. 824 A1 # map(1) 825 01 # unsigned(1) 826 A2 # map(2) 827 18 24 # unsigned(36) 828 76 # text(22) 829 647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw" 830 02 # unsigned(2) 831 81 # array(1) 832 A4 # map(4) 833 03 # unsigned(3) 834 19 302C # unsigned(12332) 835 18 23 # unsigned(35) 836 82 # array(2) 837 74 # text(20) 838 323030313A6462383A363430313A3A312F313238 # "2001:db8:6401::1/128" 839 74 # text(20) 840 323030313A6462383A363430313A3A322F313238 # "2001:db8:6401::2/128" 841 05 # unsigned(5) 842 83 # array(3) 843 A1 # map(1) 844 06 # unsigned(6) 845 18 50 # unsigned(80) 846 A1 # map(1) 847 06 # unsigned(6) 848 19 01BB # unsigned(443) 849 A1 # map(1) 850 06 # unsigned(6) 851 19 1F90 # unsigned(8080) 852 08 # unsigned(8) 853 81 # array(1) 854 06 # unsigned(6) 856 Figure 8: PUT for DOTS Mitigation Request (CBOR) 858 In both DOTS signal and data channel sessions, the DOTS client MUST 859 authenticate itself to the DOTS server (Section 8). The DOTS server 860 may use the algorithm presented in Section 7 of [RFC7589] to derive 861 the DOTS client identity or username from the client certificate. 862 The DOTS client identity allows the DOTS server to accept mitigation 863 requests with scopes that the DOTS client is authorized to manage. 864 The DOTS server couples the DOTS signal and data channel sessions 865 using the DOTS client identity or the 'client-domain-hash' parameter 866 value, so the DOTS server can validate whether the aliases conveyed 867 in the mitigation request were indeed created by the same DOTS client 868 using the DOTS data channel session. If the aliases were not created 869 by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in 870 the response. 872 The DOTS server couples the DOTS signal channel sessions using the 873 DOTS client identity or the 'client-domain-hash' parameter value, and 874 the DOTS server uses 'mitigation-id' and 'cuid' parameter values to 875 detect duplicate mitigation requests. If the mitigation request 876 contains the alias-name and other parameters identifying the target 877 resources (such as, 'target-prefix', 'target-port-range', 'target- 878 fqdn', or 'target-uri'), the DOTS server appends the parameter values 879 in 'alias-name' with the corresponding parameter values in 'target- 880 prefix', 'target-port-range', 'target-fqdn', or 'target-uri'. 882 The DOTS server indicates the result of processing the PUT request 883 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 884 codes are some sort of invalid requests (client errors). COAP 5.xx 885 codes are returned if the DOTS server has erred or is currently 886 unavailable to provide mitigation in response to the mitigation 887 request from the DOTS client. 889 Figure 9 shows an example of a PUT request that is successfully 890 processed by a DOTS server (i.e., CoAP 2.xx response codes). 892 { 893 "mitigation-scope": { 894 "client-domain-hash": "dz6pHjaADkaFTbjr0JGBpw", 895 "scope": [ 896 { 897 "mitigation-id": 12332, 898 "lifetime": 3600 899 } 900 ] 901 } 902 } 904 Figure 9: 2.xx Response Body 906 If the request is missing one or more mandatory attributes, or 907 includes multiple 'scope' parameters, or contains invalid or unknown 908 parameters, the DOTS server MUST reply with 4.00 (Bad Request). DOTS 909 agents can safely ignore Vendor-Specific parameters they don't 910 understand. 912 A DOTS server that receives a mitigation request with a lifetime set 913 to '0' MUST reply with a 4.00 (Bad Request). 915 If the DOTS server does not find the 'mitigation-id' parameter value 916 conveyed in the PUT request in its configuration data, it MAY accept 917 the mitigation request by sending back a 2.01 (Created) response to 918 the DOTS client; the DOTS server will consequently try to mitigate 919 the attack. 921 If the DOTS server finds the 'mitigation-id' parameter value conveyed 922 in the PUT request in its configuration data bound to that DOTS 923 client, it MAY update the mitigation request, and a 2.04 (Changed) 924 response is returned to indicate a successful update of the 925 mitigation request. 927 If the request is conflicting with an existing mitigation request 928 from a different DOTS client, and the DOTS server decides to maintain 929 the conflicting mitigation request, the DOTS server returns 4.09 930 (Conflict) [RFC8132] to the requesting DOTS client. The response 931 includes enough information for a DOTS client to recognize the source 932 of the conflict (refer to 'conflict-information' specified in 933 Section 4.4.2). 935 For a mitigation request to continue beyond the initial negotiated 936 lifetime, the DOTS client has to refresh the current mitigation 937 request by sending a new PUT request. This PUT request MUST use the 938 same 'mitigation-id' value, and MUST repeat all the other parameters 939 as sent in the original mitigation request apart from a possible 940 change to the lifetime parameter value. 942 The DOTS gateway, which inserted a 'client-domain-hash' attribute in 943 a request, MUST strip the 'client-domain-hash' parameter in the 944 corresponding response before forwarding the response to the DOTS 945 client. If we consider the example depicted in Figure 9, the message 946 that will be relayed by the DOTS gateway is shown in Figure 10. 948 { 949 "mitigation-scope": { 950 "scope": [ 951 { 952 "mitigation-id": 12332, 953 "lifetime": 3600 954 } 955 ] 956 } 957 } 959 Figure 10: 2.xx Response Body Relayed by a DOTS Gateway 961 4.4.2. Retrieve Information Related to a Mitigation 963 A GET request is used by a DOTS client to retrieve information 964 (including status) of DOTS mitigations from a DOTS server. 966 The same considerations for manipulating 'client-domain-hash' 967 parameter by server-domain DOTS gateways specified in Section 4.4.1 968 MUST be followed for GET requests. 970 If the DOTS server does not find the 'mitigation-id' parameter value 971 conveyed in the GET request in its configuration data for the 972 requesting DOTS client or the one identified by 'client-domain-hash', 973 it MUST respond with a 4.04 (Not Found) error response code. 974 Likewise, the same error MUST be returned as a response to a request 975 to retrieve all mitigation records of a given DOTS client if the DOTS 976 server does not find any mitigation record for that DOTS client or 977 the one identified by 'client-domain-hash'. 979 The 'c' (content) parameter and its permitted values defined in 980 [I-D.ietf-core-comi] can be used to retrieve non-configuration data 981 (attack mitigation status) or configuration data or both. The DOTS 982 server may support this optional filtering capability. It can safely 983 ignore it if not supported. 985 The following examples illustrate how a DOTS client retrieves active 986 mitigation requests from a DOTS server. In particular: 988 o Figure 11 shows the example of a GET request to retrieve all DOTS 989 mitigation requests signaled by a DOTS client. 991 o Figure 12 shows the example of a GET request to retrieve a 992 specific DOTS mitigation request signaled by a DOTS client. The 993 configuration data to be reported in the response is formatted in 994 the same order it was processed by the DOTS server. 996 These two examples assume the default of "c=a"; that is, the DOTS 997 client asks for all data to be reported by the DOTS server. 999 Header: GET (Code=0.01) 1000 Uri-Host: "host" 1001 Uri-Path: ".well-known" 1002 Uri-Path: "dots" 1003 Uri-Path: "version" 1004 Uri-Path: "mitigate" 1005 Uri-Query: "cuid=xyz" 1006 Observe : 0 1008 Figure 11: GET to Retrieve all DOTS Mitigation Requests 1010 Header: GET (Code=0.01) 1011 Uri-Host: "host" 1012 Uri-Path: ".well-known" 1013 Uri-Path: "dots" 1014 Uri-Path: "version" 1015 Uri-Path: "mitigate" 1016 Uri-Query: "cuid=xyz" 1017 Uri-Query: "mitigation-id=12332" 1018 Observe : 0 1020 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request 1022 Figure 13 shows a response example of all active mitigation requests 1023 associated with the DOTS client on the DOTS server and the mitigation 1024 status of each mitigation request. 1026 { 1027 "mitigation-scope": { 1028 "scope": [ 1029 { 1030 "mitigation-id": 12332, 1031 "mitigation-start": 1507818434.00, 1032 "target-prefix": [ 1033 "2001:db8:6401::1/128", 1034 "2001:db8:6401::2/128" 1035 ], 1036 "target-protocol": [ 1037 17 1038 ], 1039 "lifetime": 1800, 1040 "status": 2, 1041 "bytes-dropped": 134334555, 1042 "bps-dropped": 43344, 1043 "pkts-dropped": 333334444, 1044 "pps-dropped": 432432 1045 }, 1046 { 1047 "mitigation-id": 12333, 1048 "mitigation-start": 1507818393.00, 1049 "target-prefix": [ 1050 "2001:db8:6401::1/128", 1051 "2001:db8:6401::2/128" 1052 ], 1053 "target-protocol": [ 1054 6 1055 ], 1056 "lifetime": 1800, 1057 "status": 3, 1058 "bytes-dropped": 0, 1059 "bps-dropped": 0, 1060 "pkts-dropped": 0, 1061 "pps-dropped": 0 1062 } 1063 ] 1064 } 1065 } 1067 Figure 13: Response Body to a Get Request 1069 The mitigation status parameters are described below: 1071 mitigation-start: Mitigation start time is expressed in seconds 1072 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 1074 [RFC7049]). The encoding is modified so that the leading tag 1 1075 (epoch-based date/time) MUST be omitted. 1077 This is a mandatory attribute. 1079 lifetime: The remaining lifetime of the mitigation request, in 1080 seconds. 1082 This is a mandatory attribute. 1084 status: Status of attack mitigation. The various possible values of 1085 'status' parameter are explained in Table 2. 1087 This is a mandatory attribute. 1089 conflict-information: Indicates that a mitigation request is 1090 conflicting with another mitigation request(s) from other DOTS 1091 client(s). This optional attribute has the following structure: 1093 conflict-status: Indicates the status of a conflicting mitigation 1094 request. The following values are defined: 1096 1: DOTS server has detected conflicting mitigation requests 1097 from different DOTS clients. This mitigation request is 1098 currently inactive until the conflicts are resolved. 1099 Another mitigation request is active. 1101 2: DOTS server has detected conflicting mitigation requests 1102 from different DOTS clients. This mitigation request is 1103 currently active. 1105 3: DOTS server has detected conflicting mitigation requests 1106 from different DOTS clients. All conflicting mitigation 1107 requests are inactive. 1109 conflict-cause: Indicates the cause of the conflict. The 1110 following values are defined: 1112 1: Overlapping targets. 'conflict-scope' provides more details 1113 about the conflicting target clauses. 1115 2: Conflicts with an existing white list. This code is 1116 returned when the DDoS mitigation detects source addresses/ 1117 prefixes in the white-listed ACLs are attacking the target. 1119 3: CUID Collision. This code is returned when a DOTS client 1120 uses a CUID that is already used by another DOTS client of 1121 the same domain. 1123 conflict-scope Indicates the conflict scope. It may include a 1124 list of IP addresses, a list of prefixes, a list of port 1125 numbers, a list of target protocols, a list of FQDNs, a list of 1126 URIs, a list of alias-names, or references to conflicting ACLs. 1128 retry-timer Indicates, in seconds, the time after which the DOTS 1129 client may re-issue the same request. The DOTS server returns 1130 'retry-timer' only to DOTS client(s) for which a mitigation 1131 request is deactivated. Any retransmission of the same 1132 mitigation request before the expiry of this timer is likely to 1133 be rejected by the DOTS server for the same reasons. 1135 The retry-timer SHOULD be equal to the lifetime of the active 1136 mitigation request resulting in the deactivation of the 1137 conflicting mitigation request. The lifetime of the 1138 deactivated mitigation request will be updated to (retry-timer 1139 + 45 seconds), so the DOTS client can refresh the deactivated 1140 mitigation request after retry-timer seconds before expiry of 1141 lifetime and check if the conflict is resolved. 1143 bytes-dropped: The total dropped byte count for the mitigation 1144 request since the attack mitigation is triggered. The count wraps 1145 around when it reaches the maximum value of unsigned integer. 1147 This is an optional attribute. 1149 bps-dropped: The average number of dropped bytes per second for the 1150 mitigation request since the attack mitigation is triggered. This 1151 SHOULD be a five-minute average. 1153 This is an optional attribute. 1155 pkts-dropped: The total number of dropped packet count for the 1156 mitigation request since the attack mitigation is triggered. 1158 This is an optional attribute. 1160 pps-dropped: The average number of dropped packets per second for 1161 the mitigation request since the attack mitigation is triggered. 1162 This SHOULD be a five-minute average. 1164 This is an optional attribute. 1166 +-----------+-------------------------------------------------------+ 1167 | Parameter | Description | 1168 | value | | 1169 +-----------+-------------------------------------------------------+ 1170 | 1 | Attack mitigation is in progress (e.g., changing the | 1171 | | network path to re-route the inbound traffic to DOTS | 1172 | | mitigator). | 1173 +-----------+-------------------------------------------------------+ 1174 | 2 | Attack is successfully mitigated (e.g., traffic is | 1175 | | redirected to a DDoS mitigator and attack traffic is | 1176 | | dropped). | 1177 +-----------+-------------------------------------------------------+ 1178 | 3 | Attack has stopped and the DOTS client can withdraw | 1179 | | the mitigation request. | 1180 +-----------+-------------------------------------------------------+ 1181 | 4 | Attack has exceeded the mitigation provider | 1182 | | capability. | 1183 +-----------+-------------------------------------------------------+ 1184 | 5 | DOTS client has withdrawn the mitigation request and | 1185 | | the mitigation is active but terminating. | 1186 +-----------+-------------------------------------------------------+ 1187 | 6 | Attack mitigation is now terminated. | 1188 +-----------+-------------------------------------------------------+ 1189 | 7 | Attack mitigation is withdrawn. | 1190 +-----------+-------------------------------------------------------+ 1191 | 8 | Attack mitigation is rejected. | 1192 +-----------+-------------------------------------------------------+ 1194 Table 2: Values of 'status' Parameter 1196 The observe option defined in [RFC7641] extends the CoAP core 1197 protocol with a mechanism for a CoAP client to "observe" a resource 1198 on a CoAP server: The client retrieves a representation of the 1199 resource and requests this representation be updated by the server as 1200 long as the client is interested in the resource. A DOTS client 1201 conveys the observe option set to '0' in the GET request to receive 1202 unsolicited notifications of attack mitigation status from the DOTS 1203 server. 1205 Unidirectional notifications within the bidirectional signal channel 1206 allows unsolicited message delivery, enabling asynchronous 1207 notifications between the agents. Due to the higher likelihood of 1208 packet loss during a DDoS attack, the DOTS server periodically sends 1209 attack mitigation status to the DOTS client and also notifies the 1210 DOTS client whenever the status of the attack mitigation changes. If 1211 the DOTS server cannot maintain a RTT estimate, it SHOULD NOT send 1212 more than one unsolicited notification every 3 seconds, and SHOULD 1213 use an even less aggressive rate whenever possible (case 2 in 1214 Section 3.1.3 of [RFC8085]). The DOTS server MUST use the same CUID 1215 as the one used by the DOTS client to observe a mitigation request. 1217 When conflicting requests are detected, the DOTS server enforces the 1218 corresponding policy (e.g., accept all requests, reject all requests, 1219 accept only one request but reject all the others, ...). It is 1220 assumed that this policy is supplied by the DOTS server administrator 1221 or it is a default behavior of the DOTS server implementation. Then, 1222 the DOTS server sends notification message(s) to the DOTS client(s) 1223 at the origin of the conflict. A conflict notification message 1224 includes information about the conflict cause, scope, and the status 1225 of the mitigation request(s). For example, 1227 o A notification message with status code set to '8 (Attack 1228 mitigation is rejected)' and 'conflict-status' set to '1' is sent 1229 to a DOTS client to indicate that this mitigation request is 1230 rejected because a conflict is detected. 1232 o A notification message with status code set to '7 (Attack 1233 mitigation is withdrawn)' and 'conflict-status' set to '1' is sent 1234 to a DOTS client to indicate that an active mitigation request is 1235 deactivated because a conflict is detected. 1237 o A notification message with status code set to '1 (Attack 1238 mitigation is in progress)' and 'conflict-status' set to '2' is 1239 sent to a DOTS client to indicate that this mitigation request is 1240 in progress, but a conflict is detected. 1242 Upon receipt of a conflict notification message indicating that a 1243 mitigation request is deactivated because of a conflict, a DOTS 1244 client MUST NOT resend the same mitigation request before the expiry 1245 of 'retry-timer'. It is also recommended that DOTS clients support 1246 means to alert administrators about mitigation conflicts. 1248 A DOTS client that is no longer interested in receiving notifications 1249 from the DOTS server can simply "forget" the observation. When the 1250 DOTS server sends the next notification, the DOTS client will not 1251 recognize the token in the message and thus will return a Reset 1252 message. This causes the DOTS server to remove the associated entry. 1253 Alternatively, the DOTS client can explicitly deregister itself by 1254 issuing a GET request that has the Token field set to the token of 1255 the observation to be cancelled and includes an Observe Option with 1256 the value set to '1' (deregister). 1258 Figure 14 shows an example of a DOTS client requesting a DOTS server 1259 to send notifications related to a given mitigation request. 1261 +-----------+ +-----------+ 1262 |DOTS client| |DOTS server| 1263 +-----------+ +-----------+ 1264 | | 1265 | GET / | 1266 | Token: 0x4a | Registration 1267 | Observe: 0 | 1268 +------------------------------>| 1269 | | 1270 | 2.05 Content | 1271 | Token: 0x4a | Notification of 1272 | Observe: 12 | the current state 1273 | status: "mitigation | 1274 | in progress" | 1275 |<------------------------------+ 1276 | 2.05 Content | 1277 | Token: 0x4a | Notification upon 1278 | Observe: 44 | a state change 1279 | status: "mitigation | 1280 | complete" | 1281 |<------------------------------+ 1282 | 2.05 Content | 1283 | Token: 0x4a | Notification upon 1284 | Observe: 60 | a state change 1285 | status: "attack stopped" | 1286 |<------------------------------+ 1287 | | 1289 Figure 14: Notifications of Attack Mitigation Status 1291 4.4.2.1. Mitigation Status 1293 The DOTS client can send the GET request at frequent intervals 1294 without the Observe option to retrieve the configuration data of the 1295 mitigation request and non-configuration data (i.e., the attack 1296 status). The frequency of polling the DOTS server to get the 1297 mitigation status should follow the transmission guidelines given in 1298 Section 3.1.3 of [RFC8085]. If the DOTS server has been able to 1299 mitigate the attack and the attack has stopped, the DOTS server 1300 indicates as such in the status, and the DOTS client recalls the 1301 mitigation request by issuing a DELETE request for the 'mitigation- 1302 id'. 1304 A DOTS client SHOULD react to the status of the attack as per the 1305 information sent by the DOTS server rather than acknowledging by 1306 itself, using its own means, that the attack has been mitigated. 1307 This ensures that the DOTS client does not recall a mitigation 1308 request prematurely because it is possible that the DOTS client does 1309 not sense the DDoS attack on its resources but the DOTS server could 1310 be actively mitigating the attack and the attack is not completely 1311 averted. 1313 4.4.3. Efficacy Update from DOTS Clients 1315 While DDoS mitigation is active, due to the likelihood of packet 1316 loss, a DOTS client MAY periodically transmit DOTS mitigation 1317 efficacy updates to the relevant DOTS server. A PUT request is used 1318 to convey the mitigation efficacy update to the DOTS server. 1320 The PUT request MUST include all the parameters used in the PUT 1321 request to carry the DOTS mitigation request (Section 4.4.1) 1322 unchanged apart from the lifetime parameter value. If this is not 1323 the case, the DOTS server MUST reject the request with a 4.00 (Bad 1324 Request). 1326 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1327 value is used to make the PUT request conditional on the current 1328 existence of the mitigation request. If UDP is used as transport, 1329 CoAP requests may arrive out-of-order. For example, the DOTS client 1330 may send a PUT request to convey an efficacy update to the DOTS 1331 server followed by a DELETE request to withdraw the mitigation 1332 request, but the DELETE request arrives at the DOTS server before the 1333 PUT request. To handle out-of-order delivery of requests, if an If- 1334 Match option is present in the PUT request and the 'mitigation-id' in 1335 the request matches a mitigation request from that DOTS client, then 1336 the request is processed. If no match is found, the PUT request is 1337 silently ignored. 1339 An example of an efficacy update message, which includes an If-Match 1340 option with an empty value, is depicted in Figure 15. 1342 Header: PUT (Code=0.03) 1343 Uri-Host: "host" 1344 Uri-Path: ".well-known" 1345 Uri-Path: "dots" 1346 Uri-Path: "version" 1347 Uri-Path: "mitigate" 1348 Uri-Path: "cuid=xyz" 1349 Content-Format: "application/cbor" 1350 If-Match: 1351 { 1352 "mitigation-scope": { 1353 "scope": [ 1354 { 1355 "mitigation-id": integer, 1356 "target-prefix": [ 1357 "string" 1358 ], 1359 "target-port-range": [ 1360 { 1361 "lower-port": integer, 1362 "upper-port": integer 1363 } 1364 ], 1365 "target-protocol": [ 1366 integer 1367 ], 1368 "target-fqdn": [ 1369 "string" 1370 ], 1371 "target-uri": [ 1372 "string" 1373 ], 1374 "alias-name": [ 1375 "string" 1376 ], 1377 "lifetime": integer, 1378 "attack-status": integer 1379 } 1380 ] 1381 } 1382 } 1384 Figure 15: Efficacy Update 1386 The 'attack-status' parameter is a mandatory attribute when 1387 performing an efficacy update. The various possible values contained 1388 in the 'attack-status' parameter are described in Table 3. 1390 +-----------+-------------------------------------------------------+ 1391 | Parameter | Description | 1392 | value | | 1393 +-----------+-------------------------------------------------------+ 1394 | 1 | The DOTS client determines that it is still under | 1395 | | attack. | 1396 +-----------+-------------------------------------------------------+ 1397 | 2 | The DOTS client determines that the attack is | 1398 | | successfully mitigated (e.g., attack traffic is not | 1399 | | seen). | 1400 +-----------+-------------------------------------------------------+ 1402 Table 3: Values of 'attack-status' Parameter 1404 The DOTS server indicates the result of processing a PUT request 1405 using CoAP response codes. The response code 2.04 (Changed) is 1406 returned if the DOTS server has accepted the mitigation efficacy 1407 update. The error response code 5.03 (Service Unavailable) is 1408 returned if the DOTS server has erred or is incapable of performing 1409 the mitigation. 1411 4.4.4. Withdraw a Mitigation 1413 A DELETE request is used to withdraw a DOTS mitigation request from a 1414 DOTS server (Figure 16). 1416 The same considerations for manipulating 'client-domain-hash' 1417 parameter by DOTS gateways, as specified in Section 4.4.1, MUST be 1418 followed for DELETE requests. 1420 Header: DELETE (Code=0.04) 1421 Uri-Host: "host" 1422 Uri-Path: ".well-known" 1423 Uri-Path: "dots" 1424 Uri-Path: "version" 1425 Uri-Path: "mitigate" 1426 Uri-Query: "cuid=xyz" 1427 Uri-Query: "mitigation-id=123" 1429 Figure 16: Withdraw a DOTS Mitigation 1431 If the request does not include a 'mitigation-id' parameter, the DOTS 1432 server MUST reply with a 4.00 (Bad Request). 1434 Once the request is validated, the DOTS server immediately 1435 acknowledges a DOTS client's request to withdraw the DOTS signal 1436 using 2.02 (Deleted) response code with no response payload. A 2.02 1437 (Deleted) Response Code is returned even if the 'mitigation-id' 1438 parameter value conveyed in the DELETE request does not exist in its 1439 configuration data before the request. 1441 If the DOTS server finds the 'mitigation-id' parameter value conveyed 1442 in the DELETE request in its configuration data for the DOTS client, 1443 then to protect against route or DNS flapping caused by a DOTS client 1444 rapidly removing a mitigation, and to dampen the effect of 1445 oscillating attacks, the DOTS server MAY allow mitigation to continue 1446 for a limited period after acknowledging a DOTS client's withdrawal 1447 of a mitigation request. During this period, the DOTS server status 1448 messages SHOULD indicate that mitigation is active but terminating 1449 (Section 4.4.2). 1451 The initial active-but-terminating period SHOULD be sufficiently long 1452 to absorb latency incurred by route propagation. The active-but- 1453 terminating period SHOULD be set by default to 120 seconds. If the 1454 client requests mitigation again before the initial active-but- 1455 terminating period elapses, the DOTS server MAY exponentially 1456 increase the active-but- terminating period up to a maximum of 300 1457 seconds (5 minutes). 1459 After the active-but-terminating period elapses, the DOTS server MUST 1460 treat the mitigation as terminated, as the DOTS client is no longer 1461 responsible for the mitigation. For example, if there is a financial 1462 relationship between the DOTS client and server domains, the DOTS 1463 client stops incurring cost at this point. 1465 4.5. DOTS Signal Channel Session Configuration 1467 A DOTS client can negotiate, configure, and retrieve the DOTS signal 1468 channel session behavior. The DOTS signal channel can be used, for 1469 example, to configure the following: 1471 a. Heartbeat interval (heartbeat-interval): DOTS agents regularly 1472 send heartbeats (CoAP Ping/Pong) to each other after mutual 1473 authentication is successfully completed in order to keep the 1474 DOTS signal channel open. Heartbeat messages are exchanged 1475 between DOTS agents every 'heartbeat-interval' seconds to detect 1476 the current status of the DOTS signal channel session. 1478 b. Missing heartbeats allowed (missing-hb-allowed): This variable 1479 indicates the maximum number of consecutive heartbeat messages 1480 for which a DOTS agent did not receive a response before 1481 concluding that the session is disconnected or defunct. 1483 c. Acceptable signal loss ratio: Maximum retransmissions, 1484 retransmission timeout value, and other message transmission 1485 parameters for the DOTS signal channel. 1487 The same or distinct configuration sets may be used during times when 1488 a mitigation is active ('mitigating-config') and when no mitigation 1489 is active ('idle-config'). This is particularly useful for DOTS 1490 servers that might want to reduce heartbeat frequency or cease 1491 heartbeat exchanges when an active DOTS client has not requested 1492 mitigation. If distinct configurations are used, DOTS agents MUST 1493 follow the appropriate configuration set as a function of the 1494 mitigation activity (e.g., if no mitigation request is active, 'idle- 1495 config'-related values must be followed). Additionally, DOTS agents 1496 MUST automatically switch to the other configuration upon a change in 1497 the mitigation activity (e.g., if an attack mitigation is launched 1498 after a peacetime, the DOTS agent switches from 'idle-config' to 1499 'mitigating-config'-related values). 1501 Requests and responses are deemed reliable by marking them as 1502 Confirmable (CON) messages. DOTS signal channel session 1503 configuration requests and responses are marked as Confirmable 1504 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1505 message is retransmitted using a default timeout and exponential 1506 back-off between retransmissions, until the DOTS server sends an 1507 Acknowledgement message (ACK) with the same Message ID conveyed from 1508 the DOTS client. 1510 Message transmission parameters are defined in Section 4.8 of 1511 [RFC7252]. The DOTS server can either piggyback the response in the 1512 acknowledgement message or, if the DOTS server cannot respond 1513 immediately to a request carried in a Confirmable message, it simply 1514 responds with an Empty Acknowledgement message so that the DOTS 1515 client can stop retransmitting the request. Empty Acknowledgement 1516 message is explained in Section 2.2 of [RFC7252]. When the response 1517 is ready, the server sends it in a new Confirmable message which in 1518 turn needs to be acknowledged by the DOTS client (see Sections 5.2.1 1519 and 5.2.2 of [RFC7252]). Requests and responses exchanged between 1520 DOTS agents during peacetime are marked as Confirmable messages. 1522 Implementation Note: A DOTS client that receives a response in a 1523 CON message may want to clean up the message state right after 1524 sending the ACK. If that ACK is lost and the DOTS server 1525 retransmits the CON, the DOTS client may no longer have any state 1526 that would help it correlate this response, thereby unexpecting 1527 the retransmission message. The DOTS client will send a Reset 1528 message so it does not receive any more retransmissions. This 1529 behavior is normal and not an indication of an error (see 1530 Section 5.3.2 of [RFC7252] for more details). 1532 4.5.1. Discover Configuration Parameters 1534 A GET request is used to obtain acceptable (e.g., minimum and maximum 1535 values) and current configuration parameters on the DOTS server for 1536 DOTS signal channel session configuration. This procedure occurs 1537 between a DOTS client and its immediate peer DOTS server. As such, 1538 this GET request MUST NOT be relayed by an on-path DOTS gateway. 1540 Figure 17 shows how to obtain acceptable configuration parameters for 1541 the DOTS server. 1543 Header: GET (Code=0.01) 1544 Uri-Host: "host" 1545 Uri-Path: ".well-known" 1546 Uri-Path: "dots" 1547 Uri-Path: "version" 1548 Uri-Path: "config" 1550 Figure 17: GET to Retrieve Configuration 1552 The DOTS server in the 2.05 (Content) response conveys the current, 1553 minimum, and maximum attribute values acceptable by the DOTS server 1554 (Figure 18). 1556 Content-Format: "application/cbor" 1557 { 1558 "signal-config": { 1559 "mitigating-config": { 1560 "heartbeat-interval": { 1561 "current-value": integer, 1562 "min-value": integer, 1563 "max-value": integer 1564 }, 1565 "missing-hb-allowed": { 1566 "current-value": integer, 1567 "min-value": integer, 1568 "max-value": integer 1569 }, 1570 "max-retransmit": { 1571 "current-value": integer, 1572 "min-value": integer, 1573 "max-value": integer 1574 }, 1575 "ack-timeout": { 1576 "current-value": integer, 1577 "min-value": integer, 1578 "max-value": integer 1579 }, 1580 "ack-random-factor": { 1581 "current-value-decimal": number, 1582 "min-value-decimal": number, 1583 "max-value-decimal": number 1584 } 1585 }, 1586 "idle-config": { 1587 "heartbeat-interval": { 1588 "current-value": integer, 1589 "min-value": integer, 1590 "max-value": integer 1591 }, 1592 "missing-hb-allowed": { 1593 "current-value": integer, 1594 "min-value": integer, 1595 "max-value": integer 1596 }, 1597 "max-retransmit": { 1598 "current-value": integer, 1599 "min-value": integer, 1600 "max-value": integer 1601 }, 1602 "ack-timeout": { 1603 "current-value": integer, 1604 "min-value": integer, 1605 "max-value": integer 1606 }, 1607 "ack-random-factor": { 1608 "current-value-decimal": number, 1609 "min-value-decimal": number, 1610 "max-value-decimal": number 1611 } 1612 }, 1613 "trigger-mitigation": { 1614 "current-value": boolean 1615 } 1616 } 1617 } 1619 Figure 18: GET Configuration Response Body 1621 Figure 19 shows an example of acceptable and current configuration 1622 parameters on a DOTS server for DOTS signal channel session 1623 configuration. The same acceptable configuration is used during 1624 attack and peace times. 1626 Content-Format: "application/cbor" 1627 { 1628 "signal-config": { 1629 "mitigating-config": { 1630 "heartbeat-interval": { 1631 "current-value": 30, 1632 "min-value": 15, 1633 "max-value": 240 1634 }, 1635 "missing-hb-allowed": { 1636 "current-value": 5, 1637 "min-value": 3, 1638 "max-value": 9 1639 }, 1640 "max-retransmit": { 1641 "current-value": 3, 1642 "min-value": 2, 1643 "max-value": 15 1644 }, 1645 "ack-timeout": { 1646 "current-value": 2, 1647 "min-value": 1, 1648 "max-value": 30 1649 }, 1650 "ack-random-factor": { 1651 "current-value-decimal": 1.5, 1652 "min-value-decimal": 1.1, 1653 "max-value-decimal": 4.0 1654 } 1655 }, 1656 "idle-config": { 1657 "heartbeat-interval": { 1658 "current-value": 30, 1659 "min-value": 15, 1660 "max-value": 240 1661 }, 1662 "missing-hb-allowed": { 1663 "current-value": 5, 1664 "min-value": 3, 1665 "max-value": 9 1666 }, 1667 "max-retransmit": { 1668 "current-value": 3, 1669 "min-value": 2, 1670 "max-value": 15 1671 }, 1672 "ack-timeout": { 1673 "current-value": 2, 1674 "min-value": 1, 1675 "max-value": 30 1677 }, 1678 "ack-random-factor": { 1679 "current-value-decimal": 1.5, 1680 "min-value-decimal": 1.1, 1681 "max-value-decimal": 4.0 1682 } 1683 }, 1684 "trigger-mitigation": { 1685 "current-value": true 1686 } 1687 } 1688 } 1690 Figure 19: Example of a Configuration Response Body 1692 4.5.2. Convey DOTS Signal Channel Session Configuration 1694 A PUT request is used to convey the configuration parameters for the 1695 signal channel (e.g., heartbeat interval, maximum retransmissions). 1696 Message transmission parameters for CoAP are defined in Section 4.8 1697 of [RFC7252]. The RECOMMENDED values of transmission parameter 1698 values are ack-timeout (2 seconds), max-retransmit (3), ack-random- 1699 factor (1.5). In addition to those parameters, the RECOMMENDED 1700 specific DOTS transmission parameter values are 'heartbeat-interval' 1701 (30 seconds) and 'missing-hb-allowed' (5). 1703 Note: heartbeat-interval should be tweaked to also assist DOTS 1704 messages for NAT traversal (SIG-010 of 1705 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 1706 messages must not be sent more frequently than once every 15 1707 seconds and should use longer intervals when possible. 1708 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 1709 minutes or longer, but experience shows that sending packets every 1710 15 to 30 seconds is necessary to prevent the majority of 1711 middleboxes from losing state for UDP flows. From that 1712 standpoint, this specification recommends a minimum heartbeat- 1713 interval of 15 seconds and a maximum heartbeat-interval of 240 1714 seconds. The recommended value of 30 seconds is selected to 1715 anticipate the expiry of NAT state. 1717 A heartbeat-interval of 30 seconds may be seen as too chatty in 1718 some deployments. For such deployments, DOTS agents may negotiate 1719 longer heartbeat-interval values to prevent any network overload 1720 with too frequent keepalives. 1722 Different heartbeat intervals can be defined for 'mitigation- 1723 config' and 'idle-config' to reduce being too chatty during idle 1724 times. If there is an on-path translator between the DOTS client 1725 (standalone or part of a DOTS gateway) and the DOTS server, the 1726 'mitigation-config' heartbeat-interval has to be smaller than the 1727 translator session timeout. It is recommended that the 'idle- 1728 config' heartbeat-interval is also smaller than the translator 1729 session timeout to prevent translator transversal issues, or set 1730 to '0'. Means to discover the lifetime assigned by a translator 1731 are out of scope. 1733 When a confirmable "CoAP Ping" is sent, and if there is no response, 1734 the "CoAP Ping" is retransmitted max-retransmit number of times by 1735 the CoAP layer using an initial timeout set to a random duration 1736 between ack-timeout and (ack-timeout*ack-random-factor) and 1737 exponential back-off between retransmissions. By choosing the 1738 recommended transmission parameters, the "CoAP Ping" will timeout 1739 after 45 seconds. If the DOTS agent does not receive any response 1740 from the peer DOTS agent for 'missing-hb-allowed' number of 1741 consecutive "CoAP Ping" confirmable messages, it concludes that the 1742 DOTS signal channel session is disconnected. A DOTS client MUST NOT 1743 transmit a "CoAP Ping" while waiting for the previous "CoAP Ping" 1744 response from the same DOTS server. 1746 If the DOTS agent wishes to change the default values of message 1747 transmission parameters, then it should follow the guidance given in 1748 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 1749 values for message transmission parameters and default values for 1750 non-negotiated message transmission parameters. 1752 The signal channel session configuration is applicable to a single 1753 DOTS signal channel session between the DOTS agents. 1755 Header: PUT (Code=0.03) 1756 Uri-Host: "host" 1757 Uri-Path: ".well-known" 1758 Uri-Path: "dots" 1759 Uri-Path: "version" 1760 Uri-Path: "config" 1761 Uri-Path: "session-id=123" 1762 Content-Format: "application/cbor" 1763 { 1764 "signal-config": { 1765 "mitigating-config": { 1766 "heartbeat-interval": { 1767 "current-value": integer 1768 }, 1769 "missing-hb-allowed": { 1770 "current-value": integer 1771 }, 1772 "max-retransmit": { 1773 "current-value": integer 1774 }, 1775 "ack-timeout": { 1776 "current-value": integer 1777 }, 1778 "ack-random-factor": { 1779 "current-value-decimal": number 1780 } 1781 }, 1782 "idle-config": { 1783 "heartbeat-interval": { 1784 "current-value": integer 1785 }, 1786 "missing-hb-allowed": { 1787 "current-value": integer 1788 }, 1789 "max-retransmit": { 1790 "current-value": integer 1791 }, 1792 "ack-timeout": { 1793 "current-value": integer 1794 }, 1795 "ack-random-factor": { 1796 "current-value-decimal": number 1797 } 1798 }, 1799 "trigger-mitigation": boolean, 1800 "config-interval": integer 1801 } 1802 } 1804 Figure 20: PUT to Convey the DOTS Signal Channel Session 1805 Configuration Data 1807 The parameters in Figure 20 are described below: 1809 session-id: Identifier for the DOTS signal channel session 1810 configuration data represented as an integer. This identifier 1811 MUST be generated by the DOTS client. This document does not make 1812 any assumption about how this identifier is generated. 1814 This is a mandatory attribute. 1816 mitigation-config: Set of configuration parameters to use when a 1817 mitigation is active. The following parameters may be included: 1819 heartbeat-interval: Time interval in seconds between two 1820 consecutive heartbeat messages. 1822 '0' is used to disable the heartbeat mechanism. 1824 This is an optional attribute. 1826 missing-hb-allowed: Maximum number of consecutive heartbeat 1827 messages for which the DOTS agent did not receive a response 1828 before concluding that the session is disconnected. 1830 This is an optional attribute. 1832 max-retransmit: Maximum number of retransmissions for a message 1833 (referred to as MAX_RETRANSMIT parameter in CoAP). 1835 This is an optional attribute. 1837 ack-timeout: Timeout value in seconds used to calculate the 1838 initial retransmission timeout value (referred to as 1839 ACK_TIMEOUT parameter in CoAP). 1841 This is an optional attribute. 1843 ack-random-factor: Random factor used to influence the timing of 1844 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1845 CoAP). 1847 This is an optional attribute. 1849 idle-config: Set of configuration parameters to use when no 1850 mitigation is active. This attribute has the same structure as 1851 'mitigating-config'. 1853 trigger-mitigation: If the parameter value is set to 'false', then 1854 DDoS mitigation is triggered only when the DOTS signal channel 1855 session is lost. Automated mitigation on loss of signal is 1856 discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. 1858 If the DOTS client ceases to respond to heartbeat messages, the 1859 DOTS server can detect that the DOTS session is lost. 1861 The default value of the parameter is 'true'. 1863 This is an optional attribute. 1865 config-interval: This parameter is returned to indicate the time 1866 interval expressed in seconds, which a DOTS agent must wait for 1867 before re-contacting its peer in order to retrieve the signal 1868 channel configuration data. 1870 '0' is used to disable this refresh mechanism. 1872 If a non-zero value of 'config-interval' is received by a DOTS 1873 client, it has to issue a PUT request to refresh the configuration 1874 parameters for the signal channel before the expiry of 'config- 1875 interval'. When a DDoS attack is active, refresh requests MUST 1876 NOT be sent by DOTS clients and the DOTS server MUST NOT terminate 1877 the (D)TLS session after the expiry of 'config-interval'. 1879 This mechanism allows to update the configuration data if a change 1880 occurs at the DOTS server side. For example, the new 1881 configuration may instruct a DOTS client to cease heartbeats or 1882 reduce heartbeat frequency. 1884 If this parameter is not returned, this is equivalent to receiving 1885 a 'config-interval' value set to '0'. 1887 If a DOTS server detects that a misbehaving DOTS client does not 1888 contact the DOTS server after the expiry of 'config-interval', in 1889 order to retrieve the signal channel configuration data, it MAY 1890 terminate the (D)TLS session. A (D)TLS session is terminated by 1891 the receipt of an authenticated message that closes the connection 1892 (e.g., a fatal alert (Section 7.2 of [RFC5246])). 1894 This is an optional attribute. 1896 At least one of the attributes 'heartbeat-interval', 'missing-hb- 1897 allowed', 'max-retransmit', 'ack-timeout', 'ack-random-factor', and 1898 'trigger-mitigation' MUST be present in the PUT request. The PUT 1899 request with a higher numeric 'session-id' value overrides the DOTS 1900 signal channel session configuration data installed by a PUT request 1901 with a lower numeric 'session-id' value. 1903 Figure 21 shows a PUT request example to convey the configuration 1904 parameters for the DOTS signal channel. In this example, heartbeat 1905 mechanism is disabled when no mitigation is active, while the 1906 heartbeat interval is set to '91' when a mitigation is active. 1908 Header: PUT (Code=0.03) 1909 Uri-Host: "www.example.com" 1910 Uri-Path: ".well-known" 1911 Uri-Path: "dots" 1912 Uri-Path: "v1" 1913 Uri-Path: "config" 1914 Uri-Path: "session-id=123" 1915 Content-Format: "application/cbor" 1916 { 1917 "signal-config": { 1918 "mitigating-config": { 1919 "heartbeat-interval": { 1920 "current-value": 91 1921 }, 1922 "missing-hb-allowed": { 1923 "current-value": 3 1924 }, 1925 "max-retransmit": { 1926 "current-value": 7 1927 }, 1928 "ack-timeout": { 1929 "current-value": 5 1930 }, 1931 "ack-random-factor": { 1932 "current-value-decimal": 1.5 1933 } 1934 }, 1935 "idle-config": { 1936 "heartbeat-interval": { 1937 "current-value": 0 1938 }, 1939 "max-retransmit": { 1940 "current-value": 7 1941 }, 1942 "ack-timeout": { 1943 "current-value": 5 1944 }, 1945 "ack-random-factor": { 1946 "current-value-decimal": 1.5 1947 } 1948 }, 1949 "trigger-mitigation": false 1950 } 1951 } 1953 Figure 21: PUT to Convey the Configuration Parameters 1955 The DOTS server indicates the result of processing the PUT request 1956 using CoAP response codes: 1958 o If the DOTS server finds the 'session-id' parameter value conveyed 1959 in the PUT request in its configuration data and if the DOTS 1960 server has accepted the updated configuration parameters, then 1961 2.04 (Changed) code is returned in the response. 1963 o If the DOTS server does not find the 'session-id' parameter value 1964 conveyed in the PUT request in its configuration data and if the 1965 DOTS server has accepted the configuration parameters, then a 1966 response code 2.01 (Created) is returned in the response. 1968 o If the request is missing one or more mandatory attributes or it 1969 contains one or more invalid or unknown parameters, 4.00 (Bad 1970 Request) is returned in the response. 1972 o Response code 4.22 (Unprocessable Entity) is returned in the 1973 response, if any of the 'heartbeat-interval', 'missing-hb- 1974 allowed', 'max-retransmit', 'target-protocol', 'ack-timeout', and 1975 'ack-random-factor' attribute values are not acceptable to the 1976 DOTS server. Upon receipt of the 4.22 error response code, the 1977 DOTS client should request the maximum and minimum attribute 1978 values acceptable to the DOTS server (Section 4.5.1). 1980 The DOTS client may re-try and send the PUT request with updated 1981 attribute values acceptable to the DOTS server. 1983 4.5.3. Delete DOTS Signal Channel Session Configuration 1985 A DELETE request is used to delete the installed DOTS signal channel 1986 session configuration data (Figure 22). 1988 Header: DELETE (Code=0.04) 1989 Uri-Host: "host" 1990 Uri-Path: ".well-known" 1991 Uri-Path: "dots" 1992 Uri-Path: "version" 1993 Uri-Path: "config" 1994 Uri-Query: "session-id=123" 1996 Figure 22: DELETE Configuration 1998 The DOTS server resets the DOTS signal channel session configuration 1999 back to the default values and acknowledges a DOTS client's request 2000 to remove the DOTS signal channel session configuration using 2.02 2001 (Deleted) response code. 2003 4.6. Redirected Signaling 2005 Redirected DOTS signaling is discussed in detail in Section 3.2.2 of 2006 [I-D.ietf-dots-architecture]. 2008 If a DOTS server wants to redirect a DOTS client to an alternative 2009 DOTS server for a signal session, then the response code 3.00 2010 (alternate server) will be returned in the response to the DOTS 2011 client. 2013 The DOTS server can return the error response code 3.00 in response 2014 to a PUT request from the DOTS client or convey the error response 2015 code 3.00 in a unidirectional notification response from the DOTS 2016 server. 2018 The DOTS server in the error response conveys the alternate DOTS 2019 server's FQDN, and the alternate DOTS server's IP address(es) and 2020 time to live values in the CBOR body (Figure 23). 2022 { 2023 "alt-server": "string", 2024 "alt-server-record": [ 2025 { 2026 "addr": "string", 2027 "ttl" : integer 2028 } 2029 ] 2030 } 2032 Figure 23: Redirected Server Error Response Body 2034 The parameters are described below: 2036 alt-server: FQDN of an alternate DOTS server. 2038 addr: IP address of an alternate DOTS server. 2040 ttl: Time to live (TTL) represented as an integer number of seconds. 2042 Figure 24 shows a 3.00 response example to convey the DOTS alternate 2043 server 'alt-server.example', its IP addresses 2001:db8:6401::1 and 2044 2001:db8:6401::2, and TTL values 3600 and 1800. 2046 { 2047 "alt-server": "alt-server.example", 2048 "alt-server-record": [ 2049 { 2050 "ttl" : 3600, 2051 "addr": "2001:db8:6401::1" 2052 }, 2053 { 2054 "ttl" : 1800, 2055 "addr": "2001:db8:6401::2" 2056 } 2057 ] 2058 } 2060 Figure 24: Example of Redirected Server Error Response Body 2062 When the DOTS client receives 3.00 response, it considers the current 2063 request as failed, but SHOULD try re-sending the request to the 2064 alternate DOTS server. During a DDoS attack, the DNS server may be 2065 the target of another DDoS attack, alternate DOTS server's IP 2066 addresses conveyed in the 3.00 response help the DOTS client skip DNS 2067 lookup of the alternate DOTS server. The DOTS client can then try to 2068 establish a UDP or a TCP session with the alternate DOTS server. The 2069 DOTS client SHOULD implement a DNS64 function to handle the scenario 2070 where an IPv6-only DOTS client communicates with an IPv4-only 2071 alternate DOTS server. 2073 4.7. Heartbeat Mechanism 2075 To provide an indication of signal health and distinguish an 'idle' 2076 signal channel from a 'disconnected' or 'defunct' session, the DOTS 2077 agent sends a heartbeat over the signal channel to maintain its half 2078 of the channel. The DOTS agent similarly expects a heartbeat from 2079 its peer DOTS agent, and may consider a session terminated in the 2080 prolonged absence of a peer agent heartbeat. 2082 While the communication between the DOTS agents is quiescent, the 2083 DOTS client will probe the DOTS server to ensure it has maintained 2084 cryptographic state and vice versa. Such probes can also keep 2085 firewalls and/or stateful translators bindings alive. This probing 2086 reduces the frequency of establishing a new handshake when a DOTS 2087 signal needs to be conveyed to the DOTS server. 2089 DOTS servers MAY trigger their heartbeat requests immediately after 2090 receiving heartbeat probes from peer DOTS clients. As a reminder, it 2091 is the responsibility of DOTS clients to ensure that on-path 2092 translators/firewalls are maintaining a binding so that the same 2093 external IP address and/or port number is retained for the DOTS 2094 session. 2096 In case of a massive DDoS attack that saturates the incoming link(s) 2097 to the DOTS client, all traffic from the DOTS server to the DOTS 2098 client will likely be dropped, although the DOTS server receives 2099 heartbeat requests in addition to DOTS messages sent by the DOTS 2100 client. In this scenario, the DOTS agents MUST behave differently to 2101 handle message transmission and DOTS session liveliness during link 2102 saturation: 2104 o The DOTS client MUST NOT consider the DOTS session terminated even 2105 after a maximum 'missing-hb-allowed' threshold is reached. The 2106 DOTS client SHOULD keep on using the current DOTS session to send 2107 heartbeat requests over it, so that the DOTS server knows the DOTS 2108 client has not disconnected the DOTS session. 2110 After the maximum 'missing-hb-allowed' threshold is reached, the 2111 DOTS client SHOULD try to resume the (D)TLS session. The DOTS 2112 client SHOULD send mitigation requests over the current DOTS 2113 session, and in parallel, for example, try to resume the (D)TLS 2114 session or use 0-RTT mode in DTLS 1.3 to piggyback the mitigation 2115 request in the ClientHello message. 2117 As soon as the link is no longer saturated, if traffic from the 2118 DOTS server reaches the DOTS client over the current DOTS session, 2119 the DOTS client can stop (D)TLS session resumption or if (D)TLS 2120 session resumption is successful then disconnect the current DOTS 2121 session. 2123 o If the DOTS server does not receive any traffic from the peer DOTS 2124 client, then the DOTS server sends heartbeat requests to the DOTS 2125 client and after maximum 'missing-hb-allowed' threshold is 2126 reached, the DOTS server concludes the session is disconnected. 2128 In DOTS over UDP, heartbeat messages MUST be exchanged between the 2129 DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of 2130 [RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable 2131 message and the peer DOTS agent will respond by sending a Reset 2132 message. 2134 In DOTS over TCP, heartbeat messages MUST be exchanged between the 2135 DOTS agents using the Ping and Pong messages specified in Section 4.4 2136 of [I-D.ietf-core-coap-tcp-tls]. That is, the DOTS agent sends a 2137 Ping message and the peer DOTS agent would respond by sending a 2138 single Pong message. 2140 5. DOTS Signal Channel YANG Module 2142 This document defines a YANG [RFC7950] module for mitigation scope 2143 and DOTS signal channel session configuration data. 2145 5.1. Tree Structure 2147 This document defines the YANG module "ietf-dots-signal" 2148 (Section 5.2), which has the following tree structure. A DOTS signal 2149 message can either be a mitigation or a configuration message. 2151 module: ietf-dots-signal 2152 +--rw dots-signal 2153 +--rw (message-type)? 2154 +--:(mitigation-scope) 2155 | +--rw client-domain-hash? string 2156 | +--rw scope* [cuid mitigation-id] 2157 | +--rw cuid string 2158 | +--rw mitigation-id int32 2159 | +--rw target-prefix* inet:ip-prefix 2160 | +--rw target-port-range* [lower-port upper-port] 2161 | | +--rw lower-port inet:port-number 2162 | | +--rw upper-port inet:port-number 2163 | +--rw target-protocol* uint8 2164 | +--rw target-fqdn* inet:domain-name 2165 | +--rw target-uri* inet:uri 2166 | +--rw alias-name* string 2167 | +--rw lifetime? int32 2168 | +--rw mitigation-start? int64 2169 | +--ro status? enumeration 2170 | +--ro conflict-information 2171 | | +--ro conflict-status? enumeration 2172 | | +--ro conflict-cause? enumeration 2173 | | +--ro retry-timer? int32 2174 | | +--ro conflict-scope 2175 | | +--ro target-prefix* inet:ip-prefix 2176 | | +--ro target-port-range* [lower-port upper-port] 2177 | | | +--ro lower-port inet:port-number 2178 | | | +--ro upper-port inet:port-number 2179 | | +--ro target-protocol* uint8 2180 | | +--ro target-fqdn* inet:domain-name 2181 | | +--ro target-uri* inet:uri 2182 | | +--ro alias-name* string 2183 | | +--ro acl-list* [acl-name acl-type] 2184 | | +--ro acl-name -> /ietf-acl:access-lists/acl/acl-name 2185 | | +--ro acl-type -> /ietf-acl:access-lists/acl/acl-type 2186 | +--ro pkts-dropped? yang:zero-based-counter64 2187 | +--ro bps-dropped? yang:zero-based-counter64 2188 | +--ro bytes-dropped? yang:zero-based-counter64 2189 | +--ro pps-dropped? yang:zero-based-counter64 2190 | +--rw attack-status? enumeration 2191 +--:(signal-config) 2192 | +--rw session-id int32 2193 | +--rw mitigating-config 2194 | | +--rw heartbeat-interval 2195 | | | +--rw max-value? int16 2196 | | | +--rw min-value? int16 2197 | | | +--rw current-value? int16 2198 | | +--rw missing-hb-allowed 2199 | | | +--rw max-value? int16 2200 | | | +--rw min-value? int16 2201 | | | +--rw current-value? int16 2202 | | +--rw max-retransmit 2203 | | | +--rw max-value? int16 2204 | | | +--rw min-value? int16 2205 | | | +--rw current-value? int16 2206 | | +--rw ack-timeout 2207 | | | +--rw max-value? int16 2208 | | | +--rw min-value? int16 2209 | | | +--rw current-value? int16 2210 | | +--rw ack-random-factor 2211 | | +--rw max-value-decimal? decimal64 2212 | | +--rw min-value-decimal? decimal64 2213 | | +--rw current-value-decimal? decimal64 2214 | +--rw idle-config 2215 | | +--rw heartbeat-interval 2216 | | | +--rw max-value? int16 2217 | | | +--rw min-value? int16 2218 | | | +--rw current-value? int16 2219 | | +--rw missing-hb-allowed 2220 | | | +--rw max-value? int16 2221 | | | +--rw min-value? int16 2222 | | | +--rw current-value? int16 2223 | | +--rw max-retransmit 2224 | | | +--rw max-value? int16 2225 | | | +--rw min-value? int16 2226 | | | +--rw current-value? int16 2227 | | +--rw ack-timeout 2228 | | | +--rw max-value? int16 2229 | | | +--rw min-value? int16 2230 | | | +--rw current-value? int16 2231 | | +--rw ack-random-factor 2232 | | +--rw max-value-decimal? decimal64 2233 | | +--rw min-value-decimal? decimal64 2234 | | +--rw current-value-decimal? decimal64 2235 | +--rw trigger-mitigation? boolean 2236 | +--rw config-interval? int32 2237 +--:(redirected-signal) 2238 +--rw alt-server string 2239 +--rw alt-server-record* [addr] 2240 +--rw addr inet:ip-address 2241 +--rw ttl? int32 2243 5.2. YANG Module 2245 file "ietf-dots-signal@2018-01-09.yang" 2247 module ietf-dots-signal { 2248 yang-version 1.1; 2249 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; 2250 prefix "signal"; 2252 import ietf-inet-types {prefix "inet";} 2253 import ietf-yang-types {prefix yang;} 2254 import ietf-access-control-list {prefix "ietf-acl";} 2256 organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 2258 contact 2259 "WG Web: 2260 WG List: 2262 Editor: Konda, Tirumaleswar Reddy 2263 2265 Editor: Mohamed Boucadair 2266 2268 Author: Prashanth Patil 2269 2271 Author: Andrew Mortensen 2272 2274 Author: Nik Teague 2275 "; 2277 description 2278 "This module contains YANG definition for the signaling 2279 messages exchanged between a DOTS client and a DOTS server. 2281 Copyright (c) 2017 IETF Trust and the persons identified as 2282 authors of the code. All rights reserved. 2284 Redistribution and use in source and binary forms, with or 2285 without modification, is permitted pursuant to, and subject 2286 to the license terms contained in, the Simplified BSD License 2287 set forth in Section 4.c of the IETF Trust's Legal Provisions 2288 Relating to IETF Documents 2289 (http://trustee.ietf.org/license-info). 2291 This version of this YANG module is part of RFC XXXX; see 2292 the RFC itself for full legal notices."; 2294 revision 2018-01-09 { 2295 description 2296 "Initial revision."; 2297 reference 2298 "RFC XXXX: Distributed Denial-of-Service Open Threat 2299 Signaling (DOTS) Signal Channel"; 2300 } 2302 grouping target { 2303 description 2304 "Specifies the targets of the mitigation request."; 2306 leaf-list target-prefix { 2307 type inet:ip-prefix; 2308 description 2309 "IPv4 or IPv6 prefix identifying the target."; 2310 } 2312 list target-port-range { 2313 key "lower-port upper-port"; 2315 description 2316 "Port range. When only lower-port is 2317 present, it represents a single port."; 2319 leaf lower-port { 2320 type inet:port-number; 2321 mandatory true; 2322 description "Lower port number."; 2323 } 2325 leaf upper-port { 2326 type inet:port-number; 2327 must ". >= ../lower-port" { 2328 error-message 2329 "The upper port number must be greater than 2330 or equal to lower port number."; 2331 } 2332 description "Upper port number."; 2333 } 2334 } 2336 leaf-list target-protocol { 2337 type uint8; 2338 description 2339 "Identifies the target protocol number. 2341 The value '0' means 'all protocols'. 2343 Values are taken from the IANA protocol registry: 2344 https://www.iana.org/assignments/protocol-numbers/ 2345 protocol-numbers.xhtml 2347 For example, 6 for TCP or 17 for UDP."; 2348 } 2350 leaf-list target-fqdn { 2351 type inet:domain-name; 2352 description "FQDN identifying the target."; 2353 } 2355 leaf-list target-uri { 2356 type inet:uri; 2357 description "URI identifying the target."; 2358 } 2360 leaf-list alias-name { 2361 type string; 2362 description "alias name"; 2363 } 2364 } 2366 grouping mitigation-scope { 2367 description 2368 "Specifies the scope of the mitigation request."; 2370 leaf client-domain-hash { 2371 type string; 2372 description 2373 "The client domain hash may be conveyed by 2374 the server-domain DOTS gateway to propagate the 2375 client domain identification information from the 2376 gateway's client-side to the gateway's server-side, 2377 and from the gateway's server-side to the DOTS 2378 server. 2380 It may be used by the final DOTS server 2381 for policy enforcement purposes."; 2382 } 2384 list scope { 2385 key "cuid mitigation-id"; 2386 description 2387 "The scope of the request."; 2389 leaf cuid { 2390 type string; 2391 description 2392 "A unique identifier that is randomly 2393 generated by a DOTS client to prevent 2394 request collisions."; 2395 } 2397 leaf mitigation-id { 2398 type int32; 2399 description 2400 "Mitigation request identifier. 2402 This identifier must be unique for each mitigation 2403 request bound to the DOTS client."; 2404 } 2406 uses target; 2408 leaf lifetime { 2409 type int32; 2410 units "seconds"; 2411 default 3600; 2412 description 2413 "Indicates the lifetime of the mitigation request."; 2414 reference 2415 "RFC XXXX: Distributed Denial-of-Service Open Threat 2416 Signaling (DOTS) Signal Channel"; 2417 } 2419 leaf mitigation-start { 2420 type int64; 2421 units "seconds"; 2422 description 2423 "Mitigation start time is represented in seconds 2424 relative to 1970-01-01T00:00Z in UTC time."; 2425 } 2427 leaf status { 2428 type enumeration { 2429 enum "attack-mitigation-in-progress" { 2430 value 1; 2431 description 2432 "Attack mitigation is in progress (e.g., changing 2433 the network path to re-route the inbound traffic 2434 to DOTS mitigator)."; 2435 } 2437 enum "attack-successfully-mitigated" { 2438 value 2; 2439 description 2440 "Attack is successfully mitigated (e.g., traffic 2441 is redirected to a DDoS mitigator and attack 2442 traffic is dropped or blackholed)."; 2443 } 2445 enum "attack-stopped" { 2446 value 3; 2447 description 2448 "Attack has stopped and the DOTS client can 2449 withdraw the mitigation request."; 2450 } 2452 enum "attack-exceeded-capability" { 2453 value 4; 2454 description 2455 "Attack has exceeded the mitigation provider 2456 capability."; 2457 } 2459 enum "dots-client-withdrawn-mitigation" { 2460 value 5; 2461 description 2462 "DOTS client has withdrawn the mitigation 2463 request and the mitigation is active but 2464 terminating."; 2465 } 2467 enum "attack-mitigation-terminated" { 2468 value 6; 2469 description 2470 "Attack mitigation is now terminated."; 2471 } 2473 enum "attack-mitigation-withdrawn" { 2474 value 7; 2475 description 2476 "Attack mitigation is withdrawn."; 2477 } 2479 enum "attack-mitigation-rejected" { 2480 value 8; 2481 description 2482 "Attack mitigation is rejected."; 2483 } 2484 } 2485 config false; 2486 description 2487 "Indicates the status of a mitigation request. 2488 It must be included in responses only."; 2489 } 2491 container conflict-information { 2492 config false; 2493 description 2494 "Indicates that a conflict is detected. 2495 Must only be used for responses."; 2497 leaf conflict-status { 2498 type enumeration { 2499 enum "request-inactive-other-active" { 2500 value 1; 2501 description 2502 "DOTS Server has detected conflicting mitigation 2503 requests from different DOTS clients. 2504 This mitigation request is currently inactive 2505 until the conflicts are resolved. Another 2506 mitigation request is active."; 2507 } 2509 enum "request-active" { 2510 value 2; 2511 description 2512 "DOTS Server has detected conflicting mitigation 2513 requests from different DOTS clients. 2514 This mitigation request is currently active."; 2515 } 2517 enum "all-requests-inactive" { 2518 value 3; 2519 description 2520 "DOTS Server has detected conflicting mitigation 2521 requests from different DOTS clients. All 2522 conflicting mitigation requests are inactive."; 2523 } 2525 } 2526 description 2527 "Indicates the conflict status. 2528 It must be included in responses only."; 2529 } 2531 leaf conflict-cause { 2532 type enumeration { 2533 enum "overlapping-targets" { 2534 value 1; 2535 description 2536 "Overlapping targets. conflict-scope provides 2537 more details about the exact conflict."; 2538 } 2540 enum "conflict-with-whitelist" { 2541 value 2; 2542 description 2543 "Conflicts with an existing white list. 2545 This code is returned when the DDoS mitigation 2546 detects that some of the source addresses/prefixes 2547 listed in the white list ACLs are actually 2548 attacking the target."; 2549 } 2551 enum "cuid-collision" { 2552 value 3; 2553 description 2554 "Conflicts with the CUID used by another 2555 DOTS client of the same domain."; 2556 } 2557 } 2558 description 2559 "Indicates the cause of the conflict. 2560 It must be included in responses only."; 2561 } 2563 leaf retry-timer { 2564 type int32; 2565 units "seconds"; 2566 description 2567 "The DOTS client must not re-send the 2568 same request before the expiry of this timer. 2569 It must be included in responses, only."; 2570 } 2572 container conflict-scope { 2573 description 2574 "Provides more information about the conflict scope."; 2576 uses target { 2577 when "../conflict-cause = 'overlapping-targets'"; 2578 } 2580 list acl-list { 2581 when "../../conflict-cause = 'conflict-with-whitelist'"; 2582 key "acl-name acl-type"; 2583 description 2584 "List of conflicting ACLs"; 2586 leaf acl-name { 2587 type leafref { 2588 path "/ietf-acl:access-lists/ietf-acl:acl" + 2589 "/ietf-acl:acl-name"; 2590 } 2591 description 2592 "Reference to the conflicting ACL name bound to 2593 a DOTS client."; 2594 } 2596 leaf acl-type { 2597 type leafref { 2598 path "/ietf-acl:access-lists/ietf-acl:acl" + 2599 "/ietf-acl:acl-type"; 2600 } 2601 description 2602 "Reference to the conflicting ACL type bound to 2603 a DOTS client."; 2604 } 2605 } 2606 } 2607 } 2609 leaf pkts-dropped { 2610 type yang:zero-based-counter64; 2611 config false; 2612 description 2613 "Number of dropped packets"; 2614 } 2616 leaf bps-dropped { 2617 type yang:zero-based-counter64; 2618 config false; 2619 description 2620 "The average number of dropped bytes per second for 2621 the mitigation request since the attack 2622 mitigation is triggered."; 2623 } 2625 leaf bytes-dropped { 2626 type yang:zero-based-counter64; 2627 units 'bytes'; 2628 config false; 2629 description 2630 "Counter for dropped packets; in bytes."; 2631 } 2633 leaf pps-dropped { 2634 type yang:zero-based-counter64; 2635 config false; 2636 description 2637 "The average number of dropped packets per second 2638 for the mitigation request since the attack 2639 mitigation is triggered."; 2640 } 2642 leaf attack-status { 2643 type enumeration { 2644 enum "under-attack" { 2645 value 1; 2646 description 2647 "The DOTS client determines that it is still under 2648 attack."; 2649 } 2651 enum "attack-successfully-mitigated" { 2652 value 2; 2653 description 2654 "The DOTS client determines that the attack is 2655 successfully mitigated."; 2656 } 2657 } 2658 description 2659 "Indicates the status of an attack as seen by the 2660 DOTS client."; 2661 } 2662 } 2663 } 2665 grouping config-parameters { 2666 description 2667 "Subset of DOTS signal channel session configuration."; 2669 container heartbeat-interval { 2670 description 2671 "DOTS agents regularly send heartbeats to each other 2672 after mutual authentication is successfully 2673 completed in order to keep the DOTS signal channel 2674 open."; 2676 leaf max-value { 2677 type int16; 2678 units "seconds"; 2679 description 2680 "Maximum acceptable value."; 2681 reference 2682 "RFC XXXX: Distributed Denial-of-Service Open Threat 2683 Signaling (DOTS) Signal Channel"; 2684 } 2686 leaf min-value { 2687 type int16; 2688 units "seconds"; 2689 description 2690 "Minimum acceptable value."; 2691 reference 2692 "RFC XXXX: Distributed Denial-of-Service Open Threat 2693 Signaling (DOTS) Signal Channel"; 2694 } 2695 leaf current-value { 2696 type int16; 2697 units "seconds"; 2698 default 30; 2699 description 2700 "Current value. 2702 '0' means that heartbeat mechanism is deactivated."; 2703 reference 2704 "RFC XXXX: Distributed Denial-of-Service Open Threat 2705 Signaling (DOTS) Signal Channel"; 2706 } 2707 } 2709 container missing-hb-allowed { 2710 description 2711 "Maximum number of missing heartbeats allowed."; 2713 leaf max-value { 2714 type int16; 2715 description 2716 "Maximum acceptable value."; 2718 reference 2719 "RFC XXXX: Distributed Denial-of-Service Open Threat 2720 Signaling (DOTS) Signal Channel"; 2721 } 2723 leaf min-value { 2724 type int16; 2725 description 2726 "Minimum acceptable value."; 2727 reference 2728 "RFC XXXX: Distributed Denial-of-Service Open Threat 2729 Signaling (DOTS) Signal Channel"; 2730 } 2731 leaf current-value { 2732 type int16; 2733 default 5; 2734 description 2735 "Current value."; 2736 reference 2737 "RFC XXXX: Distributed Denial-of-Service Open Threat 2738 Signaling (DOTS) Signal Channel"; 2739 } 2740 } 2742 container max-retransmit { 2743 description 2744 "Maximum number of retransmissions of a Confirmable 2745 message."; 2747 leaf max-value { 2748 type int16; 2749 description 2750 "Maximum acceptable value."; 2751 reference 2752 "Section 4.8 of RFC 7552."; 2753 } 2755 leaf min-value { 2756 type int16; 2757 description 2758 "Minimum acceptable value."; 2759 reference 2760 "Section 4.8 of RFC 7552."; 2761 } 2762 leaf current-value { 2763 type int16; 2764 default 3; 2765 description 2766 "Current value."; 2767 reference 2768 "RFC XXXX: Distributed Denial-of-Service Open Threat 2769 Signaling (DOTS) Signal Channel"; 2770 } 2771 } 2773 container ack-timeout { 2774 description 2775 "Initial retransmission timeout value."; 2777 leaf max-value { 2778 type int16; 2779 units "seconds"; 2780 description 2781 "Maximum value."; 2782 reference 2783 "Section 4.8 of RFC 7552."; 2784 } 2786 leaf min-value { 2787 type int16; 2788 units "seconds"; 2789 description 2790 "Minimum value."; 2791 reference 2792 "Section 4.8 of RFC 7552."; 2793 } 2794 leaf current-value { 2795 type int16; 2796 units "seconds"; 2797 default 2; 2798 description 2799 "Current value."; 2800 reference 2801 "Section 4.8 of RFC 7552."; 2802 } 2803 } 2805 container ack-random-factor { 2806 description 2807 "Random factor used to influence the timing of 2808 retransmissions."; 2810 leaf max-value-decimal { 2811 type decimal64 { 2812 fraction-digits 2; 2813 } 2814 description 2815 "Maximum acceptable value."; 2816 reference 2817 "Section 4.8 of RFC 7552."; 2818 } 2820 leaf min-value-decimal { 2821 type decimal64 { 2822 fraction-digits 2; 2823 } 2824 description 2825 "Minimum acceptable value."; 2826 reference 2827 "Section 4.8 of RFC 7552."; 2828 } 2829 leaf current-value-decimal { 2830 type decimal64 { 2831 fraction-digits 2; 2832 } 2833 default 1.5; 2834 description 2835 "Current value."; 2836 reference 2837 "Section 4.8 of RFC 7552."; 2838 } 2839 } 2840 } 2842 grouping signal-config { 2843 description 2844 "DOTS signal channel session configuration."; 2846 leaf session-id { 2847 type int32; 2848 mandatory true; 2849 description 2850 "An identifier for the DOTS signal channel 2851 session configuration data."; 2852 } 2854 container mitigating-config { 2855 description 2856 "Configuration parameters to use when a mitigation is active."; 2857 uses config-parameters; 2858 } 2860 container idle-config { 2861 description 2862 "Configuration parameters to use when no mitigation is 2863 active."; 2864 uses config-parameters; 2865 } 2867 leaf trigger-mitigation { 2868 type boolean; 2869 default true; 2870 description 2871 "If false, then mitigation is triggered 2872 only when the DOTS server channel session is lost"; 2873 reference 2874 "RFC XXXX: Distributed Denial-of-Service Open Threat 2875 Signaling (DOTS) Signal Channel"; 2876 } 2878 leaf config-interval { 2879 type int32; 2880 units "seconds"; 2881 description 2882 "This parameter is returned by a DOTS server to 2883 a requesting DOTS client to indicate the time interval 2884 after which the DOTS client must contact the DOTS 2885 server in order to retrieve the signal channel 2886 configuration data. 2888 This mechanism allows the update of the configuration 2889 data if a change occurs. 2891 For example, the new configuration may instruct 2892 a DOTS client to cease heartbeats or reduce 2893 heartbeat frequency. 2895 '0' is used to disable this refresh mechanism."; 2896 } 2897 } 2899 grouping redirected-signal { 2900 description 2901 "Grouping for the redirected signaling."; 2903 leaf alt-server { 2904 type string; 2905 mandatory true; 2906 description 2907 "Alias of an alternate server."; 2908 } 2909 list alt-server-record { 2910 key "addr"; 2911 description 2912 "List of records for the alternate server."; 2914 leaf addr { 2915 type inet:ip-address; 2916 description 2917 "IPv4 or IPv6 address identifying the server."; 2918 } 2920 leaf ttl { 2921 type int32; 2922 description 2923 "TTL associated with this record."; 2924 } 2925 } 2926 } 2928 container dots-signal { 2929 description 2930 "Main container for DOTS signal message. 2931 A DOTS signal message can be a mitigation message or 2932 a configuration message."; 2934 choice message-type { 2935 description 2936 "Can be a mitigation, a configuration, or a redirect 2937 message."; 2939 case mitigation-scope { 2940 description 2941 "Mitigation scope of a mitigation message."; 2942 uses mitigation-scope; 2943 } 2945 case signal-config { 2946 description 2947 "Configuration message."; 2948 uses signal-config; 2949 } 2951 case redirected-signal { 2952 description 2953 "Redirected signaling."; 2954 uses redirected-signal; 2955 } 2956 } 2958 } 2959 } 2960 2962 6. Mapping Parameters to CBOR 2964 All parameters in the payload of the DOTS signal channel MUST be 2965 mapped to CBOR types as shown in Table 4 and are assigned an integer 2966 key to save space. The recipient of the payload MAY reject the 2967 information if it is not suitably mapped. 2969 +-----------------------+----------+--------------------+ 2970 | Parameter Name | CBOR Key | CBOR Major Type | 2971 +-----------------------+----------+--------------------+ 2972 | mitigation-scope | 1 | 5 (map) | 2973 | scope | 2 | 5 (map) | 2974 | mitigation-id | 3 | 0 (unsigned) | 2975 | acl-list | 4 | 4 | 2976 | target-port-range | 5 | 4 | 2977 | lower-port | 6 | 0 | 2978 | upper-port | 7 | 0 | 2979 | target-protocol | 8 | 4 | 2980 | target-fqdn | 9 | 4 | 2981 | target-uri | 10 | 4 | 2982 | alias-name | 11 | 4 | 2983 | lifetime | 12 | 0 | 2984 | attack-status | 13 | 0 | 2985 | signal-config | 14 | 5 (map) | 2986 | heartbeat-interval | 15 | 5 (map) | 2987 | max-retransmit | 16 | 5 (map) | 2988 | ack-timeout | 17 | 5 (map) | 2989 | ack-random-factor | 18 | 5 (map) | 2990 | min-value | 19 | 0 | 2991 | max-value | 20 | 0 | 2992 | status | 21 | 0 | 2993 | conflict-information | 22 | 5 (map) | 2994 | conflict-status | 23 | 0 | 2995 | conflict-cause | 24 | 0 | 2996 | retry-timer | 25 | 0 | 2997 | bytes-dropped | 26 | 0 | 2998 | bps-dropped | 27 | 0 | 2999 | pkts-dropped | 28 | 0 | 3000 | pps-dropped | 29 | 0 | 3001 | session-id | 30 | 0 | 3002 | trigger-mitigation | 31 | 7 (simple types) | 3003 | missing-hb-allowed | 32 | 5 (map) | 3004 | current-value | 33 | 0 | 3005 | mitigation-start | 34 | 7 (floating-point) | 3006 | target-prefix | 35 | 4 (array) | 3007 | client-domain-hash | 36 | 3 | 3008 | alt-server | 37 | 3 | 3009 | alt-server-record | 38 | 4 | 3010 | addr | 39 | 3 | 3011 | ttl | 40 | 0 | 3012 | conflict-scope | 41 | 5 (map) | 3013 | acl-name | 42 | 3 | 3014 | acl-type | 43 | 3 | 3015 | config-interval | 44 | 0 | 3016 | mitigating-config | 45 | 5 (map) | 3017 | idle-config | 46 | 5 (map) | 3018 | cuid | 47 | 3 | 3019 | min-value-decimal | 48 | 7 | 3020 | max-value-decimal | 49 | 7 | 3021 | current-value-decimal | 50 | 7 | 3022 +-----------------------+----------+--------------------+ 3024 Table 4: CBOR Mappings Used in DOTS Signal Channel Messages 3026 7. (D)TLS Protocol Profile and Performance Considerations 3028 7.1. (D)TLS Protocol Profile 3030 This section defines the (D)TLS protocol profile of DOTS signal 3031 channel over (D)TLS and DOTS data channel over TLS. 3033 There are known attacks on (D)TLS, such as man-in-the-middle and 3034 protocol downgrade attacks. These are general attacks on (D)TLS and, 3035 as such, they are not specific to DOTS over (D)TLS; refer to the 3036 (D)TLS RFCs for discussion of these security issues. DOTS agents 3037 MUST adhere to the (D)TLS implementation recommendations and security 3038 considerations of [RFC7525] except with respect to (D)TLS version. 3039 Since DOTS signal channel encryption relies upon (D)TLS is virtually 3040 a green-field deployment, DOTS agents MUST implement only (D)TLS 1.2 3041 or later. 3043 When a DOTS client is configured with a domain name of the DOTS 3044 server, and connects to its configured DOTS server, the server may 3045 present it with a PKIX certificate. In order to ensure proper 3046 authentication, a DOTS client MUST verify the entire certification 3047 path per [RFC5280]. The DOTS client additionally uses [RFC6125] 3048 validation techniques to compare the domain name with the certificate 3049 provided. 3051 A key challenge to deploying DOTS is the provisioning of DOTS 3052 clients, including the distribution of keying material to DOTS 3053 clients to enable the required mutual authentication of DOTS agents. 3055 EST defines a method of certificate enrollment by which domains 3056 operating DOTS servers may provide DOTS clients with all the 3057 necessary cryptographic keying material, including a private key and 3058 a certificate to authenticate themselves. One deployment option is 3059 DOTS clients behave as EST clients for certificate enrollment from an 3060 EST server provisioned by the mitigation provider. This document 3061 does not specify which EST mechanism the DOTS client uses to achieve 3062 initial enrollment. 3064 The Server Name Indication (SNI) extension [RFC6066] defines a 3065 mechanism for a client to tell a (D)TLS server the name of the server 3066 it wants to contact. This is a useful extension for hosting 3067 environments where multiple virtual servers are reachable over a 3068 single IP address. The DOTS client may or may not know if it is 3069 interacting with a DOTS server in the hosting environment, so the 3070 DOTS client SHOULD include the DOTS server FQDN in the SNI extension. 3072 Implementations compliant with this profile MUST implement all of the 3073 following items: 3075 o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect 3076 against replay attacks. 3078 o (D)TLS session resumption without server-side state [RFC5077] to 3079 resume session and convey the DOTS signal. 3081 o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduces 3082 the size of the ServerHello, and can be used by DOTS agents that 3083 cannot obtain certificates. 3085 Implementations compliant with this profile SHOULD implement all of 3086 the following items to reduce the delay required to deliver a DOTS 3087 signal channel message: 3089 o TLS False Start [RFC7918] which reduces round-trips by allowing 3090 the TLS second flight of messages (ChangeCipherSpec) to also 3091 contain the DOTS signal. 3093 o Cached Information Extension [RFC7924] which avoids transmitting 3094 the server's certificate and certificate chain if the client has 3095 cached that information from a previous TLS handshake. 3097 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 3098 convey DOTS signal channel message. 3100 7.2. (D)TLS 1.3 Considerations 3102 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 3103 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 3104 [I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides 3105 equivalent security guarantees. (D)TLS 1.3 provides two basic 3106 handshake modes the DOTS signal channel can take advantage of: 3108 o A full handshake mode in which a DOTS client can send a DOTS 3109 mitigation request message after one round trip and the DOTS 3110 server immediately responds with a DOTS mitigation response. This 3111 assumes no packet loss is experienced. 3113 o 0-RTT mode in which the DOTS client can authenticate itself and 3114 send DOTS mitigation request messages in the first message, thus 3115 reducing handshake latency. 0-RTT only works if the DOTS client 3116 has previously communicated with that DOTS server, which is very 3117 likely with the DOTS signal channel. 3119 The DOTS client has to establish a (D)TLS session with the DOTS 3120 server during peacetime and share a PSK. 3122 During a DDoS attack, the DOTS client can use the (D)TLS session 3123 to convey the DOTS mitigation request message and, if there is no 3124 response from the server after multiple retries, the DOTS client 3125 can resume the (D)TLS session in 0-RTT mode using PSK. 3127 Section 8 of [I-D.ietf-tls-tls13] discusses some mechanisms to 3128 implement to limit the impact of replay attacks on 0-RTT data. If 3129 TLS1.3 is used, DOTS servers must implement one of these 3130 mechanisms. 3132 A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request 3133 message exchange is shown in Figure 25. 3135 DOTS Client DOTS Server 3137 ClientHello 3138 (Finished) 3139 (0-RTT DOTS signal message) 3140 (end_of_early_data) --------> 3141 ServerHello 3142 {EncryptedExtensions} 3143 {ServerConfiguration} 3144 {Certificate} 3145 {CertificateVerify} 3146 {Finished} 3147 <-------- [DOTS signal message] 3148 {Finished} --------> 3150 [DOTS signal message] <-------> [DOTS signal message] 3152 Figure 25: TLS 1.3 handshake with 0-RTT 3154 7.3. MTU and Fragmentation 3156 To avoid DOTS signal message fragmentation and the subsequent 3157 decreased probability of message delivery, DOTS agents MUST ensure 3158 that the DTLS record MUST fit within a single datagram. If the path 3159 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 3160 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 3161 is used to convey the DOTS signal messages then the DOTS client must 3162 consider the amount of record expansion expected by the DTLS 3163 processing when calculating the size of CoAP message that fits within 3164 the path MTU. Path MTU MUST be greater than or equal to [CoAP 3165 message size + DTLS overhead of 13 octets + authentication overhead 3166 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 3167 of [RFC6347]). If the request size exceeds the path MTU then the 3168 DOTS client MUST split the DOTS signal into separate messages, for 3169 example the list of addresses in the 'target-prefix' parameter could 3170 be split into multiple lists and each list conveyed in a new PUT 3171 request. 3173 Implementation Note: DOTS choice of message size parameters works 3174 well with IPv6 and with most of today's IPv4 paths. However, with 3175 IPv4, it is harder to reliably ensure that there is no IP 3176 fragmentation. If IPv4 path MTU is unknown, implementations may want 3177 to limit themselves to more conservative IPv4 datagram sizes such as 3178 576 bytes, as per [RFC0791]. IP packets whose size does not exceed 3179 576 bytes should never need to be fragmented: therefore, sending a 3180 maximum of 500 bytes of DOTS signal over a UDP datagram will 3181 generally avoid IP fragmentation. 3183 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 3185 (D)TLS based upon client certificate can be used for mutual 3186 authentication between DOTS agents. If a DOTS gateway is involved, 3187 DOTS clients and DOTS gateways MUST perform mutual authentication; 3188 only authorized DOTS clients are allowed to send DOTS signals to a 3189 DOTS gateway. The DOTS gateway and the DOTS server MUST perform 3190 mutual authentication; a DOTS server only allows DOTS signal channel 3191 messages from an authorized DOTS gateway, thereby creating a two-link 3192 chain of transitive authentication between the DOTS client and the 3193 DOTS server. 3195 The DOTS server SHOULD support certificate-based client 3196 authentication. The DOTS client SHOULD respond to the DOTS server's 3197 TLS certificate request message with the PKIX certificate held by the 3198 DOTS client. DOTS client certificate validation MUST be performed as 3199 per [RFC5280] and the DOTS client certificate MUST conform to the 3200 [RFC5280] certificate profile. If a DOTS client does not support TLS 3201 client certificate authentication, it MUST support pre-shared key 3202 based or raw public key based client authentication. 3204 +-----------------------------------------------+ 3205 | example.com domain +---------+ | 3206 | | AAA | | 3207 | +---------------+ | Server | | 3208 | | Application | +------+--+ | 3209 | | server +<-----------------+ ^ | 3210 | | (DOTS client) | | | | 3211 | +---------------+ | | | 3212 | V V | example.net domain 3213 | +-----+----+--+ | +---------------+ 3214 | +--------------+ | | | | | 3215 | | Guest +<-----x----->+ DOTS +<------>+ DOTS | 3216 | | (DOTS client)| | gateway | | | server | 3217 | +--------------+ | | | | | 3218 | +----+--------+ | +---------------+ 3219 | ^ | 3220 | | | 3221 | +----------------+ | | 3222 | | DDoS detector | | | 3223 | | (DOTS client) +<---------------+ | 3224 | +----------------+ | 3225 +-----------------------------------------------+ 3227 Figure 26: Example of Authentication and Authorization of DOTS Agents 3229 In the example depicted in Figure 26, the DOTS gateway and DOTS 3230 clients within the 'example.com' domain mutually authenticate with 3231 each other. After the DOTS gateway validates the identity of a DOTS 3232 client, it communicates with the AAA server in the 'example.com' 3233 domain to determine if the DOTS client is authorized to request DDoS 3234 mitigation. If the DOTS client is not authorized, a 4.01 3235 (Unauthorized) is returned in the response to the DOTS client. In 3236 this example, the DOTS gateway only allows the application server and 3237 DDoS attack detector to request DDoS mitigation, but does not permit 3238 the user of type 'guest' to request DDoS mitigation. 3240 Also, DOTS gateways and servers located in different domains MUST 3241 perform mutual authentication (e.g., using certificates). A DOTS 3242 server will only allow a DOTS gateway with a certificate for a 3243 particular domain to request mitigation for that domain. In 3244 reference to Figure 26, the DOTS server only allows the DOTS gateway 3245 to request mitigation for 'example.com' domain and not for other 3246 domains. 3248 9. IANA Considerations 3250 This specification registers a service port (Section 9.1), an URI 3251 suffix in the Well-Known URIs registry (Section 9.2), a CoAP response 3252 code (Section 9.3), a YANG module (Section 9.5). It also creates a 3253 registry for mappings to CBOR (Section 9.4). 3255 9.1. DOTS Signal Channel UDP and TCP Port Number 3257 IANA is requested to assign the port number TBD to the DOTS signal 3258 channel protocol for both UDP and TCP from the "Service Name and 3259 Transport Protocol Port Number Registry" available at 3260 https://www.iana.org/assignments/service-names-port-numbers/service- 3261 names-port-numbers.xhtml. 3263 The assignment of port number 4646 is strongly suggested, as 4646 is 3264 the ASCII decimal value for ".." (DOTS). 3266 9.2. Well-Known 'dots' URI 3268 This document requests IANA to register the 'dots' well-known URI in 3269 the Well-Known URIs registry (https://www.iana.org/assignments/well- 3270 known-uris/well-known-uris.xhtml) as defined by [RFC5785]. 3272 URI suffix: dots 3274 Change controller: IETF 3276 Specification document(s): This RFC 3278 Related information: None 3280 9.3. CoAP Response Code 3282 IANA is requested to add the following entry to the "CoAP Response 3283 Codes" sub-registry available at https://www.iana.org/assignments/ 3284 core-parameters/core-parameters.xhtml#response-codes: 3286 +------+------------------+-----------+ 3287 | Code | Description | Reference | 3288 +------+------------------+-----------+ 3289 | 3.00 | Alternate Server | [RFCXXXX] | 3290 +------+------------------+-----------+ 3292 Table 5: CoAP Response Code 3294 9.4. DOTS Signal Channel CBOR Mappings Registry 3296 The document requests IANA to create a new registry, entitled "DOTS 3297 Signal Channel CBOR Mappings Registry". The structure of this 3298 registry is provided in Section 9.4.1. 3300 The registry is initially populated with the values in Section 9.4.2. 3302 Values from that registry MUST be assigned via Expert Review 3303 [RFC8126]. 3305 9.4.1. Registration Template 3307 Parameter name: 3308 Parameter name as used in the DOTS signal channel. 3310 CBOR Key Value: 3311 Key value for the parameter. The key value MUST be an integer in 3312 the 1-65536 range. The key values in the 32758-65536 range are 3313 assigned to Vendor-Specific parameters. 3315 CBOR Major Type: 3316 CBOR Major type and optional tag for the claim. 3318 Change Controller: 3319 For Standards Track RFCs, list the "IESG". For others, give the 3320 name of the responsible party. Other details (e.g., postal 3321 address, email address, home page URI) may also be included. 3323 Specification Document(s): 3324 Reference to the document or documents that specify the parameter, 3325 preferably including URIs that can be used to retrieve copies of 3326 the documents. An indication of the relevant sections may also be 3327 included but is not required. 3329 9.4.2. Initial Registry Contents 3331 o Parameter Name: mitigation-scope 3332 o CBOR Key Value: 1 3333 o CBOR Major Type: 5 3334 o Change Controller: IESG 3335 o Specification Document(s): this document 3337 o Parameter Name: scope 3338 o CBOR Key Value: 2 3339 o CBOR Major Type: 5 3340 o Change Controller: IESG 3341 o Specification Document(s): this document 3343 o Parameter Name: mitigation-id 3344 o CBOR Key Value: 3 3345 o CBOR Major Type: 0 3346 o Change Controller: IESG 3347 o Specification Document(s): this document 3349 o Parameter Name: acl-list 3350 o CBOR Key Value: 4 3351 o CBOR Major Type: 4 3352 o Change Controller: IESG 3353 o Specification Document(s): this document 3355 o Parameter Name: target-port-range 3356 o CBOR Key Value: 5 3357 o CBOR Major Type: 4 3358 o Change Controller: IESG 3359 o Specification Document(s): this document 3361 o Parameter Name: lower-port 3362 o CBOR Key Value: 6 3363 o CBOR Major Type: 0 3364 o Change Controller: IESG 3365 o Specification Document(s): this document 3367 o Parameter Name: upper-port 3368 o CBOR Key Value: 7 3369 o CBOR Major Type: 0 3370 o Change Controller: IESG 3371 o Specification Document(s): this document 3373 o Parameter Name: target-protocol 3374 o CBOR Key Value: 8 3375 o CBOR Major Type: 4 3376 o Change Controller: IESG 3377 o Specification Document(s): this document 3379 o Parameter Name: target-fqdn 3380 o CBOR Key Value: 9 3381 o CBOR Major Type: 4 3382 o Change Controller: IESG 3383 o Specification Document(s): this document 3385 o Parameter Name: target-uri 3386 o CBOR Key Value: 10 3387 o CBOR Major Type: 4 3388 o Change Controller: IESG 3389 o Specification Document(s): this document 3391 o Parameter Name: alias-name 3392 o CBOR Key Value: 11 3393 o CBOR Major Type: 4 3394 o Change Controller: IESG 3395 o Specification Document(s): this document 3397 o Parameter Name: lifetime 3398 o CBOR Key Value: 12 3399 o CBOR Major Type: 0 3400 o Change Controller: IESG 3401 o Specification Document(s): this document 3403 o Parameter Name: attack-status 3404 o CBOR Key Value: 13 3405 o CBOR Major Type: 0 3406 o Change Controller: IESG 3407 o Specification Document(s): this document 3409 o Parameter Name: signal-config 3410 o CBOR Key Value: 14 3411 o CBOR Major Type: 5 3412 o Change Controller: IESG 3413 o Specification Document(s): this document 3415 o Parameter Name: heartbeat-interval 3416 o CBOR Key Value: 15 3417 o CBOR Major Type: 5 3418 o Change Controller: IESG 3419 o Specification Document(s): this document 3421 o Parameter Name: max-retransmit 3422 o CBOR Key Value: 16 3423 o CBOR Major Type: 5 3424 o Change Controller: IESG 3425 o Specification Document(s): this document 3427 o Parameter Name: ack-timeout 3428 o CBOR Key Value: 17 3429 o CBOR Major Type: 5 3430 o Change Controller: IESG 3431 o Specification Document(s): this document 3433 o Parameter Name: ack-random-factor 3434 o CBOR Key Value: 18 3435 o CBOR Major Type: 5 3436 o Change Controller: IESG 3437 o Specification Document(s): this document 3439 o Parameter Name: min-value 3440 o CBOR Key Value: 19 3441 o CBOR Major Type: 0 3442 o Change Controller: IESG 3443 o Specification Document(s): this document 3445 o Parameter Name: max-value 3446 o CBOR Key Value: 20 3447 o CBOR Major Type: 0 3448 o Change Controller: IESG 3449 o Specification Document(s): this document 3451 o Parameter Name: status 3452 o CBOR Key Value: 21 3453 o CBOR Major Type: 0 3454 o Change Controller: IESG 3455 o Specification Document(s): this document 3457 o Parameter Name: conflict-information 3458 o CBOR Key Value: 22 3459 o CBOR Major Type: 5 3460 o Change Controller: IESG 3461 o Specification Document(s): this document 3463 o Parameter Name: conflict-status 3464 o CBOR Key Value: 23 3465 o CBOR Major Type: 0 3466 o Change Controller: IESG 3467 o Specification Document(s): this document 3469 o Parameter Name: conflict-cause 3470 o CBOR Key Value: 24 3471 o CBOR Major Type: 0 3472 o Change Controller: IESG 3473 o Specification Document(s): this document 3475 o Parameter Name: retry-timer 3476 o CBOR Key Value: 25 3477 o CBOR Major Type: 0 3478 o Change Controller: IESG 3479 o Specification Document(s): this document 3481 o Parameter Name: bytes-dropped 3482 o CBOR Key Value: 26 3483 o CBOR Major Type: 0 3484 o Change Controller: IESG 3485 o Specification Document(s): this document 3487 o Parameter Name: bps-dropped 3488 o CBOR Key Value: 27 3489 o CBOR Major Type: 0 3490 o Change Controller: IESG 3491 o Specification Document(s): this document 3493 o Parameter Name: pkts-dropped 3494 o CBOR Key Value: 28 3495 o CBOR Major Type: 0 3496 o Change Controller: IESG 3497 o Specification Document(s): this document 3499 o Parameter Name: pps-dropped 3500 o CBOR Key Value: 29 3501 o CBOR Major Type: 0 3502 o Change Controller: IESG 3503 o Specification Document(s): this document 3505 o Parameter Name: session-id 3506 o CBOR Key Value: 30 3507 o CBOR Major Type: 0 3508 o Change Controller: IESG 3509 o Specification Document(s): this document 3511 o Parameter Name: trigger-mitigation 3512 o CBOR Key Value: 31 3513 o CBOR Major Type: 7 3514 o Change Controller: IESG 3515 o Specification Document(s): this document 3517 o Parameter Name: missing-hb-allowed 3518 o CBOR Key Value: 32 3519 o CBOR Major Type: 5 3520 o Change Controller: IESG 3521 o Specification Document(s): this document 3523 o Parameter Name: current-value 3524 o CBOR Key Value: 33 3525 o CBOR Major Type: 0 3526 o Change Controller: IESG 3527 o Specification Document(s): this document 3529 o Parameter Name: mitigation-start 3530 o CBOR Key Value: 34 3531 o CBOR Major Type: 7 3532 o Change Controller: IESG 3533 o Specification Document(s): this document 3535 o Parameter Name: target-prefix 3536 o CBOR Key Value: 35 3537 o CBOR Major Type: 4 3538 o Change Controller: IESG 3539 o Specification Document(s): this document 3541 o Parameter Name: client-domain-hash 3542 o CBOR Key Value: 36 3543 o CBOR Major Type: 3 3544 o Change Controller: IESG 3545 o Specification Document(s): this document 3547 o Parameter Name: alt-server 3548 o CBOR Key Value: 37 3549 o CBOR Major Type: 3 3550 o Change Controller: IESG 3551 o Specification Document(s): this document 3553 o Parameter Name: alt-server-record 3554 o CBOR Key Value: 38 3555 o CBOR Major Type: 4 3556 o Change Controller: IESG 3557 o Specification Document(s): this document 3559 o Parameter Name: addr 3560 o CBOR Key Value: 39 3561 o CBOR Major Type: 3 3562 o Change Controller: IESG 3563 o Specification Document(s): this document 3565 o Parameter Name: ttl 3566 o CBOR Key Value: 40 3567 o CBOR Major Type: 0 3568 o Change Controller: IESG 3569 o Specification Document(s): this document 3571 o Parameter Name: conflict-scope 3572 o CBOR Key Value: 41 3573 o CBOR Major Type: 5 3574 o Change Controller: IESG 3575 o Specification Document(s): this document 3577 o Parameter Name: acl-name 3578 o CBOR Key Value: 42 3579 o CBOR Major Type: 3 3580 o Change Controller: IESG 3581 o Specification Document(s): this document 3583 o Parameter Name: acl-type 3584 o CBOR Key Value: 43 3585 o CBOR Major Type: 3 3586 o Change Controller: IESG 3587 o Specification Document(s): this document 3589 o Parameter Name: config-interval 3590 o CBOR Key Value: 44 3591 o CBOR Major Type: 0 3592 o Change Controller: IESG 3593 o Specification Document(s): this document 3595 o Parameter Name: mitigating-config 3596 o CBOR Key Value: 45 3597 o CBOR Major Type: 5 3598 o Change Controller: IESG 3599 o Specification Document(s): this document 3601 o Parameter Name: idle-config 3602 o CBOR Key Value: 46 3603 o CBOR Major Type: 5 3604 o Change Controller: IESG 3605 o Specification Document(s): this document 3607 o Parameter Name: cuid 3608 o CBOR Key Value: 47 3609 o CBOR Major Type: 3 3610 o Change Controller: IESG 3611 o Specification Document(s): this document 3613 o Parameter Name: min-value-decimal 3614 o CBOR Key Value: 48 3615 o CBOR Major Type: 7 3616 o Change Controller: IESG 3617 o Specification Document(s): this document 3619 o Parameter Name: max-value-decimal 3620 o CBOR Key Value: 49 3621 o CBOR Major Type: 7 3622 o Change Controller: IESG 3623 o Specification Document(s): this document 3625 o Parameter Name: current-value-decimal 3626 o CBOR Key Value: 50 3627 o CBOR Major Type: 7 3628 o Change Controller: IESG 3629 o Specification Document(s): this document 3631 9.5. DOTS Signal Channel YANG Module 3633 This document requests IANA to register the following URI in the 3634 "IETF XML Registry" [RFC3688]: 3636 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal 3637 Registrant Contact: The IESG. 3638 XML: N/A; the requested URI is an XML namespace. 3640 This document requests IANA to register the following YANG module in 3641 the "YANG Module Names" registry [RFC7950]. 3643 name: ietf-signal 3644 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal 3645 prefix: signal 3646 reference: RFC XXXX 3648 10. Implementation Status 3650 [Note to RFC Editor: Please remove this section and reference to 3651 [RFC7942] prior to publication.] 3653 This section records the status of known implementations of the 3654 protocol defined by this specification at the time of posting this 3655 Internet-Draft, and is based upon a proposal described in [RFC7942]. 3656 The description of implementations in this section is intended to 3657 assist the IETF in its decision-making process when progressing 3658 drafts to RFCs. Please note that the listing of any individual 3659 implementation here does not imply endorsement by the IETF. 3660 Furthermore, no effort has been spent to verify the information 3661 presented here, and which was provided by individuals. This is not 3662 intended as, and must not be construed to be, a catalog of available 3663 implementations or features. Readers are advised to note that other 3664 implementations may exist. 3666 According to [RFC7942], "this will allow reviewers and working groups 3667 to assign due consideration to documents that have the benefit of 3668 running code, which may serve as evidence of valuable experimentation 3669 and feedback that have made the implemented protocols more mature. 3670 It is up to the individual working groups to use this information as 3671 they see fit". 3673 10.1. nttdots 3675 Organization: NTT Communication is developing a DOTS client and 3676 DOTS server software based on DOTS signal channel specified in 3677 this draft. It will be open-sourced. 3678 Description: Early implementation of DOTS protocol. It is aimed to 3679 implement a full DOTS protocol specification in accordance with 3680 the nurturing DOTS protocol. 3681 Implementation: https://github.com/nttdots/go-dots 3682 Level of maturity: It is an early implementation of the DOTS 3683 protocol. Messaging between DOTS clients and DOTS servers has 3684 been tested. Level of maturity will increase in accordance with 3685 the nurturing DOTS protocol. 3686 Coverage: Capability of DOTS client: sending DOTS messages to the 3687 DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS 3688 server: receiving dots-signal, validating received dots-signal, 3689 starting mitigation by handing over the dots-signal to DDoS 3690 mitigator. 3691 Licensing: It will be open-sourced with BSD 3-clause license. 3692 Implementation experience: It is implemented in Go-lang. Core 3693 specification of signaling is mature to be implemented, however, 3694 finding good libraries(like DTLS, CoAP) is rather difficult. 3695 Contact: Kaname Nishizuka 3697 11. Security Considerations 3699 Authenticated encryption MUST be used for data confidentiality and 3700 message integrity. The interaction between the DOTS agents requires 3701 Datagram Transport Layer Security (DTLS) and Transport Layer Security 3702 (TLS) with a cipher suite offering confidentiality protection and the 3703 guidance given in [RFC7525] MUST be followed to avoid attacks on 3704 (D)TLS. The (D)TLS protocol profile for DOTS signal channel is 3705 specified in Section 7. 3707 A single DOTS signal channel between DOTS agents can be used to 3708 exchange multiple DOTS signal messages. To reduce DOTS client and 3709 DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session. 3711 If TCP is used between DOTS agents, an attacker may be able to inject 3712 RST packets, bogus application segments, etc., regardless of whether 3713 TLS authentication is used. Because the application data is TLS 3714 protected, this will not result in the application receiving bogus 3715 data, but it will constitute a DoS on the connection. This attack 3716 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 3717 any bogus packets injected by an attacker will be rejected by the 3718 TCP-AO integrity check and therefore will never reach the TLS layer. 3720 In order to prevent leaking internal information outside a client- 3721 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 3722 the identification information that pertains to internal DOTS clients 3723 (e.g., source IP address, client's hostname) unless explicitly 3724 configured to do so. 3726 Special care should be taken in order to ensure that the activation 3727 of the proposed mechanism will not impact the stability of the 3728 network (including connectivity and services delivered over that 3729 network). 3731 12. Contributors 3733 The following individuals have contributed to this document: 3735 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 3736 mgeller@cisco.com 3738 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 3739 Email: rgm@htt-consult.com 3741 Dan Wing Email: dwing-ietf@fuggles.com 3743 13. Acknowledgements 3745 Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, 3746 Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang 3747 Xia, Gilbert Clark, and Nesredien Suleiman for the discussion and 3748 comments. 3750 Special thanks to Jon Shallow for the careful reviews and inputs that 3751 enhanced this specification. 3753 14. References 3755 14.1. Normative References 3757 [I-D.ietf-core-coap-tcp-tls] 3758 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 3759 Silverajan, B., and B. Raymor, "CoAP (Constrained 3760 Application Protocol) over TCP, TLS, and WebSockets", 3761 draft-ietf-core-coap-tcp-tls-11 (work in progress), 3762 December 2017. 3764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3765 Requirement Levels", BCP 14, RFC 2119, 3766 DOI 10.17487/RFC2119, March 1997, 3767 . 3769 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3770 DOI 10.17487/RFC3688, January 2004, 3771 . 3773 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 3774 Ciphersuites for Transport Layer Security (TLS)", 3775 RFC 4279, DOI 10.17487/RFC4279, December 2005, 3776 . 3778 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3779 (TLS) Protocol Version 1.2", RFC 5246, 3780 DOI 10.17487/RFC5246, August 2008, 3781 . 3783 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3784 Housley, R., and W. Polk, "Internet X.509 Public Key 3785 Infrastructure Certificate and Certificate Revocation List 3786 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3787 . 3789 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3790 Uniform Resource Identifiers (URIs)", RFC 5785, 3791 DOI 10.17487/RFC5785, April 2010, 3792 . 3794 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 3795 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 3796 June 2010, . 3798 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 3799 Extensions: Extension Definitions", RFC 6066, 3800 DOI 10.17487/RFC6066, January 2011, 3801 . 3803 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3804 Verification of Domain-Based Application Service Identity 3805 within Internet Public Key Infrastructure Using X.509 3806 (PKIX) Certificates in the Context of Transport Layer 3807 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3808 2011, . 3810 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 3811 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 3812 DOI 10.17487/RFC6234, May 2011, 3813 . 3815 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3816 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3817 January 2012, . 3819 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 3820 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 3821 Transport Layer Security (TLS) and Datagram Transport 3822 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 3823 June 2014, . 3825 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3826 Application Protocol (CoAP)", RFC 7252, 3827 DOI 10.17487/RFC7252, June 2014, 3828 . 3830 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3831 "Recommendations for Secure Use of Transport Layer 3832 Security (TLS) and Datagram Transport Layer Security 3833 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3834 2015, . 3836 [RFC7641] Hartke, K., "Observing Resources in the Constrained 3837 Application Protocol (CoAP)", RFC 7641, 3838 DOI 10.17487/RFC7641, September 2015, 3839 . 3841 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3842 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3843 . 3845 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3846 Writing an IANA Considerations Section in RFCs", BCP 26, 3847 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3848 . 3850 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 3851 FETCH Methods for the Constrained Application Protocol 3852 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 3853 . 3855 14.2. Informative References 3857 [I-D.ietf-core-comi] 3858 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 3859 Management Interface", draft-ietf-core-comi-02 (work in 3860 progress), December 2017. 3862 [I-D.ietf-core-yang-cbor] 3863 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 3864 Minaburo, "CBOR Encoding of Data Modeled with YANG", 3865 draft-ietf-core-yang-cbor-05 (work in progress), August 3866 2017. 3868 [I-D.ietf-dots-architecture] 3869 Mortensen, A., Andreasen, F., Reddy, T., 3870 christopher_gray3@cable.comcast.com, c., Compton, R., and 3871 N. Teague, "Distributed-Denial-of-Service Open Threat 3872 Signaling (DOTS) Architecture", draft-ietf-dots- 3873 architecture-05 (work in progress), October 2017. 3875 [I-D.ietf-dots-data-channel] 3876 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 3877 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 3878 Service Open Threat Signaling (DOTS) Data Channel", draft- 3879 ietf-dots-data-channel-11 (work in progress), December 3880 2017. 3882 [I-D.ietf-dots-requirements] 3883 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 3884 Denial of Service (DDoS) Open Threat Signaling 3885 Requirements", draft-ietf-dots-requirements-10 (work in 3886 progress), January 2018. 3888 [I-D.ietf-dots-use-cases] 3889 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 3890 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 3891 Open Threat Signaling", draft-ietf-dots-use-cases-09 (work 3892 in progress), November 2017. 3894 [I-D.ietf-netmod-yang-tree-diagrams] 3895 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 3896 ietf-netmod-yang-tree-diagrams-04 (work in progress), 3897 December 2017. 3899 [I-D.ietf-tls-dtls13] 3900 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 3901 Datagram Transport Layer Security (DTLS) Protocol Version 3902 1.3", draft-ietf-tls-dtls13-22 (work in progress), 3903 November 2017. 3905 [I-D.ietf-tls-tls13] 3906 Rescorla, E., "The Transport Layer Security (TLS) Protocol 3907 Version 1.3", draft-ietf-tls-tls13-22 (work in progress), 3908 November 2017. 3910 [proto_numbers] 3911 "IANA, "Protocol Numbers"", 2011, 3912 . 3914 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3915 DOI 10.17487/RFC0791, September 1981, 3916 . 3918 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3919 Address Translator (Traditional NAT)", RFC 3022, 3920 DOI 10.17487/RFC3022, January 2001, 3921 . 3923 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3924 Resource Identifier (URI): Generic Syntax", STD 66, 3925 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3926 . 3928 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3929 "Randomness Requirements for Security", BCP 106, RFC 4086, 3930 DOI 10.17487/RFC4086, June 2005, 3931 . 3933 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3934 Congestion Control Protocol (DCCP)", RFC 4340, 3935 DOI 10.17487/RFC4340, March 2006, 3936 . 3938 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3939 (CIDR): The Internet Address Assignment and Aggregation 3940 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 3941 2006, . 3943 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 3944 Denial-of-Service Considerations", RFC 4732, 3945 DOI 10.17487/RFC4732, December 2006, 3946 . 3948 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 3949 Translation (NAT) Behavioral Requirements for Unicast 3950 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 3951 2007, . 3953 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3954 Extensions for Stateless Address Autoconfiguration in 3955 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 3956 . 3958 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3959 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3960 . 3962 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3963 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 3964 . 3966 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 3967 "Transport Layer Security (TLS) Session Resumption without 3968 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 3969 January 2008, . 3971 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3972 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3973 DOI 10.17487/RFC5389, October 2008, 3974 . 3976 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3977 NAT64: Network Address and Protocol Translation from IPv6 3978 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3979 April 2011, . 3981 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3982 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 3983 . 3985 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 3986 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 3987 2012, . 3989 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 3990 "Default Address Selection for Internet Protocol Version 6 3991 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 3992 . 3994 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 3995 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 3996 DOI 10.17487/RFC6887, April 2013, 3997 . 3999 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 4000 A., and H. Ashida, "Common Requirements for Carrier-Grade 4001 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 4002 April 2013, . 4004 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4005 "Enrollment over Secure Transport", RFC 7030, 4006 DOI 10.17487/RFC7030, October 2013, 4007 . 4009 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 4010 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 4011 October 2013, . 4013 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 4014 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 4015 . 4017 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 4018 "Architectural Considerations in Smart Object Networking", 4019 RFC 7452, DOI 10.17487/RFC7452, March 2015, 4020 . 4022 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 4023 NETCONF Protocol over Transport Layer Security (TLS) with 4024 Mutual X.509 Authentication", RFC 7589, 4025 DOI 10.17487/RFC7589, June 2015, 4026 . 4028 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 4029 Layer Security (TLS) False Start", RFC 7918, 4030 DOI 10.17487/RFC7918, August 2016, 4031 . 4033 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 4034 (TLS) Cached Information Extension", RFC 7924, 4035 DOI 10.17487/RFC7924, July 2016, 4036 . 4038 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 4039 Code: The Implementation Status Section", BCP 205, 4040 RFC 7942, DOI 10.17487/RFC7942, July 2016, 4041 . 4043 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 4044 RFC 7951, DOI 10.17487/RFC7951, August 2016, 4045 . 4047 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 4048 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 4049 March 2017, . 4051 Authors' Addresses 4053 Tirumaleswar Reddy (editor) 4054 McAfee, Inc. 4055 Embassy Golf Link Business Park 4056 Bangalore, Karnataka 560071 4057 India 4059 Email: kondtir@gmail.com 4061 Mohamed Boucadair (editor) 4062 Orange 4063 Rennes 35000 4064 France 4066 Email: mohamed.boucadair@orange.com 4068 Prashanth Patil 4069 Cisco Systems, Inc. 4071 Email: praspati@cisco.com 4073 Andrew Mortensen 4074 Arbor Networks, Inc. 4075 2727 S. State St 4076 Ann Arbor, MI 48104 4077 United States 4079 Email: amortensen@arbor.net 4081 Nik Teague 4082 Verisign, Inc. 4083 United States 4085 Email: nteague@verisign.com