idnits 2.17.1 draft-ietf-dots-signal-channel-16.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 2170 has weird spacing: '...er-port ine...' == Line 2171 has weird spacing: '...er-port ine...' == Line 2186 has weird spacing: '...er-port ine...' == Line 2187 has weird spacing: '...er-port ine...' == Line 2249 has weird spacing: '...rw addr ine...' -- The document date (January 11, 2018) is 2297 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 3308, 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 15, 2018 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 January 11, 2018 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel 16 draft-ietf-dots-signal-channel-16 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 15, 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 . . . . 24 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=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example" 506 Uri-Path: "mitigation-id=123" 507 Content-Type: "application/cbor" 508 { 509 "ietf-dots-signal:mitigation-scope": { 510 "scope": [ 511 { 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 MUST handle CUID collision directly 564 and it is RECOMMENDED that CUID collision is handled directly by 565 server-domain DOTS gateways. 567 Client-domain DOTS gateways MAY rewrite the CUIDs used by internal 568 DOTS clients. Triggers for such rewriting are out of scope. 570 This is a mandatory attribute. 572 mitigation-id: Identifier for the mitigation request represented 573 with an integer. This identifier MUST be unique for each 574 mitigation request bound to the DOTS client, i.e., the 575 'mitigation-id' parameter value in the mitigation request needs to 576 be unique relative to the 'mitigation-id' parameter values of 577 active mitigation requests conveyed from the DOTS client to the 578 DOTS server. This identifier MUST be generated by the DOTS 579 client. This document does not make any assumption about how this 580 identifier is generated. 582 This is a mandatory attribute. 584 target-prefix: A list of prefixes identifying resources under 585 attack. Prefixes are represented using Classless Inter-Domain 586 Routing (CIDR) notation [RFC4632]. 587 As a reminder, the prefix length must be less than or equal to 32 588 (resp. 128) for IPv4 (resp. IPv6). 590 This is an optional attribute. 592 target-port-range: A list of port numbers bound to resources under 593 attack. 595 The port range is defined by two bounds, a lower port number 596 (lower-port) and an upper port number (upper-port). When only 597 'lower-port' is present, it represents a single port number. For 598 TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], 599 or Datagram Congestion Control Protocol (DCCP) [RFC4340], the 600 range of ports can be, for example, 1024-65535. 602 This is an optional attribute. 604 target-protocol: A list of protocols involved in an attack. Values 605 are taken from the IANA protocol registry [proto_numbers]. 607 The value '0' has a special meaning for 'all protocols'. 609 This is an optional attribute. 611 target-fqdn: A list of Fully Qualified Domain Names (FQDNs) 612 identifying resources under attack. An FQDN is the full name of a 613 resource, rather than just its hostname. For example, "venera" is 614 a hostname, and "venera.isi.edu" is an FQDN. 616 This is an optional attribute. 618 target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986] 619 identifying resources under attack. 621 This is an optional attribute. 623 alias-name: A list of aliases of resources for which the mitigation 624 is requested. Aliases can be created using the DOTS data channel 625 (Section 6.1 of [I-D.ietf-dots-data-channel]), direct 626 configuration, or other means. An alias is used in subsequent 627 signal channel exchanges to refer more efficiently to the 628 resources under attack. 630 This is an optional attribute. 632 lifetime: Lifetime of the mitigation request in seconds. The 633 RECOMMENDED lifetime of a mitigation request is 3600 seconds (60 634 minutes) -- this value was chosen to be long enough so that 635 refreshing is not typically a burden on the DOTS client, while 636 expiring the request where the client has unexpectedly quit in a 637 timely manner. DOTS clients MUST include this parameter in their 638 mitigation requests. Upon the expiry of this lifetime, and if the 639 request is not refreshed, the mitigation request is removed. The 640 request can be refreshed by sending the same request again. 642 A lifetime of '0' in a mitigation request is an invalid value. 644 A lifetime of negative one (-1) indicates indefinite lifetime for 645 the mitigation request. The DOTS server MAY refuse indefinite 646 lifetime, for policy reasons; the granted lifetime value is 647 returned in the response. DOTS clients MUST be prepared to not be 648 granted mitigations with indefinite lifetimes. 650 The DOTS server MUST always indicate the actual lifetime in the 651 response and the remaining lifetime in status messages sent to the 652 DOTS client. 654 This is a mandatory attribute. 656 In deployments where server-domain DOTS gateways are enabled, 657 identity information about the origin source client domain has to be 658 supplied to the DOTS server. That information is meant to assist the 659 DOTS server to enforce some policies. Figure 6 shows an example of a 660 request relayed by a server-domain DOTS gateway. 662 Header: PUT (Code=0.03) 663 Uri-Host: "host" 664 Uri-Path: ".well-known" 665 Uri-Path: "dots" 666 Uri-Path: "version" 667 Uri-Path: "mitigate" 668 Uri-Path: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example" 669 Uri-Path: "mitigation-id=123" 670 Content-Type: "application/cbor" 671 { 672 "ietf-dots-signal:mitigation-scope": { 673 "client-domain-hash": "string", 674 "scope": [ 675 { 676 "target-prefix": [ 677 "string" 678 ], 679 "target-port-range": [ 680 { 681 "lower-port": integer, 682 "upper-port": integer 683 } 684 ], 685 "target-protocol": [ 686 integer 687 ], 688 "target-fqdn": [ 689 "string" 690 ], 691 "target-uri": [ 692 "string" 693 ], 694 "alias-name": [ 695 "string" 696 ], 697 "lifetime": integer 698 } 699 ] 700 } 701 } 703 Figure 6: PUT to Convey DOTS Mitigation Request as relayed by a 704 Server-Domain DOTS Gateway 706 The DOTS gateway may add the following parameter: 708 client-domain-hash: The client identifier MAY be conveyed by a 709 server-domain DOTS gateway to propagate the source domain identity 710 from the gateway's client-side to the gateway's server-side, and 711 from the gateway's server-side to the DOTS server. 'client-domain- 712 hash' MAY be used by the final DOTS server for policy enforcement 713 purposes (e.g., enforce a quota on filtering rules). 715 The 'client-domain-hash' value MUST be assigned by the server- 716 domain DOTS gateway in a manner that ensures that there is zero 717 probability that the same value will be assigned to a different 718 client domain. 720 If the DOTS client is using the certificate provisioned by the 721 Enrollment over Secure Transport (EST) server [RFC7030] in the 722 DOTS gateway-domain to authenticate itself to the DOTS gateway, 723 the 'client-domain-hash' value may be the output of a 724 cryptographic hash algorithm whose input is the DER-encoded ASN.1 725 representation of the Subject Public Key Info (SPKI) of an X.509 726 certificate. In this version of the specification, the 727 cryptographic hash algorithm used is SHA-256 [RFC6234]. The 728 output of the cryptographic hash algorithm is truncated to 16 729 bytes; truncation is done by stripping off the final 16 bytes. 730 The truncated output is base64url encoded. 732 The 'client-domain-hash' attribute MUST NOT be generated and 733 included by DOTS clients. 735 DOTS servers MUST ignore 'client-domain-hash' attributes that are 736 directly supplied by source DOTS clients or client-domain DOTS 737 gateways. This implies that first server-domain DOTS gateways 738 MUST strip 'client-domain-hash' attributes supplied by DOTS 739 clients. DOTS servers MAY support a configuration parameter to 740 identify DOTS gateways that are trusted to supply 'client-domain- 741 hash' attributes. 743 Only singe-valued 'client-domain-hash' are defined in this 744 document. 746 This is an optional attribute. 748 Because of the complexity to handle partial failure cases, this 749 specification does not allow for including multiple mitigation 750 requests in the same PUT request. Concretely, a DOTS client MUST NOT 751 include multiple 'scope' parameters in the same PUT request. 753 The CBOR key values for the parameters are defined in Section 6. 754 Section 9 defines how the CBOR key values can be allocated to 755 standard bodies and vendors. 757 FQDN and URI mitigation scopes may be thought of as a form of scope 758 alias, in which the addresses to which the domain name or URI resolve 759 represent the full scope of the mitigation. 761 In the PUT request at least one of the attributes 'target-prefix' or 762 'target-fqdn' or 'target-uri 'or 'alias-name' MUST be present. 763 Attributes with empty values MUST NOT be present in a request. 765 The relative order of two mitigation requests from a DOTS client is 766 determined by comparing their respective 'mitigation-id' values. If 767 two mitigation requests have overlapping mitigation scopes, the 768 mitigation request with the highest numeric 'mitigation-id' value 769 will override the other mitigation request. Two mitigation-ids from 770 a DOTS client are overlapping if there is a common IP address, IP 771 prefix, FQDN, URI, or alias-name. To avoid maintaining a long list 772 of overlapping mitigation requests from a DOTS client and avoid 773 error-prone provisioning of mitigation requests from a DOTS client, 774 the overlapped lower numeric 'mitigation-id' MUST be automatically 775 deleted and no longer available at the DOTS server. 777 The Uri-Path option carries a major and minor version nomenclature to 778 manage versioning and DOTS signal channel in this specification uses 779 v1 major version. 781 Figure 7 shows a PUT request example to signal that ports 80, 8080, 782 and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 servers are 783 under attack (illustrated in JSON diagnostic notation). The presence 784 of 'client-domain-hash' indicates that a server-domain DOTS gateway 785 has modified the initial PUT request sent by the DOTS client. 787 Header: PUT (Code=0.03) 788 Uri-Host: "www.example.com" 789 Uri-Path: ".well-known" 790 Uri-Path: "dots" 791 Uri-Path: "v1" 792 Uri-Path: "mitigate" 793 Uri-Path: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example" 794 Uri-Path: "mitigation-id=123" 795 Content-Format: "application/cbor" 796 { 797 "ietf-dots-signal:mitigation-scope": { 798 "client-domain-hash": "dz6pHjaADkaFTbjr0JGBpw", 799 "scope": [ 800 { 801 "target-prefix": [ 802 "2001:db8:6401::1/128", 803 "2001:db8:6401::2/128" 804 ], 805 "target-port-range": [ 806 { 807 "lower-port": 80 808 }, 809 { 810 "lower-port": 443 811 }, 812 { 813 "lower-port": 8080 814 } 815 ], 816 "target-protocol": [ 817 6 818 ] 819 } 820 ] 821 } 822 } 824 Figure 7: PUT for DOTS Mitigation Request 826 The corresponding CBOR encoding format is shown in Figure 8. 828 A1 # map(1) 829 01 # unsigned(1) 830 A2 # map(2) 831 18 24 # unsigned(36) 832 76 # text(22) 833 647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw" 834 02 # unsigned(2) 835 81 # array(1) 836 A3 # map(3) 837 18 23 # unsigned(35) 838 82 # array(2) 839 74 # text(20) 840 323030313A6462383A363430313A3A312F313238 # "2001:db8:6401::1/128" 841 74 # text(20) 842 323030313A6462383A363430313A3A322F313238 # "2001:db8:6401::2/128" 843 05 # unsigned(5) 844 83 # array(3) 845 A1 # map(1) 846 06 # unsigned(6) 847 18 50 # unsigned(80) 848 A1 # map(1) 849 06 # unsigned(6) 850 19 01BB # unsigned(443) 851 A1 # map(1) 852 06 # unsigned(6) 853 19 1F90 # unsigned(8080) 854 08 # unsigned(8) 855 81 # array(1) 856 06 # unsigned(6) 858 Figure 8: PUT for DOTS Mitigation Request (CBOR) 860 In both DOTS signal and data channel sessions, the DOTS client MUST 861 authenticate itself to the DOTS server (Section 8). The DOTS server 862 may use the algorithm presented in Section 7 of [RFC7589] to derive 863 the DOTS client identity or username from the client certificate. 864 The DOTS client identity allows the DOTS server to accept mitigation 865 requests with scopes that the DOTS client is authorized to manage. 866 The DOTS server couples the DOTS signal and data channel sessions 867 using the DOTS client identity or the 'client-domain-hash' parameter 868 value, so the DOTS server can validate whether the aliases conveyed 869 in the mitigation request were indeed created by the same DOTS client 870 using the DOTS data channel session. If the aliases were not created 871 by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in 872 the response. 874 The DOTS server couples the DOTS signal channel sessions using the 875 DOTS client identity or the 'client-domain-hash' parameter value, and 876 the DOTS server uses 'mitigation-id' and 'cuid' parameter values to 877 detect duplicate mitigation requests. If the mitigation request 878 contains the alias-name and other parameters identifying the target 879 resources (such as, 'target-prefix', 'target-port-range', 'target- 880 fqdn', or 'target-uri'), the DOTS server appends the parameter values 881 in 'alias-name' with the corresponding parameter values in 'target- 882 prefix', 'target-port-range', 'target-fqdn', or 'target-uri'. 884 The DOTS server indicates the result of processing the PUT request 885 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 886 codes are some sort of invalid requests (client errors). COAP 5.xx 887 codes are returned if the DOTS server has erred or is currently 888 unavailable to provide mitigation in response to the mitigation 889 request from the DOTS client. 891 Figure 9 shows an example of a PUT request that is successfully 892 processed by a DOTS server (i.e., CoAP 2.xx response codes). 894 { 895 "ietf-dots-signal:mitigation-scope": { 896 "client-domain-hash": "dz6pHjaADkaFTbjr0JGBpw", 897 "scope": [ 898 { 899 "mitigation-id": 12332, 900 "lifetime": 3600 901 } 902 ] 903 } 904 } 906 Figure 9: 2.xx Response Body 908 If the request is missing one or more mandatory attributes, or 909 includes multiple 'scope' parameters, or contains invalid or unknown 910 parameters, the DOTS server MUST reply with 4.00 (Bad Request). DOTS 911 agents can safely ignore Vendor-Specific parameters they don't 912 understand. 914 A DOTS server that receives a mitigation request with a lifetime set 915 to '0' MUST reply with a 4.00 (Bad Request). 917 If the DOTS server does not find the 'mitigation-id' parameter value 918 conveyed in the PUT request in its configuration data, it MAY accept 919 the mitigation request by sending back a 2.01 (Created) response to 920 the DOTS client; the DOTS server will consequently try to mitigate 921 the attack. 923 If the DOTS server finds the 'mitigation-id' parameter value conveyed 924 in the PUT request in its configuration data bound to that DOTS 925 client, it MAY update the mitigation request, and a 2.04 (Changed) 926 response is returned to indicate a successful update of the 927 mitigation request. 929 If the request is conflicting with an existing mitigation request 930 from a different DOTS client, and the DOTS server decides to maintain 931 the conflicting mitigation request, the DOTS server returns 4.09 932 (Conflict) [RFC8132] to the requesting DOTS client. The response 933 includes enough information for a DOTS client to recognize the source 934 of the conflict as described below: 936 conflict-information: Indicates that a mitigation request is 937 conflicting with another mitigation request(s) from other DOTS 938 client(s). This optional attribute has the following structure: 940 conflict-status: Indicates the status of a conflicting mitigation 941 request. The following values are defined: 943 1: DOTS server has detected conflicting mitigation requests 944 from different DOTS clients. This mitigation request is 945 currently inactive until the conflicts are resolved. 946 Another mitigation request is active. 948 2: DOTS server has detected conflicting mitigation requests 949 from different DOTS clients. This mitigation request is 950 currently active. 952 3: DOTS server has detected conflicting mitigation requests 953 from different DOTS clients. All conflicting mitigation 954 requests are inactive. 956 conflict-cause: Indicates the cause of the conflict. The 957 following values are defined: 959 1: Overlapping targets. 'conflict-scope' provides more details 960 about the conflicting target clauses. 962 2: Conflicts with an existing white list. This code is 963 returned when the DDoS mitigation detects source addresses/ 964 prefixes in the white-listed ACLs are attacking the target. 966 3: CUID Collision. This code is returned when a DOTS client 967 uses a CUID that is already used by another DOTS client of 968 the same domain. This code is an indication that the 969 request has been rejected and a new request with a new CUID 970 is to be re-sent by the DOTS client. Note that 'conflict- 971 status', 'conflict-scope', and 'retry-timer' are not 972 returned in the error response. 974 conflict-scope: Indicates the conflict scope. It may include a 975 list of IP addresses, a list of prefixes, a list of port 976 numbers, a list of target protocols, a list of FQDNs, a list of 977 URIs, a list of alias-names, or references to conflicting ACLs. 979 retry-timer: Indicates, in seconds, the time after which the DOTS 980 client may re-issue the same request. The DOTS server returns 981 'retry-timer' only to DOTS client(s) for which a mitigation 982 request is deactivated. Any retransmission of the same 983 mitigation request before the expiry of this timer is likely to 984 be rejected by the DOTS server for the same reasons. 986 The retry-timer SHOULD be equal to the lifetime of the active 987 mitigation request resulting in the deactivation of the 988 conflicting mitigation request. The lifetime of the 989 deactivated mitigation request will be updated to (retry-timer 990 + 45 seconds), so the DOTS client can refresh the deactivated 991 mitigation request after retry-timer seconds before expiry of 992 lifetime and check if the conflict is resolved. 994 For a mitigation request to continue beyond the initial negotiated 995 lifetime, the DOTS client has to refresh the current mitigation 996 request by sending a new PUT request. This PUT request MUST use the 997 same 'mitigation-id' value, and MUST repeat all the other parameters 998 as sent in the original mitigation request apart from a possible 999 change to the lifetime parameter value. 1001 The DOTS gateway, which inserted a 'client-domain-hash' attribute in 1002 a request, MUST strip the 'client-domain-hash' parameter in the 1003 corresponding response before forwarding the response to the DOTS 1004 client. If we consider the example depicted in Figure 9, the message 1005 that will be relayed by the DOTS gateway is shown in Figure 10. 1007 { 1008 "ietf-dots-signal:mitigation-scope": { 1009 "scope": [ 1010 { 1011 "mitigation-id": 12332, 1012 "lifetime": 3600 1013 } 1014 ] 1015 } 1016 } 1018 Figure 10: 2.xx Response Body Relayed by a DOTS Gateway 1020 4.4.2. Retrieve Information Related to a Mitigation 1022 A GET request is used by a DOTS client to retrieve information 1023 (including status) of DOTS mitigations from a DOTS server. 1025 The same considerations for manipulating 'client-domain-hash' 1026 parameter by server-domain DOTS gateways specified in Section 4.4.1 1027 MUST be followed for GET requests. 1029 If the DOTS server does not find the 'mitigation-id' parameter value 1030 conveyed in the GET request in its configuration data for the 1031 requesting DOTS client or the one identified by 'client-domain-hash', 1032 it MUST respond with a 4.04 (Not Found) error response code. 1033 Likewise, the same error MUST be returned as a response to a request 1034 to retrieve all mitigation records of a given DOTS client if the DOTS 1035 server does not find any mitigation record for that DOTS client or 1036 the one identified by 'client-domain-hash'. 1038 The 'c' (content) parameter and its permitted values defined in 1039 [I-D.ietf-core-comi] can be used to retrieve non-configuration data 1040 (attack mitigation status) or configuration data or both. The DOTS 1041 server may support this optional filtering capability. It can safely 1042 ignore it if not supported. 1044 The following examples illustrate how a DOTS client retrieves active 1045 mitigation requests from a DOTS server. In particular: 1047 o Figure 11 shows the example of a GET request to retrieve all DOTS 1048 mitigation requests signaled by a DOTS client. 1050 o Figure 12 shows the example of a GET request to retrieve a 1051 specific DOTS mitigation request signaled by a DOTS client. The 1052 configuration data to be reported in the response is formatted in 1053 the same order it was processed by the DOTS server. 1055 These two examples assume the default of "c=a"; that is, the DOTS 1056 client asks for all data to be reported by the DOTS server. 1058 Header: GET (Code=0.01) 1059 Uri-Host: "host" 1060 Uri-Path: ".well-known" 1061 Uri-Path: "dots" 1062 Uri-Path: "version" 1063 Uri-Path: "mitigate" 1064 Uri-Query: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example" 1065 Observe : 0 1067 Figure 11: GET to Retrieve all DOTS Mitigation Requests 1069 Header: GET (Code=0.01) 1070 Uri-Host: "host" 1071 Uri-Path: ".well-known" 1072 Uri-Path: "dots" 1073 Uri-Path: "version" 1074 Uri-Path: "mitigate" 1075 Uri-Query: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example" 1076 Uri-Query: "mitigation-id=12332" 1077 Observe : 0 1079 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request 1081 Figure 13 shows a response example of all active mitigation requests 1082 associated with the DOTS client on the DOTS server and the mitigation 1083 status of each mitigation request. 1085 { 1086 "ietf-dots-signal:mitigation-scope": { 1087 "scope": [ 1088 { 1089 "mitigation-id": 12332, 1090 "mitigation-start": 1507818434.00, 1091 "target-prefix": [ 1092 "2001:db8:6401::1/128", 1093 "2001:db8:6401::2/128" 1094 ], 1095 "target-protocol": [ 1096 17 1097 ], 1098 "lifetime": 1800, 1099 "status": 2, 1100 "bytes-dropped": 134334555, 1101 "bps-dropped": 43344, 1102 "pkts-dropped": 333334444, 1103 "pps-dropped": 432432 1104 }, 1105 { 1106 "mitigation-id": 12333, 1107 "mitigation-start": 1507818393.00, 1108 "target-prefix": [ 1109 "2001:db8:6401::1/128", 1110 "2001:db8:6401::2/128" 1111 ], 1112 "target-protocol": [ 1113 6 1114 ], 1115 "lifetime": 1800, 1116 "status": 3, 1117 "bytes-dropped": 0, 1118 "bps-dropped": 0, 1119 "pkts-dropped": 0, 1120 "pps-dropped": 0 1121 } 1122 ] 1123 } 1124 } 1126 Figure 13: Response Body to a Get Request 1128 The mitigation status parameters are described below: 1130 mitigation-start: Mitigation start time is expressed in seconds 1131 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 1133 [RFC7049]). The encoding is modified so that the leading tag 1 1134 (epoch-based date/time) MUST be omitted. 1136 This is a mandatory attribute. 1138 lifetime: The remaining lifetime of the mitigation request, in 1139 seconds. 1141 This is a mandatory attribute. 1143 status: Status of attack mitigation. The various possible values of 1144 'status' parameter are explained in Table 2. 1146 This is a mandatory attribute. 1148 bytes-dropped: The total dropped byte count for the mitigation 1149 request since the attack mitigation is triggered. The count wraps 1150 around when it reaches the maximum value of unsigned integer. 1152 This is an optional attribute. 1154 bps-dropped: The average number of dropped bytes per second for the 1155 mitigation request since the attack mitigation is triggered. This 1156 SHOULD be a five-minute average. 1158 This is an optional attribute. 1160 pkts-dropped: The total number of dropped packet count for the 1161 mitigation request since the attack mitigation is triggered. 1163 This is an optional attribute. 1165 pps-dropped: The average number of dropped packets per second for 1166 the mitigation request since the attack mitigation is triggered. 1167 This SHOULD be a five-minute average. 1169 This is an optional attribute. 1171 +-----------+-------------------------------------------------------+ 1172 | Parameter | Description | 1173 | value | | 1174 +-----------+-------------------------------------------------------+ 1175 | 1 | Attack mitigation is in progress (e.g., changing the | 1176 | | network path to re-route the inbound traffic to DOTS | 1177 | | mitigator). | 1178 +-----------+-------------------------------------------------------+ 1179 | 2 | Attack is successfully mitigated (e.g., traffic is | 1180 | | redirected to a DDoS mitigator and attack traffic is | 1181 | | dropped). | 1182 +-----------+-------------------------------------------------------+ 1183 | 3 | Attack has stopped and the DOTS client can withdraw | 1184 | | the mitigation request. | 1185 +-----------+-------------------------------------------------------+ 1186 | 4 | Attack has exceeded the mitigation provider | 1187 | | capability. | 1188 +-----------+-------------------------------------------------------+ 1189 | 5 | DOTS client has withdrawn the mitigation request and | 1190 | | the mitigation is active but terminating. | 1191 +-----------+-------------------------------------------------------+ 1192 | 6 | Attack mitigation is now terminated. | 1193 +-----------+-------------------------------------------------------+ 1194 | 7 | Attack mitigation is withdrawn. | 1195 +-----------+-------------------------------------------------------+ 1196 | 8 | Attack mitigation is rejected. | 1197 +-----------+-------------------------------------------------------+ 1199 Table 2: Values of 'status' Parameter 1201 The observe option defined in [RFC7641] extends the CoAP core 1202 protocol with a mechanism for a CoAP client to "observe" a resource 1203 on a CoAP server: The client retrieves a representation of the 1204 resource and requests this representation be updated by the server as 1205 long as the client is interested in the resource. A DOTS client 1206 conveys the observe option set to '0' in the GET request to receive 1207 unsolicited notifications of attack mitigation status from the DOTS 1208 server. 1210 Unidirectional notifications within the bidirectional signal channel 1211 allows unsolicited message delivery, enabling asynchronous 1212 notifications between the agents. Due to the higher likelihood of 1213 packet loss during a DDoS attack, the DOTS server periodically sends 1214 attack mitigation status to the DOTS client and also notifies the 1215 DOTS client whenever the status of the attack mitigation changes. If 1216 the DOTS server cannot maintain a RTT estimate, it SHOULD NOT send 1217 more than one unsolicited notification every 3 seconds, and SHOULD 1218 use an even less aggressive rate whenever possible (case 2 in 1219 Section 3.1.3 of [RFC8085]). The DOTS server MUST use the same CUID 1220 as the one used by the DOTS client to observe a mitigation request. 1222 When conflicting requests are detected, the DOTS server enforces the 1223 corresponding policy (e.g., accept all requests, reject all requests, 1224 accept only one request but reject all the others, ...). It is 1225 assumed that this policy is supplied by the DOTS server administrator 1226 or it is a default behavior of the DOTS server implementation. Then, 1227 the DOTS server sends notification message(s) to the DOTS client(s) 1228 at the origin of the conflict. A conflict notification message 1229 includes information about the conflict cause, scope, and the status 1230 of the mitigation request(s). For example, 1232 o A notification message with status code set to '8 (Attack 1233 mitigation is rejected)' and 'conflict-status' set to '1' is sent 1234 to a DOTS client to indicate that this mitigation request is 1235 rejected because a conflict is detected. 1237 o A notification message with status code set to '7 (Attack 1238 mitigation is withdrawn)' and 'conflict-status' set to '1' is sent 1239 to a DOTS client to indicate that an active mitigation request is 1240 deactivated because a conflict is detected. 1242 o A notification message with status code set to '1 (Attack 1243 mitigation is in progress)' and 'conflict-status' set to '2' is 1244 sent to a DOTS client to indicate that this mitigation request is 1245 in progress, but a conflict is detected. 1247 Upon receipt of a conflict notification message indicating that a 1248 mitigation request is deactivated because of a conflict, a DOTS 1249 client MUST NOT resend the same mitigation request before the expiry 1250 of 'retry-timer'. It is also recommended that DOTS clients support 1251 means to alert administrators about mitigation conflicts. 1253 A DOTS client that is no longer interested in receiving notifications 1254 from the DOTS server can simply "forget" the observation. When the 1255 DOTS server sends the next notification, the DOTS client will not 1256 recognize the token in the message and thus will return a Reset 1257 message. This causes the DOTS server to remove the associated entry. 1258 Alternatively, the DOTS client can explicitly deregister itself by 1259 issuing a GET request that has the Token field set to the token of 1260 the observation to be cancelled and includes an Observe Option with 1261 the value set to '1' (deregister). 1263 Figure 14 shows an example of a DOTS client requesting a DOTS server 1264 to send notifications related to a given mitigation request. 1266 +-----------+ +-----------+ 1267 |DOTS client| |DOTS server| 1268 +-----------+ +-----------+ 1269 | | 1270 | GET / | 1271 | Token: 0x4a | Registration 1272 | Observe: 0 | 1273 +------------------------------>| 1274 | | 1275 | 2.05 Content | 1276 | Token: 0x4a | Notification of 1277 | Observe: 12 | the current state 1278 | status: "mitigation | 1279 | in progress" | 1280 |<------------------------------+ 1281 | 2.05 Content | 1282 | Token: 0x4a | Notification upon 1283 | Observe: 44 | a state change 1284 | status: "mitigation | 1285 | complete" | 1286 |<------------------------------+ 1287 | 2.05 Content | 1288 | Token: 0x4a | Notification upon 1289 | Observe: 60 | a state change 1290 | status: "attack stopped" | 1291 |<------------------------------+ 1292 | | 1294 Figure 14: Notifications of Attack Mitigation Status 1296 4.4.2.1. Mitigation Status 1298 The DOTS client can send the GET request at frequent intervals 1299 without the Observe option to retrieve the configuration data of the 1300 mitigation request and non-configuration data (i.e., the attack 1301 status). The frequency of polling the DOTS server to get the 1302 mitigation status should follow the transmission guidelines given in 1303 Section 3.1.3 of [RFC8085]. If the DOTS server has been able to 1304 mitigate the attack and the attack has stopped, the DOTS server 1305 indicates as such in the status, and the DOTS client recalls the 1306 mitigation request by issuing a DELETE request for the 'mitigation- 1307 id'. 1309 A DOTS client SHOULD react to the status of the attack as per the 1310 information sent by the DOTS server rather than acknowledging by 1311 itself, using its own means, that the attack has been mitigated. 1312 This ensures that the DOTS client does not recall a mitigation 1313 request prematurely because it is possible that the DOTS client does 1314 not sense the DDoS attack on its resources but the DOTS server could 1315 be actively mitigating the attack and the attack is not completely 1316 averted. 1318 4.4.3. Efficacy Update from DOTS Clients 1320 While DDoS mitigation is active, due to the likelihood of packet 1321 loss, a DOTS client MAY periodically transmit DOTS mitigation 1322 efficacy updates to the relevant DOTS server. A PUT request is used 1323 to convey the mitigation efficacy update to the DOTS server. 1325 The PUT request MUST include all the parameters used in the PUT 1326 request to carry the DOTS mitigation request (Section 4.4.1) 1327 unchanged apart from the lifetime parameter value. If this is not 1328 the case, the DOTS server MUST reject the request with a 4.00 (Bad 1329 Request). 1331 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1332 value is used to make the PUT request conditional on the current 1333 existence of the mitigation request. If UDP is used as transport, 1334 CoAP requests may arrive out-of-order. For example, the DOTS client 1335 may send a PUT request to convey an efficacy update to the DOTS 1336 server followed by a DELETE request to withdraw the mitigation 1337 request, but the DELETE request arrives at the DOTS server before the 1338 PUT request. To handle out-of-order delivery of requests, if an If- 1339 Match option is present in the PUT request and the 'mitigation-id' in 1340 the request matches a mitigation request from that DOTS client, then 1341 the request is processed. If no match is found, the PUT request is 1342 silently ignored. 1344 An example of an efficacy update message, which includes an If-Match 1345 option with an empty value, is depicted in Figure 15. 1347 Header: PUT (Code=0.03) 1348 Uri-Host: "host" 1349 Uri-Path: ".well-known" 1350 Uri-Path: "dots" 1351 Uri-Path: "version" 1352 Uri-Path: "mitigate" 1353 Uri-Path: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example" 1354 Uri-Path: "mitigation-id=123" 1355 Content-Format: "application/cbor" 1356 If-Match: 1357 { 1358 "ietf-dots-signal:mitigation-scope": { 1359 "scope": [ 1360 { 1361 "target-prefix": [ 1362 "string" 1363 ], 1364 "target-port-range": [ 1365 { 1366 "lower-port": integer, 1367 "upper-port": integer 1368 } 1369 ], 1370 "target-protocol": [ 1371 integer 1372 ], 1373 "target-fqdn": [ 1374 "string" 1375 ], 1376 "target-uri": [ 1377 "string" 1378 ], 1379 "alias-name": [ 1380 "string" 1381 ], 1382 "lifetime": integer, 1383 "attack-status": integer 1384 } 1385 ] 1386 } 1387 } 1389 Figure 15: Efficacy Update 1391 The 'attack-status' parameter is a mandatory attribute when 1392 performing an efficacy update. The various possible values contained 1393 in the 'attack-status' parameter are described in Table 3. 1395 +-----------+-------------------------------------------------------+ 1396 | Parameter | Description | 1397 | value | | 1398 +-----------+-------------------------------------------------------+ 1399 | 1 | The DOTS client determines that it is still under | 1400 | | attack. | 1401 +-----------+-------------------------------------------------------+ 1402 | 2 | The DOTS client determines that the attack is | 1403 | | successfully mitigated (e.g., attack traffic is not | 1404 | | seen). | 1405 +-----------+-------------------------------------------------------+ 1407 Table 3: Values of 'attack-status' Parameter 1409 The DOTS server indicates the result of processing a PUT request 1410 using CoAP response codes. The response code 2.04 (Changed) is 1411 returned if the DOTS server has accepted the mitigation efficacy 1412 update. The error response code 5.03 (Service Unavailable) is 1413 returned if the DOTS server has erred or is incapable of performing 1414 the mitigation. 1416 4.4.4. Withdraw a Mitigation 1418 A DELETE request is used to withdraw a DOTS mitigation request from a 1419 DOTS server (Figure 16). 1421 The same considerations for manipulating 'client-domain-hash' 1422 parameter by DOTS gateways, as specified in Section 4.4.1, MUST be 1423 followed for DELETE requests. 1425 Header: DELETE (Code=0.04) 1426 Uri-Host: "host" 1427 Uri-Path: ".well-known" 1428 Uri-Path: "dots" 1429 Uri-Path: "version" 1430 Uri-Path: "mitigate" 1431 Uri-Query: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example" 1432 Uri-Query: "mitigation-id=123" 1434 Figure 16: Withdraw a DOTS Mitigation 1436 If the request does not include a 'mitigation-id' parameter, the DOTS 1437 server MUST reply with a 4.00 (Bad Request). 1439 Once the request is validated, the DOTS server immediately 1440 acknowledges a DOTS client's request to withdraw the DOTS signal 1441 using 2.02 (Deleted) response code with no response payload. A 2.02 1442 (Deleted) Response Code is returned even if the 'mitigation-id' 1443 parameter value conveyed in the DELETE request does not exist in its 1444 configuration data before the request. 1446 If the DOTS server finds the 'mitigation-id' parameter value conveyed 1447 in the DELETE request in its configuration data for the DOTS client, 1448 then to protect against route or DNS flapping caused by a DOTS client 1449 rapidly removing a mitigation, and to dampen the effect of 1450 oscillating attacks, the DOTS server MAY allow mitigation to continue 1451 for a limited period after acknowledging a DOTS client's withdrawal 1452 of a mitigation request. During this period, the DOTS server status 1453 messages SHOULD indicate that mitigation is active but terminating 1454 (Section 4.4.2). 1456 The initial active-but-terminating period SHOULD be sufficiently long 1457 to absorb latency incurred by route propagation. The active-but- 1458 terminating period SHOULD be set by default to 120 seconds. If the 1459 client requests mitigation again before the initial active-but- 1460 terminating period elapses, the DOTS server MAY exponentially 1461 increase the active-but- terminating period up to a maximum of 300 1462 seconds (5 minutes). 1464 After the active-but-terminating period elapses, the DOTS server MUST 1465 treat the mitigation as terminated, as the DOTS client is no longer 1466 responsible for the mitigation. For example, if there is a financial 1467 relationship between the DOTS client and server domains, the DOTS 1468 client stops incurring cost at this point. 1470 4.5. DOTS Signal Channel Session Configuration 1472 A DOTS client can negotiate, configure, and retrieve the DOTS signal 1473 channel session behavior. The DOTS signal channel can be used, for 1474 example, to configure the following: 1476 a. Heartbeat interval (heartbeat-interval): DOTS agents regularly 1477 send heartbeats (CoAP Ping/Pong) to each other after mutual 1478 authentication is successfully completed in order to keep the 1479 DOTS signal channel open. Heartbeat messages are exchanged 1480 between DOTS agents every 'heartbeat-interval' seconds to detect 1481 the current status of the DOTS signal channel session. 1483 b. Missing heartbeats allowed (missing-hb-allowed): This variable 1484 indicates the maximum number of consecutive heartbeat messages 1485 for which a DOTS agent did not receive a response before 1486 concluding that the session is disconnected or defunct. 1488 c. Acceptable signal loss ratio: Maximum retransmissions, 1489 retransmission timeout value, and other message transmission 1490 parameters for the DOTS signal channel. 1492 The same or distinct configuration sets may be used during times when 1493 a mitigation is active ('mitigating-config') and when no mitigation 1494 is active ('idle-config'). This is particularly useful for DOTS 1495 servers that might want to reduce heartbeat frequency or cease 1496 heartbeat exchanges when an active DOTS client has not requested 1497 mitigation. If distinct configurations are used, DOTS agents MUST 1498 follow the appropriate configuration set as a function of the 1499 mitigation activity (e.g., if no mitigation request is active, 'idle- 1500 config'-related values must be followed). Additionally, DOTS agents 1501 MUST automatically switch to the other configuration upon a change in 1502 the mitigation activity (e.g., if an attack mitigation is launched 1503 after a peacetime, the DOTS agent switches from 'idle-config' to 1504 'mitigating-config'-related values). 1506 Requests and responses are deemed reliable by marking them as 1507 Confirmable (CON) messages. DOTS signal channel session 1508 configuration requests and responses are marked as Confirmable 1509 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1510 message is retransmitted using a default timeout and exponential 1511 back-off between retransmissions, until the DOTS server sends an 1512 Acknowledgement message (ACK) with the same Message ID conveyed from 1513 the DOTS client. 1515 Message transmission parameters are defined in Section 4.8 of 1516 [RFC7252]. The DOTS server can either piggyback the response in the 1517 acknowledgement message or, if the DOTS server cannot respond 1518 immediately to a request carried in a Confirmable message, it simply 1519 responds with an Empty Acknowledgement message so that the DOTS 1520 client can stop retransmitting the request. Empty Acknowledgement 1521 message is explained in Section 2.2 of [RFC7252]. When the response 1522 is ready, the server sends it in a new Confirmable message which in 1523 turn needs to be acknowledged by the DOTS client (see Sections 5.2.1 1524 and 5.2.2 of [RFC7252]). Requests and responses exchanged between 1525 DOTS agents during peacetime are marked as Confirmable messages. 1527 Implementation Note: A DOTS client that receives a response in a 1528 CON message may want to clean up the message state right after 1529 sending the ACK. If that ACK is lost and the DOTS server 1530 retransmits the CON, the DOTS client may no longer have any state 1531 that would help it correlate this response, thereby unexpecting 1532 the retransmission message. The DOTS client will send a Reset 1533 message so it does not receive any more retransmissions. This 1534 behavior is normal and not an indication of an error (see 1535 Section 5.3.2 of [RFC7252] for more details). 1537 4.5.1. Discover Configuration Parameters 1539 A GET request is used to obtain acceptable (e.g., minimum and maximum 1540 values) and current configuration parameters on the DOTS server for 1541 DOTS signal channel session configuration. This procedure occurs 1542 between a DOTS client and its immediate peer DOTS server. As such, 1543 this GET request MUST NOT be relayed by an on-path DOTS gateway. 1545 Figure 17 shows how to obtain acceptable configuration parameters for 1546 the DOTS server. 1548 Header: GET (Code=0.01) 1549 Uri-Host: "host" 1550 Uri-Path: ".well-known" 1551 Uri-Path: "dots" 1552 Uri-Path: "version" 1553 Uri-Path: "config" 1555 Figure 17: GET to Retrieve Configuration 1557 The DOTS server in the 2.05 (Content) response conveys the current, 1558 minimum, and maximum attribute values acceptable by the DOTS server 1559 (Figure 18). 1561 Content-Format: "application/cbor" 1562 { 1563 "ietf-dots-signal:signal-config": { 1564 "mitigating-config": { 1565 "heartbeat-interval": { 1566 "current-value": integer, 1567 "min-value": integer, 1568 "max-value": integer 1569 }, 1570 "missing-hb-allowed": { 1571 "current-value": integer, 1572 "min-value": integer, 1573 "max-value": integer 1574 }, 1575 "max-retransmit": { 1576 "current-value": integer, 1577 "min-value": integer, 1578 "max-value": integer 1579 }, 1580 "ack-timeout": { 1581 "current-value": integer, 1582 "min-value": integer, 1583 "max-value": integer 1584 }, 1585 "ack-random-factor": { 1586 "current-value-decimal": number, 1587 "min-value-decimal": number, 1588 "max-value-decimal": number 1589 } 1590 }, 1591 "idle-config": { 1592 "heartbeat-interval": { 1593 "current-value": integer, 1594 "min-value": integer, 1595 "max-value": integer 1596 }, 1597 "missing-hb-allowed": { 1598 "current-value": integer, 1599 "min-value": integer, 1600 "max-value": integer 1601 }, 1602 "max-retransmit": { 1603 "current-value": integer, 1604 "min-value": integer, 1605 "max-value": integer 1606 }, 1607 "ack-timeout": { 1608 "current-value": integer, 1609 "min-value": integer, 1610 "max-value": integer 1611 }, 1612 "ack-random-factor": { 1613 "current-value-decimal": number, 1614 "min-value-decimal": number, 1615 "max-value-decimal": number 1616 } 1617 }, 1618 "trigger-mitigation": { 1619 "current-value": boolean 1620 } 1621 } 1622 } 1624 Figure 18: GET Configuration Response Body 1626 Figure 19 shows an example of acceptable and current configuration 1627 parameters on a DOTS server for DOTS signal channel session 1628 configuration. The same acceptable configuration is used during 1629 attack and peace times. 1631 Content-Format: "application/cbor" 1632 { 1633 "ietf-dots-signal:signal-config": { 1634 "mitigating-config": { 1635 "heartbeat-interval": { 1636 "current-value": 30, 1637 "min-value": 15, 1638 "max-value": 240 1639 }, 1640 "missing-hb-allowed": { 1641 "current-value": 5, 1642 "min-value": 3, 1643 "max-value": 9 1644 }, 1645 "max-retransmit": { 1646 "current-value": 3, 1647 "min-value": 2, 1648 "max-value": 15 1649 }, 1650 "ack-timeout": { 1651 "current-value": 2, 1652 "min-value": 1, 1653 "max-value": 30 1654 }, 1655 "ack-random-factor": { 1656 "current-value-decimal": 1.5, 1657 "min-value-decimal": 1.1, 1658 "max-value-decimal": 4.0 1659 } 1660 }, 1661 "idle-config": { 1662 "heartbeat-interval": { 1663 "current-value": 30, 1664 "min-value": 15, 1665 "max-value": 240 1666 }, 1667 "missing-hb-allowed": { 1668 "current-value": 5, 1669 "min-value": 3, 1670 "max-value": 9 1671 }, 1672 "max-retransmit": { 1673 "current-value": 3, 1674 "min-value": 2, 1675 "max-value": 15 1676 }, 1677 "ack-timeout": { 1678 "current-value": 2, 1679 "min-value": 1, 1680 "max-value": 30 1682 }, 1683 "ack-random-factor": { 1684 "current-value-decimal": 1.5, 1685 "min-value-decimal": 1.1, 1686 "max-value-decimal": 4.0 1687 } 1688 }, 1689 "trigger-mitigation": { 1690 "current-value": true 1691 } 1692 } 1693 } 1695 Figure 19: Example of a Configuration Response Body 1697 4.5.2. Convey DOTS Signal Channel Session Configuration 1699 A PUT request is used to convey the configuration parameters for the 1700 signal channel (e.g., heartbeat interval, maximum retransmissions). 1701 Message transmission parameters for CoAP are defined in Section 4.8 1702 of [RFC7252]. The RECOMMENDED values of transmission parameter 1703 values are ack-timeout (2 seconds), max-retransmit (3), ack-random- 1704 factor (1.5). In addition to those parameters, the RECOMMENDED 1705 specific DOTS transmission parameter values are 'heartbeat-interval' 1706 (30 seconds) and 'missing-hb-allowed' (5). 1708 Note: heartbeat-interval should be tweaked to also assist DOTS 1709 messages for NAT traversal (SIG-010 of 1710 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 1711 messages must not be sent more frequently than once every 15 1712 seconds and should use longer intervals when possible. 1713 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 1714 minutes or longer, but experience shows that sending packets every 1715 15 to 30 seconds is necessary to prevent the majority of 1716 middleboxes from losing state for UDP flows. From that 1717 standpoint, this specification recommends a minimum heartbeat- 1718 interval of 15 seconds and a maximum heartbeat-interval of 240 1719 seconds. The recommended value of 30 seconds is selected to 1720 anticipate the expiry of NAT state. 1722 A heartbeat-interval of 30 seconds may be seen as too chatty in 1723 some deployments. For such deployments, DOTS agents may negotiate 1724 longer heartbeat-interval values to prevent any network overload 1725 with too frequent keepalives. 1727 Different heartbeat intervals can be defined for 'mitigation- 1728 config' and 'idle-config' to reduce being too chatty during idle 1729 times. If there is an on-path translator between the DOTS client 1730 (standalone or part of a DOTS gateway) and the DOTS server, the 1731 'mitigation-config' heartbeat-interval has to be smaller than the 1732 translator session timeout. It is recommended that the 'idle- 1733 config' heartbeat-interval is also smaller than the translator 1734 session timeout to prevent translator transversal issues, or set 1735 to '0'. Means to discover the lifetime assigned by a translator 1736 are out of scope. 1738 When a confirmable "CoAP Ping" is sent, and if there is no response, 1739 the "CoAP Ping" is retransmitted max-retransmit number of times by 1740 the CoAP layer using an initial timeout set to a random duration 1741 between ack-timeout and (ack-timeout*ack-random-factor) and 1742 exponential back-off between retransmissions. By choosing the 1743 recommended transmission parameters, the "CoAP Ping" will timeout 1744 after 45 seconds. If the DOTS agent does not receive any response 1745 from the peer DOTS agent for 'missing-hb-allowed' number of 1746 consecutive "CoAP Ping" confirmable messages, it concludes that the 1747 DOTS signal channel session is disconnected. A DOTS client MUST NOT 1748 transmit a "CoAP Ping" while waiting for the previous "CoAP Ping" 1749 response from the same DOTS server. 1751 If the DOTS agent wishes to change the default values of message 1752 transmission parameters, then it should follow the guidance given in 1753 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 1754 values for message transmission parameters and default values for 1755 non-negotiated message transmission parameters. 1757 The signal channel session configuration is applicable to a single 1758 DOTS signal channel session between the DOTS agents. 1760 Header: PUT (Code=0.03) 1761 Uri-Host: "host" 1762 Uri-Path: ".well-known" 1763 Uri-Path: "dots" 1764 Uri-Path: "version" 1765 Uri-Path: "config" 1766 Uri-Path: "session-id=123" 1767 Content-Format: "application/cbor" 1768 { 1769 "ietf-dots-signal:signal-config": { 1770 "mitigating-config": { 1771 "heartbeat-interval": { 1772 "current-value": integer 1773 }, 1774 "missing-hb-allowed": { 1775 "current-value": integer 1776 }, 1777 "max-retransmit": { 1778 "current-value": integer 1779 }, 1780 "ack-timeout": { 1781 "current-value": integer 1782 }, 1783 "ack-random-factor": { 1784 "current-value-decimal": number 1785 } 1786 }, 1787 "idle-config": { 1788 "heartbeat-interval": { 1789 "current-value": integer 1790 }, 1791 "missing-hb-allowed": { 1792 "current-value": integer 1793 }, 1794 "max-retransmit": { 1795 "current-value": integer 1796 }, 1797 "ack-timeout": { 1798 "current-value": integer 1799 }, 1800 "ack-random-factor": { 1801 "current-value-decimal": number 1802 } 1803 }, 1804 "trigger-mitigation": boolean, 1805 "config-interval": integer 1806 } 1807 } 1809 Figure 20: PUT to Convey the DOTS Signal Channel Session 1810 Configuration Data 1812 The parameters in Figure 20 are described below: 1814 session-id: Identifier for the DOTS signal channel session 1815 configuration data represented as an integer. This identifier 1816 MUST be generated by the DOTS client. This document does not make 1817 any assumption about how this identifier is generated. 1819 This is a mandatory attribute. 1821 mitigation-config: Set of configuration parameters to use when a 1822 mitigation is active. The following parameters may be included: 1824 heartbeat-interval: Time interval in seconds between two 1825 consecutive heartbeat messages. 1827 '0' is used to disable the heartbeat mechanism. 1829 This is an optional attribute. 1831 missing-hb-allowed: Maximum number of consecutive heartbeat 1832 messages for which the DOTS agent did not receive a response 1833 before concluding that the session is disconnected. 1835 This is an optional attribute. 1837 max-retransmit: Maximum number of retransmissions for a message 1838 (referred to as MAX_RETRANSMIT parameter in CoAP). 1840 This is an optional attribute. 1842 ack-timeout: Timeout value in seconds used to calculate the 1843 initial retransmission timeout value (referred to as 1844 ACK_TIMEOUT parameter in CoAP). 1846 This is an optional attribute. 1848 ack-random-factor: Random factor used to influence the timing of 1849 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1850 CoAP). 1852 This is an optional attribute. 1854 idle-config: Set of configuration parameters to use when no 1855 mitigation is active. This attribute has the same structure as 1856 'mitigating-config'. 1858 trigger-mitigation: If the parameter value is set to 'false', then 1859 DDoS mitigation is triggered only when the DOTS signal channel 1860 session is lost. Automated mitigation on loss of signal is 1861 discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. 1863 If the DOTS client ceases to respond to heartbeat messages, the 1864 DOTS server can detect that the DOTS session is lost. 1866 The default value of the parameter is 'true'. 1868 This is an optional attribute. 1870 config-interval: This parameter is returned to indicate the time 1871 interval expressed in seconds, which a DOTS agent must wait for 1872 before re-contacting its peer in order to retrieve the signal 1873 channel configuration data. 1875 '0' is used to disable this refresh mechanism. 1877 If a non-zero value of 'config-interval' is received by a DOTS 1878 client, it has to issue a PUT request to refresh the configuration 1879 parameters for the signal channel before the expiry of 'config- 1880 interval'. When a DDoS attack is active, refresh requests MUST 1881 NOT be sent by DOTS clients and the DOTS server MUST NOT terminate 1882 the (D)TLS session after the expiry of 'config-interval'. 1884 This mechanism allows to update the configuration data if a change 1885 occurs at the DOTS server side. For example, the new 1886 configuration may instruct a DOTS client to cease heartbeats or 1887 reduce heartbeat frequency. 1889 If this parameter is not returned, this is equivalent to receiving 1890 a 'config-interval' value set to '0'. 1892 If a DOTS server detects that a misbehaving DOTS client does not 1893 contact the DOTS server after the expiry of 'config-interval', in 1894 order to retrieve the signal channel configuration data, it MAY 1895 terminate the (D)TLS session. A (D)TLS session is terminated by 1896 the receipt of an authenticated message that closes the connection 1897 (e.g., a fatal alert (Section 7.2 of [RFC5246])). 1899 This is an optional attribute. 1901 At least one of the attributes 'heartbeat-interval', 'missing-hb- 1902 allowed', 'max-retransmit', 'ack-timeout', 'ack-random-factor', and 1903 'trigger-mitigation' MUST be present in the PUT request. The PUT 1904 request with a higher numeric 'session-id' value overrides the DOTS 1905 signal channel session configuration data installed by a PUT request 1906 with a lower numeric 'session-id' value. 1908 Figure 21 shows a PUT request example to convey the configuration 1909 parameters for the DOTS signal channel. In this example, heartbeat 1910 mechanism is disabled when no mitigation is active, while the 1911 heartbeat interval is set to '91' when a mitigation is active. 1913 Header: PUT (Code=0.03) 1914 Uri-Host: "www.example.com" 1915 Uri-Path: ".well-known" 1916 Uri-Path: "dots" 1917 Uri-Path: "v1" 1918 Uri-Path: "config" 1919 Uri-Path: "session-id=123" 1920 Content-Format: "application/cbor" 1921 { 1922 "ietf-dots-signal:signal-config": { 1923 "mitigating-config": { 1924 "heartbeat-interval": { 1925 "current-value": 91 1926 }, 1927 "missing-hb-allowed": { 1928 "current-value": 3 1929 }, 1930 "max-retransmit": { 1931 "current-value": 7 1932 }, 1933 "ack-timeout": { 1934 "current-value": 5 1935 }, 1936 "ack-random-factor": { 1937 "current-value-decimal": 1.5 1938 } 1939 }, 1940 "idle-config": { 1941 "heartbeat-interval": { 1942 "current-value": 0 1943 }, 1944 "max-retransmit": { 1945 "current-value": 7 1946 }, 1947 "ack-timeout": { 1948 "current-value": 5 1949 }, 1950 "ack-random-factor": { 1951 "current-value-decimal": 1.5 1952 } 1953 }, 1954 "trigger-mitigation": false 1955 } 1956 } 1958 Figure 21: PUT to Convey the Configuration Parameters 1960 The DOTS server indicates the result of processing the PUT request 1961 using CoAP response codes: 1963 o If the DOTS server finds the 'session-id' parameter value conveyed 1964 in the PUT request in its configuration data and if the DOTS 1965 server has accepted the updated configuration parameters, then 1966 2.04 (Changed) code is returned in the response. 1968 o If the DOTS server does not find the 'session-id' parameter value 1969 conveyed in the PUT request in its configuration data and if the 1970 DOTS server has accepted the configuration parameters, then a 1971 response code 2.01 (Created) is returned in the response. 1973 o If the request is missing one or more mandatory attributes or it 1974 contains one or more invalid or unknown parameters, 4.00 (Bad 1975 Request) is returned in the response. 1977 o Response code 4.22 (Unprocessable Entity) is returned in the 1978 response, if any of the 'heartbeat-interval', 'missing-hb- 1979 allowed', 'max-retransmit', 'target-protocol', 'ack-timeout', and 1980 'ack-random-factor' attribute values are not acceptable to the 1981 DOTS server. Upon receipt of the 4.22 error response code, the 1982 DOTS client should request the maximum and minimum attribute 1983 values acceptable to the DOTS server (Section 4.5.1). 1985 The DOTS client may re-try and send the PUT request with updated 1986 attribute values acceptable to the DOTS server. 1988 4.5.3. Delete DOTS Signal Channel Session Configuration 1990 A DELETE request is used to delete the installed DOTS signal channel 1991 session configuration data (Figure 22). 1993 Header: DELETE (Code=0.04) 1994 Uri-Host: "host" 1995 Uri-Path: ".well-known" 1996 Uri-Path: "dots" 1997 Uri-Path: "version" 1998 Uri-Path: "config" 1999 Uri-Query: "session-id=123" 2001 Figure 22: DELETE Configuration 2003 The DOTS server resets the DOTS signal channel session configuration 2004 back to the default values and acknowledges a DOTS client's request 2005 to remove the DOTS signal channel session configuration using 2.02 2006 (Deleted) response code. 2008 4.6. Redirected Signaling 2010 Redirected DOTS signaling is discussed in detail in Section 3.2.2 of 2011 [I-D.ietf-dots-architecture]. 2013 If a DOTS server wants to redirect a DOTS client to an alternative 2014 DOTS server for a signal session, then the response code 3.00 2015 (alternate server) will be returned in the response to the DOTS 2016 client. 2018 The DOTS server can return the error response code 3.00 in response 2019 to a PUT request from the DOTS client or convey the error response 2020 code 3.00 in a unidirectional notification response from the DOTS 2021 server. 2023 The DOTS server in the error response conveys the alternate DOTS 2024 server's FQDN, and the alternate DOTS server's IP address(es) and 2025 time to live values in the CBOR body (Figure 23). 2027 { 2028 "ietf-dots-signal:redirected-signal": { 2029 "alt-server": "string", 2030 "alt-server-record": [ 2031 { 2032 "addr": "string", 2033 "ttl" : integer 2034 } 2035 ] 2036 } 2037 } 2039 Figure 23: Redirected Server Error Response Body 2041 The parameters are described below: 2043 alt-server: FQDN of an alternate DOTS server. 2045 addr: IP address of an alternate DOTS server. 2047 ttl: Time to live (TTL) represented as an integer number of seconds. 2049 Figure 24 shows a 3.00 response example to convey the DOTS alternate 2050 server 'alt-server.example', its IP addresses 2001:db8:6401::1 and 2051 2001:db8:6401::2, and TTL values 3600 and 1800. 2053 { 2054 "ietf-dots-signal:redirected-signal": { 2055 "alt-server": "alt-server.example", 2056 "alt-server-record": [ 2057 { 2058 "ttl" : 3600, 2059 "addr": "2001:db8:6401::1" 2060 }, 2061 { 2062 "ttl" : 1800, 2063 "addr": "2001:db8:6401::2" 2064 } 2065 ] 2066 } 2067 } 2069 Figure 24: Example of Redirected Server Error Response Body 2071 When the DOTS client receives 3.00 response, it considers the current 2072 request as failed, but SHOULD try re-sending the request to the 2073 alternate DOTS server. During a DDoS attack, the DNS server may be 2074 the target of another DDoS attack, alternate DOTS server's IP 2075 addresses conveyed in the 3.00 response help the DOTS client skip DNS 2076 lookup of the alternate DOTS server. The DOTS client can then try to 2077 establish a UDP or a TCP session with the alternate DOTS server. The 2078 DOTS client SHOULD implement a DNS64 function to handle the scenario 2079 where an IPv6-only DOTS client communicates with an IPv4-only 2080 alternate DOTS server. 2082 4.7. Heartbeat Mechanism 2084 To provide an indication of signal health and distinguish an 'idle' 2085 signal channel from a 'disconnected' or 'defunct' session, the DOTS 2086 agent sends a heartbeat over the signal channel to maintain its half 2087 of the channel. The DOTS agent similarly expects a heartbeat from 2088 its peer DOTS agent, and may consider a session terminated in the 2089 prolonged absence of a peer agent heartbeat. 2091 While the communication between the DOTS agents is quiescent, the 2092 DOTS client will probe the DOTS server to ensure it has maintained 2093 cryptographic state and vice versa. Such probes can also keep 2094 firewalls and/or stateful translators bindings alive. This probing 2095 reduces the frequency of establishing a new handshake when a DOTS 2096 signal needs to be conveyed to the DOTS server. 2098 DOTS servers MAY trigger their heartbeat requests immediately after 2099 receiving heartbeat probes from peer DOTS clients. As a reminder, it 2100 is the responsibility of DOTS clients to ensure that on-path 2101 translators/firewalls are maintaining a binding so that the same 2102 external IP address and/or port number is retained for the DOTS 2103 session. 2105 In case of a massive DDoS attack that saturates the incoming link(s) 2106 to the DOTS client, all traffic from the DOTS server to the DOTS 2107 client will likely be dropped, although the DOTS server receives 2108 heartbeat requests in addition to DOTS messages sent by the DOTS 2109 client. In this scenario, the DOTS agents MUST behave differently to 2110 handle message transmission and DOTS session liveliness during link 2111 saturation: 2113 o The DOTS client MUST NOT consider the DOTS session terminated even 2114 after a maximum 'missing-hb-allowed' threshold is reached. The 2115 DOTS client SHOULD keep on using the current DOTS session to send 2116 heartbeat requests over it, so that the DOTS server knows the DOTS 2117 client has not disconnected the DOTS session. 2119 After the maximum 'missing-hb-allowed' threshold is reached, the 2120 DOTS client SHOULD try to resume the (D)TLS session. The DOTS 2121 client SHOULD send mitigation requests over the current DOTS 2122 session, and in parallel, for example, try to resume the (D)TLS 2123 session or use 0-RTT mode in DTLS 1.3 to piggyback the mitigation 2124 request in the ClientHello message. 2126 As soon as the link is no longer saturated, if traffic from the 2127 DOTS server reaches the DOTS client over the current DOTS session, 2128 the DOTS client can stop (D)TLS session resumption or if (D)TLS 2129 session resumption is successful then disconnect the current DOTS 2130 session. 2132 o If the DOTS server does not receive any traffic from the peer DOTS 2133 client, then the DOTS server sends heartbeat requests to the DOTS 2134 client and after maximum 'missing-hb-allowed' threshold is 2135 reached, the DOTS server concludes the session is disconnected. 2137 In DOTS over UDP, heartbeat messages MUST be exchanged between the 2138 DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of 2139 [RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable 2140 message and the peer DOTS agent will respond by sending a Reset 2141 message. 2143 In DOTS over TCP, heartbeat messages MUST be exchanged between the 2144 DOTS agents using the Ping and Pong messages specified in Section 4.4 2145 of [I-D.ietf-core-coap-tcp-tls]. That is, the DOTS agent sends a 2146 Ping message and the peer DOTS agent would respond by sending a 2147 single Pong message. 2149 5. DOTS Signal Channel YANG Module 2151 This document defines a YANG [RFC7950] module for mitigation scope 2152 and DOTS signal channel session configuration data. 2154 5.1. Tree Structure 2156 This document defines the YANG module "ietf-dots-signal" 2157 (Section 5.2), which has the following tree structure. A DOTS signal 2158 message can either be a mitigation or a configuration message. 2160 module: ietf-dots-signal 2161 +--rw dots-signal 2162 +--rw (message-type)? 2163 +--:(mitigation-scope) 2164 | +--rw client-domain-hash? string 2165 | +--rw scope* [cuid mitigation-id] 2166 | +--rw cuid string 2167 | +--rw mitigation-id int32 2168 | +--rw target-prefix* inet:ip-prefix 2169 | +--rw target-port-range* [lower-port upper-port] 2170 | | +--rw lower-port inet:port-number 2171 | | +--rw upper-port inet:port-number 2172 | +--rw target-protocol* uint8 2173 | +--rw target-fqdn* inet:domain-name 2174 | +--rw target-uri* inet:uri 2175 | +--rw alias-name* string 2176 | +--rw lifetime? int32 2177 | +--rw mitigation-start? int64 2178 | +--ro status? enumeration 2179 | +--ro conflict-information 2180 | | +--ro conflict-status? enumeration 2181 | | +--ro conflict-cause? enumeration 2182 | | +--ro retry-timer? int32 2183 | | +--ro conflict-scope 2184 | | +--ro target-prefix* inet:ip-prefix 2185 | | +--ro target-port-range* [lower-port upper-port] 2186 | | | +--ro lower-port inet:port-number 2187 | | | +--ro upper-port inet:port-number 2188 | | +--ro target-protocol* uint8 2189 | | +--ro target-fqdn* inet:domain-name 2190 | | +--ro target-uri* inet:uri 2191 | | +--ro alias-name* string 2192 | | +--ro acl-list* [acl-name acl-type] 2193 | | +--ro acl-name -> /ietf-acl:access-lists/acl/acl-name 2194 | | +--ro acl-type -> /ietf-acl:access-lists/acl/acl-type 2195 | +--ro pkts-dropped? yang:zero-based-counter64 2196 | +--ro bps-dropped? yang:zero-based-counter64 2197 | +--ro bytes-dropped? yang:zero-based-counter64 2198 | +--ro pps-dropped? yang:zero-based-counter64 2199 | +--rw attack-status? enumeration 2200 +--:(signal-config) 2201 | +--rw session-id int32 2202 | +--rw mitigating-config 2203 | | +--rw heartbeat-interval 2204 | | | +--rw max-value? int16 2205 | | | +--rw min-value? int16 2206 | | | +--rw current-value? int16 2207 | | +--rw missing-hb-allowed 2208 | | | +--rw max-value? int16 2209 | | | +--rw min-value? int16 2210 | | | +--rw current-value? int16 2211 | | +--rw max-retransmit 2212 | | | +--rw max-value? int16 2213 | | | +--rw min-value? int16 2214 | | | +--rw current-value? int16 2215 | | +--rw ack-timeout 2216 | | | +--rw max-value? int16 2217 | | | +--rw min-value? int16 2218 | | | +--rw current-value? int16 2219 | | +--rw ack-random-factor 2220 | | +--rw max-value-decimal? decimal64 2221 | | +--rw min-value-decimal? decimal64 2222 | | +--rw current-value-decimal? decimal64 2223 | +--rw idle-config 2224 | | +--rw heartbeat-interval 2225 | | | +--rw max-value? int16 2226 | | | +--rw min-value? int16 2227 | | | +--rw current-value? int16 2228 | | +--rw missing-hb-allowed 2229 | | | +--rw max-value? int16 2230 | | | +--rw min-value? int16 2231 | | | +--rw current-value? int16 2232 | | +--rw max-retransmit 2233 | | | +--rw max-value? int16 2234 | | | +--rw min-value? int16 2235 | | | +--rw current-value? int16 2236 | | +--rw ack-timeout 2237 | | | +--rw max-value? int16 2238 | | | +--rw min-value? int16 2239 | | | +--rw current-value? int16 2240 | | +--rw ack-random-factor 2241 | | +--rw max-value-decimal? decimal64 2242 | | +--rw min-value-decimal? decimal64 2243 | | +--rw current-value-decimal? decimal64 2244 | +--rw trigger-mitigation? boolean 2245 | +--rw config-interval? int32 2246 +--:(redirected-signal) 2247 +--rw alt-server string 2248 +--rw alt-server-record* [addr] 2249 +--rw addr inet:ip-address 2250 +--rw ttl? int32 2252 5.2. YANG Module 2254 file "ietf-dots-signal@2018-01-09.yang" 2256 module ietf-dots-signal { 2257 yang-version 1.1; 2258 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; 2259 prefix "signal"; 2261 import ietf-inet-types {prefix "inet";} 2262 import ietf-yang-types {prefix yang;} 2263 import ietf-access-control-list {prefix "ietf-acl";} 2265 organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 2267 contact 2268 "WG Web: 2269 WG List: 2271 Editor: Konda, Tirumaleswar Reddy 2272 2274 Editor: Mohamed Boucadair 2275 2277 Author: Prashanth Patil 2278 2280 Author: Andrew Mortensen 2281 2283 Author: Nik Teague 2284 "; 2286 description 2287 "This module contains YANG definition for the signaling 2288 messages exchanged between a DOTS client and a DOTS server. 2290 Copyright (c) 2017 IETF Trust and the persons identified as 2291 authors of the code. All rights reserved. 2293 Redistribution and use in source and binary forms, with or 2294 without modification, is permitted pursuant to, and subject 2295 to the license terms contained in, the Simplified BSD License 2296 set forth in Section 4.c of the IETF Trust's Legal Provisions 2297 Relating to IETF Documents 2298 (http://trustee.ietf.org/license-info). 2300 This version of this YANG module is part of RFC XXXX; see 2301 the RFC itself for full legal notices."; 2303 revision 2018-01-09 { 2304 description 2305 "Initial revision."; 2306 reference 2307 "RFC XXXX: Distributed Denial-of-Service Open Threat 2308 Signaling (DOTS) Signal Channel"; 2309 } 2311 grouping target { 2312 description 2313 "Specifies the targets of the mitigation request."; 2315 leaf-list target-prefix { 2316 type inet:ip-prefix; 2317 description 2318 "IPv4 or IPv6 prefix identifying the target."; 2319 } 2321 list target-port-range { 2322 key "lower-port upper-port"; 2324 description 2325 "Port range. When only lower-port is 2326 present, it represents a single port."; 2328 leaf lower-port { 2329 type inet:port-number; 2330 mandatory true; 2331 description 2332 "Lower port number of the port range."; 2333 } 2335 leaf upper-port { 2336 type inet:port-number; 2337 must ". >= ../lower-port" { 2338 error-message 2339 "The upper port number must be greater than 2340 or equal to lower port number."; 2342 } 2343 description 2344 "Upper port number of the port range."; 2345 } 2346 } 2348 leaf-list target-protocol { 2349 type uint8; 2350 description 2351 "Identifies the target protocol number. 2353 The value '0' means 'all protocols'. 2355 Values are taken from the IANA protocol registry: 2356 https://www.iana.org/assignments/protocol-numbers/ 2357 protocol-numbers.xhtml 2359 For example, 6 for TCP or 17 for UDP."; 2360 } 2362 leaf-list target-fqdn { 2363 type inet:domain-name; 2364 description "FQDN identifying the target."; 2365 } 2367 leaf-list target-uri { 2368 type inet:uri; 2369 description "URI identifying the target."; 2370 } 2372 leaf-list alias-name { 2373 type string; 2374 description 2375 "An alias name that points to a resoucre."; 2376 } 2377 } 2379 grouping mitigation-scope { 2380 description 2381 "Specifies the scope of the mitigation request."; 2383 leaf client-domain-hash { 2384 type string; 2385 description 2386 "The client domain hash may be conveyed by 2387 the server-domain DOTS gateway to propagate the 2388 client domain identification information from the 2389 gateway's client-side to the gateway's server-side, 2390 and from the gateway's server-side to the DOTS 2391 server. 2393 It may be used by the final DOTS server 2394 for policy enforcement purposes."; 2395 } 2397 list scope { 2398 key "cuid mitigation-id"; 2399 description 2400 "The scope of the request."; 2402 leaf cuid { 2403 type string; 2404 description 2405 "A unique identifier that is randomly 2406 generated by a DOTS client to prevent 2407 request collisions."; 2408 } 2410 leaf mitigation-id { 2411 type int32; 2412 description 2413 "Mitigation request identifier. 2415 This identifier must be unique for each mitigation 2416 request bound to the DOTS client."; 2417 } 2419 uses target; 2421 leaf lifetime { 2422 type int32; 2423 units "seconds"; 2424 default 3600; 2425 description 2426 "Indicates the lifetime of the mitigation request."; 2427 reference 2428 "RFC XXXX: Distributed Denial-of-Service Open Threat 2429 Signaling (DOTS) Signal Channel"; 2430 } 2432 leaf mitigation-start { 2433 type int64; 2434 units "seconds"; 2435 description 2436 "Mitigation start time is represented in seconds 2437 relative to 1970-01-01T00:00Z in UTC time."; 2439 } 2441 leaf status { 2442 type enumeration { 2443 enum "attack-mitigation-in-progress" { 2444 value 1; 2445 description 2446 "Attack mitigation is in progress (e.g., changing 2447 the network path to re-route the inbound traffic 2448 to DOTS mitigator)."; 2449 } 2451 enum "attack-successfully-mitigated" { 2452 value 2; 2453 description 2454 "Attack is successfully mitigated (e.g., traffic 2455 is redirected to a DDoS mitigator and attack 2456 traffic is dropped or blackholed)."; 2457 } 2459 enum "attack-stopped" { 2460 value 3; 2461 description 2462 "Attack has stopped and the DOTS client can 2463 withdraw the mitigation request."; 2464 } 2466 enum "attack-exceeded-capability" { 2467 value 4; 2468 description 2469 "Attack has exceeded the mitigation provider 2470 capability."; 2471 } 2473 enum "dots-client-withdrawn-mitigation" { 2474 value 5; 2475 description 2476 "DOTS client has withdrawn the mitigation 2477 request and the mitigation is active but 2478 terminating."; 2479 } 2481 enum "attack-mitigation-terminated" { 2482 value 6; 2483 description 2484 "Attack mitigation is now terminated."; 2485 } 2486 enum "attack-mitigation-withdrawn" { 2487 value 7; 2488 description 2489 "Attack mitigation is withdrawn."; 2490 } 2492 enum "attack-mitigation-rejected" { 2493 value 8; 2494 description 2495 "Attack mitigation is rejected."; 2496 } 2497 } 2498 config false; 2499 description 2500 "Indicates the status of a mitigation request. 2501 It must be included in responses only."; 2502 } 2504 container conflict-information { 2505 config false; 2506 description 2507 "Indicates that a conflict is detected. 2508 Must only be used for responses."; 2510 leaf conflict-status { 2511 type enumeration { 2512 enum "request-inactive-other-active" { 2513 value 1; 2514 description 2515 "DOTS Server has detected conflicting mitigation 2516 requests from different DOTS clients. 2517 This mitigation request is currently inactive 2518 until the conflicts are resolved. Another 2519 mitigation request is active."; 2520 } 2522 enum "request-active" { 2523 value 2; 2524 description 2525 "DOTS Server has detected conflicting mitigation 2526 requests from different DOTS clients. 2527 This mitigation request is currently active."; 2528 } 2530 enum "all-requests-inactive" { 2531 value 3; 2532 description 2533 "DOTS Server has detected conflicting mitigation 2534 requests from different DOTS clients. All 2535 conflicting mitigation requests are inactive."; 2536 } 2537 } 2538 description 2539 "Indicates the conflict status. 2540 It must be included in responses only."; 2541 } 2543 leaf conflict-cause { 2544 type enumeration { 2545 enum "overlapping-targets" { 2546 value 1; 2547 description 2548 "Overlapping targets. conflict-scope provides 2549 more details about the exact conflict."; 2550 } 2552 enum "conflict-with-whitelist" { 2553 value 2; 2554 description 2555 "Conflicts with an existing white list. 2557 This code is returned when the DDoS mitigation 2558 detects that some of the source addresses/prefixes 2559 listed in the white list ACLs are actually 2560 attacking the target."; 2561 } 2563 enum "cuid-collision" { 2564 value 3; 2565 description 2566 "Conflicts with the CUID used by another 2567 DOTS client of the same domain."; 2568 } 2569 } 2570 description 2571 "Indicates the cause of the conflict. 2572 It must be included in responses only."; 2573 } 2575 leaf retry-timer { 2576 type int32; 2577 units "seconds"; 2578 description 2579 "The DOTS client must not re-send the 2580 same request before the expiry of this timer. 2581 It must be included in responses, only."; 2583 } 2585 container conflict-scope { 2586 description 2587 "Provides more information about the conflict scope."; 2589 uses target { 2590 when "../conflict-cause = 'overlapping-targets'"; 2591 } 2593 list acl-list { 2594 when "../../conflict-cause = 'conflict-with-whitelist'"; 2595 key "acl-name acl-type"; 2596 description 2597 "List of conflicting ACLs"; 2599 leaf acl-name { 2600 type leafref { 2601 path "/ietf-acl:access-lists/ietf-acl:acl" + 2602 "/ietf-acl:acl-name"; 2603 } 2604 description 2605 "Reference to the conflicting ACL name bound to 2606 a DOTS client."; 2607 } 2609 leaf acl-type { 2610 type leafref { 2611 path "/ietf-acl:access-lists/ietf-acl:acl" + 2612 "/ietf-acl:acl-type"; 2613 } 2614 description 2615 "Reference to the conflicting ACL type bound to 2616 a DOTS client."; 2617 } 2618 } 2619 } 2620 } 2622 leaf pkts-dropped { 2623 type yang:zero-based-counter64; 2624 config false; 2625 description 2626 "Number of dropped packets."; 2627 } 2629 leaf bps-dropped { 2630 type yang:zero-based-counter64; 2631 config false; 2632 description 2633 "The average number of dropped bytes per second for 2634 the mitigation request since the attack 2635 mitigation is triggered."; 2636 } 2638 leaf bytes-dropped { 2639 type yang:zero-based-counter64; 2640 units 'bytes'; 2641 config false; 2642 description 2643 "Counter for dropped packets; in bytes."; 2644 } 2646 leaf pps-dropped { 2647 type yang:zero-based-counter64; 2648 config false; 2649 description 2650 "The average number of dropped packets per second 2651 for the mitigation request since the attack 2652 mitigation is triggered."; 2653 } 2655 leaf attack-status { 2656 type enumeration { 2657 enum "under-attack" { 2658 value 1; 2659 description 2660 "The DOTS client determines that it is still under 2661 attack."; 2662 } 2664 enum "attack-successfully-mitigated" { 2665 value 2; 2666 description 2667 "The DOTS client determines that the attack is 2668 successfully mitigated."; 2669 } 2670 } 2671 description 2672 "Indicates the status of an attack as seen by the 2673 DOTS client."; 2674 } 2675 } 2676 } 2678 grouping config-parameters { 2679 description 2680 "Subset of DOTS signal channel session configuration."; 2682 container heartbeat-interval { 2683 description 2684 "DOTS agents regularly send heartbeats to each other 2685 after mutual authentication is successfully 2686 completed in order to keep the DOTS signal channel 2687 open."; 2689 leaf max-value { 2690 type int16; 2691 units "seconds"; 2692 description 2693 "Maximum acceptable heartbeat-interval value."; 2694 reference 2695 "RFC XXXX: Distributed Denial-of-Service Open Threat 2696 Signaling (DOTS) Signal Channel"; 2697 } 2699 leaf min-value { 2700 type int16; 2701 units "seconds"; 2702 description 2703 "Minimum acceptable heartbeat-interval value."; 2704 reference 2705 "RFC XXXX: Distributed Denial-of-Service Open Threat 2706 Signaling (DOTS) Signal Channel"; 2707 } 2708 leaf current-value { 2709 type int16; 2710 units "seconds"; 2711 default 30; 2712 description 2713 "Current heartbeat-interval value. 2715 '0' means that heartbeat mechanism is deactivated."; 2716 reference 2717 "RFC XXXX: Distributed Denial-of-Service Open Threat 2718 Signaling (DOTS) Signal Channel"; 2719 } 2720 } 2722 container missing-hb-allowed { 2723 description 2724 "Maximum number of missing heartbeats allowed."; 2726 leaf max-value { 2727 type int16; 2728 description 2729 "Maximum acceptable value."; 2730 reference 2731 "RFC XXXX: Distributed Denial-of-Service Open Threat 2732 Signaling (DOTS) Signal Channel"; 2733 } 2735 leaf min-value { 2736 type int16; 2737 description 2738 "Minimum acceptable value."; 2739 reference 2740 "RFC XXXX: Distributed Denial-of-Service Open Threat 2741 Signaling (DOTS) Signal Channel"; 2742 } 2743 leaf current-value { 2744 type int16; 2745 default 5; 2746 description 2747 "Current value."; 2748 reference 2749 "RFC XXXX: Distributed Denial-of-Service Open Threat 2750 Signaling (DOTS) Signal Channel"; 2751 } 2752 } 2754 container max-retransmit { 2755 description 2756 "Maximum number of retransmissions of a Confirmable 2757 message."; 2759 leaf max-value { 2760 type int16; 2761 description 2762 "Maximum acceptable value."; 2763 reference 2764 "Section 4.8 of RFC 7552."; 2765 } 2767 leaf min-value { 2768 type int16; 2769 description 2770 "Minimum acceptable value."; 2771 reference 2772 "Section 4.8 of RFC 7552."; 2773 } 2774 leaf current-value { 2775 type int16; 2776 default 3; 2777 description 2778 "Current value."; 2779 reference 2780 "RFC XXXX: Distributed Denial-of-Service Open Threat 2781 Signaling (DOTS) Signal Channel"; 2782 } 2783 } 2785 container ack-timeout { 2786 description 2787 "Initial retransmission timeout value."; 2789 leaf max-value { 2790 type int16; 2791 units "seconds"; 2792 description 2793 "Maximum value."; 2794 reference 2795 "Section 4.8 of RFC 7552."; 2796 } 2798 leaf min-value { 2799 type int16; 2800 units "seconds"; 2801 description 2802 "Minimum value."; 2803 reference 2804 "Section 4.8 of RFC 7552."; 2805 } 2806 leaf current-value { 2807 type int16; 2808 units "seconds"; 2809 default 2; 2810 description 2811 "Current value."; 2812 reference 2813 "Section 4.8 of RFC 7552."; 2814 } 2815 } 2817 container ack-random-factor { 2818 description 2819 "Random factor used to influence the timing of 2820 retransmissions."; 2822 leaf max-value-decimal { 2823 type decimal64 { 2824 fraction-digits 2; 2825 } 2826 description 2827 "Maximum acceptable value."; 2828 reference 2829 "Section 4.8 of RFC 7552."; 2830 } 2832 leaf min-value-decimal { 2833 type decimal64 { 2834 fraction-digits 2; 2835 } 2836 description 2837 "Minimum acceptable value."; 2838 reference 2839 "Section 4.8 of RFC 7552."; 2840 } 2841 leaf current-value-decimal { 2842 type decimal64 { 2843 fraction-digits 2; 2844 } 2845 default 1.5; 2846 description 2847 "Current value."; 2848 reference 2849 "Section 4.8 of RFC 7552."; 2850 } 2851 } 2852 } 2854 grouping signal-config { 2855 description 2856 "DOTS signal channel session configuration."; 2858 leaf session-id { 2859 type int32; 2860 mandatory true; 2861 description 2862 "An identifier for the DOTS signal channel 2863 session configuration data."; 2864 } 2866 container mitigating-config { 2867 description 2868 "Configuration parameters to use when a mitigation is active."; 2869 uses config-parameters; 2870 } 2871 container idle-config { 2872 description 2873 "Configuration parameters to use when no mitigation is 2874 active."; 2875 uses config-parameters; 2876 } 2878 leaf trigger-mitigation { 2879 type boolean; 2880 default true; 2881 description 2882 "If false, then mitigation is triggered 2883 only when the DOTS server channel session is lost"; 2884 reference 2885 "RFC XXXX: Distributed Denial-of-Service Open Threat 2886 Signaling (DOTS) Signal Channel"; 2887 } 2889 leaf config-interval { 2890 type int32; 2891 units "seconds"; 2892 description 2893 "This parameter is returned by a DOTS server to 2894 a requesting DOTS client to indicate the time interval 2895 after which the DOTS client must contact the DOTS 2896 server in order to retrieve the signal channel 2897 configuration data. 2899 This mechanism allows the update of the configuration 2900 data if a change occurs. 2902 For example, the new configuration may instruct 2903 a DOTS client to cease heartbeats or reduce 2904 heartbeat frequency. 2906 '0' is used to disable this refresh mechanism."; 2907 } 2908 } 2910 grouping redirected-signal { 2911 description 2912 "Grouping for the redirected signaling."; 2914 leaf alt-server { 2915 type string; 2916 mandatory true; 2917 description 2918 "Alias of an alternate server."; 2920 } 2922 list alt-server-record { 2923 key "addr"; 2924 description 2925 "List of records for the alternate server."; 2927 leaf addr { 2928 type inet:ip-address; 2929 description 2930 "IPv4 or IPv6 address identifying the server."; 2931 } 2933 leaf ttl { 2934 type int32; 2935 description 2936 "TTL associated with this record."; 2937 } 2938 } 2939 } 2941 container dots-signal { 2942 description 2943 "Main container for DOTS signal message. 2944 A DOTS signal message can be a mitigation message or 2945 a configuration message."; 2947 choice message-type { 2948 description 2949 "Can be a mitigation, a configuration, or a redirect 2950 message."; 2952 case mitigation-scope { 2953 description 2954 "Mitigation scope of a mitigation message."; 2955 uses mitigation-scope; 2956 } 2958 case signal-config { 2959 description 2960 "Configuration message."; 2961 uses signal-config; 2962 } 2964 case redirected-signal { 2965 description 2966 "Redirected signaling."; 2967 uses redirected-signal; 2969 } 2970 } 2971 } 2972 } 2973 2975 6. Mapping Parameters to CBOR 2977 All parameters in the payload of the DOTS signal channel MUST be 2978 mapped to CBOR types as shown in Table 4 and are assigned an integer 2979 key to save space. The recipient of the payload MAY reject the 2980 information if it is not suitably mapped. 2982 +-----------------------+---------+--------------------+------------+ 2983 | Parameter Name | CBOR | CBOR Major Type | JSON Type | 2984 | | Key | | | 2985 +-----------------------+---------+--------------------+------------+ 2986 | mitigation-scope | 1 | 5 (map) | Object | 2987 | scope | 2 | 4 (array) | Array | 2988 | mitigation-id | 3 | 0 (unsigned) | Number | 2989 | acl-list | 4 | 4 (array) | Array | 2990 | target-port-range | 5 | 4 (array) | Array | 2991 | lower-port | 6 | 0 (unsigned) | Number | 2992 | upper-port | 7 | 0 (unsigned) | Number | 2993 | target-protocol | 8 | 4 (array) | Array | 2994 | | | 0 (unsigned) | Number | 2995 | target-fqdn | 9 | 4 (array) | Array | 2996 | | | 3 (text string) | String | 2997 | target-uri | 10 | 4 (array) | Array | 2998 | | | 3 (text string) | String | 2999 | alias-name | 11 | 4 (array) | Array | 3000 | | | 3 (text string) | String | 3001 | lifetime | 12 | 0 (unsigned) | Number | 3002 | attack-status | 13 | 0 (unsigned) | Number | 3003 | signal-config | 14 | 5 (map) | Object | 3004 | heartbeat-interval | 15 | 5 (map) | Object | 3005 | max-retransmit | 16 | 5 (map) | Object | 3006 | ack-timeout | 17 | 5 (map) | Object | 3007 | ack-random-factor | 18 | 5 (map) | Object | 3008 | min-value | 19 | 0 (unsigned) | Number | 3009 | max-value | 20 | 0 (unsigned) | Number | 3010 | status | 21 | 0 (unsigned) | Number | 3011 | conflict-information | 22 | 5 (map) | Object | 3012 | conflict-status | 23 | 0 (unsigned) | Number | 3013 | conflict-cause | 24 | 0 (unsigned) | Number | 3014 | retry-timer | 25 | 0 (unsigned) | Number | 3015 | bytes-dropped | 26 | 0 (unsigned) | String | 3016 | bps-dropped | 27 | 0 (unsigned) | String | 3017 | pkts-dropped | 28 | 0 (unsigned) | String | 3018 | pps-dropped | 29 | 0 (unsigned) | String | 3019 | session-id | 30 | 0 (unsigned) | Number | 3020 | trigger-mitigation | 31 | 7 (simple type) | true/false | 3021 | missing-hb-allowed | 32 | 5 (map) | Object | 3022 | current-value | 33 | 0 (unsigned) | Number | 3023 | mitigation-start | 34 | 7 (floating-point) | Number | 3024 | target-prefix | 35 | 4 (array) | Array | 3025 | | | 3 (text string) | String | 3026 | client-domain-hash | 36 | 3 (text string) | String | 3027 | alt-server | 37 | 3 (text string) | String | 3028 | alt-server-record | 38 | 4 (array) | Array | 3029 | addr | 39 | 3 (text string) | String | 3030 | ttl | 40 | 0 (unsigned) | Number | 3031 | conflict-scope | 41 | 5 (map) | Object | 3032 | acl-name | 42 | 3 (text string) | String | 3033 | acl-type | 43 | 3 (text string) | String | 3034 | config-interval | 44 | 0 (unsigned) | Number | 3035 | mitigating-config | 45 | 5 (map) | Object | 3036 | idle-config | 46 | 5 (map) | Object | 3037 | cuid | 47 | 3 (text string) | String | 3038 | min-value-decimal | 48 | 7 (floating-point) | Number | 3039 | max-value-decimal | 49 | 7 (floating-point) | Number | 3040 | current-value-decimal | 50 | 7 (floating-point) | Number | 3041 +-----------------------+---------+--------------------+------------+ 3043 Table 4: CBOR Mappings Used in DOTS Signal Channel Messages 3045 7. (D)TLS Protocol Profile and Performance Considerations 3047 7.1. (D)TLS Protocol Profile 3049 This section defines the (D)TLS protocol profile of DOTS signal 3050 channel over (D)TLS and DOTS data channel over TLS. 3052 There are known attacks on (D)TLS, such as man-in-the-middle and 3053 protocol downgrade attacks. These are general attacks on (D)TLS and, 3054 as such, they are not specific to DOTS over (D)TLS; refer to the 3055 (D)TLS RFCs for discussion of these security issues. DOTS agents 3056 MUST adhere to the (D)TLS implementation recommendations and security 3057 considerations of [RFC7525] except with respect to (D)TLS version. 3058 Since DOTS signal channel encryption relies upon (D)TLS is virtually 3059 a green-field deployment, DOTS agents MUST implement only (D)TLS 1.2 3060 or later. 3062 When a DOTS client is configured with a domain name of the DOTS 3063 server, and connects to its configured DOTS server, the server may 3064 present it with a PKIX certificate. In order to ensure proper 3065 authentication, a DOTS client MUST verify the entire certification 3066 path per [RFC5280]. The DOTS client additionally uses [RFC6125] 3067 validation techniques to compare the domain name with the certificate 3068 provided. 3070 A key challenge to deploying DOTS is the provisioning of DOTS 3071 clients, including the distribution of keying material to DOTS 3072 clients to enable the required mutual authentication of DOTS agents. 3073 EST defines a method of certificate enrollment by which domains 3074 operating DOTS servers may provide DOTS clients with all the 3075 necessary cryptographic keying material, including a private key and 3076 a certificate to authenticate themselves. One deployment option is 3077 DOTS clients behave as EST clients for certificate enrollment from an 3078 EST server provisioned by the mitigation provider. This document 3079 does not specify which EST mechanism the DOTS client uses to achieve 3080 initial enrollment. 3082 The Server Name Indication (SNI) extension [RFC6066] defines a 3083 mechanism for a client to tell a (D)TLS server the name of the server 3084 it wants to contact. This is a useful extension for hosting 3085 environments where multiple virtual servers are reachable over a 3086 single IP address. The DOTS client may or may not know if it is 3087 interacting with a DOTS server in a virtual server hosting 3088 environment, so the DOTS client SHOULD include the DOTS server FQDN 3089 in the SNI extension. 3091 Implementations compliant with this profile MUST implement all of the 3092 following items: 3094 o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect 3095 against replay attacks. 3097 o (D)TLS session resumption without server-side state [RFC5077] to 3098 resume session and convey the DOTS signal. 3100 o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduces 3101 the size of the ServerHello, and can be used by DOTS agents that 3102 cannot obtain certificates. 3104 Implementations compliant with this profile SHOULD implement all of 3105 the following items to reduce the delay required to deliver a DOTS 3106 signal channel message: 3108 o TLS False Start [RFC7918] which reduces round-trips by allowing 3109 the TLS second flight of messages (ChangeCipherSpec) to also 3110 contain the DOTS signal. 3112 o Cached Information Extension [RFC7924] which avoids transmitting 3113 the server's certificate and certificate chain if the client has 3114 cached that information from a previous TLS handshake. 3116 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 3117 convey DOTS signal channel message. 3119 7.2. (D)TLS 1.3 Considerations 3121 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 3122 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 3123 [I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides 3124 equivalent security guarantees. (D)TLS 1.3 provides two basic 3125 handshake modes the DOTS signal channel can take advantage of: 3127 o A full handshake mode in which a DOTS client can send a DOTS 3128 mitigation request message after one round trip and the DOTS 3129 server immediately responds with a DOTS mitigation response. This 3130 assumes no packet loss is experienced. 3132 o 0-RTT mode in which the DOTS client can authenticate itself and 3133 send DOTS mitigation request messages in the first message, thus 3134 reducing handshake latency. 0-RTT only works if the DOTS client 3135 has previously communicated with that DOTS server, which is very 3136 likely with the DOTS signal channel. 3138 The DOTS client has to establish a (D)TLS session with the DOTS 3139 server during peacetime and share a PSK. 3141 During a DDoS attack, the DOTS client can use the (D)TLS session 3142 to convey the DOTS mitigation request message and, if there is no 3143 response from the server after multiple retries, the DOTS client 3144 can resume the (D)TLS session in 0-RTT mode using PSK. 3146 Section 8 of [I-D.ietf-tls-tls13] discusses some mechanisms to 3147 implement to limit the impact of replay attacks on 0-RTT data. If 3148 TLS1.3 is used, DOTS servers must implement one of these 3149 mechanisms. 3151 A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request 3152 message exchange is shown in Figure 25. 3154 DOTS Client DOTS Server 3156 ClientHello 3157 (Finished) 3158 (0-RTT DOTS signal message) 3159 (end_of_early_data) --------> 3160 ServerHello 3161 {EncryptedExtensions} 3162 {ServerConfiguration} 3163 {Certificate} 3164 {CertificateVerify} 3165 {Finished} 3166 <-------- [DOTS signal message] 3167 {Finished} --------> 3169 [DOTS signal message] <-------> [DOTS signal message] 3171 Figure 25: TLS 1.3 handshake with 0-RTT 3173 7.3. MTU and Fragmentation 3175 To avoid DOTS signal message fragmentation and the subsequent 3176 decreased probability of message delivery, DOTS agents MUST ensure 3177 that the DTLS record MUST fit within a single datagram. If the path 3178 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 3179 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 3180 is used to convey the DOTS signal messages then the DOTS client must 3181 consider the amount of record expansion expected by the DTLS 3182 processing when calculating the size of CoAP message that fits within 3183 the path MTU. Path MTU MUST be greater than or equal to [CoAP 3184 message size + DTLS overhead of 13 octets + authentication overhead 3185 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 3186 of [RFC6347]). If the request size exceeds the path MTU then the 3187 DOTS client MUST split the DOTS signal into separate messages, for 3188 example the list of addresses in the 'target-prefix' parameter could 3189 be split into multiple lists and each list conveyed in a new PUT 3190 request. 3192 Implementation Note: DOTS choice of message size parameters works 3193 well with IPv6 and with most of today's IPv4 paths. However, with 3194 IPv4, it is harder to reliably ensure that there is no IP 3195 fragmentation. If IPv4 path MTU is unknown, implementations may want 3196 to limit themselves to more conservative IPv4 datagram sizes such as 3197 576 bytes, as per [RFC0791]. IP packets whose size does not exceed 3198 576 bytes should never need to be fragmented: therefore, sending a 3199 maximum of 500 bytes of DOTS signal over a UDP datagram will 3200 generally avoid IP fragmentation. 3202 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 3204 (D)TLS based upon client certificate can be used for mutual 3205 authentication between DOTS agents. If a DOTS gateway is involved, 3206 DOTS clients and DOTS gateways MUST perform mutual authentication; 3207 only authorized DOTS clients are allowed to send DOTS signals to a 3208 DOTS gateway. The DOTS gateway and the DOTS server MUST perform 3209 mutual authentication; a DOTS server only allows DOTS signal channel 3210 messages from an authorized DOTS gateway, thereby creating a two-link 3211 chain of transitive authentication between the DOTS client and the 3212 DOTS server. 3214 The DOTS server SHOULD support certificate-based client 3215 authentication. The DOTS client SHOULD respond to the DOTS server's 3216 TLS certificate request message with the PKIX certificate held by the 3217 DOTS client. DOTS client certificate validation MUST be performed as 3218 per [RFC5280] and the DOTS client certificate MUST conform to the 3219 [RFC5280] certificate profile. If a DOTS client does not support TLS 3220 client certificate authentication, it MUST support pre-shared key 3221 based or raw public key based client authentication. 3223 +-----------------------------------------------+ 3224 | example.com domain +---------+ | 3225 | | AAA | | 3226 | +---------------+ | Server | | 3227 | | Application | +------+--+ | 3228 | | server +<-----------------+ ^ | 3229 | | (DOTS client) | | | | 3230 | +---------------+ | | | 3231 | V V | example.net domain 3232 | +-----+----+--+ | +---------------+ 3233 | +--------------+ | | | | | 3234 | | Guest +<-----x----->+ DOTS +<------>+ DOTS | 3235 | | (DOTS client)| | gateway | | | server | 3236 | +--------------+ | | | | | 3237 | +----+--------+ | +---------------+ 3238 | ^ | 3239 | | | 3240 | +----------------+ | | 3241 | | DDoS detector | | | 3242 | | (DOTS client) +<---------------+ | 3243 | +----------------+ | 3244 +-----------------------------------------------+ 3246 Figure 26: Example of Authentication and Authorization of DOTS Agents 3248 In the example depicted in Figure 26, the DOTS gateway and DOTS 3249 clients within the 'example.com' domain mutually authenticate with 3250 each other. After the DOTS gateway validates the identity of a DOTS 3251 client, it communicates with the AAA server in the 'example.com' 3252 domain to determine if the DOTS client is authorized to request DDoS 3253 mitigation. If the DOTS client is not authorized, a 4.01 3254 (Unauthorized) is returned in the response to the DOTS client. In 3255 this example, the DOTS gateway only allows the application server and 3256 DDoS attack detector to request DDoS mitigation, but does not permit 3257 the user of type 'guest' to request DDoS mitigation. 3259 Also, DOTS gateways and servers located in different domains MUST 3260 perform mutual authentication (e.g., using certificates). A DOTS 3261 server will only allow a DOTS gateway with a certificate for a 3262 particular domain to request mitigation for that domain. In 3263 reference to Figure 26, the DOTS server only allows the DOTS gateway 3264 to request mitigation for 'example.com' domain and not for other 3265 domains. 3267 9. IANA Considerations 3269 This specification registers a service port (Section 9.1), an URI 3270 suffix in the Well-Known URIs registry (Section 9.2), a CoAP response 3271 code (Section 9.3), a YANG module (Section 9.5). It also creates a 3272 registry for mappings to CBOR (Section 9.4). 3274 9.1. DOTS Signal Channel UDP and TCP Port Number 3276 IANA is requested to assign the port number TBD to the DOTS signal 3277 channel protocol for both UDP and TCP from the "Service Name and 3278 Transport Protocol Port Number Registry" available at 3279 https://www.iana.org/assignments/service-names-port-numbers/service- 3280 names-port-numbers.xhtml. 3282 The assignment of port number 4646 is strongly suggested, as 4646 is 3283 the ASCII decimal value for ".." (DOTS). 3285 9.2. Well-Known 'dots' URI 3287 This document requests IANA to register the 'dots' well-known URI in 3288 the Well-Known URIs registry (https://www.iana.org/assignments/well- 3289 known-uris/well-known-uris.xhtml) as defined by [RFC5785]. 3291 URI suffix: dots 3293 Change controller: IETF 3295 Specification document(s): This RFC 3297 Related information: None 3299 9.3. CoAP Response Code 3301 IANA is requested to add the following entry to the "CoAP Response 3302 Codes" sub-registry available at https://www.iana.org/assignments/ 3303 core-parameters/core-parameters.xhtml#response-codes: 3305 +------+------------------+-----------+ 3306 | Code | Description | Reference | 3307 +------+------------------+-----------+ 3308 | 3.00 | Alternate Server | [RFCXXXX] | 3309 +------+------------------+-----------+ 3311 Table 5: CoAP Response Code 3313 9.4. DOTS Signal Channel CBOR Mappings Registry 3315 The document requests IANA to create a new registry, entitled "DOTS 3316 Signal Channel CBOR Mappings Registry". The structure of this 3317 registry is provided in Section 9.4.1. 3319 The registry is initially populated with the values in Section 9.4.2. 3321 Values from that registry MUST be assigned via Expert Review 3322 [RFC8126]. 3324 9.4.1. Registration Template 3326 Parameter name: 3327 Parameter name as used in the DOTS signal channel. 3329 CBOR Key Value: 3330 Key value for the parameter. The key value MUST be an integer in 3331 the 1-65536 range. The key values in the 32758-65536 range are 3332 assigned to Vendor-Specific parameters. 3334 CBOR Major Type: 3335 CBOR Major type and optional tag for the claim. 3337 Change Controller: 3338 For Standards Track RFCs, list the "IESG". For others, give the 3339 name of the responsible party. Other details (e.g., postal 3340 address, email address, home page URI) may also be included. 3342 Specification Document(s): 3343 Reference to the document or documents that specify the parameter, 3344 preferably including URIs that can be used to retrieve copies of 3345 the documents. An indication of the relevant sections may also be 3346 included but is not required. 3348 9.4.2. Initial Registry Contents 3350 o Parameter Name: mitigation-scope 3351 o CBOR Key Value: 1 3352 o CBOR Major Type: 5 3353 o Change Controller: IESG 3354 o Specification Document(s): this document 3356 o Parameter Name: scope 3357 o CBOR Key Value: 2 3358 o CBOR Major Type: 4 3359 o Change Controller: IESG 3360 o Specification Document(s): this document 3362 o Parameter Name: mitigation-id 3363 o CBOR Key Value: 3 3364 o CBOR Major Type: 0 3365 o Change Controller: IESG 3366 o Specification Document(s): this document 3368 o Parameter Name: acl-list 3369 o CBOR Key Value: 4 3370 o CBOR Major Type: 4 3371 o Change Controller: IESG 3372 o Specification Document(s): this document 3374 o Parameter Name: target-port-range 3375 o CBOR Key Value: 5 3376 o CBOR Major Type: 4 3377 o Change Controller: IESG 3378 o Specification Document(s): this document 3380 o Parameter Name: lower-port 3381 o CBOR Key Value: 6 3382 o CBOR Major Type: 0 3383 o Change Controller: IESG 3384 o Specification Document(s): this document 3386 o Parameter Name: upper-port 3387 o CBOR Key Value: 7 3388 o CBOR Major Type: 0 3389 o Change Controller: IESG 3390 o Specification Document(s): this document 3392 o Parameter Name: target-protocol 3393 o CBOR Key Value: 8 3394 o CBOR Major Type: 4 3395 o Change Controller: IESG 3396 o Specification Document(s): this document 3398 o Parameter Name: target-fqdn 3399 o CBOR Key Value: 9 3400 o CBOR Major Type: 4 3401 o Change Controller: IESG 3402 o Specification Document(s): this document 3404 o Parameter Name: target-uri 3405 o CBOR Key Value: 10 3406 o CBOR Major Type: 4 3407 o Change Controller: IESG 3408 o Specification Document(s): this document 3410 o Parameter Name: alias-name 3411 o CBOR Key Value: 11 3412 o CBOR Major Type: 4 3413 o Change Controller: IESG 3414 o Specification Document(s): this document 3416 o Parameter Name: lifetime 3417 o CBOR Key Value: 12 3418 o CBOR Major Type: 0 3419 o Change Controller: IESG 3420 o Specification Document(s): this document 3422 o Parameter Name: attack-status 3423 o CBOR Key Value: 13 3424 o CBOR Major Type: 0 3425 o Change Controller: IESG 3426 o Specification Document(s): this document 3428 o Parameter Name: signal-config 3429 o CBOR Key Value: 14 3430 o CBOR Major Type: 5 3431 o Change Controller: IESG 3432 o Specification Document(s): this document 3434 o Parameter Name: heartbeat-interval 3435 o CBOR Key Value: 15 3436 o CBOR Major Type: 5 3437 o Change Controller: IESG 3438 o Specification Document(s): this document 3440 o Parameter Name: max-retransmit 3441 o CBOR Key Value: 16 3442 o CBOR Major Type: 5 3443 o Change Controller: IESG 3444 o Specification Document(s): this document 3446 o Parameter Name: ack-timeout 3447 o CBOR Key Value: 17 3448 o CBOR Major Type: 5 3449 o Change Controller: IESG 3450 o Specification Document(s): this document 3452 o Parameter Name: ack-random-factor 3453 o CBOR Key Value: 18 3454 o CBOR Major Type: 5 3455 o Change Controller: IESG 3456 o Specification Document(s): this document 3458 o Parameter Name: min-value 3459 o CBOR Key Value: 19 3460 o CBOR Major Type: 0 3461 o Change Controller: IESG 3462 o Specification Document(s): this document 3464 o Parameter Name: max-value 3465 o CBOR Key Value: 20 3466 o CBOR Major Type: 0 3467 o Change Controller: IESG 3468 o Specification Document(s): this document 3470 o Parameter Name: status 3471 o CBOR Key Value: 21 3472 o CBOR Major Type: 0 3473 o Change Controller: IESG 3474 o Specification Document(s): this document 3476 o Parameter Name: conflict-information 3477 o CBOR Key Value: 22 3478 o CBOR Major Type: 5 3479 o Change Controller: IESG 3480 o Specification Document(s): this document 3482 o Parameter Name: conflict-status 3483 o CBOR Key Value: 23 3484 o CBOR Major Type: 0 3485 o Change Controller: IESG 3486 o Specification Document(s): this document 3488 o Parameter Name: conflict-cause 3489 o CBOR Key Value: 24 3490 o CBOR Major Type: 0 3491 o Change Controller: IESG 3492 o Specification Document(s): this document 3494 o Parameter Name: retry-timer 3495 o CBOR Key Value: 25 3496 o CBOR Major Type: 0 3497 o Change Controller: IESG 3498 o Specification Document(s): this document 3500 o Parameter Name: bytes-dropped 3501 o CBOR Key Value: 26 3502 o CBOR Major Type: 0 3503 o Change Controller: IESG 3504 o Specification Document(s): this document 3506 o Parameter Name: bps-dropped 3507 o CBOR Key Value: 27 3508 o CBOR Major Type: 0 3509 o Change Controller: IESG 3510 o Specification Document(s): this document 3512 o Parameter Name: pkts-dropped 3513 o CBOR Key Value: 28 3514 o CBOR Major Type: 0 3515 o Change Controller: IESG 3516 o Specification Document(s): this document 3518 o Parameter Name: pps-dropped 3519 o CBOR Key Value: 29 3520 o CBOR Major Type: 0 3521 o Change Controller: IESG 3522 o Specification Document(s): this document 3524 o Parameter Name: session-id 3525 o CBOR Key Value: 30 3526 o CBOR Major Type: 0 3527 o Change Controller: IESG 3528 o Specification Document(s): this document 3530 o Parameter Name: trigger-mitigation 3531 o CBOR Key Value: 31 3532 o CBOR Major Type: 7 3533 o Change Controller: IESG 3534 o Specification Document(s): this document 3536 o Parameter Name: missing-hb-allowed 3537 o CBOR Key Value: 32 3538 o CBOR Major Type: 5 3539 o Change Controller: IESG 3540 o Specification Document(s): this document 3542 o Parameter Name: current-value 3543 o CBOR Key Value: 33 3544 o CBOR Major Type: 0 3545 o Change Controller: IESG 3546 o Specification Document(s): this document 3548 o Parameter Name: mitigation-start 3549 o CBOR Key Value: 34 3550 o CBOR Major Type: 7 3551 o Change Controller: IESG 3552 o Specification Document(s): this document 3554 o Parameter Name: target-prefix 3555 o CBOR Key Value: 35 3556 o CBOR Major Type: 4 3557 o Change Controller: IESG 3558 o Specification Document(s): this document 3560 o Parameter Name: client-domain-hash 3561 o CBOR Key Value: 36 3562 o CBOR Major Type: 3 3563 o Change Controller: IESG 3564 o Specification Document(s): this document 3566 o Parameter Name: alt-server 3567 o CBOR Key Value: 37 3568 o CBOR Major Type: 3 3569 o Change Controller: IESG 3570 o Specification Document(s): this document 3572 o Parameter Name: alt-server-record 3573 o CBOR Key Value: 38 3574 o CBOR Major Type: 4 3575 o Change Controller: IESG 3576 o Specification Document(s): this document 3578 o Parameter Name: addr 3579 o CBOR Key Value: 39 3580 o CBOR Major Type: 3 3581 o Change Controller: IESG 3582 o Specification Document(s): this document 3584 o Parameter Name: ttl 3585 o CBOR Key Value: 40 3586 o CBOR Major Type: 0 3587 o Change Controller: IESG 3588 o Specification Document(s): this document 3590 o Parameter Name: conflict-scope 3591 o CBOR Key Value: 41 3592 o CBOR Major Type: 5 3593 o Change Controller: IESG 3594 o Specification Document(s): this document 3596 o Parameter Name: acl-name 3597 o CBOR Key Value: 42 3598 o CBOR Major Type: 3 3599 o Change Controller: IESG 3600 o Specification Document(s): this document 3602 o Parameter Name: acl-type 3603 o CBOR Key Value: 43 3604 o CBOR Major Type: 3 3605 o Change Controller: IESG 3606 o Specification Document(s): this document 3608 o Parameter Name: config-interval 3609 o CBOR Key Value: 44 3610 o CBOR Major Type: 0 3611 o Change Controller: IESG 3612 o Specification Document(s): this document 3614 o Parameter Name: mitigating-config 3615 o CBOR Key Value: 45 3616 o CBOR Major Type: 5 3617 o Change Controller: IESG 3618 o Specification Document(s): this document 3620 o Parameter Name: idle-config 3621 o CBOR Key Value: 46 3622 o CBOR Major Type: 5 3623 o Change Controller: IESG 3624 o Specification Document(s): this document 3626 o Parameter Name: cuid 3627 o CBOR Key Value: 47 3628 o CBOR Major Type: 3 3629 o Change Controller: IESG 3630 o Specification Document(s): this document 3632 o Parameter Name: min-value-decimal 3633 o CBOR Key Value: 48 3634 o CBOR Major Type: 7 3635 o Change Controller: IESG 3636 o Specification Document(s): this document 3638 o Parameter Name: max-value-decimal 3639 o CBOR Key Value: 49 3640 o CBOR Major Type: 7 3641 o Change Controller: IESG 3642 o Specification Document(s): this document 3644 o Parameter Name: current-value-decimal 3645 o CBOR Key Value: 50 3646 o CBOR Major Type: 7 3647 o Change Controller: IESG 3648 o Specification Document(s): this document 3650 9.5. DOTS Signal Channel YANG Module 3652 This document requests IANA to register the following URI in the 3653 "IETF XML Registry" [RFC3688]: 3655 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal 3656 Registrant Contact: The IESG. 3657 XML: N/A; the requested URI is an XML namespace. 3659 This document requests IANA to register the following YANG module in 3660 the "YANG Module Names" registry [RFC7950]. 3662 name: ietf-signal 3663 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal 3664 prefix: signal 3665 reference: RFC XXXX 3667 10. Implementation Status 3669 [Note to RFC Editor: Please remove this section and reference to 3670 [RFC7942] prior to publication.] 3672 This section records the status of known implementations of the 3673 protocol defined by this specification at the time of posting this 3674 Internet-Draft, and is based upon a proposal described in [RFC7942]. 3675 The description of implementations in this section is intended to 3676 assist the IETF in its decision-making process when progressing 3677 drafts to RFCs. Please note that the listing of any individual 3678 implementation here does not imply endorsement by the IETF. 3679 Furthermore, no effort has been spent to verify the information 3680 presented here, and which was provided by individuals. This is not 3681 intended as, and must not be construed to be, a catalog of available 3682 implementations or features. Readers are advised to note that other 3683 implementations may exist. 3685 According to [RFC7942], "this will allow reviewers and working groups 3686 to assign due consideration to documents that have the benefit of 3687 running code, which may serve as evidence of valuable experimentation 3688 and feedback that have made the implemented protocols more mature. 3689 It is up to the individual working groups to use this information as 3690 they see fit". 3692 10.1. nttdots 3694 Organization: NTT Communication is developing a DOTS client and 3695 DOTS server software based on DOTS signal channel specified in 3696 this draft. It will be open-sourced. 3697 Description: Early implementation of DOTS protocol. It is aimed to 3698 implement a full DOTS protocol specification in accordance with 3699 the nurturing DOTS protocol. 3700 Implementation: https://github.com/nttdots/go-dots 3701 Level of maturity: It is an early implementation of the DOTS 3702 protocol. Messaging between DOTS clients and DOTS servers has 3703 been tested. Level of maturity will increase in accordance with 3704 the nurturing DOTS protocol. 3705 Coverage: Capability of DOTS client: sending DOTS messages to the 3706 DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS 3707 server: receiving dots-signal, validating received dots-signal, 3708 starting mitigation by handing over the dots-signal to DDoS 3709 mitigator. 3710 Licensing: It will be open-sourced with BSD 3-clause license. 3711 Implementation experience: It is implemented in Go-lang. Core 3712 specification of signaling is mature to be implemented, however, 3713 finding good libraries(like DTLS, CoAP) is rather difficult. 3714 Contact: Kaname Nishizuka 3716 11. Security Considerations 3718 Authenticated encryption MUST be used for data confidentiality and 3719 message integrity. The interaction between the DOTS agents requires 3720 Datagram Transport Layer Security (DTLS) and Transport Layer Security 3721 (TLS) with a cipher suite offering confidentiality protection and the 3722 guidance given in [RFC7525] MUST be followed to avoid attacks on 3723 (D)TLS. The (D)TLS protocol profile for DOTS signal channel is 3724 specified in Section 7. 3726 A single DOTS signal channel between DOTS agents can be used to 3727 exchange multiple DOTS signal messages. To reduce DOTS client and 3728 DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session. 3730 If TCP is used between DOTS agents, an attacker may be able to inject 3731 RST packets, bogus application segments, etc., regardless of whether 3732 TLS authentication is used. Because the application data is TLS 3733 protected, this will not result in the application receiving bogus 3734 data, but it will constitute a DoS on the connection. This attack 3735 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 3736 any bogus packets injected by an attacker will be rejected by the 3737 TCP-AO integrity check and therefore will never reach the TLS layer. 3739 In order to prevent leaking internal information outside a client- 3740 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 3741 the identification information that pertains to internal DOTS clients 3742 (e.g., source IP address, client's hostname) unless explicitly 3743 configured to do so. 3745 Special care should be taken in order to ensure that the activation 3746 of the proposed mechanism will not impact the stability of the 3747 network (including connectivity and services delivered over that 3748 network). 3750 12. Contributors 3752 The following individuals have contributed to this document: 3754 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 3755 mgeller@cisco.com 3757 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 3758 Email: rgm@htt-consult.com 3760 Dan Wing Email: dwing-ietf@fuggles.com 3762 13. Acknowledgements 3764 Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, 3765 Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang 3766 Xia, Gilbert Clark, and Nesredien Suleiman for the discussion and 3767 comments. 3769 Special thanks to Jon Shallow for the careful reviews and inputs that 3770 enhanced this specification. 3772 14. References 3774 14.1. Normative References 3776 [I-D.ietf-core-coap-tcp-tls] 3777 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 3778 Silverajan, B., and B. Raymor, "CoAP (Constrained 3779 Application Protocol) over TCP, TLS, and WebSockets", 3780 draft-ietf-core-coap-tcp-tls-11 (work in progress), 3781 December 2017. 3783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3784 Requirement Levels", BCP 14, RFC 2119, 3785 DOI 10.17487/RFC2119, March 1997, 3786 . 3788 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3789 DOI 10.17487/RFC3688, January 2004, 3790 . 3792 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 3793 Ciphersuites for Transport Layer Security (TLS)", 3794 RFC 4279, DOI 10.17487/RFC4279, December 2005, 3795 . 3797 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3798 (TLS) Protocol Version 1.2", RFC 5246, 3799 DOI 10.17487/RFC5246, August 2008, 3800 . 3802 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3803 Housley, R., and W. Polk, "Internet X.509 Public Key 3804 Infrastructure Certificate and Certificate Revocation List 3805 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3806 . 3808 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3809 Uniform Resource Identifiers (URIs)", RFC 5785, 3810 DOI 10.17487/RFC5785, April 2010, 3811 . 3813 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 3814 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 3815 June 2010, . 3817 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 3818 Extensions: Extension Definitions", RFC 6066, 3819 DOI 10.17487/RFC6066, January 2011, 3820 . 3822 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3823 Verification of Domain-Based Application Service Identity 3824 within Internet Public Key Infrastructure Using X.509 3825 (PKIX) Certificates in the Context of Transport Layer 3826 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3827 2011, . 3829 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 3830 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 3831 DOI 10.17487/RFC6234, May 2011, 3832 . 3834 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3835 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3836 January 2012, . 3838 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 3839 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 3840 Transport Layer Security (TLS) and Datagram Transport 3841 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 3842 June 2014, . 3844 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3845 Application Protocol (CoAP)", RFC 7252, 3846 DOI 10.17487/RFC7252, June 2014, 3847 . 3849 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3850 "Recommendations for Secure Use of Transport Layer 3851 Security (TLS) and Datagram Transport Layer Security 3852 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3853 2015, . 3855 [RFC7641] Hartke, K., "Observing Resources in the Constrained 3856 Application Protocol (CoAP)", RFC 7641, 3857 DOI 10.17487/RFC7641, September 2015, 3858 . 3860 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3861 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3862 . 3864 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3865 Writing an IANA Considerations Section in RFCs", BCP 26, 3866 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3867 . 3869 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 3870 FETCH Methods for the Constrained Application Protocol 3871 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 3872 . 3874 14.2. Informative References 3876 [I-D.ietf-core-comi] 3877 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 3878 Management Interface", draft-ietf-core-comi-02 (work in 3879 progress), December 2017. 3881 [I-D.ietf-core-yang-cbor] 3882 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 3883 Minaburo, "CBOR Encoding of Data Modeled with YANG", 3884 draft-ietf-core-yang-cbor-05 (work in progress), August 3885 2017. 3887 [I-D.ietf-dots-architecture] 3888 Mortensen, A., Andreasen, F., Reddy, T., 3889 christopher_gray3@cable.comcast.com, c., Compton, R., and 3890 N. Teague, "Distributed-Denial-of-Service Open Threat 3891 Signaling (DOTS) Architecture", draft-ietf-dots- 3892 architecture-05 (work in progress), October 2017. 3894 [I-D.ietf-dots-data-channel] 3895 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 3896 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 3897 Service Open Threat Signaling (DOTS) Data Channel", draft- 3898 ietf-dots-data-channel-11 (work in progress), December 3899 2017. 3901 [I-D.ietf-dots-requirements] 3902 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 3903 Denial of Service (DDoS) Open Threat Signaling 3904 Requirements", draft-ietf-dots-requirements-10 (work in 3905 progress), January 2018. 3907 [I-D.ietf-dots-use-cases] 3908 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 3909 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 3910 Open Threat Signaling", draft-ietf-dots-use-cases-09 (work 3911 in progress), November 2017. 3913 [I-D.ietf-netmod-yang-tree-diagrams] 3914 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 3915 ietf-netmod-yang-tree-diagrams-04 (work in progress), 3916 December 2017. 3918 [I-D.ietf-tls-dtls13] 3919 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 3920 Datagram Transport Layer Security (DTLS) Protocol Version 3921 1.3", draft-ietf-tls-dtls13-22 (work in progress), 3922 November 2017. 3924 [I-D.ietf-tls-tls13] 3925 Rescorla, E., "The Transport Layer Security (TLS) Protocol 3926 Version 1.3", draft-ietf-tls-tls13-22 (work in progress), 3927 November 2017. 3929 [proto_numbers] 3930 "IANA, "Protocol Numbers"", 2011, 3931 . 3933 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3934 DOI 10.17487/RFC0791, September 1981, 3935 . 3937 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3938 Address Translator (Traditional NAT)", RFC 3022, 3939 DOI 10.17487/RFC3022, January 2001, 3940 . 3942 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3943 Resource Identifier (URI): Generic Syntax", STD 66, 3944 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3945 . 3947 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3948 "Randomness Requirements for Security", BCP 106, RFC 4086, 3949 DOI 10.17487/RFC4086, June 2005, 3950 . 3952 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3953 Congestion Control Protocol (DCCP)", RFC 4340, 3954 DOI 10.17487/RFC4340, March 2006, 3955 . 3957 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3958 (CIDR): The Internet Address Assignment and Aggregation 3959 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 3960 2006, . 3962 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 3963 Denial-of-Service Considerations", RFC 4732, 3964 DOI 10.17487/RFC4732, December 2006, 3965 . 3967 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 3968 Translation (NAT) Behavioral Requirements for Unicast 3969 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 3970 2007, . 3972 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3973 Extensions for Stateless Address Autoconfiguration in 3974 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 3975 . 3977 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3978 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3979 . 3981 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3982 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 3983 . 3985 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 3986 "Transport Layer Security (TLS) Session Resumption without 3987 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 3988 January 2008, . 3990 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3991 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3992 DOI 10.17487/RFC5389, October 2008, 3993 . 3995 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3996 NAT64: Network Address and Protocol Translation from IPv6 3997 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3998 April 2011, . 4000 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 4001 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 4002 . 4004 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 4005 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 4006 2012, . 4008 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 4009 "Default Address Selection for Internet Protocol Version 6 4010 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 4011 . 4013 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 4014 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 4015 DOI 10.17487/RFC6887, April 2013, 4016 . 4018 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 4019 A., and H. Ashida, "Common Requirements for Carrier-Grade 4020 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 4021 April 2013, . 4023 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4024 "Enrollment over Secure Transport", RFC 7030, 4025 DOI 10.17487/RFC7030, October 2013, 4026 . 4028 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 4029 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 4030 October 2013, . 4032 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 4033 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 4034 . 4036 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 4037 "Architectural Considerations in Smart Object Networking", 4038 RFC 7452, DOI 10.17487/RFC7452, March 2015, 4039 . 4041 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 4042 NETCONF Protocol over Transport Layer Security (TLS) with 4043 Mutual X.509 Authentication", RFC 7589, 4044 DOI 10.17487/RFC7589, June 2015, 4045 . 4047 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 4048 Layer Security (TLS) False Start", RFC 7918, 4049 DOI 10.17487/RFC7918, August 2016, 4050 . 4052 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 4053 (TLS) Cached Information Extension", RFC 7924, 4054 DOI 10.17487/RFC7924, July 2016, 4055 . 4057 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 4058 Code: The Implementation Status Section", BCP 205, 4059 RFC 7942, DOI 10.17487/RFC7942, July 2016, 4060 . 4062 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 4063 RFC 7951, DOI 10.17487/RFC7951, August 2016, 4064 . 4066 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 4067 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 4068 March 2017, . 4070 Authors' Addresses 4072 Tirumaleswar Reddy (editor) 4073 McAfee, Inc. 4074 Embassy Golf Link Business Park 4075 Bangalore, Karnataka 560071 4076 India 4078 Email: kondtir@gmail.com 4080 Mohamed Boucadair (editor) 4081 Orange 4082 Rennes 35000 4083 France 4085 Email: mohamed.boucadair@orange.com 4087 Prashanth Patil 4088 Cisco Systems, Inc. 4090 Email: praspati@cisco.com 4092 Andrew Mortensen 4093 Arbor Networks, Inc. 4094 2727 S. State St 4095 Ann Arbor, MI 48104 4096 United States 4098 Email: amortensen@arbor.net 4100 Nik Teague 4101 Verisign, Inc. 4102 United States 4104 Email: nteague@verisign.com