idnits 2.17.00 (12 Aug 2021) /tmp/idnits53032/draft-ietf-dots-signal-channel-12.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 3 instances of too long lines in the document, the longest one being 8 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 1819 has weird spacing: '...er-port ine...' == Line 1820 has weird spacing: '...er-port ine...' == Line 1836 has weird spacing: '...er-port ine...' == Line 1837 has weird spacing: '...er-port ine...' -- The document date (December 6, 2017) is 1626 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 2620, but not defined == Outdated reference: draft-ietf-core-coap-tcp-tls has been published as RFC 8323 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-11) exists of draft-ietf-core-comi-01 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-05 == Outdated reference: draft-ietf-dots-architecture has been published as RFC 8811 == Outdated reference: draft-ietf-dots-data-channel has been published as RFC 8783 == Outdated reference: draft-ietf-dots-requirements has been published as RFC 8612 == Outdated reference: draft-ietf-dots-use-cases has been published as RFC 8903 == Outdated reference: draft-ietf-netmod-yang-tree-diagrams has been published as RFC 8340 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- 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: 6 errors (**), 0 flaws (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair 5 Expires: June 9, 2018 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 December 6, 2017 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel 16 draft-ietf-dots-signal-channel-12 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. 28 Editorial Note (To be removed by RFC Editor) 30 Please update these statements with the RFC number to be assigned to 31 this document: 33 o "This version of this YANG module is part of RFC XXXX;" 35 o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling 36 (DOTS) Signal Channel"; 38 o "| 3.00 | Alternate server | [RFCXXXX] |" 40 o reference: RFC XXXX 42 o This RFC 44 Please update TBD statements with the port number to be assigned to 45 DOTS Signal Channel Protocol. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on June 9, 2018. 64 Copyright Notice 66 Copyright (c) 2017 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (https://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. Notational Conventions and Terminology . . . . . . . . . . . 5 83 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 84 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8 85 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8 86 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8 87 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 8 88 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10 89 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 10 90 4.4.2. Retrieve Information Related to a Mitigation . . . . 19 91 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 27 92 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 29 93 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 31 94 4.5.1. Discover Configuration Parameters . . . . . . . . . . 32 95 4.5.2. Convey DOTS Signal Channel Session Configuration . . 34 96 4.5.3. Delete DOTS Signal Channel Session Configuration . . 39 97 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 39 98 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 41 99 5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 42 100 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 42 101 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 44 102 6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 53 103 7. (D)TLS Protocol Profile and Performance Considerations . . . 55 104 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 55 105 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 56 106 7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 57 107 8. Mutual Authentication of DOTS Agents & Authorization of DOTS 108 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 110 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 59 111 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 59 112 9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 59 113 9.4. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 60 114 9.4.1. Registration Template . . . . . . . . . . . . . . . . 60 115 9.4.2. Initial Registry Contents . . . . . . . . . . . . . . 60 116 9.5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 66 117 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 66 118 10.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 67 119 11. Security Considerations . . . . . . . . . . . . . . . . . . . 67 120 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 68 121 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 122 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 123 14.1. Normative References . . . . . . . . . . . . . . . . . . 68 124 14.2. Informative References . . . . . . . . . . . . . . . . . 70 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 127 1. Introduction 129 A distributed denial-of-service (DDoS) attack is an attempt to make 130 machines or network resources unavailable to their intended users. 131 In most cases, sufficient scale can be achieved by compromising 132 enough end-hosts and using those infected hosts to perpetrate and 133 amplify the attack. The victim in this attack can be an application 134 server, a host, a router, a firewall, or an entire network. 136 Network applications have finite resources like CPU cycles, number of 137 processes or threads they can create and use, maximum number of 138 simultaneous connections it can handle, limited resources of the 139 control plane, etc. When processing network traffic, such 140 applications are supposed to use these resources to offer the 141 intended task in the most efficient fashion. However, a DDoS 142 attacker may be able to prevent an application from performing its 143 intended task by causing the application to exhaust the finite supply 144 of a specific resource. 146 TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the 147 victim and ACK-flood is a CPU exhaustion attack on the victim 148 [RFC4987]. Attacks on the link are carried out by sending enough 149 traffic such that the link becomes excessively congested, and 150 legitimate traffic suffers high packet loss. Stateful firewalls can 151 also be attacked by sending traffic that causes the firewall to hold 152 excessive state. The firewall then runs out of memory, and can no 153 longer instantiate the state required to pass legitimate flows. 154 Other possible DDoS attacks are discussed in [RFC4732]. 156 In many cases, it may not be possible for network administrators to 157 determine the causes of an attack, but instead just realize that 158 certain resources seem to be under attack. This document defines a 159 lightweight protocol permitting a DOTS client to request mitigation 160 from one or more DOTS servers for protection against detected, 161 suspected, or anticipated attacks. This protocol enables cooperation 162 between DOTS agents to permit a highly-automated network defense that 163 is robust, reliable, and secure. 165 An example of network diagram showing a deployment of DOTS agents is 166 shown in Figure 1. In this example, the DOTS server is operating on 167 the access network. The DOTS client is located on the LAN (Local 168 Area Network), while a DOTS gateway is embedded in the CPE (Customer 169 Premises Equipment). 171 Network 172 Resource CPE router Access network __________ 173 +-----------+ +--------------+ +-------------+ / \ 174 | |____| |_______| |___ | Internet | 175 |DOTS client| | DOTS gateway | | DOTS server | | | 176 | | | | | | | | 177 +-----------+ +--------------+ +-------------+ \__________/ 179 Figure 1: Sample DOTS Deployment (1) 181 The DOTS server can also be reachable over the Internet, as depicted 182 in Figure 2. 184 Network DDoS mitigation 185 Resource CPE router __________ service 186 +-----------+ +-------------+ / \ +-------------+ 187 | |____| |_______| |___ | | 188 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 189 | | | | | | | | 190 +-----------+ +-------------+ \__________/ +-------------+ 192 Figure 2: Sample DOTS Deployment (2) 194 In typical deployments, the DOTS client belongs to a different 195 administrative domain than the DOTS server. For example, the DOTS 196 client is embedded in a firewall protecting services owned and 197 operated by a domain, while the DOTS server is owned and operated by 198 a different domain providing DDoS mitigation services. That domain 199 providing DDoS mitigation service might, or might not, provide 200 connectivity service to the network hosting the DOTS client. 202 The DOTS server may (not) be co-located with the DOTS mitigator. In 203 typical deployments, the DOTS server belongs to the same 204 administrative domain as the mitigator. The DOTS client can 205 communicate directly with a DOTS server or indirectly via a DOTS 206 gateway. 208 The document adheres to the DOTS architecture 209 [I-D.ietf-dots-architecture]. The requirements for DOTS signal 210 channel protocol are obtained from [I-D.ietf-dots-requirements]. 211 This document satisfies all the use cases discussed in 212 [I-D.ietf-dots-use-cases]. 214 This document focuses on the DOTS signal channel. This is a 215 companion document to the DOTS data channel specification 216 [I-D.ietf-dots-data-channel] that defines a configuration and bulk 217 data exchange mechanism supporting the DOTS signal channel. 219 2. Notational Conventions and Terminology 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 223 "OPTIONAL" in this document are to be interpreted as described in 224 [RFC2119]. 226 (D)TLS is used for statements that apply to both Transport Layer 227 Security [RFC5246] and Datagram Transport Layer Security [RFC6347]. 228 Specific terms will be used for any statement that applies to either 229 protocol alone. 231 The reader should be familiar with the terms defined in 232 [I-D.ietf-dots-architecture]. 234 The meaning of the symbols in YANG tree diagrams is defined in 235 [I-D.ietf-netmod-yang-tree-diagrams]. 237 3. Design Overview 239 The DOTS signal channel is built on top of the Constrained 240 Application Protocol (CoAP) [RFC7252], a lightweight protocol 241 originally designed for constrained devices and networks. CoAP's 242 expectation of packet loss, support for asynchronous non-confirmable 243 messaging, congestion control, small message overhead limiting the 244 need for fragmentation, use of minimal resources, and support for 245 (D)TLS make it a good foundation on which to build the DOTS signaling 246 mechanism. 248 The DOTS signal channel is layered on existing standards (Figure 3). 250 +--------------+ 251 | DOTS | 252 +--------------+ 253 | CoAP | 254 +--------------+ 255 | TLS | DTLS | 256 +--------------+ 257 | TCP | UDP | 258 +--------------+ 259 | IP | 260 +--------------+ 262 Figure 3: Abstract Layering of DOTS signal channel over CoAP over 263 (D)TLS 265 By default, DOTS signal channel MUST run over port number TBD as 266 defined in Section 9.1, for both UDP and TCP, unless the DOTS server 267 has mutual agreement with its DOTS clients to use a port number other 268 than TBD for DOTS signal channel, or DOTS clients supports means to 269 dynamically discover the ports used by their DOTS servers. In order 270 to use a distinct port number (vs. TBD), DOTS clients and servers 271 should support a configurable parameter to supply the port number to 272 use. The rationale for not using the default port number 5684 273 ((D)TLS CoAP) is to allow for differentiated behaviors in deployment 274 contexts where both a DOTS gateway and an IoT gateway (e.g., Figure 3 275 of [RFC7452]) are present. 277 The signal channel is initiated by the DOTS client (Section 4.4). 278 Once the signal channel is established, the DOTS agents periodically 279 send heartbeats to keep the channel active (Section 4.7). At any 280 time, the DOTS client may send a mitigation request message to a DOTS 281 server over the active channel. While mitigation is active, due to 282 the higher likelihood of packet loss during a DDoS attack, the DOTS 283 server periodically sends status messages to the client, including 284 basic mitigation feedback details. Mitigation remains active until 285 the DOTS client explicitly terminates mitigation, or the mitigation 286 lifetime expires. 288 DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS 289 [RFC5246] over TCP. Likewise, DOTS requests may be sent using IPv4 290 or IPv6 transfer capabilities. A Happy Eyeballs procedure for DOTS 291 signal channel is specified in Section 4.3. 293 Messages exchanged between DOTS agents are serialized using Concise 294 Binary Object Representation (CBOR) [RFC7049], CBOR is a binary 295 encoding designed for small code and message size. CBOR encoded 296 payloads are used to convey signal channel specific payload messages 297 that convey request parameters and response information such as 298 errors. This specification uses the encoding rules defined in 299 [I-D.ietf-core-yang-cbor] for representing mitigation scope and DOTS 300 signal channel session configuration data defined using YANG 301 (Section 5) as CBOR data. 303 In order to prevent fragmentation, DOTS agents must follow the 304 recommendations in Section 4.6 of [RFC7252]. Refer to Section 7.3 305 for more details. 307 DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The 308 payload included in CoAP responses with 2.xx and 3.xx Response Codes 309 MUST be of content type "application/cbor" (Section 5.5.1 of 310 [RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes 311 MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The 312 Diagnostic Payload may contain additional information to aid 313 troubleshooting. 315 In deployments where multiple DOTS clients are enabled in a network 316 (owned by the same entity), the DOTS server may detect conflicting 317 mitigation requests from these clients. This document does not aim 318 to specify a comprehensive list of conditions under which a DOTS 319 server will characterize two mitigation requests from distinct DOTS 320 clients as conflicting, nor recommend a DOTS server behavior for 321 processing conflicting mitigation requests. Those considerations are 322 implementation- and deployment-specific. Nevertheless, the document 323 specifies the mechanisms to notify DOTS clients when conflicts occur, 324 including the conflict cause (Section 4.4). 326 4. DOTS Signal Channel: Messages & Behaviors 328 4.1. DOTS Server(s) Discovery 330 This document assumes that DOTS clients are provisioned with the 331 reachability information of their DOTS server(s) using a variety of 332 means (e.g., local configuration, or dynamic means such as DHCP). 333 These means are out of scope of this document. 335 Likewise, it is out of scope of this document to specify the behavior 336 to follow by a DOTS client to place its requests (e.g., contact all 337 servers, select one server among the list) when multiple DOTS servers 338 are provisioned. 340 4.2. CoAP URIs 342 The DOTS server MUST support the use of the path-prefix of "/.well- 343 known/" as defined in [RFC5785] and the registered name of "dots". 344 Each DOTS operation is indicated by a path-suffix that indicates the 345 intended operation. The operation path (Table 1) is appended to the 346 path-prefix to form the URI used with a CoAP request to perform the 347 desired DOTS operation. 349 +-----------------------+----------------+-------------+ 350 | Operation | Operation path | Details | 351 +-----------------------+----------------+-------------+ 352 | Mitigation | /v1/mitigate | Section 4.4 | 353 +-----------------------+----------------+-------------+ 354 | Session configuration | /v1/config | Section 4.5 | 355 +-----------------------+----------------+-------------+ 357 Table 1: Operations and their corresponding URIs 359 4.3. Happy Eyeballs for DOTS Signal Channel 361 DOTS signaling can happen with DTLS over UDP and TLS over TCP. A 362 DOTS client can use DNS to determine the IP address(es) of a DOTS 363 server or a DOTS client may be provided with the list of DOTS server 364 IP addresses. The DOTS client MUST know a DOTS server's domain name; 365 hard-coding the domain name of the DOTS server into software is NOT 366 RECOMMENDED in case the domain name is not valid or needs to change 367 for legal or other reasons. The DOTS client performs A and/or AAAA 368 record lookup of the domain name and the result will be a list of IP 369 addresses, each of which can be used to contact the DOTS server using 370 UDP and TCP. 372 If an IPv4 path to reach a DOTS server is found, but the DOTS 373 server's IPv6 path is not working, a dual-stack DOTS client can 374 experience a significant connection delay compared to an IPv4-only 375 DOTS client. The other problem is that if a middlebox between the 376 DOTS client and DOTS server is configured to block UDP, the DOTS 377 client will fail to establish a DTLS session with the DOTS server and 378 will, then, have to fall back to TLS over TCP incurring significant 379 connection delays. [I-D.ietf-dots-requirements] discusses that DOTS 380 agents will have to support both connectionless and connection- 381 oriented protocols. 383 To overcome these connection setup problems, the DOTS client can try 384 connecting to the DOTS server using both IPv6 and IPv4, and try both 385 DTLS over UDP and TLS over TCP in a fashion similar to the Happy 386 Eyeballs mechanism [RFC6555]. These connection attempts are 387 performed by the DOTS client when its initializes, and the client 388 uses that information for its subsequent alert to the DOTS server. 389 In order of preference (most preferred first), it is UDP over IPv6, 390 UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which 391 adheres to address preference order [RFC6724] and the DOTS preference 392 that UDP be used over TCP (to avoid TCP's head of line blocking). 394 DOTS client DOTS server 395 | | 396 |--DTLS ClientHello, IPv6 ---->X | 397 |--TCP SYN, IPv6-------------->X | 398 |--DTLS ClientHello, IPv4 ---->X | 399 |--TCP SYN, IPv4----------------------------------------->| 400 |--DTLS ClientHello, IPv6 ---->X | 401 |--TCP SYN, IPv6-------------->X | 402 |<-TCP SYNACK---------------------------------------------| 403 |--DTLS ClientHello, IPv4 ---->X | 404 |--TCP ACK----------------------------------------------->| 405 |<------------Establish TLS Session---------------------->| 406 |----------------DOTS signal----------------------------->| 407 | | 409 Figure 4: DOTS Happy Eyeballs 411 In reference to Figure 4, the DOTS client sends two TCP SYNs and two 412 DTLS ClientHello messages at the same time over IPv6 and IPv4. In 413 this example, it is assumed that the IPv6 path is broken and UDP is 414 dropped by a middlebox but has little impact to the DOTS client 415 because there is no long delay before using IPv4 and TCP. The DOTS 416 client repeats the mechanism to discover if DOTS signaling with DTLS 417 over UDP becomes available from the DOTS server, so the DOTS client 418 can migrate the DOTS signal channel from TCP to UDP, but such probing 419 SHOULD NOT be done more frequently than every 24 hours and MUST NOT 420 be done more frequently than every 5 minutes. 422 4.4. DOTS Mitigation Methods 424 The following methods are used by a DOTS client to request, withdraw, 425 or retrieve the status of mitigation requests: 427 PUT: DOTS clients use the PUT method to request mitigation from a 428 DOTS server (Section 4.4.1). During active mitigation, DOTS 429 clients may use PUT requests to convey mitigation efficacy 430 updates to the DOTS server (Section 4.4.3). 432 GET: DOTS clients may use the GET method to subscribe to DOTS 433 server status messages, or to retrieve the list of its 434 mitigations maintained by a DOTS server (Section 4.4.2). 436 DELETE: DOTS clients use the DELETE method to withdraw a request for 437 mitigation from a DOTS server (Section 4.4.4). 439 Mitigation request and response messages are marked as Non- 440 confirmable messages (Section 2.2 of [RFC7252]). 442 DOTS agents SHOULD follow the data transmission guidelines discussed 443 in Section 3.1.3 of [RFC8085] and control transmission behavior by 444 not sending on average more than one UDP datagram per RTT to the peer 445 DOTS agent. 447 Requests marked by the DOTS client as Non-confirmable messages are 448 sent at regular intervals until a response is received from the DOTS 449 server. If the DOTS client cannot maintain an RTT estimate, it 450 SHOULD NOT send more than one Non-confirmable request every 3 451 seconds, and SHOULD use an even less aggressive rate when possible 452 (case 2 in Section 3.1.3 of [RFC8085]). 454 4.4.1. Request Mitigation 456 When a DOTS client requires mitigation for any reason, the DOTS 457 client uses CoAP PUT method to send a mitigation request to its DOTS 458 server(s) (Figure 5, illustrated in JSON diagnostic notation). If 459 this DOTS client is entitled to solicit the DOTS service, the DOTS 460 server can enable mitigation on behalf of the DOTS client by 461 communicating the DOTS client's request to the mitigator and relaying 462 selected mitigator feedback to the requesting DOTS client. 464 Header: PUT (Code=0.03) 465 Uri-Host: "host" 466 Uri-Path: ".well-known" 467 Uri-Path: "dots" 468 Uri-Path: "version" 469 Uri-Path: "mitigate" 470 Content-Type: "application/cbor" 471 { 472 "mitigation-scope": { 473 "client-identifier": [ 474 "string" 475 ], 476 "scope": [ 477 { 478 "mitigation-id": integer, 479 "target-ip": [ 480 "string" 481 ], 482 "target-prefix": [ 483 "string" 484 ], 485 "target-port-range": [ 486 { 487 "lower-port": integer, 488 "upper-port": integer 489 } 490 ], 491 "target-protocol": [ 492 integer 493 ], 494 "target-fqdn": [ 495 "string" 496 ], 497 "target-uri": [ 498 "string" 499 ], 500 "alias-name": [ 501 "string" 502 ], 503 "lifetime": integer 504 } 505 ] 506 } 507 } 509 Figure 5: PUT to convey DOTS signals 511 The parameters are described below: 513 client-identifier: The client identifier MAY be conveyed by the DOTS 514 gateway to propagate the DOTS client identity from the gateway's 515 client-side to the gateway's server-side, and from the gateway's 516 server-side to the DOTS server. This allows the final DOTS server 517 to accept mitigation requests with scopes which the DOTS client is 518 authorized to manage. 520 The 'client-identifier' value MUST be assigned by the DOTS gateway 521 in a manner that ensures that there is no probability that the 522 same value will be assigned to a different DOTS client. The DOTS 523 gateway MUST obscure potentially sensitive DOTS client identity 524 information. The client-identifier attribute SHOULD NOT to be 525 generated and included by the DOTS client. 527 This is an optional attribute. 529 mitigation-id: Identifier for the mitigation request represented 530 using an integer. This identifier MUST be unique for each 531 mitigation request bound to the DOTS client, i.e., the mitigation- 532 id parameter value in the mitigation request needs to be unique 533 relative to the mitigation-id parameter values of active 534 mitigation requests conveyed from the DOTS client to the DOTS 535 server. This identifier MUST be generated by the DOTS client. 536 This document does not make any assumption about how this 537 identifier is generated. 539 This is a mandatory attribute. 541 target-ip: A list of IP addresses identifying resources under 542 attack. This is an optional attribute. 544 target-prefix: A list of prefixes identifying resources under 545 attack. Prefixes are represented using Classless Inter-domain 546 Routing (CIDR) notation [RFC4632]. 548 This is an optional attribute. 550 target-port-range: A list of port numbers bound to resources under 551 attack. 553 The port range is defined by two bounds, a lower port number 554 (lower-port) and an upper port number (upper-port). When only 555 'lower-port' is present, it represents a single port number. For 556 TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], 557 or Datagram Congestion Control Protocol (DCCP) [RFC4340], the 558 range of ports can be, for example, 1024-65535. 560 This is an optional attribute. 562 target-protocol: A list of protocols involved in an attack. Values 563 are taken from the IANA protocol registry [proto_numbers]. 565 The value 0 has a special meaning for 'all protocols'. 567 This is an optional attribute. 569 target-fqdn: A list of Fully Qualified Domain Names (FQDNs) 570 identifying resources under attack. An FQDN is the full name of a 571 resource, rather than just its hostname. For example, "venera" is 572 a hostname, and "venera.isi.edu" is an FQDN. 574 This is an optional attribute. 576 target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986] 577 identifying resources under attack. 579 This is an optional attribute. 581 alias-name: A list of aliases of resources for which the mitigation 582 is requested. Aliases can be created using the DOTS data channel 583 (Section 6.1 of [I-D.ietf-dots-data-channel]), direct 584 configuration, or other means. An alias is used in subsequent 585 signal channel exchanges to refer more efficiently to the 586 resources under attack. 588 This is an optional attribute. 590 lifetime: Lifetime of the mitigation request in seconds. The 591 RECOMMENDED lifetime of a mitigation request is 3600 seconds (60 592 minutes) -- this value was chosen to be long enough so that 593 refreshing is not typically a burden on the DOTS client, while 594 expiring the request where the client has unexpectedly quit in a 595 timely manner. DOTS clients MUST include this parameter in their 596 mitigation requests. Upon the expiry of this lifetime, and if the 597 request is not refreshed, the mitigation request is removed. The 598 request can be refreshed by sending the same request again. 600 A lifetime of 0 in a mitigation request is an invalid value. 602 A lifetime of negative one (-1) indicates indefinite lifetime for 603 the mitigation request. The DOTS server MAY refuse indefinite 604 lifetime, for policy reasons; the granted lifetime value is 605 returned in the response. DOTS clients MUST be prepared to not be 606 granted mitigations with indefinite lifetimes. 608 The DOTS server MUST always indicate the actual lifetime in the 609 response and the remaining lifetime in status messages sent to the 610 DOTS client. 612 This is a mandatory attribute. 614 Because of the complexity to handle partial failure cases, this 615 specification does not allow for including multiple mitigation 616 requests in the same PUT request. Concretely, a DOTS client MUST NOT 617 include multiple 'scope' parameters in the same PUT request. 619 The CBOR key values for the parameters are defined in Section 6. 620 Section 9 defines how the CBOR key values can be allocated to 621 standards bodies and vendors. 623 FQDN and URI mitigation scopes may be thought of as a form of scope 624 alias, in which the addresses to which the domain name or URI resolve 625 represent the full scope of the mitigation. 627 In the PUT request at least one of the attributes 'target-ip' or 628 'target-prefix' or 'target-fqdn' or 'target-uri 'or 'alias-name' MUST 629 be present. If the attribute value is empty, then the attribute MUST 630 NOT be present in the request. 632 The relative order of two mitigation requests from a DOTS client is 633 determined by comparing their respective 'mitigation-id' values. If 634 two mitigation requests have overlapping mitigation scopes, the 635 mitigation request with higher numeric 'mitigation-id' value will 636 override the mitigation request with a lower numeric 'mitigation-id' 637 value. Two mitigation-ids from a DOTS client are overlapping if 638 there is a common IP address, IP prefix, FQDN, URI, or alias-name. 639 To avoid maintaining a long list of overlapping mitigation requests 640 from a DOTS client and avoid error-prone provisioning of mitigation 641 requests from a DOTS client, the overlapped lower numeric 642 'mitigation-id' MUST be automatically deleted and no longer available 643 at the DOTS server. 645 The Uri-Path option carries a major and minor version nomenclature to 646 manage versioning and DOTS signal channel in this specification uses 647 v1 major version. 649 Figure 6 shows a PUT request example to signal that ports 80, 8080, 650 and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are 651 being attacked (illustrated in JSON diagnostic notation). 653 Header: PUT (Code=0.03) 654 Uri-Host: "www.example.com" 655 Uri-Path: ".well-known" 656 Uri-Path: "dots" 657 Uri-Path: "v1" 658 Uri-Path: "mitigate" 659 Content-Format: "application/cbor" 660 { 661 "mitigation-scope": { 662 "client-identifier": [ 663 "dz6pHjaADkaFTbjr0JGBpw" 664 ], 665 "scope": [ 666 { 667 "mitigation-id": 12332, 668 "target-ip": [ 669 "2001:db8:6401::1", 670 "2001:db8:6401::2" 671 ], 672 "target-port-range": [ 673 { 674 "lower-port": 80 675 }, 676 { 677 "lower-port": 443 678 }, 679 { 680 "lower-port": 8080 681 } 682 ], 683 "target-protocol": [ 684 6 685 ] 686 } 687 ] 688 } 689 } 691 Figure 6: PUT for DOTS signal 693 The corresponding CBOR encoding format is shown in Figure 7. 695 A1 # map(1) 696 01 # unsigned(1) 697 A2 # map(2) 698 18 20 # unsigned(32) 699 81 # array(1) 700 76 # text(22) 701 647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw" 702 02 # unsigned(2) 703 81 # array(1) 704 A4 # map(4) 705 03 # unsigned(3) 706 19 302C # unsigned(12332) 707 04 # unsigned(4) 708 82 # array(2) 709 70 # text(16) 710 323030313A6462383A363430313A3A31 # "2001:db8:6401::1" 711 70 # text(16) 712 323030313A6462383A363430313A3A32 # "2001:db8:6401::2" 713 05 # unsigned(5) 714 83 # array(3) 715 A1 # map(1) 716 06 # unsigned(6) 717 18 50 # unsigned(80) 718 A1 # map(1) 719 06 # unsigned(6) 720 19 01BB # unsigned(443) 721 A1 # map(1) 722 06 # unsigned(6) 723 19 1F90 # unsigned(8080) 724 08 # unsigned(8) 725 81 # array(1) 726 06 # unsigned(6) 728 Figure 7: PUT for DOTS signal (CBOR) 730 If the DOTS client is using the certificate provisioned by the 731 Enrollment over Secure Transport (EST) server [RFC7030] in the DOTS 732 gateway-domain to authenticate itself to the DOTS gateway, then the 733 'client-identifier' value can be the output of a cryptographic hash 734 algorithm whose input is the DER-encoded ASN.1 representation of the 735 Subject Public Key Info (SPKI) of an X.509 certificate. In this 736 version of the specification, the cryptographic hash algorithm used 737 is SHA-256 [RFC6234]. The output of the cryptographic hash algorithm 738 is truncated to 16 bytes; truncation is done by stripping off the 739 final 16 bytes. The truncated output is base64url encoded. If the 740 'client-identifier' value is already present in the mitigation 741 request received from the DOTS client, the DOTS gateway MAY compute 742 the 'client-identifier' value, as discussed above, and add the 743 computed 'client-identifier' value to the end of the 'client- 744 identifier' list. The DOTS server MUST NOT use the 'client- 745 identifier' for the DOTS client authentication process. 747 In both DOTS signal and data channel sessions, the DOTS client MUST 748 authenticate itself to the DOTS server (Section 8). The DOTS server 749 may use the algorithm in Section 7 of [RFC7589] to derive the DOTS 750 client identity or username from the client certificate. The DOTS 751 client identity allows the DOTS server to accept mitigation requests 752 with scopes which the DOTS client is authorized to manage. The DOTS 753 server couples the DOTS signal and data channel sessions using the 754 DOTS client identity and the 'client-identifier' parameter value, so 755 the DOTS server can validate whether the aliases conveyed in the 756 mitigation request were indeed created by the same DOTS client using 757 the DOTS data channel session. If the aliases were not created by 758 the DOTS client, the DOTS server returns 4.00 (Bad Request) in the 759 response. 761 The DOTS server couples the DOTS signal channel sessions using the 762 DOTS client identity and the 'client-identifier' parameter value, and 763 the DOTS server uses 'mitigation-id' parameter value to detect 764 duplicate mitigation requests. If the mitigation request contains 765 both alias-name and other parameters identifying the target resources 766 (such as, 'target-ip', 'target-prefix', 'target-port-range', 'target- 767 fqdn', or 'target-uri'), then the DOTS server appends the parameter 768 values in 'alias-name' with the corresponding parameter values in 769 'target-ip', 'target-prefix', 'target-port-range', 'target-fqdn', or 770 'target-uri'. 772 The DOTS server indicates the result of processing the PUT request 773 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 774 codes are some sort of invalid requests (client errors). COAP 5.xx 775 codes are returned if the DOTS server has erred or is currently 776 unavailable to provide mitigation in response to the mitigation 777 request from the DOTS client. 779 Figure 8 shows an example of a PUT request that is successfully 780 processed (i.e., CoAP 2.xx response codes). 782 { 783 "mitigation-scope": { 784 "client-identifier": [ 785 "string" 786 ], 787 "scope": [ 788 { 789 "mitigation-id": integer, 790 "lifetime": integer 791 } 792 ] 793 } 794 } 796 Figure 8: 2.xx response body 798 If the request is missing one or more mandatory attributes, includes 799 multiple 'scope' parameters, or contains invalid or unknown 800 parameters, the DOTS server replies with 4.00 (Bad Request). DOTS 801 agents can safely ignore Vendor-Specific parameters they don't 802 understand. 804 A DOTS server that receives a mitigation request with a lifetime set 805 to 0 MUST reply with a 4.00 (Bad Request). 807 If the DOTS server does not find the 'mitigation-id' parameter value 808 conveyed in the PUT request in its configuration data, it MAY accept 809 the mitigation request by sending back a 2.01 (Created) response to 810 the DOTS client; the DOTS server will consequently try to mitigate 811 the attack. 813 If the DOTS server finds the 'mitigation-id' parameter value conveyed 814 in the PUT request in its configuration data, it MAY update the 815 mitigation request, and a 2.04 (Changed) response is returned to 816 indicate a successful update of the mitigation request. 818 If the request is conflicting with an existing mitigation request 819 from a different DOTS client, and the DOTS server decides to maintain 820 the conflicting mitigation request, the DOTS server returns 4.09 821 (Conflict) [RFC8132] to the requesting DOTS client. The response 822 includes enough information for a DOTS client to recognize the source 823 of the conflict (refer to 'conflict-information' specified in 824 Section 4.4.2). 826 For a mitigation request to continue beyond the initial negotiated 827 lifetime, the DOTS client has to refresh the current mitigation 828 request by sending a new PUT request. This PUT request MUST use the 829 same 'mitigation-id' value, and MUST repeat all the other parameters 830 as sent in the original mitigation request apart from a possible 831 change to the lifetime parameter value. 833 A DOTS gateway MUST update the 'client-identifier' list in the 834 response to remove the 'client-identifier' value it had added in the 835 corresponding request before forwarding the response to the DOTS 836 client. 838 4.4.2. Retrieve Information Related to a Mitigation 840 A GET request is used to retrieve information (including status) of a 841 DOTS mitigation from a DOTS server. If the DOTS server does not find 842 the 'mitigation-id' parameter value conveyed in the GET request in 843 its configuration data, it responds with a 4.04 (Not Found) error 844 response code. 846 The 'c' (content) parameter and its permitted values defined in 847 [I-D.ietf-core-comi] can be used to retrieve non-configuration data 848 (attack mitigation status) or configuration data or both. The DOTS 849 server SHOULD support this optional filtering capability but can 850 safely ignore it if not supported. 852 The following examples illustrate how a DOTS client retrieves active 853 mitigation requests from a DOTS server. In particular: 855 o Figure 9 shows the example of a GET request to retrieve all DOTS 856 mitigation requests signaled by a DOTS client. 858 o Figure 10 shows the example of a GET request to retrieve a 859 specific DOTS mitigation request signaled by a DOTS client. The 860 configuration data to be reported in the response is formatted in 861 the same order it was processed at the DOTS server. 863 These two examples assume the default of "c=a"; that is the DOTS 864 client asks for all data to be reported by the DOTS server. 866 Header: GET (Code=0.01) 867 Uri-Host: "host" 868 Uri-Path: ".well-known" 869 Uri-Path: "dots" 870 Uri-Path: "version" 871 Uri-Path: "mitigate" 872 Observe : 0 873 { 874 "mitigation-scope": { 875 "client-identifier": [ 876 "string" 877 ] 878 } 879 } 881 Figure 9: GET to retrieve all DOTS mitigation requests 883 Header: GET (Code=0.01) 884 Uri-Host: "host" 885 Uri-Path: ".well-known" 886 Uri-Path: "dots" 887 Uri-Path: "version" 888 Uri-Path: "mitigate" 889 Observe : 0 890 Content-Format: "application/cbor" 891 { 892 "mitigation-scope": { 893 "client-identifier": [ 894 "string" 895 ], 896 "scope": [ 897 { 898 "mitigation-id": integer 899 } 900 ] 901 } 902 } 904 Figure 10: GET to retrieve a specific DOTS mitigation request 906 Figure 11 shows a response example of all active mitigation requests 907 associated with the DOTS client on the DOTS server and the mitigation 908 status of each mitigation request. 910 { 911 "mitigation-scope": { 912 "scope": [ 913 { 914 "mitigation-id": 12332, 915 "mitigation-start": 1507818434.00, 916 "target-protocol": [ 917 17 918 ], 919 "lifetime":1800, 920 "status":2, 921 "bytes-dropped": 134334555, 922 "bps-dropped": 43344, 923 "pkts-dropped": 333334444, 924 "pps-dropped": 432432 925 }, 926 { 927 "mitigation-id": 12333, 928 "mitigation-start": 1507818393.00, 929 "target-protocol": [ 930 6 931 ], 932 "lifetime":1800, 933 "status":3 934 "bytes-dropped": 0, 935 "bps-dropped": 0, 936 "pkts-dropped": 0, 937 "pps-dropped": 0 938 } 939 ] 940 } 941 } 943 Figure 11: Response body 945 The mitigation status parameters are described below: 947 mitigation-start: Mitigation start time is represented in seconds 948 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 949 [RFC7049]). The encoding is modified so that the leading tag 1 950 (epoch-based date/time) MUST be omitted. 952 lifetime: The remaining lifetime of the mitigation request, in 953 seconds. 955 status: Status of attack mitigation. The 'status' parameter is a 956 mandatory attribute. The various possible values of 'status' 957 parameter are explained in Table 2. 959 conflict-information: Indicates that a mitigation request is 960 conflicting with another mitigation request(s) from other DOTS 961 client(s). This optional attribute has the following structure: 963 conflict-status: Indicates the status of a conflicting mitigation 964 request. The following values are defined: 966 1: DOTS server has detected conflicting mitigation requests 967 from different DOTS clients. This mitigation request is 968 currently inactive until the conflicts are resolved. 969 Another mitigation request is active. 971 2: DOTS server has detected conflicting mitigation requests 972 from different DOTS clients. This mitigation request is 973 currently active. 975 3: DOTS server has detected conflicting mitigation requests 976 from different DOTS clients. All conflicting mitigation 977 requests are inactive. 979 conflict-cause: Indicates the cause of the conflict. The 980 following values are defined: 982 1: Overlapping targets. 'conflict-scope' provides more details 983 about the conflicting target clauses. 985 2: Conflicts with an existing white list. This code is 986 returned when the DDoS mitigation detects source addresses/ 987 prefixes in the white-listed ACLs are attacking the target. 989 conflict-scope Indicates the conflict scope. It may include a 990 list of IP addresses, a list of prefixes, a list of port 991 numbers, a list of target protocols, a list of FQDNs, a list of 992 URIs, a list of alias-names, or references to conflicting ACLs. 994 retry-timer Indicates, in seconds, the time upon which the DOTS 995 client may re-issue the same request. The DOTS server returns 996 'retry-timer' only to DOTS client(s) for which a mitigation 997 request is deactivated. Any retransmission of the same 998 mitigation request before the expiry of this timer is likely to 999 be rejected by the DOTS server for the same reasons. 1001 The retry-timer SHOULD be equal to the lifetime of the active 1002 mitigation request resulting in the deactivation of the 1003 conflicting mitigation request. The lifetime of the 1004 deactivated mitigation request will be updated to (retry-timer 1005 + 45 seconds), so the DOTS client can refresh the deactivated 1006 mitigation request after retry-timer seconds before expiry of 1007 lifetime and check if the conflict is resolved. 1009 bytes-dropped: The total dropped byte count for the mitigation 1010 request since the attack mitigation is triggered. The count wraps 1011 around when it reaches the maximum value of unsigned integer. 1012 This is an optional attribute. 1014 bps-dropped: The average dropped bytes per second for the mitigation 1015 request since the attack mitigation is triggered. This SHOULD be 1016 a five-minute average. This is an optional attribute. 1018 pkts-dropped: The total dropped packet count for the mitigation 1019 request since the attack mitigation is triggered. This is an 1020 optional attribute. 1022 pps-dropped: The average dropped packets per second for the 1023 mitigation request since the attack mitigation is triggered. This 1024 SHOULD be a five-minute average. This is an optional attribute. 1026 +-----------+-------------------------------------------------------+ 1027 | Parameter | Description | 1028 | value | | 1029 +-----------+-------------------------------------------------------+ 1030 | 1 | Attack mitigation is in progress (e.g., changing the | 1031 | | network path to re-route the inbound traffic to DOTS | 1032 | | mitigator). | 1033 +-----------+-------------------------------------------------------+ 1034 | 2 | Attack is successfully mitigated (e.g., traffic is | 1035 | | redirected to a DDOS mitigator and attack traffic is | 1036 | | dropped). | 1037 +-----------+-------------------------------------------------------+ 1038 | 3 | Attack has stopped and the DOTS client can withdraw | 1039 | | the mitigation request. | 1040 +-----------+-------------------------------------------------------+ 1041 | 4 | Attack has exceeded the mitigation provider | 1042 | | capability. | 1043 +-----------+-------------------------------------------------------+ 1044 | 5 | DOTS client has withdrawn the mitigation request and | 1045 | | the mitigation is active but terminating. | 1046 +-----------+-------------------------------------------------------+ 1047 | 6 | Attack mitigation is now terminated. | 1048 +-----------+-------------------------------------------------------+ 1049 | 7 | Attack mitigation is withdrawn. | 1050 +-----------+-------------------------------------------------------+ 1051 | 8 | Attack mitigation is rejected. | 1052 +-----------+-------------------------------------------------------+ 1054 Table 2: Values of 'status' parameter 1056 The observe option defined in [RFC7641] extends the CoAP core 1057 protocol with a mechanism for a CoAP client to "observe" a resource 1058 on a CoAP server: the client retrieves a representation of the 1059 resource and requests this representation be updated by the server as 1060 long as the client is interested in the resource. A DOTS client 1061 conveys the observe option set to '0' in the GET request to receive 1062 unsolicited notifications of attack mitigation status from the DOTS 1063 server. Unidirectional notifications within the bidirectional signal 1064 channel allows unsolicited message delivery, enabling asynchronous 1065 notifications between the agents. Due to the higher likelihood of 1066 packet loss during a DDoS attack, DOTS server periodically sends 1067 attack mitigation status to the DOTS client and also notifies the 1068 DOTS client whenever the status of the attack mitigation changes. If 1069 the DOTS server cannot maintain a RTT estimate, it SHOULD NOT send 1070 more than one unsolicited notification every 3 seconds, and SHOULD 1071 use an even less aggressive rate when possible (case 2 in 1072 Section 3.1.3 of [RFC8085]). 1074 When conflicting requests are detected, the DOTS server enforces the 1075 corresponding policy (e.g. accept all requests, reject all requests, 1076 accept only one request but reject all the others, ...). It is 1077 assumed that this policy is supplied by the DOTS server administrator 1078 or it is a default behavior of the DOTS server implementation. Then, 1079 the DOTS server sends notification message(s) to the DOTS client(s) 1080 at the origin of the conflict. A conflict notification message 1081 includes information about the conflict cause, scope, and the status 1082 of the mitigation request(s). For example, 1084 o A notification message with status code set to '8 (Attack 1085 mitigation is rejected)' and 'conflict-status' set to '1' is sent 1086 to a DOTS client to indicate that this mitigation request is 1087 rejected because a conflict is detected. 1089 o A notification message with status code set to '7 (Attack 1090 mitigation is withdrawn)' and 'conflict-status' set to '1' is sent 1091 to a DOTS client to indicate that an active mitigation request is 1092 deactivated because a conflict is detected. 1094 o A notification message with status code set to '1 (Attack 1095 mitigation is in progress)' and 'conflict-status' set to 2 is sent 1096 to a DOTS client to indicate that this mitigation request is in 1097 progress, but a conflict is detected. 1099 Upon receipt of a conflict notification message indicating that a 1100 mitigation request is deactivated because of a conflict, a DOTS 1101 client MUST NOT resend the same mitigation request before the expiry 1102 of 'retry-timer'. It is also recommended that DOTS clients support 1103 means to alert administrators about mitigation conflicts. 1105 A DOTS client that is no longer interested in receiving notifications 1106 from the DOTS server can simply "forget" the observation. When the 1107 DOTS server then sends the next notification, the DOTS client will 1108 not recognize the token in the message and thus will return a Reset 1109 message. This causes the DOTS server to remove the associated entry. 1110 Alternatively, the DOTS client can explicitly deregister by issuing a 1111 GET request that has the Token field set to the token of the 1112 observation to be cancelled and includes an Observe Option with the 1113 value set to '1' (deregister). 1115 Figure 12 shows an example of a DOTS client requesting a DOTS server 1116 to send notifications related a given mitigation request. 1118 DOTS Client DOTS Server 1119 | | 1120 | GET / | 1121 | Token: 0x4a | Registration 1122 | Observe: 0 | 1123 +------------------------------>| 1124 | | 1125 | 2.05 Content | 1126 | Token: 0x4a | Notification of 1127 | Observe: 12 | the current state 1128 | status: "mitigation | 1129 | in progress" | 1130 |<------------------------------+ 1131 | 2.05 Content | 1132 | Token: 0x4a | Notification upon 1133 | Observe: 44 | a state change 1134 | status: "mitigation | 1135 | complete" | 1136 |<------------------------------+ 1137 | 2.05 Content | 1138 | Token: 0x4a | Notification upon 1139 | Observe: 60 | a state change 1140 | status: "attack stopped" | 1141 |<------------------------------+ 1142 | | 1144 Figure 12: Notifications of attack mitigation status 1146 4.4.2.1. Mitigation Status 1148 The DOTS client can send the GET request at frequent intervals 1149 without the Observe option to retrieve the configuration data of the 1150 mitigation request and non-configuration data (i.e., the attack 1151 status). The frequency of polling the DOTS server to get the 1152 mitigation status should follow the transmission guidelines given in 1153 Section 3.1.3 of [RFC8085]. If the DOTS server has been able to 1154 mitigate the attack and the attack has stopped, the DOTS server 1155 indicates as such in the status, and the DOTS client recalls the 1156 mitigation request by issuing a DELETE request for the mitigation-id. 1158 A DOTS client SHOULD react to the status of the attack from the DOTS 1159 server and not the fact that it has recognized, using its own means, 1160 that the attack has been mitigated. This ensures that the DOTS 1161 client does not recall a mitigation request in a premature fashion 1162 because it is possible that the DOTS client does not sense the DDOS 1163 attack on its resources but the DOTS server could be actively 1164 mitigating the attack and the attack is not completely averted. 1166 4.4.3. Efficacy Update from DOTS Clients 1168 While DDoS mitigation is active, due to the likelihood of packet 1169 loss, a DOTS client MAY periodically transmit DOTS mitigation 1170 efficacy updates to the relevant DOTS server. A PUT request is used 1171 to convey the mitigation efficacy update to the DOTS server. 1173 The PUT request MUST include all the parameters used in the PUT 1174 request to convey the DOTS signal (Section 4.4.1) unchanged apart 1175 from the lifetime parameter value. If this is not the case, the DOTS 1176 server MUST reject the request with a 4.00 (Bad Request). 1178 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1179 value is used to make the PUT request conditional on the current 1180 existence of the mitigation request. If UDP is used as transport, 1181 CoAP requests may arrive out-of-order. For example, the DOTS client 1182 may send a PUT request to convey an efficacy update to the DOTS 1183 server followed by a DELETE request to withdraw the mitigation 1184 request, but the DELETE request arrives at the DOTS server before the 1185 PUT request. To handle out-of-order delivery of requests, if an If- 1186 Match option is present in the PUT request and the 'mitigation-id' in 1187 the request matches a mitigation request from that DOTS client, then 1188 the request is processed. If no match is found, the PUT request is 1189 silently ignored. 1191 An example of an efficacy update message, which includes an If-Match 1192 option with an empty value, is depicted in Figure 13. 1194 Header: PUT (Code=0.03) 1195 Uri-Host: "host" 1196 Uri-Path: ".well-known" 1197 Uri-Path: "dots" 1198 Uri-Path: "version" 1199 Uri-Path: "mitigate" 1200 Content-Format: "application/cbor" 1201 If-Match: 1202 { 1203 "mitigation-scope": { 1204 "client-identifier": [ 1205 "string" 1206 ], 1207 "scope": [ 1208 { 1209 "mitigation-id": integer, 1210 "target-ip": [ 1211 "string" 1212 ], 1213 "target-port-range": [ 1214 { 1215 "lower-port": integer, 1216 "upper-port": integer 1217 } 1218 ], 1219 "target-protocol": [ 1220 integer 1221 ], 1222 "target-fqdn": [ 1223 "string" 1224 ], 1225 "target-uri": [ 1226 "string" 1227 ], 1228 "alias-name": [ 1229 "string" 1230 ], 1231 "lifetime": integer, 1232 "attack-status": integer 1233 } 1234 ] 1235 } 1236 } 1238 Figure 13: Efficacy Update 1240 The 'attack-status' parameter is a mandatory attribute when doing an 1241 efficacy update. The various possible values contained in the 1242 'attack-status' parameter are described in Table 3. 1244 +-----------+-------------------------------------------------------+ 1245 | Parameter | Description | 1246 | value | | 1247 +-----------+-------------------------------------------------------+ 1248 | 1 | The DOTS client determines that it is still under | 1249 | | attack. | 1250 +-----------+-------------------------------------------------------+ 1251 | 2 | The DOTS client determines that the attack is | 1252 | | successfully mitigated (e.g., attack traffic is not | 1253 | | seen). | 1254 +-----------+-------------------------------------------------------+ 1256 Table 3: Values of 'attack-status' parameter 1258 The DOTS server indicates the result of processing a PUT request 1259 using CoAP response codes. The response code 2.04 (Changed) is 1260 returned if the DOTS server has accepted the mitigation efficacy 1261 update. The error response code 5.03 (Service Unavailable) is 1262 returned if the DOTS server has erred or is incapable of performing 1263 the mitigation. 1265 4.4.4. Withdraw a Mitigation 1267 A DELETE request is used to withdraw a DOTS mitigation request from a 1268 DOTS server (Figure 14). 1270 Header: DELETE (Code=0.04) 1271 Uri-Host: "host" 1272 Uri-Path: ".well-known" 1273 Uri-Path: "dots" 1274 Uri-Path: "version" 1275 Uri-Path: "mitigate" 1276 Content-Format: "application/cbor" 1277 { 1278 "mitigation-scope": { 1279 "client-identifier": [ 1280 "string" 1281 ], 1282 "scope": [ 1283 { 1284 "mitigation-id": integer 1285 } 1286 ] 1287 } 1288 } 1290 Figure 14: Withdraw DOTS signal 1292 If the request does not include a 'mitigation-id', the DOTS server 1293 MUST reply with a 4.00 (Bad Request). 1295 Once the request is validated, the DOTS server immediately 1296 acknowledges a DOTS client's request to withdraw the DOTS signal 1297 using 2.02 (Deleted) response code with no response payload. A 2.02 1298 (Deleted) Response Code is returned even if the 'mitigation-id' 1299 parameter value conveyed in the DELETE request does not exist in its 1300 configuration data before the request. 1302 If the DOTS server finds the 'mitigation-id' parameter value conveyed 1303 in the DELETE request in its configuration data, then to protect 1304 against route or DNS flapping caused by a DOTS client rapidly 1305 toggling mitigation, and to dampen the effect of oscillating attacks, 1306 the DOTS server MAY allow mitigation to continue for a limited period 1307 after acknowledging a DOTS client's withdrawal of a mitigation 1308 request. During this period, the DOTS server status messages SHOULD 1309 indicate that mitigation is active but terminating (Section 4.4.2). 1311 The initial active-but-terminating period SHOULD be sufficiently long 1312 to absorb latency incurred by route propagation. The active-but- 1313 terminating period SHOULD be set by default to 120 seconds. If the 1314 client requests mitigation again before the initial active-but- 1315 terminating period elapses, the DOTS server MAY exponentially 1316 increase the active-but- terminating period up to a maximum of 300 1317 seconds (5 minutes). 1319 After the active-but-terminating period elapses, the DOTS server MUST 1320 treat the mitigation as terminated, as the DOTS client is no longer 1321 responsible for the mitigation. For example, if there is a financial 1322 relationship between the DOTS client and server domains, the DOTS 1323 client ceases incurring cost at this point. 1325 4.5. DOTS Signal Channel Session Configuration 1327 The DOTS client can negotiate, configure, and retrieve the DOTS 1328 signal channel session behavior. The DOTS signal channel can be 1329 used, for example, to configure the following: 1331 a. Heartbeat interval: DOTS agents regularly send heartbeats (CoAP 1332 Ping/Pong) to each other after mutual authentication in order to 1333 keep the DOTS signal channel open, heartbeat messages are 1334 exchanged between the DOTS agents every heartbeat-interval 1335 seconds to detect the current status of the DOTS signal channel 1336 session. 1338 b. Missing heartbeats allowed: This variable indicates the maximum 1339 number of consecutive heartbeat messages for which a DOTS agent 1340 did not receive a response before concluding that the session is 1341 disconnected or defunct. 1343 c. Acceptable signal loss ratio: Maximum retransmissions, 1344 retransmission timeout value and other message transmission 1345 parameters for the DOTS signal channel. 1347 Reliability is provided to requests and responses by marking them as 1348 Confirmable (CON) messages. DOTS signal channel session 1349 configuration requests and responses are marked as Confirmable 1350 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1351 message is retransmitted using a default timeout and exponential 1352 back-off between retransmissions, until the DOTS server sends an 1353 Acknowledgement message (ACK) with the same Message ID conveyed from 1354 the DOTS client. Message transmission parameters are defined in 1355 Section 4.8 of [RFC7252]. The DOTS server can either piggyback the 1356 response in the acknowledgement message or if the DOTS server is not 1357 able to respond immediately to a request carried in a Confirmable 1358 message, it simply responds with an Empty Acknowledgement message so 1359 that the DOTS client can stop retransmitting the request. Empty 1360 Acknowledgement message is explained in Section 2.2 of [RFC7252]. 1361 When the response is ready, the server sends it in a new Confirmable 1362 message which then in turn needs to be acknowledged by the DOTS 1363 client (see Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and 1364 responses exchanged between DOTS agents during peacetime are marked 1365 as Confirmable messages. 1367 Implementation Note: A DOTS client that receives a response in a 1368 CON message may want to clean up the message state right after 1369 sending the ACK. If that ACK is lost and the DOTS server 1370 retransmits the CON, the DOTS client may no longer have any state 1371 to which to correlate this response, making the retransmission an 1372 unexpected message; the DOTS client will send a Reset message so 1373 it does not receive any more retransmissions. This behavior is 1374 normal and not an indication of an error (see Section 5.3.2 of 1375 [RFC7252] for more details). 1377 4.5.1. Discover Configuration Parameters 1379 A GET request is used to obtain acceptable and current configuration 1380 parameters on the DOTS server for DOTS signal channel session 1381 configuration. Figure 15 shows how to obtain acceptable 1382 configuration parameters for the DOTS server. 1384 Header: GET (Code=0.01) 1385 Uri-Host: "host" 1386 Uri-Path: ".well-known" 1387 Uri-Path: "dots" 1388 Uri-Path: "version" 1389 Uri-Path: "config" 1391 Figure 15: GET to retrieve configuration 1393 The DOTS server in the 2.05 (Content) response conveys the current, 1394 minimum and maximum attribute values acceptable by the DOTS server. 1396 Content-Format: "application/cbor" 1397 { 1398 "heartbeat-interval": { 1399 "current-value": integer, 1400 "min-value": integer, 1401 "max-value" : integer, 1402 }, 1403 "missing-hb-allowed": { 1404 "current-value": integer, 1405 "min-value": integer, 1406 "max-value" : integer, 1407 }, 1408 "max-retransmit": { 1409 "current-value": integer, 1410 "min-value": integer, 1411 "max-value" : integer, 1412 }, 1413 "ack-timeout": { 1414 "current-value": integer, 1415 "min-value": integer, 1416 "max-value" : integer, 1417 }, 1418 "ack-random-factor": { 1419 "current-value": number, 1420 "min-value": number, 1421 "max-value" : number, 1422 }, 1423 "trigger-mitigation": { 1424 "current-value": boolean, 1425 } 1426 } 1428 Figure 16: GET response body 1430 Figure 17 shows an example of acceptable and current configuration 1431 parameters on the DOTS server for DOTS signal channel session 1432 configuration. 1434 Content-Format: "application/cbor" 1435 { 1436 "heartbeat-interval": { 1437 "current-value": 30, 1438 "min-value": 15, 1439 "max-value" : 240, 1440 }, 1441 "missing-hb-allowed": { 1442 "current-value": 5, 1443 "min-value": 3, 1444 "max-value" : 9, 1445 }, 1446 "max-retransmit": { 1447 "current-value": 3, 1448 "min-value": 2, 1449 "max-value" : 15, 1450 }, 1451 "ack-timeout": { 1452 "current-value": 2, 1453 "min-value": 1, 1454 "max-value" : 30, 1455 }, 1456 "ack-random-factor": { 1457 "current-value": 1.5, 1458 "min-value": 1.1, 1459 "max-value" : 4.0, 1460 }, 1461 "trigger-mitigation": { 1462 "current-value": true, 1463 } 1464 } 1466 Figure 17: Configuration response body 1468 4.5.2. Convey DOTS Signal Channel Session Configuration 1470 A PUT request is used to convey the configuration parameters for the 1471 signal channel (e.g., heartbeat interval, maximum retransmissions). 1472 Message transmission parameters for CoAP are defined in Section 4.8 1473 of [RFC7252]. The RECOMMENDED values of transmission parameter 1474 values are ack-timeout (2 seconds), max-retransmit (3), ack-random- 1475 factor (1.5). In addition to those parameters, the RECOMMENDED 1476 specific DOTS transmission parameter values are heartbeat-interval 1477 (30 seconds) and missing-hb-allowed (5). 1479 Note: heartbeat-interval should be tweaked to also assist DOTS 1480 messages for NAT traversal (SIG-010 of 1481 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 1482 messages must not be sent more frequently than once every 15 1483 seconds and should use longer intervals when possible. 1484 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 1485 minutes or longer, but experience shows that sending packets every 1486 15 to 30 seconds is necessary to prevent the majority of 1487 middleboxes from losing state for UDP flows. From that 1488 standpoint, this specification recommends a minimum heartbeat- 1489 interval of 15 seconds and a maximum heartbeat-interval of 240 1490 seconds. The recommended value of 30 seconds is selected to 1491 anticipate the expiry of NAT state. 1493 A heartbeat-interval of 30 second may be seen as too chatty in 1494 some deployments. For such deployments, DOTS agents may negotiate 1495 longer heartbeat-interval values to avoid overloading the network 1496 with too frequent keepalives. 1498 When a confirmable "CoAP Ping" is sent, and if there is no response, 1499 the "CoAP Ping" is retransmitted max-retransmit number of times by 1500 the CoAP layer using an initial timeout set to a random duration 1501 between ack-timeout and (ack-timeout*ack-random-factor) and 1502 exponential back-off between retransmissions. By choosing the 1503 recommended transmission parameters, the "CoAP Ping" will timeout 1504 after 45 seconds. If the DOTS agent does not receive any response 1505 from the peer DOTS agent for missing-hb-allowed number of consecutive 1506 "CoAP Ping" confirmable messages, it concludes that the DOTS signal 1507 channel session is disconnected. A DOTS client MUST NOT transmit a 1508 "CoAP Ping" while waiting for the previous "CoAP Ping" response from 1509 the same DOTS server. 1511 If the DOTS agent wishes to change the default values of message 1512 transmission parameters, then it should follow the guidance given in 1513 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 1514 values for message transmission parameters and default values for 1515 non-negotiated message transmission parameters. 1517 The signal channel session configuration is applicable to a single 1518 DOTS signal channel session between the DOTS agents. 1520 Header: PUT (Code=0.03) 1521 Uri-Host: "host" 1522 Uri-Path: ".well-known" 1523 Uri-Path: "dots" 1524 Uri-Path: "version" 1525 Uri-Path: "config" 1526 Content-Format: "application/cbor" 1527 { 1528 "signal-config": { 1529 "session-id": integer, 1530 "heartbeat-interval": integer, 1531 "missing-hb-allowed": integer, 1532 "max-retransmit": integer, 1533 "ack-timeout": integer, 1534 "ack-random-factor": number 1535 "trigger-mitigation": boolean 1536 } 1537 } 1539 Figure 18: PUT to convey the DOTS signal channel session 1540 configuration data. 1542 The parameters are described below: 1544 session-id: Identifier for the DOTS signal channel session 1545 configuration data represented as an integer. This identifier 1546 MUST be generated by the DOTS client. This document does not make 1547 any assumption about how this identifier is generated. 1549 This is a mandatory attribute. 1551 heartbeat-interval: Time interval in seconds between two 1552 consecutive heartbeat messages. 1554 This is an optional attribute. 1556 missing-hb-allowed: Maximum number of consecutive heartbeat 1557 messages for which the DOTS agent did not receive a response 1558 before concluding that the session is disconnected. 1560 This is an optional attribute. 1562 max-retransmit: Maximum number of retransmissions for a message 1563 (referred to as MAX_RETRANSMIT parameter in CoAP). 1565 This is an optional attribute. 1567 ack-timeout: Timeout value in seconds used to calculate the initial 1568 retransmission timeout value (referred to as ACK_TIMEOUT parameter 1569 in CoAP). 1571 This is an optional attribute. 1573 ack-random-factor: Random factor used to influence the timing of 1574 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1575 CoAP). 1577 This is an optional attribute. 1579 trigger-mitigation: If the parameter value is set to 'false', then 1580 DDoS mitigation is triggered only when the DOTS signal channel 1581 session is lost. Automated mitigation on loss of signal is 1582 discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. 1584 If the DOTS client ceases to respond to heartbeat messages, the 1585 DOTS server can detect that the DOTS session is lost. 1587 The default value of the parameter is 'true'. 1589 This is an optional attribute. 1591 In the PUT request at least one of the attributes 'heartbeat- 1592 interval', 'missing-hb-allowed', 'max-retransmit', 'ack-timeout', 1593 'ack-random-factor', and 'trigger-mitigation' MUST be present. The 1594 PUT request with higher numeric 'session-id' value over-rides the 1595 DOTS signal channel session configuration data installed by a PUT 1596 request with a lower numeric 'session-id' value. 1598 Figure 19 shows a PUT request example to convey the configuration 1599 parameters for the DOTS signal channel. 1601 Header: PUT (Code=0.03) 1602 Uri-Host: "www.example.com" 1603 Uri-Path: ".well-known" 1604 Uri-Path: "dots" 1605 Uri-Path: "v1" 1606 Uri-Path: "config" 1607 Content-Format: "application/cbor" 1608 { 1609 "signal-config": { 1610 "session-id": 1234534333242, 1611 "heartbeat-interval": 91, 1612 "missing-hb-allowed": 3, 1613 "max-retransmit": 7, 1614 "ack-timeout": 5, 1615 "ack-random-factor": 1.5, 1616 "trigger-mitigation": false 1617 } 1618 } 1620 Figure 19: PUT to convey the configuration parameters 1622 The DOTS server indicates the result of processing the PUT request 1623 using CoAP response codes: 1625 o If the DOTS server finds the 'session-id' parameter value conveyed 1626 in the PUT request in its configuration data and if the DOTS 1627 server has accepted the updated configuration parameters, then 1628 2.04 (Changed) code is returned in the response. 1630 o If the DOTS server does not find the 'session-id' parameter value 1631 conveyed in the PUT request in its configuration data and if the 1632 DOTS server has accepted the configuration parameters, then a 1633 response code 2.01 (Created) is returned in the response. 1635 o If the request is missing one or more mandatory attributes or it 1636 contains one or more invalid or unknown parameters, then 4.00 (Bad 1637 Request) is returned in the response. 1639 o Response code 4.22 (Unprocessable Entity) is returned in the 1640 response, if any of the 'heartbeat-interval', 'missing-hb- 1641 allowed', 'max-retransmit', 'target-protocol', 'ack-timeout', and 1642 'ack-random-factor' attribute values are not acceptable to the 1643 DOTS server. Upon receipt of the 4.22 error response code, the 1644 DOTS client should request the maximum and minimum attribute 1645 values acceptable to the DOTS server (Section 4.5.1). 1647 The DOTS client may re-try and send the PUT request with updated 1648 attribute values acceptable to the DOTS server. 1650 4.5.3. Delete DOTS Signal Channel Session Configuration 1652 A DELETE request is used to delete the installed DOTS signal channel 1653 session configuration data (Figure 20). 1655 Header: DELETE (Code=0.04) 1656 Uri-Host: "host" 1657 Uri-Path: ".well-known" 1658 Uri-Path: "dots" 1659 Uri-Path: "version" 1660 Uri-Path: "config" 1661 Content-Format: "application/cbor" 1663 Figure 20: DELETE configuration 1665 The DOTS server resets the DOTS signal channel session configuration 1666 back to the default values and acknowledges a DOTS client's request 1667 to remove the DOTS signal channel session configuration using 2.02 1668 (Deleted) response code. 1670 4.6. Redirected Signaling 1672 Redirected DOTS signaling is discussed in detail in Section 3.2.2 of 1673 [I-D.ietf-dots-architecture]. 1675 If a DOTS server wants to redirect a DOTS client to an alternative 1676 DOTS server for a signal session, then the response code 3.00 1677 (alternate server) will be returned in the response to the client. 1679 The DOTS server can return the error response code 3.00 in response 1680 to a PUT request from the DOTS client or convey the error response 1681 code 3.00 in a unidirectional notification response from the DOTS 1682 server. 1684 The DOTS server in the error response conveys the alternate DOTS 1685 server's FQDN, and the alternate DOTS server IP address(es) and time 1686 to live values in the CBOR body. 1688 { 1689 "alt-server": "string", 1690 "alt-server-record": [ 1691 { 1692 "addr": "string", 1693 "ttl" : integer, 1694 } 1695 ] 1696 } 1698 Figure 21: Error response body 1700 The parameters are described below: 1702 alt-server: FQDN of an alternate DOTS server. 1704 addr: IP address of an alternate DOTS server. 1706 ttl: Time to live (TTL) represented as an integer number of seconds. 1708 Figure 22 shows a 3.00 response example to convey the DOTS alternate 1709 server 'alt-server.example', its IP addresses 2001:db8:6401::1 and 1710 2001:db8:6401::2, and TTL values 3600 and 1800. 1712 { 1713 "alt-server": "alt-server.example", 1714 "alt-server-record": [ 1715 { 1716 "ttl" : 3600, 1717 "addr": "2001:db8:6401::1" 1718 }, 1719 { 1720 "ttl" : 1800, 1721 "addr": "2001:db8:6401::2" 1722 } 1723 ] 1724 } 1726 Figure 22: Example of error response body 1728 When the DOTS client receives 3.00 response, it considers the current 1729 request as having failed, but SHOULD try the request with the 1730 alternate DOTS server. During a DDOS attack, the DNS server may be 1731 subjected to DDOS attack, alternate DOTS server IP addresses conveyed 1732 in the 3.00 response help the DOTS client to skip DNS lookup of the 1733 alternate DOTS server and can try to establish UDP or TCP session 1734 with the alternate DOTS server IP addresses. The DOTS client SHOULD 1735 implement DNS64 function to handle the scenario where IPv6-only DOTS 1736 client communicates with IPv4-only alternate DOTS server. 1738 4.7. Heartbeat Mechanism 1740 To provide a metric of signal health and distinguish an 'idle' signal 1741 channel from a 'disconnected' or 'defunct' session, the DOTS agent 1742 sends a heartbeat over the signal channel to maintain its half of the 1743 channel. The DOTS agent similarly expects a heartbeat from its peer 1744 DOTS agent, and may consider a session terminated in the extended 1745 absence of a peer agent heartbeat. 1747 While the communication between the DOTS agents is quiescent, the 1748 DOTS client will probe the DOTS server to ensure it has maintained 1749 cryptographic state and vice versa. Such probes can also keep alive 1750 firewall and/or NAT bindings. This probing reduces the frequency of 1751 establishing a new handshake when a DOTS signal needs to be conveyed 1752 to the DOTS server. 1754 In case of a volumetric DDoS attack saturating the incoming link to 1755 the DOTS client, all traffic from the DOTS server to the DOTS client 1756 will likely be dropped, although the DOTS server receives heartbeat 1757 requests and DOTS messages from the DOTS client. In this scenario, 1758 the DOTS agents MUST behave differently to handle message 1759 transmission and DOTS session liveliness during link saturation: 1761 o The DOTS client MUST NOT consider the DOTS session terminated even 1762 after maximum 'missing-hb-allowed' threshold is reached. The DOTS 1763 client SHOULD continue to use the current DOTS session, and send 1764 heartbeat requests over the current DOTS session, so the DOTS 1765 server knows the DOTS client has not disconnected the DOTS 1766 session. 1768 After the maximum 'missing-hb-allowed' threshold is reached, the 1769 DOTS client SHOULD try (D)TLS session resumption. The DOTS client 1770 SHOULD send mitigation requests over the current DOTS session, and 1771 in parallel, try (D)TLS session resumption or 0-RTT mode in DTLS 1772 1.3 to piggyback the mitigation request in the ClientHello 1773 message. 1775 Once the link is no longer saturated, if traffic from the DOTS 1776 server reaches the DOTS client over the current DOTS session, the 1777 DOTS client can stop (D)TLS session resumption or if (D)TLS 1778 session resumption is successful then disconnect the current DOTS 1779 session. 1781 o If the DOTS server does not receive any traffic from the peer DOTS 1782 client, then the DOTS server sends heartbeat requests to the DOTS 1783 client and after maximum 'missing-hb-allowed' threshold is 1784 reached, the DOTS server concludes the session is disconnected. 1786 In DOTS over UDP, heartbeat messages may be exchanged between the 1787 DOTS agents using the "COAP Ping" mechanism defined in Section 4.2 of 1788 [RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable 1789 message and the peer DOTS agent will respond by sending an Reset 1790 message. 1792 In DOTS over TCP, heartbeat messages can be exchanged between the 1793 DOTS agents using the Ping and Pong messages specified in Section 4.4 1794 of [I-D.ietf-core-coap-tcp-tls]. That is, the DOTS agent sends a 1795 Ping message and the peer DOTS agent would respond by sending a 1796 single Pong message. 1798 5. DOTS Signal Channel YANG Module 1800 This document defines a YANG [RFC7950] module for mitigation scope 1801 and DOTS signal channel session configuration data. 1803 5.1. Tree Structure 1805 This document defines the YANG module "ietf-dots-signal" 1806 (Section 5.2), which has the following tree structure. A DOTS signal 1807 message can either be a mitigation or a configuration message. 1809 module: ietf-dots-signal 1810 +--rw dots-signal 1811 +--rw (message-type)? 1812 +--:(mitigation-scope) 1813 | +--rw client-identifier* binary 1814 | +--rw scope* [mitigation-id] 1815 | +--rw mitigation-id int32 1816 | +--rw target-ip* inet:ip-address 1817 | +--rw target-prefix* inet:ip-prefix 1818 | +--rw target-port-range* [lower-port upper-port] 1819 | | +--rw lower-port inet:port-number 1820 | | +--rw upper-port inet:port-number 1821 | +--rw target-protocol* uint8 1822 | +--rw target-fqdn* inet:domain-name 1823 | +--rw target-uri* inet:uri 1824 | +--rw alias-name* string 1825 | +--rw lifetime? int32 1826 | +--rw mitigation-start? int64 1827 | +--ro status? enumeration 1828 | +--ro conflict-information 1829 | | +--ro conflict-status? enumeration 1830 | | +--ro conflict-cause? enumeration 1831 | | +--ro retry-timer? int32 1832 | | +--ro conflict-scope 1833 | | +--ro target-ip* inet:ip-address 1834 | | +--ro target-prefix* inet:ip-prefix 1835 | | +--ro target-port-range* [lower-port upper-port] 1836 | | | +--ro lower-port inet:port-number 1837 | | | +--ro upper-port inet:port-number 1838 | | +--ro target-protocol* uint8 1839 | | +--ro target-fqdn* inet:domain-name 1840 | | +--ro target-uri* inet:uri 1841 | | +--ro alias-name* string 1842 | | +--ro acl-list* [name type] 1843 | | +--ro name -> /ietf-acl:access-lists/acl/acl-name 1844 | | +--ro type -> /ietf-acl:access-lists/acl/acl-type 1845 | +--ro pkts-dropped? yang:zero-based-counter64 1846 | +--ro bps-dropped? yang:zero-based-counter64 1847 | +--ro bytes-dropped? yang:zero-based-counter64 1848 | +--ro pps-dropped? yang:zero-based-counter64 1849 +--:(configuration) 1850 +--rw session-id int32 1851 +--rw heartbeat-interval? int16 1852 +--rw missing-hb-allowed? int16 1853 +--rw max-retransmit? int16 1854 +--rw ack-timeout? int16 1855 +--rw ack-random-factor? decimal64 1856 +--rw trigger-mitigation? boolean 1858 5.2. YANG Module 1860 file "ietf-dots-signal@2017-12-07.yang" 1862 module ietf-dots-signal { 1863 yang-version 1.1; 1864 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; 1865 prefix "signal"; 1867 import ietf-inet-types {prefix "inet";} 1868 import ietf-yang-types {prefix yang;} 1869 import ietf-access-control-list {prefix "ietf-acl";} 1871 organization "IETF DOTS Working Group"; 1873 contact 1874 "Konda, Tirumaleswar Reddy 1875 Mohamed Boucadair 1876 Prashanth Patil 1877 Andrew Mortensen 1878 Nik Teague "; 1880 description 1881 "This module contains YANG definition for the signaling 1882 messages exchanged between the DOTS client to the DOTS server. 1884 Copyright (c) 2017 IETF Trust and the persons identified as 1885 authors of the code. All rights reserved. 1887 Redistribution and use in source and binary forms, with or 1888 without modification, is permitted pursuant to, and subject 1889 to the license terms contained in, the Simplified BSD License 1890 set forth in Section 4.c of the IETF Trust's Legal Provisions 1891 Relating to IETF Documents 1892 (http://trustee.ietf.org/license-info). 1894 This version of this YANG module is part of RFC XXXX; see 1895 the RFC itself for full legal notices."; 1897 revision 2017-12-07 { 1898 description 1899 "Initial revision."; 1900 reference 1901 "RFC XXXX: Distributed Denial-of-Service Open Threat 1902 Signaling (DOTS) Signal Channel"; 1903 } 1905 grouping target { 1906 description 1907 "Specifies the scope of the mitigation request."; 1909 leaf-list target-ip { 1910 type inet:ip-address; 1911 description 1912 "IPv4 or IPv6 address identifying the target."; 1913 } 1915 leaf-list target-prefix { 1916 type inet:ip-prefix; 1917 description 1918 "IPv4 or IPv6 prefix identifying the target."; 1919 } 1921 list target-port-range { 1922 key "lower-port upper-port"; 1924 description 1925 "Port range. When only lower-port is 1926 present, it represents a single port."; 1928 leaf lower-port { 1929 type inet:port-number; 1930 mandatory true; 1931 description "Lower port number."; 1932 } 1934 leaf upper-port { 1935 type inet:port-number; 1936 must ". >= ../lower-port" { 1937 error-message 1938 "The upper port number must be greater than 1939 or equal to lower port number."; 1940 } 1941 description "Upper port number."; 1942 } 1943 } 1945 leaf-list target-protocol { 1946 type uint8; 1947 description 1948 "Identifies the target protocol number. 1950 The value '0' means 'all protocols'. 1952 Values are taken from the IANA protocol registry: 1953 https://www.iana.org/assignments/protocol-numbers/ 1954 protocol-numbers.xhtml 1956 For example, 6 for a TCP or 17 for UDP."; 1957 } 1959 leaf-list target-fqdn { 1960 type inet:domain-name; 1961 description "FQDN identifying the target."; 1962 } 1964 leaf-list target-uri { 1965 type inet:uri; 1966 description "URI identifying the target."; 1967 } 1969 leaf-list alias-name { 1970 type string; 1971 description "alias name"; 1972 } 1973 } 1975 grouping mitigation-scope { 1976 description 1977 "Specifies the scope of the mitigation request."; 1979 leaf-list client-identifier { 1980 type binary; 1981 description 1982 "The client identifier may be conveyed by 1983 the DOTS gateway to propagate the DOTS client 1984 identity from the gateway's client-side to the 1985 gateway's server-side, and from the gateway's 1986 server-side to the DOTS server. 1988 It allows the final DOTS server to accept 1989 mitigation requests with scopes which the DOTS 1990 client is authorized to manage."; 1991 } 1993 list scope { 1994 key mitigation-id; 1995 description 1996 "The scope of the request."; 1998 leaf mitigation-id { 1999 type int32; 2000 description 2001 "Mitigation request identifier. 2003 This identifier must be unique for each mitigation 2004 request bound to the DOTS client."; 2005 } 2007 uses target; 2009 leaf lifetime { 2010 type int32; 2011 units "seconds"; 2012 default 3600; 2013 description 2014 "Indicates the lifetime of the mitigation request."; 2015 reference 2016 "RFC XXXX: Distributed Denial-of-Service Open Threat 2017 Signaling (DOTS) Signal Channel"; 2018 } 2020 leaf mitigation-start { 2021 type int64; 2022 units "seconds"; 2023 description 2024 "Mitigation start time is represented in seconds 2025 relative to 1970-01-01T00:00Z in UTC time."; 2026 } 2028 leaf status { 2029 type enumeration { 2030 enum "1" { 2031 description 2032 "Attack mitigation is in progress (e.g., changing 2033 the network path to re-route the inbound traffic 2034 to DOTS mitigator)."; 2035 } 2037 enum "2" { 2038 description 2039 "Attack is successfully mitigated (e.g., traffic 2040 is redirected to a DDOS mitigator and attack 2041 traffic is dropped)."; 2042 } 2044 enum "3" { 2045 description 2046 "Attack has stopped and the DOTS client can 2047 withdraw the mitigation request."; 2048 } 2049 enum "4" { 2050 description 2051 "Attack has exceeded the mitigation provider 2052 capability."; 2053 } 2055 enum "5" { 2056 description 2057 "DOTS client has withdrawn the mitigation 2058 request and the mitigation is active but 2059 terminating."; 2060 } 2062 enum "6" { 2063 description 2064 "Attack mitigation is now terminated."; 2065 } 2067 enum "7" { 2068 description 2069 "Attack mitigation is withdrawn."; 2070 } 2072 enum "8" { 2073 description 2074 "Attack mitigation is rejected."; 2075 } 2076 } 2077 config false; 2078 description 2079 "Indicates the status of a mitigation request. 2080 It must be included in responses, only."; 2081 } 2083 container conflict-information { 2084 config false; 2085 description 2086 "Indicates that a conflict is detected. 2087 Must only be used for responses."; 2089 leaf conflict-status { 2090 type enumeration { 2091 enum "1" { 2092 description 2093 "DOTS Server has detected conflicting mitigation 2094 requests from different DOTS clients. 2095 This mitigation request is currently inactive 2096 until the conflicts are resolved. Another 2097 mitigation request is active."; 2098 } 2100 enum "2" { 2101 description 2102 "DOTS Server has detected conflicting mitigation 2103 requests from different DOTS clients. 2104 This mitigation request is currently active."; 2105 } 2107 enum "3" { 2108 description 2109 "DOTS Server has detected conflicting mitigation 2110 requests from different DOTS clients. All 2111 conflicting mitigation requests are inactive."; 2112 } 2113 } 2114 description 2115 "Indicates the conflict status. 2116 It must be included in responses, only."; 2117 } 2119 leaf conflict-cause { 2120 type enumeration { 2121 enum "1" { 2122 description 2123 "Overlapping targets. conflict-scope provides 2124 more details about the exact conflict."; 2125 } 2127 enum "2" { 2128 description 2129 "Conflicts with an existing white list. 2131 This code is returned when the DDoS mitigation 2132 detects source addresses/prefixes in the 2133 white-listed ACLs are attacking the target."; 2134 } 2135 } 2136 description 2137 "Indicates the cause of the conflict. 2138 It must be included in responses, only."; 2139 } 2141 leaf retry-timer { 2142 type int32; 2143 units "seconds"; 2144 description 2145 "The DOTS client must not re-send the 2146 same request before the expiry of this timer. 2147 It must be included in responses, only."; 2148 } 2150 container conflict-scope { 2151 description 2152 "Provides more information about the conflict scope."; 2154 uses target { 2155 when "../conflict-cause = '1'"; 2156 } 2158 list acl-list { 2159 when "../../conflict-cause = '2'"; 2160 key "name type"; 2161 description 2162 "List of conflicting ACLs"; 2164 leaf name { 2165 type leafref { 2166 path "/ietf-acl:access-lists/ietf-acl:acl" + 2167 "/ietf-acl:acl-name"; 2168 } 2169 description 2170 "Reference to the conflicting ACL name bound to 2171 a DOTS client."; 2172 } 2174 leaf type { 2175 type leafref { 2176 path "/ietf-acl:access-lists/ietf-acl:acl" + 2177 "/ietf-acl:acl-type"; 2178 } 2179 description 2180 "Reference to the conflicting ACL type bound to 2181 a DOTS client."; 2182 } 2183 } 2184 } 2185 } 2187 leaf pkts-dropped { 2188 type yang:zero-based-counter64; 2189 config false; 2190 description 2191 "Number of dropped packets"; 2192 } 2193 leaf bps-dropped { 2194 type yang:zero-based-counter64; 2195 config false; 2196 description 2197 "The average dropped bytes per second for 2198 the mitigation request since the attack 2199 mitigation is triggered."; 2200 } 2202 leaf bytes-dropped { 2203 type yang:zero-based-counter64; 2204 units 'bytes'; 2205 config false; 2206 description 2207 "Counter for dropped packets; in bytes."; 2208 } 2210 leaf pps-dropped { 2211 type yang:zero-based-counter64; 2212 config false; 2213 description 2214 "The average dropped packets per second 2215 for the mitigation request since the attack 2216 mitigation is triggered."; 2217 } 2218 } 2219 } 2221 grouping signal-config { 2222 description 2223 "DOTS signal channel session configuration."; 2225 leaf session-id { 2226 type int32; 2227 mandatory true; 2228 description 2229 "An identifier for the DOTS signal channel 2230 session configuration data."; 2231 } 2233 leaf heartbeat-interval { 2234 type int16; 2235 units "seconds"; 2236 default 30; 2237 description 2238 "DOTS agents regularly send heartbeats to each other 2239 after mutual authentication in order to keep 2240 the DOTS signal channel open."; 2242 reference 2243 "RFC XXXX: Distributed Denial-of-Service Open Threat 2244 Signaling (DOTS) Signal Channel"; 2245 } 2247 leaf missing-hb-allowed { 2248 type int16; 2249 default 5; 2250 description 2251 "Maximum number of missing heartbeats allowed."; 2252 reference 2253 "RFC XXXX: Distributed Denial-of-Service Open Threat 2254 Signaling (DOTS) Signal Channel"; 2255 } 2257 leaf max-retransmit { 2258 type int16; 2259 default 3; 2260 description 2261 "Maximum number of retransmissions of a 2262 Confirmable message."; 2263 reference 2264 "RFC XXXX: Distributed Denial-of-Service Open Threat 2265 Signaling (DOTS) Signal Channel"; 2266 } 2268 leaf ack-timeout { 2269 type int16; 2270 units "seconds"; 2271 default 2; 2272 description 2273 "Initial retransmission timeout value."; 2274 reference 2275 "Section 4.8 of RFC 7552."; 2276 } 2278 leaf ack-random-factor { 2279 type decimal64 { 2280 fraction-digits 2; 2281 } 2282 default 1.5; 2283 description 2284 "Random factor used to influence the timing of 2285 retransmissions."; 2286 reference 2287 "Section 4.8 of RFC 7552."; 2288 } 2289 leaf trigger-mitigation { 2290 type boolean; 2291 default true; 2292 description 2293 "If false, then mitigation is triggered 2294 only when the DOTS server channel session is lost"; 2295 reference 2296 "RFC XXXX: Distributed Denial-of-Service Open Threat 2297 Signaling (DOTS) Signal Channel"; 2298 } 2299 } 2301 container dots-signal { 2302 description 2303 "Main contaner for DOTS signal message. 2304 A DOTS signal message can be a mitigation messages or 2305 a configuration message."; 2307 choice message-type { 2308 description 2309 "Either a mitigation or a configuration message."; 2311 case mitigation-scope { 2312 description 2313 "Mitigation scope of a mitigation message."; 2314 uses mitigation-scope; 2315 } 2317 case configuration { 2318 description 2319 "Configuration message."; 2320 uses signal-config; 2321 } 2322 } 2323 } 2324 } 2325 2327 6. Mapping Parameters to CBOR 2329 All parameters in the payload in the DOTS signal channel MUST be 2330 mapped to CBOR types as shown in Table 4 and are given an integer key 2331 to save space. The recipient of the payload MAY reject the 2332 information if it is not suitably mapped. 2334 /----------------------+----------------+--------------------------\ 2335 | Parameter name | CBOR key | CBOR major type of value | 2336 +----------------------+----------------+--------------------------+ 2337 | mitigation-scope | 1 | 5 (map) | 2338 | scope | 2 | 5 (map) | 2339 | mitigation-id | 3 | 0 (unsigned) | 2340 | target-ip | 4 | 4 (array) | 2341 | target-port-range | 5 | 4 | 2342 | lower-port | 6 | 0 | 2343 | upper-port | 7 | 0 | 2344 | target-protocol | 8 | 4 | 2345 | target-fqdn | 9 | 4 | 2346 | target-uri | 10 | 4 | 2347 | alias-name | 11 | 4 | 2348 | lifetime | 12 | 0 | 2349 | attack-status | 13 | 0 | 2350 | signal-config | 14 | 5 | 2351 | heartbeat-interval | 15 | 0 | 2352 | max-retransmit | 16 | 0 | 2353 | ack-timeout | 17 | 0 | 2354 | ack-random-factor | 18 | 7 | 2355 | min-value | 19 | 0 | 2356 | max-value | 20 | 0 | 2357 | status | 21 | 0 | 2358 | conflict-information | 22 | 5 (map) | 2359 | conflict-status | 23 | 0 | 2360 | conflict-cause | 24 | 0 | 2361 | retry-timer | 25 | 0 | 2362 | bytes-dropped | 26 | 0 | 2363 | bps-dropped | 27 | 0 | 2364 | pkts-dropped | 28 | 0 | 2365 | pps-dropped | 29 | 0 | 2366 | session-id | 30 | 0 | 2367 | trigger-mitigation | 31 | 7 (simple types) | 2368 | missing-hb-allowed | 32 | 0 | 2369 | current-value | 33 | 0 | 2370 | mitigation-start | 34 | 7 (floating-point) | 2371 | target-prefix | 35 | 4 (array) | 2372 | client-identifier | 36 | 2 (byte string) | 2373 | alt-server | 37 | 2 | 2374 | alt-server-record | 38 | 4 | 2375 | addr | 39 | 2 | 2376 | ttl | 40 | 0 | 2377 | conflict-scope | 41 | 5 (map) | 2378 \----------------------+----------------+--------------------------/ 2379 Table 4: CBOR mappings used in DOTS signal channel message 2381 7. (D)TLS Protocol Profile and Performance Considerations 2383 7.1. (D)TLS Protocol Profile 2385 This section defines the (D)TLS protocol profile of DOTS signal 2386 channel over (D)TLS and DOTS data channel over TLS. 2388 There are known attacks on (D)TLS, such as machine-in-the-middle and 2389 protocol downgrade. These are general attacks on (D)TLS and not 2390 specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for 2391 discussion of these security issues. DOTS agents MUST adhere to the 2392 (D)TLS implementation recommendations and security considerations of 2393 [RFC7525] except with respect to (D)TLS version. Since encryption of 2394 DOTS using (D)TLS is virtually a green-field deployment DOTS agents 2395 MUST implement only (D)TLS 1.2 or later. 2397 When a DOTS client is configured with a domain name of the DOTS 2398 server, and connects to its configured DOTS server, the server may 2399 present it with a PKIX certificate. In order to ensure proper 2400 authentication, DOTS client MUST verify the entire certification path 2401 per [RFC5280]. The DOTS client additionally uses [RFC6125] 2402 validation techniques to compare the domain name to the certificate 2403 provided. 2405 A key challenge to deploying DOTS is provisioning DOTS clients, 2406 including the distribution of keying material to DOTS clients to make 2407 possible the required mutual authentication of DOTS agents. EST 2408 defines a method of certificate enrollment by which domains operating 2409 DOTS servers may provision DOTS clients with all necessary 2410 cryptographic keying material, including a private key and 2411 certificate with which to authenticate itself. One deployment option 2412 is DOTS clients to behave as EST clients for certificate enrollment 2413 from an EST server provisioned by the mitigation provider. This 2414 document does not specify which EST mechanism the DOTS client uses to 2415 achieve initial enrollment. 2417 Implementations compliant with this profile MUST implement all of the 2418 following items: 2420 o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect 2421 against replay attacks. 2423 o (D)TLS session resumption without server-side state [RFC5077] to 2424 resume session and convey the DOTS signal. 2426 o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduce 2427 the size of the ServerHello, and can be used by DOTS agents that 2428 cannot obtain certificates (e.g., DOTS clients and DOTS gateways 2429 on private networks). 2431 Implementations compliant with this profile SHOULD implement all of 2432 the following items to reduce the delay required to deliver a DOTS 2433 signal: 2435 o TLS False Start [RFC7918] which reduces round-trips by allowing 2436 the TLS second flight of messages (ChangeCipherSpec) to also 2437 contain the DOTS signal. 2439 o Cached Information Extension [RFC7924] which avoids transmitting 2440 the server's certificate and certificate chain if the client has 2441 cached that information from a previous TLS handshake. 2443 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 2444 convey DOTS signal. 2446 7.2. (D)TLS 1.3 Considerations 2448 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 2449 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 2450 [I-D.ietf-tls-dtls13] is based on the TLS 1.3 protocol and provides 2451 equivalent security guarantees. (D)TLS 1.3 provides two basic 2452 handshake modes of interest to DOTS signal channel: 2454 o Absent packet loss, a full handshake in which the DOTS client is 2455 able to send the DOTS signal message after one round trip and the 2456 DOTS server immediately after receiving the first DOTS signal 2457 message from the client. 2459 o 0-RTT mode in which the DOTS client can authenticate itself and 2460 send DOTS signal message on its first flight, thus reducing 2461 handshake latency. 0-RTT only works if the DOTS client has 2462 previously communicated with that DOTS server, which is very 2463 likely with the DOTS signal channel. 2465 The DOTS client SHOULD establish a (D)TLS session with the DOTS 2466 server during peacetime and share a PSK. 2468 During DDOS attack, the DOTS client can use the (D)TLS session to 2469 convey the DOTS signal message and if there is no response from 2470 the server after multiple re-tries, then the DOTS client can 2471 resume the (D)TLS session in 0-RTT mode using PSK. 2473 A simplified TLS 1.3 handshake with 0-RTT DOTS signal message 2474 exchange is shown in Figure 23. 2476 DOTS Client DOTS Server 2478 ClientHello 2479 (Finished) 2480 (0-RTT DOTS signal message) 2481 (end_of_early_data) --------> 2482 ServerHello 2483 {EncryptedExtensions} 2484 {ServerConfiguration} 2485 {Certificate} 2486 {CertificateVerify} 2487 {Finished} 2488 <-------- [DOTS signal message] 2489 {Finished} --------> 2491 [DOTS signal message] <-------> [DOTS signal message] 2493 Figure 23: TLS 1.3 handshake with 0-RTT 2495 7.3. MTU and Fragmentation 2497 To avoid DOTS signal message fragmentation and the consequently 2498 decreased probability of message delivery, DOTS agents MUST ensure 2499 that the DTLS record MUST fit within a single datagram. If the path 2500 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 2501 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 2502 is used to convey the DOTS signal messages then the DOTS client must 2503 consider the amount of record expansion expected by the DTLS 2504 processing when calculating the size of CoAP message that fits within 2505 the path MTU. Path MTU MUST be greater than or equal to [CoAP 2506 message size + DTLS overhead of 13 octets + authentication overhead 2507 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 2508 of [RFC6347]). If the request size exceeds the path MTU then the 2509 DOTS client MUST split the DOTS signal into separate messages, for 2510 example the list of addresses in the 'target-ip' parameter could be 2511 split into multiple lists and each list conveyed in a new PUT 2512 request. 2514 Implementation Note: DOTS choice of message size parameters works 2515 well with IPv6 and with most of today's IPv4 paths. However, with 2516 IPv4, it is harder to absolutely ensure that there is no IP 2517 fragmentation. If IPv4 support on unusual networks is a 2518 consideration and path MTU is unknown, implementations may want to 2519 limit themselves to more conservative IPv4 datagram sizes such as 576 2520 bytes, as per [RFC0791] IP packets up to 576 bytes should never need 2521 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal 2522 over a UDP datagram will generally avoid IP fragmentation. 2524 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 2526 (D)TLS based on client certificate can be used for mutual 2527 authentication between DOTS agents. If a DOTS gateway is involved, 2528 DOTS clients and DOTS gateway MUST perform mutual authentication; 2529 only authorized DOTS clients are allowed to send DOTS signals to a 2530 DOTS gateway. DOTS gateway and DOTS server MUST perform mutual 2531 authentication; DOTS server only allows DOTS signals from authorized 2532 DOTS gateway, creating a two-link chain of transitive authentication 2533 between the DOTS client and the DOTS server. 2535 +-----------------------------------------------+ 2536 | example.com domain +---------+ | 2537 | | AAA | | 2538 | +---------------+ | Server | | 2539 | | Application | +------+--+ | 2540 | | server +<-----------------+ ^ | 2541 | | (DOTS client) | | | | 2542 | +---------------+ | | | 2543 | V V | example.net domain 2544 | +-----+----+--+ | +---------------+ 2545 | +--------------+ | | | | | 2546 | | Guest +<-----x----->+ DOTS +<------>+ DOTS | 2547 | | (DOTS client)| | Gateway | | | Server | 2548 | +--------------+ | | | | | 2549 | +----+--------+ | +---------------+ 2550 | ^ | 2551 | | | 2552 | +----------------+ | | 2553 | | DDOS detector | | | 2554 | | (DOTS client) +<---------------+ | 2555 | +----------------+ | 2556 +-----------------------------------------------+ 2558 Figure 24: Example of Authentication and Authorization of DOTS Agents 2560 In the example depicted in Figure 24, the DOTS gateway and DOTS 2561 clients within the 'example.com' domain mutually authenticate with 2562 each other. After the DOTS gateway validates the identity of a DOTS 2563 client, it communicates with the AAA server in the 'example.com' 2564 domain to determine if the DOTS client is authorized to request DDOS 2565 mitigation. If the DOTS client is not authorized, a 4.01 2566 (Unauthorized) is returned in the response to the DOTS client. In 2567 this example, the DOTS gateway only allows the application server and 2568 DDOS detector to request DDOS mitigation, but does not permit the 2569 user of type 'guest' to request DDOS mitigation. 2571 Also, DOTS gateway and DOTS server located in different domains MUST 2572 perform mutual authentication (e.g., using certificates). A DOTS 2573 server will only allow a DOTS gateway with a certificate for a 2574 particular domain to request mitigation for that domain. In 2575 reference to Figure 24, the DOTS server only allows the DOTS gateway 2576 to request mitigation for 'example.com' domain and not for other 2577 domains. 2579 9. IANA Considerations 2581 This specification registers a service port (Section 9.1), an URI 2582 suffix in the Well-Known URIs registry (Section 9.2), a CoAP response 2583 code (Section 9.3), a YANG module (Section 9.5). It also creates a 2584 registry for mappings to CBOR (Section 9.4). 2586 9.1. DOTS Signal Channel UDP and TCP Port Number 2588 IANA is requested to assign the port number TBD to the DOTS signal 2589 channel protocol for both UDP and TCP from the "Service Name and 2590 Transport Protocol Port Number Registry" available at 2591 https://www.iana.org/assignments/service-names-port-numbers/service- 2592 names-port-numbers.xhtml. 2594 It is strongly suggested that the port number 4646 is to be assigned. 2595 4646 is the ASCII decimal value for ".." (DOTS). 2597 9.2. Well-Known 'dots' URI 2599 This document requests IANA to register the 'dots' well-known URI in 2600 the Well-Known URIs registry (https://www.iana.org/assignments/well- 2601 known-uris/well-known-uris.xhtml) as defined by [RFC5785]. 2603 URI suffix: dots 2605 Change controller: IETF 2607 Specification document(s): This RFC 2609 Related information: None 2611 9.3. CoAP Response Code 2613 IANA is requested to add the following entry to the "CoAP Response 2614 Codes" sub-registry available at https://www.iana.org/assignments/ 2615 core-parameters/core-parameters.xhtml#response-codes: 2617 +------+------------------+-----------+ 2618 | Code | Description | Reference | 2619 +------+------------------+-----------+ 2620 | 3.00 | Alternate server | [RFCXXXX] | 2621 +------+------------------+-----------+ 2623 Table 4: CoAP Response Code 2625 9.4. DOTS Signal Channel CBOR Mappings Registry 2627 The document requests IANA to create a new registry, entitled "DOTS 2628 Signal Channel CBOR Mappings Registry". The structure of this 2629 registry is provided in Section 9.4.1. 2631 The registry is initially populated with the values in Section 9.4.2. 2633 Values from that registry MUST be assigned via Expert Review 2634 [RFC8126]. 2636 9.4.1. Registration Template 2638 Parameter name: 2639 Parameter name as used in the DOTS signal channel. 2641 CBOR Key Value: 2642 Key value for the parameter. The key value MUST be an integer in 2643 the range of 1 to 65536. The key values in the range of 32768 to 2644 65536 are assigned for Vendor-Specific parameters. 2646 CBOR Major Type: 2647 CBOR Major type and optional tag for the claim. 2649 Change Controller: 2650 For Standards Track RFCs, list the "IESG". For others, give the 2651 name of the responsible party. Other details (e.g., postal 2652 address, email address, home page URI) may also be included. 2654 Specification Document(s): 2655 Reference to the document or documents that specify the parameter, 2656 preferably including URIs that can be used to retrieve copies of 2657 the documents. An indication of the relevant sections may also be 2658 included but is not required. 2660 9.4.2. Initial Registry Contents 2662 o Parameter Name: mitigation-scope 2663 o CBOR Key Value: 1 2664 o CBOR Major Type: 5 2665 o Change Controller: IESG 2666 o Specification Document(s): this document 2668 o Parameter Name: scope 2669 o CBOR Key Value: 2 2670 o CBOR Major Type: 5 2671 o Change Controller: IESG 2672 o Specification Document(s): this document 2674 o Parameter Name: mitigation-id 2675 o CBOR Key Value: 3 2676 o CBOR Major Type: 0 2677 o Change Controller: IESG 2678 o Specification Document(s): this document 2680 o Parameter Name: target-ip 2681 o CBOR Key Value: 4 2682 o CBOR Major Type: 4 2683 o Change Controller: IESG 2684 o Specification Document(s): this document 2686 o Parameter Name: target-port-range 2687 o CBOR Key Value: 5 2688 o CBOR Major Type: 4 2689 o Change Controller: IESG 2690 o Specification Document(s): this document 2692 o Parameter Name: lower-port 2693 o CBOR Key Value: 6 2694 o CBOR Major Type: 0 2695 o Change Controller: IESG 2696 o Specification Document(s): this document 2698 o Parameter Name: upper-port 2699 o CBOR Key Value: 7 2700 o CBOR Major Type: 0 2701 o Change Controller: IESG 2702 o Specification Document(s): this document 2704 o Parameter Name: target-protocol 2705 o CBOR Key Value: 8 2706 o CBOR Major Type: 4 2707 o Change Controller: IESG 2708 o Specification Document(s): this document 2710 o Parameter Name: target-fqdn 2711 o CBOR Key Value: 9 2712 o CBOR Major Type: 4 2713 o Change Controller: IESG 2714 o Specification Document(s): this document 2716 o Parameter Name: target-uri 2717 o CBOR Key Value: 10 2718 o CBOR Major Type: 4 2719 o Change Controller: IESG 2720 o Specification Document(s): this document 2722 o Parameter Name: alias-name 2723 o CBOR Key Value: 11 2724 o CBOR Major Type: 4 2725 o Change Controller: IESG 2726 o Specification Document(s): this document 2728 o Parameter Name: lifetime 2729 o CBOR Key Value: 12 2730 o CBOR Major Type: 0 2731 o Change Controller: IESG 2732 o Specification Document(s): this document 2734 o Parameter Name: attack-status 2735 o CBOR Key Value: 13 2736 o CBOR Major Type: 0 2737 o Change Controller: IESG 2738 o Specification Document(s): this document 2740 o Parameter Name: signal-config 2741 o CBOR Key Value: 14 2742 o CBOR Major Type: 5 2743 o Change Controller: IESG 2744 o Specification Document(s): this document 2746 o Parameter Name: heartbeat-interval 2747 o CBOR Key Value: 15 2748 o CBOR Major Type: 0 2749 o Change Controller: IESG 2750 o Specification Document(s): this document 2752 o Parameter Name: max-retransmit 2753 o CBOR Key Value: 16 2754 o CBOR Major Type: 0 2755 o Change Controller: IESG 2756 o Specification Document(s): this document 2758 o Parameter Name: ack-timeout 2759 o CBOR Key Value: 17 2760 o CBOR Major Type: 0 2761 o Change Controller: IESG 2762 o Specification Document(s): this document 2764 o Parameter Name: ack-random-factor 2765 o CBOR Key Value: 18 2766 o CBOR Major Type: 7 2767 o Change Controller: IESG 2768 o Specification Document(s): this document 2770 o Parameter Name: min-value 2771 o CBOR Key Value: 19 2772 o CBOR Major Type: 0 2773 o Change Controller: IESG 2774 o Specification Document(s): this document 2776 o Parameter Name: max-value 2777 o CBOR Key Value: 20 2778 o CBOR Major Type: 0 2779 o Change Controller: IESG 2780 o Specification Document(s): this document 2782 o Parameter Name: status 2783 o CBOR Key Value: 21 2784 o CBOR Major Type: 0 2785 o Change Controller: IESG 2786 o Specification Document(s): this document 2788 o Parameter Name: conflict-information 2789 o CBOR Key Value: 22 2790 o CBOR Major Type: 5 2791 o Change Controller: IESG 2792 o Specification Document(s): this document 2794 o Parameter Name: conflict-status 2795 o CBOR Key Value: 23 2796 o CBOR Major Type: 0 2797 o Change Controller: IESG 2798 o Specification Document(s): this document 2800 o Parameter Name: conflict-cause 2801 o CBOR Key Value: 24 2802 o CBOR Major Type: 0 2803 o Change Controller: IESG 2804 o Specification Document(s): this document 2806 o Parameter Name: retry-timer 2807 o CBOR Key Value: 25 2808 o CBOR Major Type: 0 2809 o Change Controller: IESG 2810 o Specification Document(s): this document 2812 o Parameter Name: bytes-dropped 2813 o CBOR Key Value: 26 2814 o CBOR Major Type: 0 2815 o Change Controller: IESG 2816 o Specification Document(s): this document 2818 o Parameter Name: bps-dropped 2819 o CBOR Key Value: 27 2820 o CBOR Major Type: 0 2821 o Change Controller: IESG 2822 o Specification Document(s): this document 2824 o Parameter Name: pkts-dropped 2825 o CBOR Key Value: 28 2826 o CBOR Major Type: 0 2827 o Change Controller: IESG 2828 o Specification Document(s): this document 2830 o Parameter Name: pps-dropped 2831 o CBOR Key Value: 29 2832 o CBOR Major Type: 0 2833 o Change Controller: IESG 2834 o Specification Document(s): this document 2836 o Parameter Name: session-id 2837 o CBOR Key Value: 30 2838 o CBOR Major Type: 0 2839 o Change Controller: IESG 2840 o Specification Document(s): this document 2842 o Parameter Name: trigger-mitigation 2843 o CBOR Key Value: 31 2844 o CBOR Major Type: 7 2845 o Change Controller: IESG 2846 o Specification Document(s): this document 2848 o Parameter Name: missing-hb-allowed 2849 o CBOR Key Value: 32 2850 o CBOR Major Type: 0 2851 o Change Controller: IESG 2852 o Specification Document(s): this document 2854 o Parameter Name: current-value 2855 o CBOR Key Value: 33 2856 o CBOR Major Type: 0 2857 o Change Controller: IESG 2858 o Specification Document(s): this document 2860 o Parameter Name: mitigation-start 2861 o CBOR Key Value: 34 2862 o CBOR Major Type: 7 2863 o Change Controller: IESG 2864 o Specification Document(s): this document 2866 o Parameter Name: target-prefix 2867 o CBOR Key Value: 35 2868 o CBOR Major Type: 4 2869 o Change Controller: IESG 2870 o Specification Document(s): this document 2872 o Parameter Name: client-identifier 2873 o CBOR Key Value: 36 2874 o CBOR Major Type: 2 2875 o Change Controller: IESG 2876 o Specification Document(s): this document 2878 o Parameter Name: alt-server 2879 o CBOR Key Value: 37 2880 o CBOR Major Type: 2 2881 o Change Controller: IESG 2882 o Specification Document(s): this document 2884 o Parameter Name: alt-server-record 2885 o CBOR Key Value: 38 2886 o CBOR Major Type: 4 2887 o Change Controller: IESG 2888 o Specification Document(s): this document 2890 o Parameter Name: addr 2891 o CBOR Key Value: 39 2892 o CBOR Major Type: 2 2893 o Change Controller: IESG 2894 o Specification Document(s): this document 2896 o Parameter Name: ttl 2897 o CBOR Key Value: 40 2898 o CBOR Major Type: 0 2899 o Change Controller: IESG 2900 o Specification Document(s): this document 2902 o Parameter Name: conflict-scope 2903 o CBOR Key Value: 41 2904 o CBOR Major Type: 5 2905 o Change Controller: IESG 2906 o Specification Document(s): this document 2908 9.5. DOTS Signal Channel YANG Module 2910 This document requests IANA to register the following URI in the 2911 "IETF XML Registry" [RFC3688]: 2913 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal 2914 Registrant Contact: The IESG. 2915 XML: N/A; the requested URI is an XML namespace. 2917 This document requests IANA to register the following YANG module in 2918 the "YANG Module Names" registry [RFC7950]. 2920 name: ietf-signal 2921 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal 2922 prefix: signal 2923 reference: RFC XXXX 2925 10. Implementation Status 2927 [Note to RFC Editor: Please remove this section and reference to 2928 [RFC7942] prior to publication.] 2930 This section records the status of known implementations of the 2931 protocol defined by this specification at the time of posting of this 2932 Internet-Draft, and is based on a proposal described in [RFC7942]. 2933 The description of implementations in this section is intended to 2934 assist the IETF in its decision processes in progressing drafts to 2935 RFCs. Please note that the listing of any individual implementation 2936 here does not imply endorsement by the IETF. Furthermore, no effort 2937 has been spent to verify the information presented here that was 2938 supplied by IETF contributors. This is not intended as, and must not 2939 be construed to be, a catalog of available implementations or their 2940 features. Readers are advised to note that other implementations may 2941 exist. 2943 According to [RFC7942], "this will allow reviewers and working groups 2944 to assign due consideration to documents that have the benefit of 2945 running code, which may serve as evidence of valuable experimentation 2946 and feedback that have made the implemented protocols more mature. 2947 It is up to the individual working groups to use this information as 2948 they see fit". 2950 10.1. nttdots 2952 Organization: NTT Communication is developing a DOTS client and 2953 DOTS server software based on DOTS signal channel specified in 2954 this draft. It will be open-sourced. 2955 Description: Early implementation of DOTS protocol. It is aimed to 2956 implement a full DOTS protocol spec in accordance with maturing of 2957 DOTS protocol itself. 2958 Implementation: https://github.com/nttdots/go-dots 2959 Level of maturity: It is a early implementation of DOTS protocol. 2960 Messaging between DOTS clients and DOTS servers has been tested. 2961 Level of maturity will increase in accordance with maturing of 2962 DOTS protocol itself. 2963 Coverage: Capability of DOTS client: sending DOTS messages to the 2964 DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS 2965 server: receiving dots-signal, validating received dots-signal, 2966 starting mitigation by handing over the dots-signal to DDOS 2967 mitigator. 2968 Licensing: It will be open-sourced with BSD 3-clause license. 2969 Implementation experience: It is implemented in Go-lang. Core 2970 specification of signaling is mature to be implemented, however, 2971 finding good libraries(like DTLS, CoAP) is rather difficult. 2972 Contact: Kaname Nishizuka 2974 11. Security Considerations 2976 Authenticated encryption MUST be used for data confidentiality and 2977 message integrity. The interaction between the DOTS agents requires 2978 Datagram Transport Layer Security (DTLS) and Transport Layer Security 2979 (TLS) with a cipher suite offering confidentiality protection and the 2980 guidance given in [RFC7525] MUST be followed to avoid attacks on 2981 (D)TLS. 2983 A single DOTS signal channel between DOTS agents can be used to 2984 exchange multiple DOTS signal messages. To reduce DOTS client and 2985 DOTS server workload, DOTS client SHOULD re-use the (D)TLS session. 2987 If TCP is used between DOTS agents, an attacker may be able to inject 2988 RST packets, bogus application segments, etc., regardless of whether 2989 TLS authentication is used. Because the application data is TLS 2990 protected, this will not result in the application receiving bogus 2991 data, but it will constitute a DoS on the connection. This attack 2992 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 2993 any bogus packets injected by an attacker will be rejected by the 2994 TCP-AO integrity check and therefore will never reach the TLS layer. 2996 In order to prevent leaking internal information outside a client- 2997 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 2998 the identity of internal DOTS clients (client-identifier) unless 2999 explicitly configured to do so. 3001 Special care should be taken in order to ensure that the activation 3002 of the proposed mechanism won't have an impact on the stability of 3003 the network (including connectivity and services delivered over that 3004 network). 3006 Involved functional elements in the cooperation system must establish 3007 exchange instructions and notification over a secure and 3008 authenticated channel. Adequate filters can be enforced to avoid 3009 that nodes outside a trusted domain can inject request such as 3010 deleting filtering rules. Nevertheless, attacks can be initiated 3011 from within the trusted domain if an entity has been corrupted. 3012 Adequate means to monitor trusted nodes should also be enabled. 3014 12. Contributors 3016 The following individuals have contributed to this document: 3018 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 3019 mgeller@cisco.com 3021 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 3022 Email: rgm@htt-consult.com 3024 Dan Wing Email: dwing-ietf@fuggles.com 3026 13. Acknowledgements 3028 Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, 3029 Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang 3030 Xia, Gilbert Clark, and Nesredien Suleiman for the discussion and 3031 comments. 3033 Special thanks to Jon Shallow for the careful reviews and inputs that 3034 enhanced this specification. 3036 14. References 3038 14.1. Normative References 3040 [I-D.ietf-core-coap-tcp-tls] 3041 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 3042 Silverajan, B., and B. Raymor, "CoAP (Constrained 3043 Application Protocol) over TCP, TLS, and WebSockets", 3044 draft-ietf-core-coap-tcp-tls-10 (work in progress), 3045 October 2017. 3047 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3048 Requirement Levels", BCP 14, RFC 2119, 3049 DOI 10.17487/RFC2119, March 1997, 3050 . 3052 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3053 DOI 10.17487/RFC3688, January 2004, 3054 . 3056 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 3057 Ciphersuites for Transport Layer Security (TLS)", 3058 RFC 4279, DOI 10.17487/RFC4279, December 2005, 3059 . 3061 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3062 (TLS) Protocol Version 1.2", RFC 5246, 3063 DOI 10.17487/RFC5246, August 2008, 3064 . 3066 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3067 Housley, R., and W. Polk, "Internet X.509 Public Key 3068 Infrastructure Certificate and Certificate Revocation List 3069 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3070 . 3072 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3073 Uniform Resource Identifiers (URIs)", RFC 5785, 3074 DOI 10.17487/RFC5785, April 2010, 3075 . 3077 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 3078 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 3079 June 2010, . 3081 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3082 Verification of Domain-Based Application Service Identity 3083 within Internet Public Key Infrastructure Using X.509 3084 (PKIX) Certificates in the Context of Transport Layer 3085 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3086 2011, . 3088 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 3089 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 3090 DOI 10.17487/RFC6234, May 2011, 3091 . 3093 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3094 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3095 January 2012, . 3097 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 3098 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 3099 Transport Layer Security (TLS) and Datagram Transport 3100 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 3101 June 2014, . 3103 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3104 Application Protocol (CoAP)", RFC 7252, 3105 DOI 10.17487/RFC7252, June 2014, 3106 . 3108 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3109 "Recommendations for Secure Use of Transport Layer 3110 Security (TLS) and Datagram Transport Layer Security 3111 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3112 2015, . 3114 [RFC7641] Hartke, K., "Observing Resources in the Constrained 3115 Application Protocol (CoAP)", RFC 7641, 3116 DOI 10.17487/RFC7641, September 2015, 3117 . 3119 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3120 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3121 . 3123 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3124 Writing an IANA Considerations Section in RFCs", BCP 26, 3125 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3126 . 3128 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 3129 FETCH Methods for the Constrained Application Protocol 3130 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 3131 . 3133 14.2. Informative References 3135 [I-D.ietf-core-comi] 3136 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 3137 Management Interface", draft-ietf-core-comi-01 (work in 3138 progress), July 2017. 3140 [I-D.ietf-core-yang-cbor] 3141 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 3142 Minaburo, "CBOR Encoding of Data Modeled with YANG", 3143 draft-ietf-core-yang-cbor-05 (work in progress), August 3144 2017. 3146 [I-D.ietf-dots-architecture] 3147 Mortensen, A., Andreasen, F., Reddy, T., 3148 christopher_gray3@cable.comcast.com, c., Compton, R., and 3149 N. Teague, "Distributed-Denial-of-Service Open Threat 3150 Signaling (DOTS) Architecture", draft-ietf-dots- 3151 architecture-05 (work in progress), October 2017. 3153 [I-D.ietf-dots-data-channel] 3154 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 3155 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 3156 Service Open Threat Signaling (DOTS) Data Channel", draft- 3157 ietf-dots-data-channel-08 (work in progress), November 3158 2017. 3160 [I-D.ietf-dots-requirements] 3161 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 3162 Denial of Service (DDoS) Open Threat Signaling 3163 Requirements", draft-ietf-dots-requirements-07 (work in 3164 progress), October 2017. 3166 [I-D.ietf-dots-use-cases] 3167 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 3168 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 3169 Open Threat Signaling", draft-ietf-dots-use-cases-09 (work 3170 in progress), November 2017. 3172 [I-D.ietf-netmod-yang-tree-diagrams] 3173 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 3174 ietf-netmod-yang-tree-diagrams-02 (work in progress), 3175 October 2017. 3177 [I-D.ietf-tls-dtls13] 3178 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 3179 Datagram Transport Layer Security (DTLS) Protocol Version 3180 1.3", draft-ietf-tls-dtls13-22 (work in progress), 3181 November 2017. 3183 [I-D.ietf-tls-tls13] 3184 Rescorla, E., "The Transport Layer Security (TLS) Protocol 3185 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 3186 July 2017. 3188 [proto_numbers] 3189 "IANA, "Protocol Numbers"", 2011, 3190 . 3192 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3193 DOI 10.17487/RFC0791, September 1981, 3194 . 3196 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3197 Resource Identifier (URI): Generic Syntax", STD 66, 3198 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3199 . 3201 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3202 Congestion Control Protocol (DCCP)", RFC 4340, 3203 DOI 10.17487/RFC4340, March 2006, 3204 . 3206 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3207 (CIDR): The Internet Address Assignment and Aggregation 3208 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 3209 2006, . 3211 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 3212 Denial-of-Service Considerations", RFC 4732, 3213 DOI 10.17487/RFC4732, December 2006, 3214 . 3216 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 3217 Translation (NAT) Behavioral Requirements for Unicast 3218 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 3219 2007, . 3221 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3222 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3223 . 3225 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3226 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 3227 . 3229 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 3230 "Transport Layer Security (TLS) Session Resumption without 3231 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 3232 January 2008, . 3234 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 3235 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 3236 2012, . 3238 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 3239 "Default Address Selection for Internet Protocol Version 6 3240 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 3241 . 3243 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 3244 "Enrollment over Secure Transport", RFC 7030, 3245 DOI 10.17487/RFC7030, October 2013, 3246 . 3248 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 3249 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 3250 October 2013, . 3252 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 3253 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 3254 . 3256 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 3257 "Architectural Considerations in Smart Object Networking", 3258 RFC 7452, DOI 10.17487/RFC7452, March 2015, 3259 . 3261 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 3262 NETCONF Protocol over Transport Layer Security (TLS) with 3263 Mutual X.509 Authentication", RFC 7589, 3264 DOI 10.17487/RFC7589, June 2015, 3265 . 3267 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 3268 Layer Security (TLS) False Start", RFC 7918, 3269 DOI 10.17487/RFC7918, August 2016, 3270 . 3272 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 3273 (TLS) Cached Information Extension", RFC 7924, 3274 DOI 10.17487/RFC7924, July 2016, 3275 . 3277 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 3278 Code: The Implementation Status Section", BCP 205, 3279 RFC 7942, DOI 10.17487/RFC7942, July 2016, 3280 . 3282 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 3283 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 3284 March 2017, . 3286 Authors' Addresses 3288 Tirumaleswar Reddy 3289 McAfee, Inc. 3290 Embassy Golf Link Business Park 3291 Bangalore, Karnataka 560071 3292 India 3294 Email: kondtir@gmail.com 3296 Mohamed Boucadair 3297 Orange 3298 Rennes 35000 3299 France 3301 Email: mohamed.boucadair@orange.com 3303 Prashanth Patil 3304 Cisco Systems, Inc. 3306 Email: praspati@cisco.com 3308 Andrew Mortensen 3309 Arbor Networks, Inc. 3310 2727 S. State St 3311 Ann Arbor, MI 48104 3312 United States 3314 Email: amortensen@arbor.net 3316 Nik Teague 3317 Verisign, Inc. 3318 United States 3320 Email: nteague@verisign.com