idnits 2.17.1 draft-reddy-dots-signal-channel-09.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 70 instances of too long lines in the document, the longest one being 14 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 337 has weird spacing: '...er-port ine...' == Line 338 has weird spacing: '...er-port ine...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 2, 2017) is 2584 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) == Unused Reference: 'RFC6520' is defined on line 1921, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-06 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-00 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-04 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-01 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-03 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-03 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 == Outdated reference: A later version (-05) exists of draft-reddy-dots-data-channel-04 == Outdated reference: A later version (-01) exists of draft-rescorla-tls-dtls13-00 -- 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: 4 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 Cisco 4 Intended status: Standards Track M. Boucadair 5 Expires: September 3, 2017 Orange 6 P. Patil 7 Cisco 8 March 2, 2017 10 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 11 Channel 12 draft-reddy-dots-signal-channel-09 14 Abstract 16 This document specifies a mechanism that a DOTS client can use to 17 signal that a network is under a Distributed Denial-of-Service (DDoS) 18 attack to an upstream DOTS server so that appropriate mitigation 19 actions are undertaken (including, blackhole, drop, rate-limit, or 20 add to watch list) on the suspect traffic. The document specifies 21 the DOTS signal channel including Happy Eyeballs considerations. The 22 specification of the DOTS data channel is elaborated in a companion 23 document. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 3, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Notational Conventions and Terminology . . . . . . . . . . . 3 61 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . . . 5 63 5. DOTS Signal Channel . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. DOTS Signal YANG Model . . . . . . . . . . . . . . . . . 7 66 5.2.1. Mitigation Request Model structure . . . . . . . . . 7 67 5.2.2. Mitigation Request Model . . . . . . . . . . . . . . 8 68 5.2.3. Session Configuration Model structure . . . . . . . . 10 69 5.2.4. Session Configuration Model . . . . . . . . . . . . . 10 70 5.3. Mitigation Request . . . . . . . . . . . . . . . . . . . 12 71 5.3.1. Convey DOTS Signals . . . . . . . . . . . . . . . . . 13 72 5.3.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 18 73 5.3.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 19 74 5.3.4. Efficacy Update from DOTS Client . . . . . . . . . . 23 75 5.4. DOTS Signal Channel Session Configuration . . . . . . . . 25 76 5.4.1. Discover Acceptable Configuration Parameters . . . . 25 77 5.4.2. Convey DOTS Signal Channel Session Configuration . . 26 78 5.4.3. Delete DOTS Signal Channel Session Configuration . . 29 79 5.4.4. Retrieving DOTS Signal Channel Session Configuration 29 80 5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 30 81 5.6. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 31 82 6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 32 83 7. (D)TLS Protocol Profile and Performance considerations . . . 32 84 7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 33 85 8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 34 86 9. Mutual Authentication of DOTS Agents & Authorization of DOTS 87 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 89 10.1. DOTS signal channel CBOR Mappings Registry . . . . . . . 37 90 10.1.1. Registration Template . . . . . . . . . . . . . . . 37 91 10.1.2. Initial Registry Contents . . . . . . . . . . . . . 37 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 93 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 96 14.1. Normative References . . . . . . . . . . . . . . . . . . 42 97 14.2. Informative References . . . . . . . . . . . . . . . . . 43 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 100 1. Introduction 102 A distributed denial-of-service (DDoS) attack is an attempt to make 103 machines or network resources unavailable to their intended users. 104 In most cases, sufficient scale can be achieved by compromising 105 enough end-hosts and using those infected hosts to perpetrate and 106 amplify the attack. The victim in this attack can be an application 107 server, a host, a router, a firewall, or an entire network. 109 In many cases, it may not be possible for an network administrators 110 to determine the causes of an attack, but instead just realize that 111 certain resources seem to be under attack. This document, which 112 adheres to the DOTS architecture [I-D.ietf-dots-architecture], 113 proposes that, in such cases, the DOTS client just inform its DOTS 114 server(s) that the network is under a potential attack and that the 115 mitigator monitors traffic to the network to mitigate any possible 116 attacks. This cooperation between DOTS agents contributes to ensure 117 a highly automated network that is also robust, reliable and secure. 119 Protocol requirements for DOTS signal channel are obtained from DOTS 120 requirements [I-D.ietf-dots-requirements]. 122 This document satisfies all the use cases discussed in 123 [I-D.ietf-dots-use-cases] except the Third-party DOTS notifications 124 use case in Section 3.2.3 of [I-D.ietf-dots-use-cases] which is an 125 optional feature and not a core use case. Third-party DOTS 126 notifications are not part of the DOTS requirements document. 127 Moreover, the DOTS architecture does not assess whether that use case 128 may have an impact on the architecture itself and/or the DOTS trust 129 model. 131 This is a companion document to the DOTS data channel specification 132 [I-D.reddy-dots-data-channel]. 134 2. Notational Conventions and Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 (D)TLS: For brevity this term is used for statements that apply to 141 both Transport Layer Security [RFC5246] and Datagram Transport Layer 142 Security [RFC6347]. Specific terms will be used for any statement 143 that applies to either protocol alone. 145 The reader should be familiar with the terms defined in 146 [I-D.ietf-dots-architecture]. 148 3. Solution Overview 150 Network applications have finite resources like CPU cycles, number of 151 processes or threads they can create and use, maximum number of 152 simultaneous connections it can handle, limited resources of the 153 control plane, etc. When processing network traffic, such 154 applications are supposed to use these resources to offer the 155 intended task in the most efficient fashion. However, an attacker 156 may be able to prevent an application from performing its intended 157 task by causing the application to exhaust the finite supply of a 158 specific resource. 160 TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the 161 victim and ACK-flood is a CPU exhaustion attack on the victim 162 ([RFC4987]). Attacks on the link are carried out by sending enough 163 traffic such that the link becomes excessively congested, and 164 legitimate traffic suffers high packet loss. Stateful firewalls can 165 also be attacked by sending traffic that causes the firewall to hold 166 excessive state and the firewall runs out of memory, and can no 167 longer instantiate the state required to pass legitimate flows. 168 Other possible DDoS attacks are discussed in [RFC4732]. 170 In each of the cases described above, the possible arrangements 171 between the DOTS client and DOTS server to mitigate the attack are 172 discussed in [I-D.ietf-dots-use-cases]. An example of network 173 diagram showing a deployment of these elements is shown in Figure 1. 174 Architectural relationships between involved DOTS agents is explained 175 in [I-D.ietf-dots-architecture]. In this example, the DOTS server is 176 operating on the access network. 178 Network 179 Resource CPE router Access network __________ 180 +-----------+ +--------------+ +-------------+ / \ 181 | |____| |_______| |___ | Internet | 182 |DOTS client| | DOTS gateway | | DOTS server | | | 183 | | | | | | | | 184 +-----------+ +--------------+ +-------------+ \__________/ 186 Figure 1 188 The DOTS server can also be running on the Internet, as depicted in 189 Figure 2. 191 Network DDoS mitigation 192 Resource CPE router __________ service 193 +-----------+ +-------------+ / \ +-------------+ 194 | |____| |_______| |___ | | 195 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 196 | | | | | | | | | 197 +-----------+ +-------------+ \__________/ +-------------+ 199 Figure 2 201 In typical deployments, the DOTS client belongs to a different 202 administrative domain than the DOTS server. For example, the DOTS 203 client is a web server serving content owned and operated by an 204 domain, while the DOTS server is owned and operated by a different 205 domain providing DDoS mitigation services. That domain providing 206 DDoS mitigation service might, or might not, also provide Internet 207 access service to the website operator. 209 The DOTS server may (not) be co-located with the DOTS mitigator. In 210 typical deployments, the DOTS server belongs to the same 211 administrative domain as the mitigator. 213 The DOTS client can communicate directly with the DOTS server or 214 indirectly via a DOTS gateway. 216 This document focuses on the DOTS signal channel. 218 4. Happy Eyeballs for DOTS Signal Channel 220 DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS 221 [RFC5246] over TCP. A DOTS client can use DNS to determine the IP 222 address(es) of a DOTS server or a DOTS client may be provided with 223 the list of DOTS server IP addresses. The DOTS client MUST know a 224 DOTS server's domain name; hard-coding the domain name of the DOTS 225 server into software is NOT RECOMMENDED in case the domain name is 226 not valid or needs to change for legal or other reasons. The DOTS 227 client performs A and/or AAAA record lookup of the domain name and 228 the result will be a list of IP addresses, each of which can be used 229 to contact the DOTS server using UDP and TCP. 231 If an IPv4 path to reach a DOTS server is found, but the DOTS 232 server's IPv6 path is not working, a dual-stack DOTS client can 233 experience a significant connection delay compared to an IPv4-only 234 DOTS client. The other problem is that if a middlebox between the 235 DOTS client and DOTS server is configured to block UDP, the DOTS 236 client will fail to establish a DTLS session with the DOTS server and 237 will, then, have to fall back to TLS over TCP incurring significant 238 connection delays. [I-D.ietf-dots-requirements] discusses that DOTS 239 client and server will have to support both connectionless and 240 connection-oriented protocols. 242 To overcome these connection setup problems, the DOTS client can try 243 connecting to the DOTS server using both IPv6 and IPv4, and try both 244 DTLS over UDP and TLS over TCP in a fashion similar to the Happy 245 Eyeballs mechanism [RFC6555]. These connection attempts are 246 performed by the DOTS client when its initializes, and the client 247 uses that information for its subsequent alert to the DOTS server. 248 In order of preference (most preferred first), it is UDP over IPv6, 249 UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which 250 adheres to address preference order [RFC6724] and the DOTS preference 251 that UDP be used over TCP (to avoid TCP's head of line blocking). 253 DOTS client DOTS server 254 | | 255 |--DTLS ClientHello, IPv6 ---->X | 256 |--TCP SYN, IPv6-------------->X | 257 |--DTLS ClientHello, IPv4 ---->X | 258 |--TCP SYN, IPv4----------------------------------------->| 259 |--DTLS ClientHello, IPv6 ---->X | 260 |--TCP SYN, IPv6-------------->X | 261 |<-TCP SYNACK---------------------------------------------| 262 |--DTLS ClientHello, IPv4 ---->X | 263 |--TCP ACK----------------------------------------------->| 264 |<------------Establish TLS Session---------------------->| 265 |----------------DOTS signal----------------------------->| 266 | | 268 Figure 3: Happy Eyeballs 270 In reference to Figure 3, the DOTS client sends two TCP SYNs and two 271 DTLS ClientHello messages at the same time over IPv6 and IPv4. In 272 this example, it is assumed that the IPv6 path is broken and UDP is 273 dropped by a middle box but has little impact to the DOTS client 274 because there is no long delay before using IPv4 and TCP. The IPv6 275 path and UDP over IPv6 and IPv4 is retried until the DOTS client 276 gives up. 278 5. DOTS Signal Channel 280 5.1. Overview 282 Constrained Application Protocol (CoAP) [RFC7252] is used for DOTS 283 signal channel (Figure 4). COAP was designed according to the REST 284 architecture, and thus exhibits functionality similar to that of 285 HTTP, it is quite straightforward to map from CoAP to HTTP and from 286 HTTP to CoAP. CoAP has been defined to make use of both DTLS over 287 UDP and TLS over TCP [I-D.ietf-core-coap-tcp-tls]. The advantages of 288 COAP are: (1) Like HTTP, CoAP is based on the successful REST model, 289 (2) CoAP is designed to use minimal resources, (3) CoAP integrates 290 with JSON, CBOR or any other data format, (4) asynchronous message 291 exchanges, (5) includes a congestion control mechanism (6) allows 292 configuration of message transmission parameters specific to the 293 application environment (including dynamically adjusted values, see 294 Section 4.8.1 in [RFC7252]) etc. 296 +--------------+ 297 | DOTS | 298 +--------------+ 299 | CoAP | 300 +--------------+ 301 | TLS | DTLS | 302 +--------------+ 303 | TCP | UDP | 304 +--------------+ 305 | IP | 306 +--------------+ 308 Figure 4: Abstract Layering of DOTS signal channel over CoAP over 309 (D)TLS 311 A single DOTS signal channel between DOTS agents can be used to 312 exchange multiple DOTS signal messages. To reduce DOTS client and 313 DOTS server workload, DOTS client SHOULD re-use the (D)TLS session. 315 Concise Binary Object Representation (CBOR) [RFC7049] is a binary 316 encoding designed for small code and message size, CBOR encoded 317 payloads are used to convey signal channel specific payload messages 318 that convey request parameters and response information such as 319 errors. This specification uses the encoding rules defined in 320 [I-D.ietf-core-yang-cbor] for representing DOTS signal channel 321 configuration data defined using YANG (Section 5.2) as CBOR data. 323 5.2. DOTS Signal YANG Model 325 5.2.1. Mitigation Request Model structure 327 This document defines the YANG module "ietf-dots-signal", which has 328 the following structure: 330 module: ietf-dots-signal 331 +--rw mitigation-scope 332 +--rw scope* [policy-id] 333 +--rw policy-id int32 334 +--rw target-ip* inet:ip-address 335 +--rw target-prefix* inet:ip-prefix 336 +--rw target-port-range* [lower-port upper-port] 337 | +--rw lower-port inet:port-number 338 | +--rw upper-port inet:port-number 339 +--rw target-protocol* uint8 340 +--rw FQDN* inet:domain-name 341 +--rw URI* inet:uri 342 +--rw E.164* string 343 +--rw alias* string 344 +--rw lifetime? int32 346 5.2.2. Mitigation Request Model 348 file "ietf-dots-signal@2016-11-28.yang" 350 module ietf-dots-signal { 351 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; 352 prefix "signal"; 353 import ietf-inet-types { 354 prefix "inet"; 355 } 356 organization "Cisco Systems, Inc."; 357 contact "Tirumaleswar Reddy "; 359 description 360 "This module contains YANG definition for DOTS 361 signal sent by the DOTS client to the DOTS server"; 363 revision 2016-11-28 { 364 reference 365 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 366 } 368 container mitigation-scope { 369 description "top level container for mitigation request"; 370 list scope { 371 key policy-id; 372 description "Identifier for the mitigation request"; 373 leaf policy-id { 374 type int32; 375 description "policy identifier"; 376 } 377 leaf-list target-ip { 378 type inet:ip-address; 379 description "IP address"; 380 } 381 leaf-list target-prefix { 382 type inet:ip-prefix; 383 description "prefix"; 384 } 385 list target-port-range { 386 key "lower-port upper-port"; 387 description "Port range. When only lower-port is present, 388 it represents a single port."; 389 leaf lower-port { 390 type inet:port-number; 391 mandatory true; 392 description "lower port"; 393 } 394 leaf upper-port { 395 type inet:port-number; 396 must ". >= ../lower-port" { 397 error-message 398 "The upper-port must be greater than or 399 equal to lower-port"; 400 } 401 description "upper port"; 402 } 403 } 404 leaf-list target-protocol { 405 type uint8; 406 description "Internet Protocol number"; 407 } 408 leaf-list FQDN { 409 type inet:domain-name; 410 description "FQDN"; 411 } 412 leaf-list URI { 413 type inet:uri; 414 description "URI"; 415 } 416 leaf-list E.164 { 417 type string; 418 description "E.164 number"; 419 } 420 leaf-list alias { 421 type string; 422 description "alias name"; 423 } 424 leaf lifetime { 425 type int32; 426 description "lifetime"; 427 } 428 } 429 } 430 } 431 433 5.2.3. Session Configuration Model structure 435 This document defines the YANG module "ietf-dots-signal-config", 436 which has the following structure: 438 module: ietf-dots-signal-config 439 +--rw signal-config 440 +--rw policy-id? int32 441 +--rw heartbeat-interval? int16 442 +--rw max-retransmit? int16 443 +--rw ack-timeout? int16 444 +--rw ack-random-factor? decimal64 446 5.2.4. Session Configuration Model 447 file "ietf-dots-signal-config@2016-11-28.yang" 449 module ietf-dots-signal-config { 450 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config"; 451 prefix "config"; 452 organization "Cisco Systems, Inc."; 453 contact "Tirumaleswar Reddy "; 455 description 456 "This module contains YANG definition for DOTS 457 signal channel session configuration"; 459 revision 2016-11-28 { 460 reference 461 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 462 } 464 container signal-config { 465 description "top level container for DOTS signal channel session 466 configuration"; 467 leaf policy-id { 468 type int32; 469 description "Identifier for the DOTS signal channel 470 session configuration data"; 471 } 472 leaf heartbeat-interval { 473 type int16; 474 description "heartbeat interval"; 475 } 476 leaf max-retransmit { 477 type int16; 478 description "Maximum number of retransmissions"; 479 } 480 leaf ack-timeout { 481 type int16; 482 description "Initial retransmission timeout value"; 483 } 484 leaf ack-random-factor { 485 type decimal64 { 486 fraction-digits 2; 487 } 488 description "Random factor used to influence the timing of 489 retransmissions"; 490 } 491 } 492 } 494 495 5.3. Mitigation Request 497 The following APIs define the means to convey a DOTS signal from a 498 DOTS client to a DOTS server: 500 PUT requests: are used to convey the DOTS signal from a DOTS client 501 to a DOTS server over the signal channel, possibly traversing a 502 DOTS gateway, indicating the DOTS client's need for mitigation, as 503 well as the scope of any requested mitigation (Section 5.3.1). 504 DOTS gateway act as a CoAP-to-CoAP Proxy (explained in [RFC7252]). 505 PUT requests are also used by the DOTS client to convey mitigation 506 efficacy updates to the DOTS server (Section 5.3.4). 507 DELETE requests: are used by the DOTS client to withdraw the request 508 for mitigation from the DOTS server (Section 5.3.2). 509 GET requests: are used by the DOTS client to retrieve the DOTS 510 signal(s) it had conveyed to the DOTS server (Section 5.3.3). 512 Reliability is provided to the requests and responses by marking them 513 as Confirmable (CON) messages. As explained in Section 2.1 of 514 [RFC7252], a Confirmable message is retransmitted using a default 515 timeout and exponential back-off between retransmissions, until the 516 DOTS server sends an Acknowledgement message (ACK) with the same 517 Message ID conveyed from the DOTS client. Message transmission 518 parameters are defined in Section 4.8 of [RFC7252]. Reliability is 519 provided to the responses by marking them as Confirmable (CON) 520 messages. The DOTS server can either piggyback the response in the 521 acknowledgement message or if the DOTS server is not able to respond 522 immediately to a request carried in a Confirmable message, it simply 523 responds with an Empty Acknowledgement message so that the DOTS 524 client can stop retransmitting the request. Empty Acknowledgement 525 message is explained in Section 2.2 of [RFC7252]. When the response 526 is ready, the server sends it in a new Confirmable message which then 527 in turn needs to be acknowledged by the DOTS client (see Sections 528 5.2.1 and Sections 5.2.2 in [RFC7252]). 530 DOTS agents should follow the data transmission guidelines discussed 531 in Section 3.1.3 of [I-D.ietf-tsvwg-rfc5405bis] and control 532 transmission behavior by not sending on average more than one UDP 533 datagram per RTT to the peer DOTS agent. Requests marked by the DOTS 534 client as Non-confirmable messages are sent at regular intervals 535 until a response is received from the DOTS server and if the DOTS 536 client cannot maintain a RTT estimate then it SHOULD NOT send more 537 than one Non-confirmable request every 3 seconds, and SHOULD use an 538 even less aggressive rate when possible (case 2 in Section 3.1.3 of 539 [I-D.ietf-tsvwg-rfc5405bis]). 541 Implementation Note: A DOTS client that receives a response in a CON 542 message may want to clean up the message state right after sending 543 the ACK. If that ACK is lost and the DOTS server retransmits the 544 CON, the DOTS client may no longer have any state to which to 545 correlate this response, making the retransmission an unexpected 546 message; the DOTS client will send a Reset message so it does not 547 receive any more retransmissions. This behavior is normal and not an 548 indication of an error (see Section 5.3.2 in [RFC7252] for more 549 details). 551 5.3.1. Convey DOTS Signals 553 When suffering an attack and desiring DoS/DDoS mitigation, a DOTS 554 signal is sent by the DOTS client to the DOTS server. A PUT request 555 is used to convey a DOTS signal to the DOTS server (Figure 5, 556 illustrated in JSON diagnostic notation). The DOTS server can enable 557 mitigation on behalf of the DOTS client by communicating the DOTS 558 client's request to the mitigator and relaying any mitigator feedback 559 to the requesting DOTS client. The PUT request and response are 560 marked as Non-confirmable messages. 562 Header: PUT (Code=0.03) 563 Uri-Host: "host" 564 Uri-Path: ".well-known" 565 Uri-Path: "version" 566 Uri-Path: "dots-signal" 567 Uri-Path: "signal" 568 Content-Type: "application/cbor" 569 { 570 "mitigation-scope": { 571 "scope": [ 572 { 573 "policy-id": integer, 574 "target-ip": [ 575 "string" 576 ], 577 "target-prefix": [ 578 "string" 579 ], 580 "target-port-range": [ 581 { 582 "lower-port": integer, 583 "upper-port": integer 584 } 585 ], 586 "target-protocol": [ 587 integer 588 ], 589 "FQDN": [ 590 "string" 591 ], 592 "URI": [ 593 "string" 594 ], 595 "E.164": [ 596 "string" 597 ], 598 "alias": [ 599 "string" 600 ], 601 "lifetime": integer 602 } 603 ] 604 } 605 } 607 Figure 5: PUT to convey DOTS signals 609 The parameters are described below. 611 policy-id: Identifier for the mitigation request represented using 612 an integer. This identifier MUST be unique for each mitigation 613 request bound to the DOTS client, i.e., the policy-id parameter 614 value in the mitigation request needs to be unique relative to the 615 policy-id parameter values of active mitigation requests conveyed 616 from the DOTS client to the DOTS server. This identifier MUST be 617 generated by the DOTS client. This document does not make any 618 assumption about how this identifier is generated. This is a 619 mandatory attribute. 620 target-ip: A list of IP addresses under attack. IP addresses are 621 separated by commas. This is an optional attribute. 622 target-prefix: A list of prefixes under attack. Prefixes are 623 separated by commas. Prefixes are represented using CIDR notation 624 [RFC4632]. This is an optional attribute. 625 target-port-range: A list of ports under attack. The port range, 626 lower-port for lower port number and upper-port for upper port 627 number. When only lower-port is present, it represents a single 628 port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g., 629 1024-65535). This is an optional attribute. 630 target-protocol: A list of protocols under attack. Internet 631 Protocol numbers. This is an optional attribute. 632 FQDN: A list of Fully Qualified Domain Names. Fully Qualified 633 Domain Name (FQDN) is the full name of a system, rather than just 634 its hostname. For example, "venera" is a hostname, and 635 "venera.isi.edu" is an FQDN. This is an optional attribute. 636 URI: A list of Uniform Resource Identifiers (URI). This is an 637 optional attribute. 638 E.164: A list of E.164 numbers. This is an optional attribute. 639 alias: A list of aliases (see Section 3.1.1 in 640 [I-D.reddy-dots-data-channel]). This is an optional attribute. 641 lifetime: Lifetime of the mitigation request in seconds. Upon the 642 expiry of this lifetime, and if the request is not refreshed, the 643 mitigation request is removed. The request can be refreshed by 644 sending the same request again. The default lifetime of the 645 mitigation request is 3600 seconds (60 minutes) -- this value was 646 chosen to be long enough so that refreshing is not typically a 647 burden on the DOTS client, while expiring the request where the 648 client has unexpectedly quit in a timely manner. A lifetime of 649 zero indicates indefinite lifetime for the mitigation request. 650 The server MUST always indicate the actual lifetime in the 651 response. This is an optional attribute in the request. 653 The CBOR key values for the parameters are defined in Section 6. The 654 IANA Considerations section defines how the CBOR key values can be 655 allocated to standards bodies and vendors. In the PUT request at 656 least one of the attributes target-ip or target-prefix or FQDN or URI 657 or alias MUST be present. DOTS agents can safely ignore Vendor- 658 Specific parameters they don't understand. The relative order of two 659 mitigation requests from a DOTS client is determined by comparing 660 their respective policy-id values. The mitigation request with 661 higher numeric policy-id value has higher precedence (and thus will 662 match before) than the mitigation request with lower numeric policy- 663 id value. 665 In both DOTS signal and data channel sessions, the DOTS client MUST 666 authenticate itself to the DOTS server (Section 9). The DOTS server 667 couples the DOTS signal and data channel sessions using the DOTS 668 client identity, so the DOTS server can validate whether the aliases 669 conveyed in the mitigation request were indeed created by the same 670 DOTS client using the DOTS data channel session. If the aliases were 671 not created by the DOTS client then the DOTS server returns 4.00 (Bad 672 Request) in the response. The DOTS server couples the DOTS signal 673 channel sessions using the DOTS client identity, the DOTS server uses 674 policy-id parameter value to detect duplicate mitigation requests. 676 Figure 6 shows a PUT request example to signal that ports 80, 8080, 677 and 443 on the servers 2002:db8:6401::1 and 2002:db8:6401::2 are 678 being attacked (illustrated in JSON diagnostic notation). 680 Header: PUT (Code=0.03) 681 Uri-Host: "www.example.com" 682 Uri-Path: ".well-known" 683 Uri-Path: "v1" 684 Uri-Path: "dots-signal" 685 Uri-Path: "signal" 686 Content-Format: "application/cbor" 687 { 688 "mitigation-scope": { 689 "scope": [ 690 { 691 "policy-id": 12332, 692 "target-ip": [ 693 "2002:db8:6401::1", 694 "2002:db8:6401::2" 695 ], 696 "target-port-range": [ 697 { 698 "lower-port": 80 699 }, 700 { 701 "lower-port": 443 702 }, 703 { 704 "lower-port": 8080 705 } 706 ], 707 "target-protocol": [ 708 6 709 ] 710 } 711 ] 712 } 713 } 715 The CBOR encoding format is shown below: 717 a1 # map(1) 718 01 # unsigned(1) 719 a1 # map(1) 720 02 # unsigned(2) 721 81 # array(1) 722 a4 # map(4) 723 03 # unsigned(3) 724 19 302c # unsigned(12332) 725 04 # unsigned(4) 726 82 # array(2) 727 70 # text(16) 728 323030323a6462383a363430313a3a31 # "2002:db8:6401::1" 729 70 # text(16) 730 323030323a6462383a363430313a3a32 # "2002:db8:6401::2" 731 05 # unsigned(5) 732 83 # array(3) 733 a1 # map(1) 734 06 # unsigned(6) 735 18 50 # unsigned(80) 736 a1 # map(1) 737 06 # unsigned(6) 738 19 01bb # unsigned(443) 739 a1 # map(1) 740 06 # unsigned(6) 741 19 1f90 # unsigned(8080) 742 08 # unsigned(8) 743 81 # array(1) 744 06 # unsigned(6) 746 Figure 6: POST for DOTS signal 748 The DOTS server indicates the result of processing the PUT request 749 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 750 codes are some sort of invalid requests. COAP 5.xx codes are 751 returned if the DOTS server has erred or is currently unavailable to 752 provide mitigation in response to the mitigation request from the 753 DOTS client. If the DOTS server does not find the policy-id 754 parameter value conveyed in the PUT request in its configuration data 755 then the server MAY accept the mitigation request, and a 2.01 756 (Created) response is returned to the DOTS client, and the DOTS 757 server will try to mitigate the attack. If the DOTS server finds the 758 policy-id parameter value conveyed in the PUT request in its 759 configuration data then the server MAY update the mitigation request, 760 and a 2.04 (Changed) response is returned to indicate a successful 761 updation of the mitigation request. If the request is missing one or 762 more mandatory attributes, then 4.00 (Bad Request) will be returned 763 in the response or if the request contains invalid or unknown 764 parameters then 4.02 (Invalid query) will be returned in the 765 response. For responses indicating a client or server error, the 766 payload explains the error situation of the result of the requested 767 action (Section 5.5 in [RFC7252]). 769 5.3.2. Withdraw a DOTS Signal 771 A DELETE request is used to withdraw a DOTS signal from a DOTS server 772 (Figure 7). The DELETE request and response are marked as 773 Confirmable messages. 775 Header: DELETE (Code=0.04) 776 Uri-Host: "host" 777 Uri-Path: ".well-known" 778 Uri-Path: "version" 779 Uri-Path: "dots-signal" 780 Uri-Path: "signal" 781 Content-Format: "application/cbor" 782 { 783 "mitigation-scope": { 784 "scope": [ 785 { 786 "policy-id": integer 787 } 788 ] 789 } 790 } 792 Figure 7: Withdraw DOTS signal 794 If the DOTS server does not find the policy-id parameter value 795 conveyed in the DELETE request in its configuration data, then it 796 responds with a 4.04 (Not Found) error response code. The DOTS 797 server successfully acknowledges a DOTS client's request to withdraw 798 the DOTS signal using 2.02 (Deleted) response code, and ceases 799 mitigation activity as quickly as possible. 801 5.3.3. Retrieving a DOTS Signal 803 A GET request is used to retrieve information and status of a DOTS 804 signal from a DOTS server (Figure 8). If the DOTS server does not 805 find the policy-id parameter value conveyed in the GET request in its 806 configuration data, then it responds with a 4.04 (Not Found) error 807 response code. The GET request is marked as Non-confirmable message. 808 The 'c' (content) parameter and its permitted values defined in 809 [I-D.ietf-core-comi] can be used to retreive non-configuration data 810 or configuration data or both. 812 1) To retrieve all DOTS signals signaled by the DOTS client. 814 Header: GET (Code=0.01) 815 Uri-Host: "host" 816 Uri-Path: ".well-known" 817 Uri-Path: "version" 818 Uri-Path: "dots-signal" 819 Uri-Path: "signal" 820 Observe : 0 822 2) To retrieve a specific DOTS signal signaled by the DOTS client. 823 The configuration data in the response will be formatted in the 824 same order it was processed at the DOTS server. 826 Header: GET (Code=0.01) 827 Uri-Host: "host" 828 Uri-Path: ".well-known" 829 Uri-Path: "version" 830 Uri-Path: "dots-signal" 831 Uri-Path: "signal" 832 Observe : 0 833 Content-Format: "application/cbor" 834 { 835 "mitigation-scope": { 836 "scope": [ 837 { 838 "policy-id": integer 839 } 840 ] 841 } 842 } 844 Figure 8: GET to retrieve the rules 846 Figure 9 shows a response example of all the active mitigation 847 requests associated with the DOTS client on the DOTS server and the 848 mitigation status of each mitigation request. 850 { 851 "mitigation-scope":[ 852 { 853 "scope": [ 854 { 855 "policy-id": 12332, 856 "target-protocol": [ 857 17 858 ], 859 "lifetime":1800, 860 "status":2, 861 "bytes_dropped": 134334555, 862 "bps_dropped": 43344, 863 "pkts_dropped": 333334444, 864 "pps_dropped": 432432 865 } 866 ] 867 }, 868 { 869 "scope": [ 870 { 871 "policy-id": 12333, 872 "target-protocol": [ 873 6 874 ], 875 "lifetime":1800, 876 "status":3 877 "bytes_dropped": 0, 878 "bps_dropped": 0, 879 "pkts_dropped": 0, 880 "pps_dropped": 0 881 } 882 ] 883 } 884 ] 885 } 887 Figure 9: Response body 889 The mitigation status parameters are described below. 891 bytes_dropped: The total dropped byte count for the mitigation 892 request. This is a optional attribute. 893 bps_dropped: The average dropped bytes per second for the mitigation 894 request. This is a optional attribute. 895 pkts_dropped: The total dropped packet count for the mitigation 896 request. This is a optional attribute. 898 pps_dropped: The average dropped packets per second for the 899 mitigation request. This is a optional attribute. 900 status: Status of attack mitigation. The 'status' parameter is a 901 mandatory attribute. 903 The various possible values of 'status' parameter are explained 904 below: 906 /--------------------+---------------------------------------------------\ 907 | Parameter value | Description | 908 |--------------------+---------------------------------------------------| 909 | 1 | Attack mitigation is in progress | 910 | | (e.g., changing the network path to re-route the | 911 | | inbound traffic to DOTS mitigator). | 912 +------------------------------------------------------------------------+ 913 | 2 | Attack is successfully mitigated | 914 | | (e.g., traffic is redirected to a DDOS mitigator | 915 | | and attack traffic is dropped). | 916 +------------------------------------------------------------------------+ 917 | 3 | Attack has stopped and the DOTS client | 918 | | can withdraw the mitigation request. | 919 +------------------------------------------------------------------------+ 920 | 4 | Attack has exceeded the mitigation provider | 921 | | capability. | 922 \--------------------+---------------------------------------------------/ 924 The observe option defined in [RFC7641] extends the CoAP core 925 protocol with a mechanism for a CoAP client to "observe" a resource 926 on a CoAP server: the client retrieves a representation of the 927 resource and requests this representation be updated by the server as 928 long as the client is interested in the resource. A DOTS client 929 conveys the observe option set to 0 in the GET request to receive 930 unsolicited notifications of attack mitigation status from the DOTS 931 server. Unidirectional notifications within the bidirectional signal 932 channel allows unsolicited message delivery, enabling asynchronous 933 notifications between the agents. A DOTS client that is no longer 934 interested in receiving notifications from the DOTS server can simply 935 "forget" the observation. The notification response is marked as 936 Non-confirmable message. When the DOTS server then sends the next 937 notification, the DOTS client will not recognize the token in the 938 message and thus will return a Reset message. This causes the DOTS 939 server to remove the associated entry. 941 DOTS Client DOTS Server 942 | | 943 | GET / | 944 | Token: 0x4a | Registration 945 | Observe: 0 | 946 +-------------------------->| 947 | | 948 | 2.05 Content | 949 | Token: 0x4a | Notification of 950 | Observe: 12 | the current state 951 | status: "mitigation | 952 | in progress" | 953 |<--------------------------+ 954 | 2.05 Content | 955 | Token: 0x4a | Notification upon 956 | Observe: 44 | a state change 957 | status: "mitigation | 958 | complete" | 959 |<--------------------------+ 960 | 2.05 Content | 961 | Token: 0x4a | Notification upon 962 | Observe: 60 | a state change 963 | status: "attack stopped" | 964 |<--------------------------+ 965 | | 967 Figure 10: Notifications of attack mitigation status 969 5.3.3.1. Mitigation Status 971 A DOTS client retrieves the information about a DOTS signal at 972 frequent intervals to determine the status of an attack. If the DOTS 973 server has been able to mitigate the attack and the attack has 974 stopped, the DOTS server indicates as such in the status, and the 975 DOTS client recalls the mitigation request. 977 A DOTS client should react to the status of the attack from the DOTS 978 server and not the fact that it has recognized, using its own means, 979 that the attack has been mitigated. This ensures that the DOTS 980 client does not recall a mitigation request in a premature fashion 981 because it is possible that the DOTS client does not sense the DDOS 982 attack on its resources but the DOTS server could be actively 983 mitigating the attack and the attack is not completely averted. 985 5.3.4. Efficacy Update from DOTS Client 987 While DDoS mitigation is active, a DOTS client MAY frequently 988 transmit DOTS mitigation efficacy updates to the relevant DOTS 989 server. An PUT request (Figure 11) is used to convey the mitigation 990 efficacy update to the DOTS server. The PUT request MUST include all 991 the parameters used in the PUT request to convey the DOTS signal 992 (Section 5.3.1). The PUT request and response are marked as Non- 993 Confirmable messages. 995 Header: PUT (Code=0.03) 996 Uri-Host: "host" 997 Uri-Path: ".well-known" 998 Uri-Path: "version" 999 Uri-Path: "dots-signal" 1000 Uri-Path: "signal" 1001 Content-Format: "application/cbor" 1002 { 1003 "mitigation-scope": { 1004 "scope": [ 1005 { 1006 "policy-id": integer, 1007 "target-ip": [ 1008 "string" 1009 ], 1010 "target-port-range": [ 1011 { 1012 "lower-port": integer, 1013 "upper-port": integer 1014 } 1015 ], 1016 "target-protocol": [ 1017 integer 1018 ], 1019 "FQDN": [ 1020 "string" 1021 ], 1022 "URI": [ 1023 "string" 1024 ], 1025 "E.164": [ 1026 "string" 1027 ], 1028 "alias": [ 1029 "string" 1030 ], 1031 "lifetime": integer, 1032 "attack-status": integer 1033 } 1034 ] 1035 } 1036 } 1038 Figure 11: Efficacy Update 1040 The 'attack-status' parameter is a mandatory attribute. The various 1041 possible values contained in the 'attack-status' parameter are 1042 explained below: 1044 /--------------------+------------------------------------------------------\ 1045 | Parameter value | Description | 1046 |--------------------+------------------------------------------------------| 1047 | 1 | DOTS client determines that it is still under attack.| 1048 +---------------------------------------------------------------------------+ 1049 | 2 | DOTS client determines that the attack is | 1050 | | successfully mitigated | 1051 | | (e.g., attack traffic is not seen). | 1052 \--------------------+------------------------------------------------------/ 1054 The DOTS server indicates the result of processing the PUT request 1055 using CoAP response codes. The response code 2.04 (Changed) will be 1056 returned in the response if the DOTS server has accepted the 1057 mitigation efficacy update. If the DOTS server does not find the 1058 policy-id parameter value conveyed in the PUT request in its 1059 configuration data then the server MAY accept the mitigation request 1060 and will try to mitigate the attack, resulting in a 2.01 (Created) 1061 Response Code. The 5.xx response codes are returned if the DOTS 1062 server has erred or is incapable of performing the mitigation. 1064 5.4. DOTS Signal Channel Session Configuration 1066 The DOTS client can negotiate, configure and retrieve the DOTS signal 1067 channel session behavior. The DOTS signal channel can be used, for 1068 example, to configure the following: 1070 a. Heartbeat interval: DOTS agents regularly send heartbeats to each 1071 other after mutual authentication in order to keep the DOTS 1072 signal channel open. 1073 b. Acceptable signal loss ratio: Maximum retransmissions, 1074 retransmission timeout value and other message transmission 1075 parameters for the DOTS signal channel. 1077 5.4.1. Discover Acceptable Configuration Parameters 1079 A GET request is used to obtain acceptable configuration parameters 1080 on the DOTS server for DOTS signal channel session configuration. 1081 Figure 12 shows how to obtain acceptable configuration parameters for 1082 the server. The GET request and response are marked as Confirmable 1083 messages. 1085 Header: GET (Code=0.01) 1086 Uri-Host: "host" 1087 Uri-Path: ".well-known" 1088 Uri-Path: "version" 1089 Uri-Path: "dots-signal" 1090 Uri-Path: "config" 1092 Figure 12: GET to retrieve configuration 1094 The DOTS server in the 2.05 (Content) response conveys the minimum 1095 and maximum attribute values acceptable by the DOTS server. 1097 Content-Format: "application/cbor" 1098 { 1099 "heartbeat-interval": {"MinValue": integer, "MaxValue" : integer}, 1100 "max-retransmit": {"MinValue": integer, "MaxValue" : integer}, 1101 "ack-timeout": {"MinValue": integer, "MaxValue" : integer}, 1102 "ack-random-factor": {"MinValue": number, "MaxValue" : number} 1103 } 1105 Figure 13: GET response body 1107 5.4.2. Convey DOTS Signal Channel Session Configuration 1109 A POST request is used to convey the configuration parameters for the 1110 signaling channel (e.g., heartbeat interval, maximum retransmissions 1111 etc). Message transmission parameters for CoAP are defined in 1112 Section 4.8 of [RFC7252]. If the DOTS agent wishes to change the 1113 default values of message transmission parameters then it should 1114 follow the guidence given in Section 4.8.1 of [RFC7252]. The DOTS 1115 agents MUST use the negotiated values for message transmission 1116 parameters and default values for non-negotiated message transmission 1117 parameters. The signaling channel session configuration is 1118 applicable to a single DOTS signal channel session between the DOTS 1119 agents. The POST request and response are marked as Confirmable 1120 messages. 1122 Header: POST (Code=0.02) 1123 Uri-Host: "host" 1124 Uri-Path: ".well-known" 1125 Uri-Path: "version" 1126 Uri-Path: "dots-signal" 1127 Uri-Path: "config" 1128 Content-Format: "application/cbor" 1129 { 1130 "signal-config": { 1131 "policy-id": integer, 1132 "heartbeat-interval": integer, 1133 "max-retransmit": integer, 1134 "ack-timeout": integer, 1135 "ack-random-factor": number 1136 } 1137 } 1139 Figure 14: POST to convey the DOTS signal channel session 1140 configuration data. 1142 The parameters are described below: 1144 policy-id: Identifier for the DOTS signal channel session 1145 configuration data represented as an integer. This identifier 1146 MUST be generated by the DOTS client. This document does not make 1147 any assumption about how this identifier is generated. This is a 1148 mandatory attribute. 1149 heartbeat-interval: Heartbeat interval to check the DOTS peer 1150 health. This is an optional attribute. 1151 max-retransmit: Maximum number of retransmissions for a message 1152 (referred to as MAX_RETRANSMIT parameter in CoAP). This is an 1153 optional attribute. 1154 ack-timeout: Timeout value in seconds used to calculate the intial 1155 retransmission timeout value (referred to as ACK_TIMEOUT parameter 1156 in CoAP). This is an optional attribute. 1157 ack-random-factor: Random factor used to influence the timing of 1158 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1159 CoAP). This is an optional attribute. 1161 In the POST request at least one of the attributes heartbeat-interval 1162 or max-retransmit or ack-timeout or ack-random-factor MUST be 1163 present. The POST request with higher numeric policy-id value over- 1164 rides the DOTS signal channel session configuration data installed by 1165 a POST request with a lower numeric policy-id value. 1167 Figure 15 shows a POST request example to convey the configuration 1168 parameters for the DOTS signal channel. 1170 Header: POST (Code=0.02) 1171 Uri-Host: "www.example.com" 1172 Uri-Path: ".well-known" 1173 Uri-Path: "v1" 1174 Uri-Path: "dots-signal" 1175 Uri-Path: "config" 1176 Content-Format: "application/cbor" 1177 { 1178 "signal-config": { 1179 "policy-id": 1234534333242, 1180 "heartbeat-interval": 30, 1181 "max-retransmit": 7, 1182 "ack-timeout": 5, 1183 "ack-random-factor": 1.5 1184 } 1185 } 1187 Figure 15: POST to convey the configuration parameters 1189 The DOTS server indicates the result of processing the POST request 1190 using CoAP response codes. The CoAP response will include the CBOR 1191 body received in the request. Response code 2.01 (Created) will be 1192 returned in the response if the DOTS server has accepted the 1193 configuration parameters. If the request is missing one or more 1194 mandatory attributes then 4.00 (Bad Request) will be returned in the 1195 response or if the request contains invalid or unknown parameters 1196 then 4.02 (Invalid query) will be returned in the response. Response 1197 code 4.22 (Unprocessable Entity) will be returned in the response if 1198 any of the heartbeat-interval, max-retransmit, target-protocol, ack- 1199 timeout and ack-random-factor attribute values is not acceptable to 1200 the DOTS server. The DOTS server in the error response conveys the 1201 minumum and maximum attribute values acceptable by the DOTS server. 1202 The DOTS client can re-try and send the POST request with updated 1203 attribute values acceptable to the DOTS server. 1205 Content-Format: "application/cbor" 1206 { 1207 "heartbeat-interval": {"MinValue": 15, "MaxValue" : 60}, 1208 "max-retransmit": {"MinValue": 3, "MaxValue" : 15}, 1209 "ack-timeout": {"MinValue": 1, "MaxValue" : 30}, 1210 "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0} 1211 } 1213 Figure 16: Error response body 1215 5.4.3. Delete DOTS Signal Channel Session Configuration 1217 A DELETE request is used to delete the installed DOTS signal channel 1218 session configuration data (Figure 17). The DELETE request and 1219 response are marked as Confirmable messages. 1221 Header: DELETE (Code=0.04) 1222 Uri-Host: "host" 1223 Uri-Path: ".well-known" 1224 Uri-Path: "version" 1225 Uri-Path: "dots-signal" 1226 Uri-Path: "config" 1227 Content-Format: "application/cbor" 1228 { 1229 "signal-config": { 1230 "policy-id": integer 1231 } 1232 } 1234 Figure 17: DELETE configuration 1236 If the DOTS server does not find the policy-id parameter value 1237 conveyed in the DELETE request in its configuration data, then it 1238 responds with a 4.04 (Not Found) error response code. The DOTS 1239 server successfully acknowledges a DOTS client's request to remove 1240 the DOTS signal channel session configuration using 2.02 (Deleted) 1241 response code. 1243 5.4.4. Retrieving DOTS Signal Channel Session Configuration 1245 A GET request is used to retrieve the installed DOTS signal channel 1246 session configuration data from a DOTS server. Figure 18 shows how 1247 to retrieve the DOTS signal channel session configuration data. The 1248 GET request and response are marked as Confirmable messages. 1250 Header: GET (Code=0.01) 1251 Uri-Host: "host" 1252 Uri-Path: ".well-known" 1253 Uri-Path: "version" 1254 Uri-Path: "dots-signal" 1255 Uri-Path: "config" 1256 Content-Format: "application/cbor" 1257 { 1258 "signal-config": { 1259 "policy-id": integer 1260 } 1261 } 1263 Figure 18: GET to retrieve configuration 1265 5.5. Redirected Signaling 1267 Redirected Signaling is discussed in detail in Section 3.2.2 of 1268 [I-D.ietf-dots-architecture]. If the DOTS server wants to redirect 1269 the DOTS client to an alternative DOTS server for a signaling session 1270 then the response code 3.00 (alternate server) will be returned in 1271 the response to the client. The DOTS server can return the error 1272 response code 3.00 in response to a POST or PUT request from the DOTS 1273 client or convey the error response code 3.00 in a unidirectional 1274 notification response from the DOTS server. The DOTS server can mark 1275 the notification response conveying the alternate server address as a 1276 a Confirmable message to request an acknowledgement from the DOTS 1277 client. 1279 The DOTS server in the error response conveys the alternate DOTS 1280 server FQDN, and the alternate DOTS server IP addresses and TTL (time 1281 to live) values in the CBOR body. 1283 { 1284 "alt-server": "string", 1285 "alt-server-record": [ 1286 { 1287 "addr": "string", 1288 "TTL" : integer, 1289 } 1290 ] 1291 } 1293 Figure 19: Error response body 1295 The parameters are described below: 1297 alt-server: FQDN of alternate DOTS server. 1299 addr: IP address of alternate DOTS server. 1300 TTL: Time to live represented as an integer number of seconds. 1302 Figure 20 shows a 3.00 response example to convey the DOTS alternate 1303 server www.example-alt.com, its IP addresses 2002:db8:6401::1 and 1304 2002:db8:6401::2, and TTL values 3600 and 1800. 1306 { 1308 "alt-server": "www.example-alt.com", 1309 "alt-server-record": [ 1310 { 1311 "TTL" : 3600, 1312 "addr": "2002:db8:6401::1" 1313 }, 1314 { 1315 "TTL" : 1800, 1316 "addr": "2002:db8:6401::2" 1317 } 1318 ] 1319 } 1321 Figure 20: Example of error response body 1323 When the DOTS client receives 3.00 response, it considers the current 1324 request as having failed, but SHOULD try the request with the 1325 alternate DOTS server. During a DDOS attack, the DNS server may be 1326 subjected to DDOS attack, alternate DOTS server IP addresses conveyed 1327 in the 3.00 response help the DOTS client to skip DNS lookup of the 1328 alternate DOTS server and can try to establish UDP or TCP session 1329 with the alternate DOTS server IP addresses. The DOTS client SHOULD 1330 implement DNS64 function to handle the scenario where IPv6-only DOTS 1331 client communicates with IPv4-only alternate DOTS server. 1333 5.6. Heartbeat Mechanism 1335 While the communication between the DOTS agents is quiescent, the 1336 DOTS client will probe the DOTS server to ensure it has maintained 1337 cryptographic state and vice versa. Such probes can also keep alive 1338 firewall or NAT bindings. This probing reduces the frequency of 1339 needing a new handshake when a DOTS signal needs to be conveyed to 1340 the DOTS server. In DOTS over UDP, heartbeat messages can be 1341 exchanged between the DOTS agents using the "COAP ping" mechanism 1342 (Section 4.2 in [RFC7252]). The DOTS agent sends an Empty 1343 Confirmable message and the peer DOTS agent will respond by sending 1344 an Reset message. In DOTS over TCP, heartbeat messages can be 1345 exchanged between the DOTS agents using the Ping and Pong messages 1346 (Section 4.4 in [I-D.ietf-core-coap-tcp-tls]). The DOTS agent sends 1347 an Ping message and the peer DOTS agent will respond by sending an 1348 single Pong message. 1350 6. Mapping parameters to CBOR 1352 All parameters in DOTS signal channel are mapped to CBOR types as 1353 follows and are given an integer key value to save space. 1355 /--------------------+------------------------+--------------------------\ 1356 | Parameter name | CBOR key | CBOR major type of value | 1357 |--------------------+------------------------+--------------------------| 1358 | mitigation-scope | 1 | 5 (map) | 1359 | scope | 2 | 5 (map) | 1360 | policy-id | 3 | 0 (unsigned) | 1361 | target-ip | 4 | 4 (array) | 1362 | target-port-range | 5 | 4 | 1363 | lower-port | 6 | 0 | 1364 | upper-port | 7 | 0 | 1365 | target-protocol | 8 | 4 | 1366 | FQDN | 9 | 4 | 1367 | URI | 10 | 4 | 1368 | E.164 | 11 | 4 | 1369 | alias | 12 | 4 | 1370 | lifetime | 13 | 0 | 1371 | attack-status | 14 | 0 | 1372 | signal-config | 15 | 5 | 1373 | heartbeat-interval | 16 | 0 | 1374 | max-retransmit | 17 | 0 | 1375 | ack-timeout | 18 | 0 | 1376 | ack-random-factor | 19 | 7 | 1377 | MinValue | 20 | 0 | 1378 | MaxValue | 21 | 0 | 1379 | status | 22 | 0 | 1380 | bytes_dropped | 23 | 0 | 1381 | bps_dropped | 24 | 0 | 1382 | pkts_dropped | 25 | 0 | 1383 | pps_dropped | 26 | 0 | 1384 \--------------------+------------------------+--------------------------/ 1386 Figure 21: CBOR mappings used in DOTS signal channel message 1388 7. (D)TLS Protocol Profile and Performance considerations 1390 This section defines the (D)TLS protocol profile of DOTS signal 1391 channel over (D)TLS and DOTS data channel over TLS. 1393 There are known attacks on (D)TLS, such as machine-in-the-middle and 1394 protocol downgrade. These are general attacks on (D)TLS and not 1395 specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for 1396 discussion of these security issues. DOTS agents MUST adhere to the 1397 (D)TLS implementation recommendations and security considerations of 1398 [RFC7525] except with respect to (D)TLS version. Since encryption of 1399 DOTS using (D)TLS is virtually a green-field deployment DOTS agents 1400 MUST implement only (D)TLS 1.2 or later. 1402 Implementations compliant with this profile MUST implement all of the 1403 following items: 1405 o DOTS agents MUST support DTLS record replay detection (Section 3.3 1406 in [RFC6347]) to protect against replay attacks. 1407 o DOTS client can use (D)TLS session resumption without server-side 1408 state [RFC5077] to resume session and convey the DOTS signal. 1409 o Raw public keys [RFC7250] which reduce the size of the 1410 ServerHello, and can be used by servers that cannot obtain 1411 certificates (e.g., DOTS gateways on private networks). 1413 Implementations compliant with this profile SHOULD implement all of 1414 the following items to reduce the delay required to deliver a DOTS 1415 signal: 1417 o TLS False Start [RFC7918] which reduces round-trips by allowing 1418 the TLS second flight of messages (ChangeCipherSpec) to also 1419 contain the DOTS signal. 1420 o Cached Information Extension [RFC7924] which avoids transmitting 1421 the server's certificate and certificate chain if the client has 1422 cached that information from a previous TLS handshake. 1423 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 1424 convey DOTS signal. 1426 7.1. MTU and Fragmentation Issues 1428 To avoid DOTS signal message fragmentation and the consequently 1429 decreased probability of message delivery, DOTS agents MUST ensure 1430 that the DTLS record MUST fit within a single datagram. If the Path 1431 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 1432 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 1433 is used to convey the DOTS signal messages then the DOTS client must 1434 consider the amount of record expansion expected by the DTLS 1435 processing when calculating the size of CoAP message that fits within 1436 the path MTU. Path MTU MUST be greater than or equal to [CoAP 1437 message size + DTLS overhead of 13 octets + authentication overhead 1438 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 1439 of [RFC6347]]. If the request size exceeds the Path MTU then the 1440 DOTS client MUST split the DOTS signal into separate messages, for 1441 example the list of addresses in the 'target-ip' parameter could be 1442 split into multiple lists and each list conveyed in a new POST 1443 request. 1445 Implementation Note: DOTS choice of message size parameters works 1446 well with IPv6 and with most of today's IPv4 paths. However, with 1447 IPv4, it is harder to absolutely ensure that there is no IP 1448 fragmentation. If IPv4 support on unusual networks is a 1449 consideration and path MTU is unknown, implementations may want to 1450 limit themselves to more conservative IPv4 datagram sizes such as 576 1451 bytes, as per [RFC0791] IP packets up to 576 bytes should never need 1452 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal 1453 over a UDP datagram will generally avoid IP fragmentation. 1455 8. (D)TLS 1.3 considerations 1457 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 1458 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 1459 [I-D.rescorla-tls-dtls13] is based on the TLS 1.3 protocol and 1460 provides equivalent security guarantees. (D)TLS 1.3 provides two 1461 basic handshake modes of interest to DOTS signal channel: 1463 o Absent packet loss, a full handshake in which the DOTS client is 1464 able to send the DOTS signal message after one round trip and the 1465 DOTS server immediately after receiving the first DOTS signal 1466 message from the client. 1467 o 0-RTT mode in which the DOTS client can authenticate itself and 1468 send DOTS signal message on its first flight, thus reducing 1469 handshake latency. 0-RTT only works if the DOTS client has 1470 previously communicated with that DOTS server, which is very 1471 likely with the DOTS signal channel. The DOTS client SHOULD 1472 establish a (D)TLS session with the DOTS server during peacetime 1473 and share a PSK. During DDOS attack, the DOTS client can use the 1474 (D)TLS session to convey the DOTS signal message and if there is 1475 no response from the server after multiple re-tries then the DOTS 1476 client can resume the (D)TLS session in 0-RTT mode using PSK. A 1477 simplified TLS 1.3 handshake with 0-RTT DOTS signal message 1478 exchange is shown in Figure 22. 1480 DOTS Client DOTS Server 1482 ClientHello 1483 (Finished) 1484 (0-RTT DOTS signal message) 1485 (end_of_early_data) --------> 1486 ServerHello 1487 {EncryptedExtensions} 1488 {ServerConfiguration} 1489 {Certificate} 1490 {CertificateVerify} 1491 {Finished} 1492 <-------- [DOTS signal message] 1493 {Finished} --------> 1495 [DOTS signal message] <-------> [DOTS signal message] 1497 Figure 22: TLS 1.3 handshake with 0-RTT 1499 9. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 1501 (D)TLS based on client certificate can be used for mutual 1502 authentication between DOTS agents. If a DOTS gateway is involved, 1503 DOTS clients and DOTS gateway MUST perform mutual authentication; 1504 only authorized DOTS clients are allowed to send DOTS signals to a 1505 DOTS gateway. DOTS gateway and DOTS server MUST perform mutual 1506 authentication; DOTS server only allows DOTS signals from authorized 1507 DOTS gateway, creating a two-link chain of transitive authentication 1508 between the DOTS client and the DOTS server. 1510 +-------------------------------------------------+ 1511 | example.com domain +---------+ | 1512 | | AAA | | 1513 | +---------------+ | Server | | 1514 | | Application | +------+--+ | 1515 | | server + ^ 1516 | | (DOTS client) |<-----------------+ | | 1517 | +---------------+ + | | example.net domain 1518 | V V | 1519 | +-------------+ | +---------------+ 1520 | +--------------+ | | | | | 1521 | | Guest +<-----x----->+ +<---------------->+ DOTS | 1522 | | (DOTS client)| | DOTS | | | Server | 1523 | +--------------+ | Gateway | | | | 1524 | +----+--------+ | +---------------+ 1525 | ^ | 1526 | | | 1527 | +----------------+ | | 1528 | | DDOS detector | | | 1529 | | (DOTS client) +<--------------+ | 1530 | +----------------+ | 1531 | | 1532 +-------------------------------------------------+ 1534 Figure 23: Example of Authentication and Authorization of DOTS Agents 1536 In the example depicted in Figure 23, the DOTS gateway and DOTS 1537 clients within the 'example.com' domain mutually authenticate with 1538 each other. After the DOTS gateway validates the identity of a DOTS 1539 client, it communicates with the AAA server in the 'example.com' 1540 domain to determine if the DOTS client is authorized to request DDOS 1541 mitigation. If the DOTS client is not authorized, a 4.01 1542 (Unauthorized) is returned in the response to the DOTS client. In 1543 this example, the DOTS gateway only allows the application server and 1544 DDOS detector to request DDOS mitigation, but does not permit the 1545 user of type 'guest' to request DDOS mitigation. 1547 Also, DOTS gateway and DOTS server MUST perform mutual authentication 1548 using certificates. A DOTS server will only allow a DOTS gateway 1549 with a certificate for a particular domain to request mitigation for 1550 that domain. In reference to Figure 23, the DOTS server only allows 1551 the DOTS gateway to request mitigation for 'example.com' domain and 1552 not for other domains. 1554 10. IANA Considerations 1556 This specification registers new parameters for DOTS signal channel 1557 and establishes registries for mappings to CBOR. 1559 10.1. DOTS signal channel CBOR Mappings Registry 1561 A new registry will be requested from IANA, entitled "DOTS signal 1562 channel CBOR Mappings Registry". The registry is to be created as 1563 Expert Review Required. 1565 10.1.1. Registration Template 1567 Parameter name: 1568 Parameter names (e.g., "target_ip") in the DOTS signal channel. 1569 CBOR Key Value: 1570 Key value for the parameter. The key value MUST be an integer in 1571 the range of 1 to 65536. The key values in the range of 32768 to 1572 65536 are assigned for Vendor-Specific parameters. 1573 CBOR Major Type: 1574 CBOR Major type and optional tag for the claim. 1575 Change Controller: 1576 For Standards Track RFCs, list the "IESG". For others, give the 1577 name of the responsible party. Other details (e.g., postal 1578 address, email address, home page URI) may also be included. 1579 Specification Document(s): 1580 Reference to the document or documents that specify the parameter, 1581 preferably including URIs that can be used to retrieve copies of 1582 the documents. An indication of the relevant sections may also be 1583 included but is not required. 1585 10.1.2. Initial Registry Contents 1587 o Parameter Name: "mitigation-scope" 1588 o CBOR Key Value: 1 1589 o CBOR Major Type: 5 1590 o Change Controller: IESG 1591 o Specification Document(s): this document 1593 o Parameter Name: "scope" 1594 o CBOR Key Value: 2 1595 o CBOR Major Type: 5 1596 o Change Controller: IESG 1597 o Specification Document(s): this document 1599 o Parameter Name: "policy-id" 1600 o CBOR Key Value: 3 1601 o CBOR Major Type: 0 1602 o Change Controller: IESG 1603 o Specification Document(s): this document 1605 o Parameter Name:target-ip 1606 o CBOR Key Value: 4 1607 o CBOR Major Type: 4 1608 o Change Controller: IESG 1609 o Specification Document(s): this document 1611 o Parameter Name: target-port-range 1612 o CBOR Key Value: 5 1613 o CBOR Major Type: 4 1614 o Change Controller: IESG 1615 o Specification Document(s): this document 1617 o Parameter Name: "lower-port" 1618 o CBOR Key Value: 6 1619 o CBOR Major Type: 0 1620 o Change Controller: IESG 1621 o Specification Document(s): this document 1623 o Parameter Name: "upper-port" 1624 o CBOR Key Value: 7 1625 o CBOR Major Type: 0 1626 o Change Controller: IESG 1627 o Specification Document(s): this document 1629 o Parameter Name: target-protocol 1630 o CBOR Key Value: 8 1631 o CBOR Major Type: 4 1632 o Change Controller: IESG 1633 o Specification Document(s): this document 1635 o Parameter Name: "FQDN" 1636 o CBOR Key Value: 9 1637 o CBOR Major Type: 4 1638 o Change Controller: IESG 1639 o Specification Document(s): this document 1641 o Parameter Name: "URI" 1642 o CBOR Key Value: 10 1643 o CBOR Major Type: 4 1644 o Change Controller: IESG 1645 o Specification Document(s): this document 1647 o Parameter Name: "E.164" 1648 o CBOR Key Value: 11 1649 o CBOR Major Type: 4 1650 o Change Controller: IESG 1651 o Specification Document(s): this document 1653 o Parameter Name: alias 1654 o CBOR Key Value: 12 1655 o CBOR Major Type: 4 1656 o Change Controller: IESG 1657 o Specification Document(s): this document 1659 o Parameter Name: "lifetime" 1660 o CBOR Key Value: 13 1661 o CBOR Major Type: 0 1662 o Change Controller: IESG 1663 o Specification Document(s): this document 1665 o Parameter Name: attack-status 1666 o CBOR Key Value: 14 1667 o CBOR Major Type: 0 1668 o Change Controller: IESG 1669 o Specification Document(s): this document 1671 o Parameter Name: signal-config 1672 o CBOR Key Value: 15 1673 o CBOR Major Type: 5 1674 o Change Controller: IESG 1675 o Specification Document(s): this document 1677 o Parameter Name: heartbeat-interval 1678 o CBOR Key Value: 16 1679 o CBOR Major Type: 0 1680 o Change Controller: IESG 1681 o Specification Document(s): this document 1683 o Parameter Name: max-retransmit 1684 o CBOR Key Value: 17 1685 o CBOR Major Type: 0 1686 o Change Controller: IESG 1687 o Specification Document(s): this document 1689 o Parameter Name: ack-timeout 1690 o CBOR Key Value: 18 1691 o CBOR Major Type: 0 1692 o Change Controller: IESG 1693 o Specification Document(s): this document 1695 o Parameter Name: ack-random-factor 1696 o CBOR Key Value: 19 1697 o CBOR Major Type: 7 1698 o Change Controller: IESG 1699 o Specification Document(s): this document 1701 o Parameter Name: MinValue 1702 o CBOR Key Value: 20 1703 o CBOR Major Type: 0 1704 o Change Controller: IESG 1705 o Specification Document(s): this document 1707 o Parameter Name: MaxValue 1708 o CBOR Key Value: 21 1709 o CBOR Major Type: 0 1710 o Change Controller: IESG 1711 o Specification Document(s): this document 1713 o Parameter Name: status 1714 o CBOR Key Value: 22 1715 o CBOR Major Type: 0 1716 o Change Controller: IESG 1717 o Specification Document(s): this document 1719 o Parameter Name: bytes_dropped 1720 o CBOR Key Value: 23 1721 o CBOR Major Type: 0 1722 o Change Controller: IESG 1723 o Specification Document(s): this document 1725 o Parameter Name: bps_dropped 1726 o CBOR Key Value: 24 1727 o CBOR Major Type: 0 1728 o Change Controller: IESG 1729 o Specification Document(s): this document 1731 o Parameter Name: pkts_dropped 1732 o CBOR Key Value: 25 1733 o CBOR Major Type: 0 1734 o Change Controller: IESG 1735 o Specification Document(s): this document 1737 o Parameter Name: pps_dropped 1738 o CBOR Key Value: 26 1739 o CBOR Major Type: 0 1740 o Change Controller: IESG 1741 o Specification Document(s): this document 1743 11. Security Considerations 1745 Authenticated encryption MUST be used for data confidentiality and 1746 message integrity. (D)TLS based on client certificate MUST be used 1747 for mutual authentication. The interaction between the DOTS agents 1748 requires Datagram Transport Layer Security (DTLS) and Transport Layer 1749 Security (TLS) with a cipher suite offering confidentiality 1750 protection and the guidance given in [RFC7525] MUST be followed to 1751 avoid attacks on (D)TLS. 1753 If TCP is used between DOTS agents, an attacker may be able to inject 1754 RST packets, bogus application segments, etc., regardless of whether 1755 TLS authentication is used. Because the application data is TLS 1756 protected, this will not result in the application receiving bogus 1757 data, but it will constitute a DoS on the connection. This attack 1758 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 1759 any bogus packets injected by an attacker will be rejected by the 1760 TCP-AO integrity check and therefore will never reach the TLS layer. 1762 Special care should be taken in order to ensure that the activation 1763 of the proposed mechanism won't have an impact on the stability of 1764 the network (including connectivity and services delivered over that 1765 network). 1767 Involved functional elements in the cooperation system must establish 1768 exchange instructions and notification over a secure and 1769 authenticated channel. Adequate filters can be enforced to avoid 1770 that nodes outside a trusted domain can inject request such as 1771 deleting filtering rules. Nevertheless, attacks can be initiated 1772 from within the trusted domain if an entity has been corrupted. 1773 Adequate means to monitor trusted nodes should also be enabled. 1775 12. Contributors 1777 The following individuals have contributed to this document: 1779 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 1780 mgeller@cisco.com 1782 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 1783 Email: rgm@htt-consult.com 1785 Dan Wing Email: dwing-ietf@fuggles.com 1787 13. Acknowledgements 1789 Thanks to Christian Jacquenet, Roland Dobbins, Andrew Mortensen, 1790 Roman D. Danyliw, Michael Richardson, Ehud Doron, Kaname Nishizuka, 1791 Dave Dolson and Gilbert Clark for the discussion and comments. 1793 14. References 1795 14.1. Normative References 1797 [I-D.ietf-core-coap-tcp-tls] 1798 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1799 Silverajan, B., and B. Raymor, "CoAP (Constrained 1800 Application Protocol) over TCP, TLS, and WebSockets", 1801 draft-ietf-core-coap-tcp-tls-06 (work in progress), 1802 February 2017. 1804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1805 Requirement Levels", BCP 14, RFC 2119, 1806 DOI 10.17487/RFC2119, March 1997, 1807 . 1809 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1810 (TLS) Protocol Version 1.2", RFC 5246, 1811 DOI 10.17487/RFC5246, August 2008, 1812 . 1814 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1815 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1816 June 2010, . 1818 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1819 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1820 January 2012, . 1822 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1823 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1824 Transport Layer Security (TLS) and Datagram Transport 1825 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1826 June 2014, . 1828 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1829 Application Protocol (CoAP)", RFC 7252, 1830 DOI 10.17487/RFC7252, June 2014, 1831 . 1833 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1834 "Recommendations for Secure Use of Transport Layer 1835 Security (TLS) and Datagram Transport Layer Security 1836 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1837 2015, . 1839 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1840 Application Protocol (CoAP)", RFC 7641, 1841 DOI 10.17487/RFC7641, September 2015, 1842 . 1844 14.2. Informative References 1846 [I-D.ietf-core-comi] 1847 Stok, P., Bierman, A., Veillette, M., and A. Pelov, "CoAP 1848 Management Interface", draft-ietf-core-comi-00 (work in 1849 progress), January 2017. 1851 [I-D.ietf-core-yang-cbor] 1852 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 1853 Minaburo, "CBOR Encoding of Data Modeled with YANG", 1854 draft-ietf-core-yang-cbor-04 (work in progress), February 1855 2017. 1857 [I-D.ietf-dots-architecture] 1858 Mortensen, A., Andreasen, F., Reddy, T., 1859 christopher_gray3@cable.comcast.com, c., Compton, R., and 1860 N. Teague, "Distributed-Denial-of-Service Open Threat 1861 Signaling (DOTS) Architecture", draft-ietf-dots- 1862 architecture-01 (work in progress), October 2016. 1864 [I-D.ietf-dots-requirements] 1865 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1866 Denial of Service (DDoS) Open Threat Signaling 1867 Requirements", draft-ietf-dots-requirements-03 (work in 1868 progress), October 2016. 1870 [I-D.ietf-dots-use-cases] 1871 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 1872 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 1873 Open Threat Signaling", draft-ietf-dots-use-cases-03 (work 1874 in progress), November 2016. 1876 [I-D.ietf-tls-tls13] 1877 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1878 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 1879 October 2016. 1881 [I-D.ietf-tsvwg-rfc5405bis] 1882 Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1883 Guidelines", draft-ietf-tsvwg-rfc5405bis-19 (work in 1884 progress), October 2016. 1886 [I-D.reddy-dots-data-channel] 1887 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 1888 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 1889 Service Open Threat Signaling (DOTS) Data Channel", draft- 1890 reddy-dots-data-channel-04 (work in progress), February 1891 2017. 1893 [I-D.rescorla-tls-dtls13] 1894 Rescorla, E. and H. Tschofenig, "The Datagram Transport 1895 Layer Security (DTLS) Protocol Version 1.3", draft- 1896 rescorla-tls-dtls13-00 (work in progress), October 2016. 1898 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1899 DOI 10.17487/RFC0791, September 1981, 1900 . 1902 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1903 (CIDR): The Internet Address Assignment and Aggregation 1904 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1905 2006, . 1907 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1908 Denial-of-Service Considerations", RFC 4732, 1909 DOI 10.17487/RFC4732, December 2006, 1910 . 1912 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1913 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1914 . 1916 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1917 "Transport Layer Security (TLS) Session Resumption without 1918 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1919 January 2008, . 1921 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1922 Layer Security (TLS) and Datagram Transport Layer Security 1923 (DTLS) Heartbeat Extension", RFC 6520, 1924 DOI 10.17487/RFC6520, February 2012, 1925 . 1927 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1928 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 1929 2012, . 1931 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1932 "Default Address Selection for Internet Protocol Version 6 1933 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1934 . 1936 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1937 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1938 October 2013, . 1940 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1941 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1942 . 1944 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1945 Layer Security (TLS) False Start", RFC 7918, 1946 DOI 10.17487/RFC7918, August 2016, 1947 . 1949 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1950 (TLS) Cached Information Extension", RFC 7924, 1951 DOI 10.17487/RFC7924, July 2016, 1952 . 1954 Authors' Addresses 1956 Tirumaleswar Reddy 1957 Cisco Systems, Inc. 1958 Cessna Business Park, Varthur Hobli 1959 Sarjapur Marathalli Outer Ring Road 1960 Bangalore, Karnataka 560103 1961 India 1963 Email: tireddy@cisco.com 1965 Mohamed Boucadair 1966 Orange 1967 Rennes 35000 1968 France 1970 Email: mohamed.boucadair@orange.com 1971 Prashanth Patil 1972 Cisco Systems, Inc. 1974 Email: praspati@cisco.com