idnits 2.17.1 draft-ietf-dots-signal-channel-07.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 87 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 368 has weird spacing: '...er-port ine...' == Line 369 has weird spacing: '...er-port ine...' -- The document date (November 12, 2017) is 2350 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 2121, but not defined == Unused Reference: 'RFC7030' is defined on line 2652, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-10 ** 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) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-01 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-05 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-05 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-06 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-07 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-09 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 5 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: May 16, 2018 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 November 12, 2017 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel 16 draft-ietf-dots-signal-channel-07 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. A companion 24 document defines the DOTS data channel, a separate reliable 25 communication layer for DOTS management and configuration. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 16, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Notational Conventions and Terminology . . . . . . . . . . . 3 63 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . . . 5 65 5. DOTS Signal Channel . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. DOTS Signal YANG Module . . . . . . . . . . . . . . . . . 8 68 5.2.1. Mitigation Request YANG Module Tree Structure . . . . 8 69 5.2.2. Mitigation Request YANG Module . . . . . . . . . . . 9 70 5.2.3. Session Configuration YANG Module Tree Structure . . 11 71 5.2.4. Session Configuration YANG Module . . . . . . . . . . 12 72 5.3. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.4. Mitigation Request . . . . . . . . . . . . . . . . . . . 15 74 5.4.1. Requesting mitigation . . . . . . . . . . . . . . . . 15 75 5.4.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 24 76 5.4.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 25 77 5.4.4. Efficacy Update from DOTS Client . . . . . . . . . . 30 78 5.5. DOTS Signal Channel Session Configuration . . . . . . . . 32 79 5.5.1. Discover Configuration Parameters . . . . . . . . . . 33 80 5.5.2. Convey DOTS Signal Channel Session Configuration . . 35 81 5.5.3. Delete DOTS Signal Channel Session Configuration . . 39 82 5.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 40 83 5.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 41 84 6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 42 85 7. (D)TLS Protocol Profile and Performance considerations . . . 43 86 7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 44 87 8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 45 88 9. Mutual Authentication of DOTS Agents & Authorization of DOTS 89 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 91 10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 48 92 10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 48 93 10.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 48 94 10.4. DOTS signal channel CBOR Mappings Registry . . . . . . . 48 95 10.4.1. Registration Template . . . . . . . . . . . . . . . 49 96 10.4.2. Initial Registry Contents . . . . . . . . . . . . . 49 98 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 54 99 11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 54 100 12. Security Considerations . . . . . . . . . . . . . . . . . . . 55 101 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56 102 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 103 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 104 15.1. Normative References . . . . . . . . . . . . . . . . . . 56 105 15.2. Informative References . . . . . . . . . . . . . . . . . 57 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 108 1. Introduction 110 A distributed denial-of-service (DDoS) attack is an attempt to make 111 machines or network resources unavailable to their intended users. 112 In most cases, sufficient scale can be achieved by compromising 113 enough end-hosts and using those infected hosts to perpetrate and 114 amplify the attack. The victim in this attack can be an application 115 server, a host, a router, a firewall, or an entire network. 117 In many cases, it may not be possible for network administrators to 118 determine the causes of an attack, but instead just realize that 119 certain resources seem to be under attack. This document defines a 120 lightweight protocol permitting a DOTS client to request mitigation 121 from one or more DOTS servers for protection against detected, 122 suspected, or anticipated attacks . This protocol enables cooperation 123 between DOTS agents to permit a highly-automated network defense that 124 is robust, reliable and secure. 126 The document adheres to the DOTS architecture 127 [I-D.ietf-dots-architecture]. The requirements for DOTS signal 128 channel protocol are obtained from [I-D.ietf-dots-requirements]. 129 This document satisfies all the use cases discussed in 130 [I-D.ietf-dots-use-cases]. 132 This is a companion document to the DOTS data channel specification 133 [I-D.ietf-dots-data-channel] that defines a configuration and bulk 134 data exchange mechanism supporting the DOTS signal channel. 136 2. Notational Conventions and Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in 141 [RFC2119]. 143 (D)TLS: For brevity this term is used for statements that apply to 144 both Transport Layer Security [RFC5246] and Datagram Transport Layer 145 Security [RFC6347]. Specific terms will be used for any statement 146 that applies to either protocol alone. 148 The reader should be familiar with the terms defined in 149 [I-D.ietf-dots-architecture]. 151 3. Solution Overview 153 Network applications have finite resources like CPU cycles, number of 154 processes or threads they can create and use, maximum number of 155 simultaneous connections it can handle, limited resources of the 156 control plane, etc. When processing network traffic, such 157 applications are supposed to use these resources to offer the 158 intended task in the most efficient fashion. However, an attacker 159 may be able to prevent an application from performing its intended 160 task by causing the application to exhaust the finite supply of a 161 specific resource. 163 TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the 164 victim and ACK-flood is a CPU exhaustion attack on the victim 165 ([RFC4987]). Attacks on the link are carried out by sending enough 166 traffic such that the link becomes excessively congested, and 167 legitimate traffic suffers high packet loss. Stateful firewalls can 168 also be attacked by sending traffic that causes the firewall to hold 169 excessive state. The firewall then runs out of memory, and can no 170 longer instantiate the state required to pass legitimate flows. 171 Other possible DDoS attacks are discussed in [RFC4732]. 173 In each of the cases described above, the possible arrangements 174 between the DOTS client and DOTS server to mitigate the attack are 175 discussed in [I-D.ietf-dots-use-cases]. An example of network 176 diagram showing a deployment of these elements is shown in Figure 1. 177 Architectural relationships between involved DOTS agents is explained 178 in [I-D.ietf-dots-architecture]. In this example, the DOTS server is 179 operating on the access network. 181 Network 182 Resource CPE router Access network __________ 183 +-----------+ +--------------+ +-------------+ / \ 184 | |____| |_______| |___ | Internet | 185 |DOTS client| | DOTS gateway | | DOTS server | | | 186 | | | | | | | | 187 +-----------+ +--------------+ +-------------+ \__________/ 189 Figure 1: Sample DOTS Deployment (1) 191 The DOTS server can also be running on the Internet, as depicted in 192 Figure 2. 194 Network DDoS mitigation 195 Resource CPE router __________ service 196 +-----------+ +-------------+ / \ +-------------+ 197 | |____| |_______| |___ | | 198 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 199 | | | | | | | | 200 +-----------+ +-------------+ \__________/ +-------------+ 202 Figure 2: Sample DOTS Deployment (2) 204 In typical deployments, the DOTS client belongs to a different 205 administrative domain than the DOTS server. For example, the DOTS 206 client is a firewall protecting services owned and operated by an 207 domain, while the DOTS server is owned and operated by a different 208 domain providing DDoS mitigation services. That domain providing 209 DDoS mitigation service might, or might not, also provide Internet 210 access service to the website operator. 212 The DOTS server may (not) be co-located with the DOTS mitigator. In 213 typical deployments, the DOTS server belongs to the same 214 administrative domain as the mitigator. 216 The DOTS client can communicate directly with the DOTS server or 217 indirectly via a DOTS gateway. 219 This document focuses on the DOTS signal channel. 221 4. Happy Eyeballs for DOTS Signal Channel 223 DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS 224 [RFC5246] over TCP. A DOTS client can use DNS to determine the IP 225 address(es) of a DOTS server or a DOTS client may be provided with 226 the list of DOTS server IP addresses. The DOTS client MUST know a 227 DOTS server's domain name; hard-coding the domain name of the DOTS 228 server into software is NOT RECOMMENDED in case the domain name is 229 not valid or needs to change for legal or other reasons. The DOTS 230 client performs A and/or AAAA record lookup of the domain name and 231 the result will be a list of IP addresses, each of which can be used 232 to contact the DOTS server using UDP and TCP. 234 If an IPv4 path to reach a DOTS server is found, but the DOTS 235 server's IPv6 path is not working, a dual-stack DOTS client can 236 experience a significant connection delay compared to an IPv4-only 237 DOTS client. The other problem is that if a middlebox between the 238 DOTS client and DOTS server is configured to block UDP, the DOTS 239 client will fail to establish a DTLS session with the DOTS server and 240 will, then, have to fall back to TLS over TCP incurring significant 241 connection delays. [I-D.ietf-dots-requirements] discusses that DOTS 242 client and server will have to support both connectionless and 243 connection-oriented protocols. 245 To overcome these connection setup problems, the DOTS client can try 246 connecting to the DOTS server using both IPv6 and IPv4, and try both 247 DTLS over UDP and TLS over TCP in a fashion similar to the Happy 248 Eyeballs mechanism [RFC6555]. These connection attempts are 249 performed by the DOTS client when its initializes, and the client 250 uses that information for its subsequent alert to the DOTS server. 251 In order of preference (most preferred first), it is UDP over IPv6, 252 UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which 253 adheres to address preference order [RFC6724] and the DOTS preference 254 that UDP be used over TCP (to avoid TCP's head of line blocking). 256 DOTS client DOTS server 257 | | 258 |--DTLS ClientHello, IPv6 ---->X | 259 |--TCP SYN, IPv6-------------->X | 260 |--DTLS ClientHello, IPv4 ---->X | 261 |--TCP SYN, IPv4----------------------------------------->| 262 |--DTLS ClientHello, IPv6 ---->X | 263 |--TCP SYN, IPv6-------------->X | 264 |<-TCP SYNACK---------------------------------------------| 265 |--DTLS ClientHello, IPv4 ---->X | 266 |--TCP ACK----------------------------------------------->| 267 |<------------Establish TLS Session---------------------->| 268 |----------------DOTS signal----------------------------->| 269 | | 271 Figure 3: Happy Eyeballs 273 In reference to Figure 3, the DOTS client sends two TCP SYNs and two 274 DTLS ClientHello messages at the same time over IPv6 and IPv4. In 275 this example, it is assumed that the IPv6 path is broken and UDP is 276 dropped by a middlebox but has little impact to the DOTS client 277 because there is no long delay before using IPv4 and TCP. The DOTS 278 client repeats the mechanism to discover if DOTS signaling with DTLS 279 over UDP becomes available from the DOTS server, so the DOTS client 280 can migrate the DOTS signal channel from TCP to UDP, but such probing 281 SHOULD NOT be done more frequently than every 24 hours and MUST NOT 282 be done more frequently than every 5 minutes. 284 5. DOTS Signal Channel 285 5.1. Overview 287 The DOTS signal channel is built on top of the Constrained 288 Application Protocol (CoAP) [RFC7252], a lightweight protocol 289 originally designed for constrained devices and networks. CoAP's 290 expectation of packet loss, support for asynchronous non-confirmable 291 messaging, congestion control, small message overhead limiting the 292 need for fragmentation, use of minimal resources, and support for 293 (D)TLS make it a good foundation on which to build the DOTS signaling 294 mechanism. 296 The DOTS signal channel is layered on existing standards (Figure 4). 298 By default, DOTS signal channel MUST run over port number TBD as 299 defined in Section 10.1, for both UDP and TCP, unless the DOTS server 300 has mutual agreement with its DOTS clients to use a port other than 301 TBD for DOTS signal channel, or DOTS clients supports means to 302 dynamically discover the ports used by their DOTS servers. In order 303 to use a distinct port number (vs. TBD), DOTS clients and servers 304 should support a configurable parameter to supply the port number to 305 use. 307 +--------------+ 308 | DOTS | 309 +--------------+ 310 | CoAP | 311 +--------------+ 312 | TLS | DTLS | 313 +--------------+ 314 | TCP | UDP | 315 +--------------+ 316 | IP | 317 +--------------+ 319 Figure 4: Abstract Layering of DOTS signal channel over CoAP over 320 (D)TLS 322 The signal channel is initiated by the DOTS client. Once the signal 323 channel is established, the DOTS agents periodically send heartbeats 324 to keep the channel active. At any time, the DOTS client may send a 325 mitigation request message to the DOTS server over the active 326 channel. While mitigation is active, due to the higher likelihood of 327 packet loss during a DDoS attack, the DOTS server periodically sends 328 status messages to the client, including basic mitigation feedback 329 details. Mitigation remains active until the DOTS client explicitly 330 terminates mitigation, or the mitigation lifetime expires. 332 Messages exchanged between DOTS client and server are serialized 333 using Concise Binary Object Representation (CBOR) [RFC7049], CBOR is 334 a binary encoding designed for small code and message size. CBOR 335 encoded payloads are used to convey signal channel specific payload 336 messages that convey request parameters and response information such 337 as errors. This specification uses the encoding rules defined in 338 [I-D.ietf-core-yang-cbor] for representing mitigation scope and DOTS 339 signal channel session configuration data defined using YANG 340 (Section 5.2) as CBOR data. 342 DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The 343 payload included in CoAP responses with 2.xx and 3.xx Response Codes 344 MUST be of content type "application/cbor" (Section 5.5.1 of 345 [RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes 346 MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The 347 Diagnostic Payload may contain additional information to aid 348 troubleshooting. 350 5.2. DOTS Signal YANG Module 352 This document defines a YANG [RFC6020] module for mitigation scope 353 and DOTS signal channel session configuration data. 355 5.2.1. Mitigation Request YANG Module Tree Structure 357 This document defines the YANG module "ietf-dots-signal", which has 358 the following tree structure: 360 module: ietf-dots-signal 361 +--rw mitigation-scope 362 +--rw client-identifier* binary 363 +--rw scope* [mitigation-id] 364 +--rw mitigation-id int32 365 +--rw target-ip* inet:ip-address 366 +--rw target-prefix* inet:ip-prefix 367 +--rw target-port-range* [lower-port upper-port] 368 | +--rw lower-port inet:port-number 369 | +--rw upper-port inet:port-number 370 +--rw target-protocol* uint8 371 +--rw fqdn* inet:domain-name 372 +--rw uri* inet:uri 373 +--rw alias-name* string 374 +--rw lifetime? int32 376 5.2.2. Mitigation Request YANG Module 378 file "ietf-dots-signal@2017-10-04.yang" 380 module ietf-dots-signal { 381 yang-version 1.1; 382 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; 383 prefix "signal"; 385 import ietf-inet-types { 386 prefix "inet"; 387 } 389 organization "IETF DOTS Working Group"; 391 contact 392 "Konda, Tirumaleswar Reddy 393 Mohamed Boucadair 394 Prashanth Patil 395 Andrew Mortensen 396 Nik Teague "; 398 description 399 "This module contains YANG definition for DOTS 400 signal sent by the DOTS client to the DOTS server. 402 Copyright (c) 2017 IETF Trust and the persons identified as 403 authors of the code. All rights reserved. 405 Redistribution and use in source and binary forms, with or 406 without modification, is permitted pursuant to, and subject 407 to the license terms contained in, the Simplified BSD License 408 set forth in Section 4.c of the IETF Trust's Legal Provisions 409 Relating to IETF Documents 410 (http://trustee.ietf.org/license-info). 412 This version of this YANG module is part of RFC XXXX; see 413 the RFC itself for full legal notices."; 415 revision 2017-10-04 { 416 description 417 "Add units and fix some nits."; 418 reference 419 "-05"; 420 } 422 revision 2017-08-03 { 423 reference 424 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 425 } 427 container mitigation-scope { 428 description 429 "Top level container for a mitigation request."; 431 leaf-list client-identifier { 432 type binary; 433 description 434 "A client identifier conveyed by a DOTS gateway 435 to a remote DOTS server."; 436 } 438 list scope { 439 key mitigation-id; 440 description "Identifier for the mitigation request."; 442 leaf mitigation-id { 443 type int32; 444 description "Mitigation request identifier."; 445 } 446 leaf-list target-ip { 447 type inet:ip-address; 448 description 449 "IPv4 or IPv6 address identifying the target."; 450 } 452 leaf-list target-prefix { 453 type inet:ip-prefix; 454 description 455 "IPv4 or IPv6 prefix identifying the target."; 456 } 458 list target-port-range { 459 key "lower-port upper-port"; 461 description "Port range. When only lower-port is present, 462 it represents a single port."; 464 leaf lower-port { 465 type inet:port-number; 466 mandatory true; 467 description "Lower port number."; 468 } 470 leaf upper-port { 471 type inet:port-number; 472 must ". >= ../lower-port" { 473 error-message 474 "The upper port number must be greater than or 475 equal to lower port number."; 476 } 477 description "Upper port number."; 478 } 479 } 481 leaf-list target-protocol { 482 type uint8; 483 description "Identifies the target protocol number."; 484 } 486 leaf-list fqdn { 487 type inet:domain-name; 488 description "FQDN"; 489 } 491 leaf-list uri { 492 type inet:uri; 493 description "URI"; 494 } 496 leaf-list alias-name { 497 type string; 498 description "alias name"; 499 } 501 leaf lifetime { 502 type int32; 503 units "seconds"; 504 default 3600; 506 description 507 "Indicates the lifetime of the mitigation request."; 508 } 509 } 510 } 511 } 512 514 5.2.3. Session Configuration YANG Module Tree Structure 516 This document defines the YANG module "ietf-dots-signal-config", 517 which has the following structure: 519 module: ietf-dots-signal-config 520 +--rw signal-config 521 +--rw session-id? int32 522 +--rw heartbeat-interval? int16 523 +--rw missing-hb-allowed? int16 524 +--rw max-retransmit? int16 525 +--rw ack-timeout? int16 526 +--rw ack-random-factor? decimal64 527 +--rw trigger-mitigation? boolean 529 5.2.4. Session Configuration YANG Module 531 file "ietf-dots-signal-config@2017-10-04.yang" 533 module ietf-dots-signal-config { 534 yang-version 1.1; 535 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config"; 536 prefix "config"; 538 organization "IETF DOTS Working Group"; 540 contact 541 "Konda, Tirumaleswar Reddy 542 Mohamed Boucadair 543 Prashanth Patil 544 Andrew Mortensen 545 Nik Teague "; 547 description 548 "This module contains YANG definition for DOTS 549 signal channel session configuration. 551 Copyright (c) 2017 IETF Trust and the persons identified as 552 authors of the code. All rights reserved. 554 Redistribution and use in source and binary forms, with or 555 without modification, is permitted pursuant to, and subject 556 to the license terms contained in, the Simplified BSD License 557 set forth in Section 4.c of the IETF Trust's Legal Provisions 558 Relating to IETF Documents 559 (http://trustee.ietf.org/license-info). 561 This version of this YANG module is part of RFC XXXX; see 562 the RFC itself for full legal notices."; 564 revision 2017-10-04 { 565 description 566 "Add units/defaults and fix some nits."; 568 reference 569 "-05"; 570 } 572 revision 2016-11-28 { 573 reference 574 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 575 } 577 container signal-config { 578 description "Top level container for DOTS signal channel session 579 configuration."; 581 leaf session-id { 582 type int32; 583 description "An identifier for the DOTS signal channel 584 session configuration data."; 585 } 587 leaf heartbeat-interval { 588 type int16; 589 units "seconds"; 590 default 30; 592 description 593 "DOTS agents regularly send heartbeats to each other 594 after mutual authentication in order to keep 595 the DOTS signal channel open."; 596 } 598 leaf missing-hb-allowed { 599 type int16; 600 default 5; 602 description 603 "Maximum number of missing heartbeats allowed."; 604 } 606 leaf max-retransmit { 607 type int16; 608 default 3; 610 description 611 "Maximum number of retransmissions of a 612 Confirmable message."; 613 } 615 leaf ack-timeout { 616 type int16; 617 units "seconds"; 618 default 2; 620 description 621 "Initial retransmission timeout value."; 622 } 624 leaf ack-random-factor { 625 type decimal64 { 626 fraction-digits 2; 627 } 629 default 1.5; 631 description 632 "Random factor used to influence the timing of 633 retransmissions"; 634 } 635 leaf trigger-mitigation { 636 type boolean; 637 default true; 639 description 640 "If false, then mitigation is triggered 641 only when the DOTS server channel session is lost"; 642 } 643 } 644 } 645 647 5.3. CoAP URIs 649 The DOTS server MUST support the use of the path-prefix of "/.well- 650 known/" as defined in [RFC5785] and the registered name of "dots". 651 Each DOTS operation is indicated by a path-suffix that indicates the 652 intended operation. 654 +------------------------+-----------------+-------------------+ 655 | Operation |Operation path | Details | 656 +========================+=================+===================+ 657 | Mitigation | /v1/mitigate | Section 5.4 | 658 | | | | 659 +------------------------+-----------------+-------------------+ 660 | Session configuration | /v1/config | Section 5.5 | 661 | | | | 662 +------------------------+-----------------+-------------------+ 664 Figure 5: Operations and their corresponding URIs: 666 5.4. Mitigation Request 668 The following methods are used to request or withdraw mitigation 669 requests: 671 PUT: DOTS clients use the PUT method to request mitigation 672 (Section 5.4.1). During active mitigation, DOTS clients may use 673 PUT requests to convey mitigation efficacy updates to the DOTS 674 server (Section 5.4.4). 676 DELETE: DOTS clients use the DELETE method to withdraw a request for 677 mitigation from the DOTS server (Section 5.4.2). 679 GET: DOTS clients may use the GET method to subscribe to DOTS server 680 status messages, or to retrieve the list of existing mitigations 681 (Section 5.4.3). 683 Mitigation request and response messages are marked as Non- 684 confirmable messages. DOTS agents SHOULD follow the data 685 transmission guidelines discussed in Section 3.1.3 of [RFC8085] and 686 control transmission behavior by not sending on average more than one 687 UDP datagram per RTT to the peer DOTS agent. 689 Requests marked by the DOTS client as Non-confirmable messages are 690 sent at regular intervals until a response is received from the DOTS 691 server and if the DOTS client cannot maintain a RTT estimate then it 692 SHOULD NOT send more than one Non-confirmable request every 3 693 seconds, and SHOULD use an even less aggressive rate when possible 694 (case 2 in Section 3.1.3 of [RFC8085]). 696 5.4.1. Requesting mitigation 698 When a DOTS client requires mitigation for any reason, the DOTS 699 client uses CoAP PUT method to send a mitigation request to the DOTS 700 server (Figure 6, illustrated in JSON diagnostic notation). The DOTS 701 server can enable mitigation on behalf of the DOTS client by 702 communicating the DOTS client's request to the mitigator and relaying 703 selected mitigator feedback to the requesting DOTS client. 705 Header: PUT (Code=0.03) 706 Uri-Host: "host" 707 Uri-Path: ".well-known" 708 Uri-Path: "dots" 709 Uri-Path: "version" 710 Uri-Path: "mitigate" 711 Content-Type: "application/cbor" 712 { 713 "mitigation-scope": { 714 "client-identifier": [ 715 "string" 716 ], 717 "scope": [ 718 { 719 "mitigation-id": integer, 720 "target-ip": [ 721 "string" 722 ], 723 "target-prefix": [ 724 "string" 725 ], 726 "target-port-range": [ 727 { 728 "lower-port": integer, 729 "upper-port": integer 730 } 731 ], 732 "target-protocol": [ 733 integer 734 ], 735 "fqdn": [ 736 "string" 737 ], 738 "uri": [ 739 "string" 740 ], 741 "alias-name": [ 742 "string" 743 ], 744 "lifetime": integer 745 } 746 ] 747 } 748 } 750 Figure 6: PUT to convey DOTS signals 752 The parameters are described below. 754 client-identifier: The client identifier MAY be conveyed by the DOTS 755 gateway to propagate the DOTS client identity from the gateway's 756 client-side to the gateway's server-side, and from the gateway's 757 server-side to the DOTS server. This allows the final DOTS server 758 to accept mitigation requests with scopes which the DOTS client is 759 authorized to manage. 761 The 'client-identifier' value MUST be assigned by the DOTS gateway 762 in a manner that ensures that there is no probability that the 763 same value will be assigned to a different DOTS client. The DOTS 764 gateway MUST obscure potentially sensitive DOTS client identity 765 information. The client-identifier attribute SHOULD NOT to be 766 generated and included by the DOTS client. 768 This is an optional attribute. 770 mitigation-id: Identifier for the mitigation request represented 771 using an integer. This identifier MUST be unique for each 772 mitigation request bound to the DOTS client, i.e., the mitigation- 773 id parameter value in the mitigation request needs to be unique 774 relative to the mitigation-id parameter values of active 775 mitigation requests conveyed from the DOTS client to the DOTS 776 server. This identifier MUST be generated by the DOTS client. 777 This document does not make any assumption about how this 778 identifier is generated. This is a mandatory attribute. 780 target-ip: A list of IP addresses under attack. This is an optional 781 attribute. 783 target-prefix: A list of prefixes under attack. Prefixes are 784 represented using CIDR notation [RFC4632]. This is an optional 785 attribute. 787 target-port-range: A list of ports under attack. The port range, 788 lower-port for lower port number and upper-port for upper port 789 number. When only lower-port is present, it represents a single 790 port. For TCP, UDP, Stream Control Transmission Protocol (SCTP) 791 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 792 [RFC4340]: the range of ports (e.g., 1024-65535). This is an 793 optional attribute. 795 target-protocol: A list of protocols under attack. Values are taken 796 from the IANA protocol registry [proto_numbers]. The value 0 has 797 a special meaning for 'all protocols'. This is an optional 798 attribute. 800 fqdn: A list of Fully Qualified Domain Names. Fully Qualified 801 Domain Name (FQDN) is the full name of a system, rather than just 802 its hostname. For example, "venera" is a hostname, and 803 "venera.isi.edu" is an FQDN. This is an optional attribute. 805 uri: A list of Uniform Resource Identifiers (URI). This is an 806 optional attribute. 808 alias-name: A list of aliases. Aliases can be created using the 809 DOTS data channel (Section 3.1.1 of [I-D.ietf-dots-data-channel]) 810 or direct configuration, or other means and then used in 811 subsequent signal channel exchanges to refer more efficiently to 812 the resources under attack. This is an optional attribute. 814 lifetime: Lifetime of the mitigation request in seconds. The 815 default lifetime of a mitigation request is 3600 seconds (60 816 minutes) -- this value was chosen to be long enough so that 817 refreshing is not typically a burden on the DOTS client, while 818 expiring the request where the client has unexpectedly quit in a 819 timely manner. 821 A lifetime of negative one (-1) indicates indefinite lifetime for 822 the mitigation request. 824 DOTS clients SHOULD include this parameter in their mitigation 825 requests. If no lifetime is supplied by a DOTS client, the DOTS 826 server uses the default lifetime value (3600 seconds). Upon the 827 expiry of this lifetime, and if the request is not refreshed, the 828 mitigation request is removed. The request can be refreshed by 829 sending the same request again. The server MAY refuse indefinite 830 lifetime, for policy reasons; the granted lifetime value is 831 returned in the response. DOTS clients MUST be prepared to not be 832 granted mitigations with indefinite lifetimes. The server MUST 833 always indicate the actual lifetime in the response and the 834 remaining lifetime in status messages sent to the client. This is 835 a mandatory parameter for responses. 837 The CBOR key values for the parameters are defined in Section 6. 838 Section 10 defines how the CBOR key values can be allocated to 839 standards bodies and vendors. 841 FQDN and URI mitigation scopes may be thought of as a form of scope 842 alias, in which the addresses to which the domain name or URI resolve 843 represent the full scope of the mitigation. 845 In the PUT request at least one of the attributes 'target-ip' or 846 'target-prefix' or 'fqdn' or 'uri 'or 'alias-name' MUST be present. 847 DOTS agents can safely ignore Vendor-Specific parameters they don't 848 understand. 850 The relative order of two mitigation requests from a DOTS client is 851 determined by comparing their respective 'mitigation-id' values. If 852 two mitigation requests have overlapping mitigation scopes, the 853 mitigation request with higher numeric 'mitigation-id' value will 854 override the mitigation request with a lower numeric 'mitigation-id' 855 value. Two mitigation-ids are overlapping if there is a common IP 856 address, IP prefix, FQDN, URI, or alias-name. The overlapped lower 857 numeric 'mitigation-id' MUST be automatically deleted and no longer 858 available at the DOTS server. 860 The Uri-Path option carries a major and minor version nomenclature to 861 manage versioning and DOTS signal channel in this specification uses 862 v1 major version. 864 If the DOTS client is using the certificate provisioned by the 865 Enrollment over Secure Transport (EST) server [RFC6234] in the DOTS 866 gateway-domain to authenticate itself to the DOTS gateway, then the 867 'client-identifier' value can be the output of a cryptographic hash 868 algorithm whose input is the DER-encoded ASN.1 representation of the 869 Subject Public Key Info (SPKI) of an X.509 certificate. In this 870 version of the specification, the cryptographic hash algorithm used 871 is SHA-256 [RFC6234]. The output of the cryptographic hash algorithm 872 is truncated to 16 bytes; truncation is done by stripping off the 873 final 16 bytes. The truncated output is base64url encoded. If the 874 'client-identifier' value is already present in the mitigation 875 request received from the DOTS client, the DOTS gateway MAY compute 876 the 'client-identifier' value, as discussed above, and add the 877 computed 'client-identifier' value to the end of the 'client- 878 identifier' list. The DOTS server MUST NOT use the 'client- 879 identifier' for the DOTS client authentication process. 881 In both DOTS signal and data channel sessions, the DOTS client MUST 882 authenticate itself to the DOTS server (Section 9). The DOTS server 883 may use the algorithm in Section 7 of [RFC7589] to derive the DOTS 884 client identity or username from the client certificate. The DOTS 885 client identity allows the DOTS server to accept mitigation requests 886 with scopes which the DOTS client is authorized to manage. The DOTS 887 server couples the DOTS signal and data channel sessions using the 888 DOTS client identity and the 'client-identifier' parameter value, so 889 the DOTS server can validate whether the aliases conveyed in the 890 mitigation request were indeed created by the same DOTS client using 891 the DOTS data channel session. If the aliases were not created by 892 the DOTS client, the DOTS server returns 4.00 (Bad Request) in the 893 response. 895 The DOTS server couples the DOTS signal channel sessions using the 896 DOTS client identity and the 'client-identifier' parameter value, and 897 the DOTS server uses 'mitigation-id' parameter value to detect 898 duplicate mitigation requests. If the mitigation request contains 899 both alias-name and other parameters identifying the target resources 900 (such as, 'target-ip', 'target-prefix', 'target-port-range', 'fqdn', 901 or 'uri'), then the DOTS server appends the parameter values in 902 'alias-name' with the corresponding parameter values in 'target-ip', 903 'target-prefix', 'target-port-range', 'fqdn', or 'uri'. 905 Figure 7 shows a PUT request example to signal that ports 80, 8080, 906 and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are 907 being attacked (illustrated in JSON diagnostic notation). 909 Header: PUT (Code=0.03) 910 Uri-Host: "www.example.com" 911 Uri-Path: ".well-known" 912 Uri-Path: "dots" 913 Uri-Path: "v1" 914 Uri-Path: "mitigate" 915 Content-Format: "application/cbor" 916 { 917 "mitigation-scope": { 918 "client-identifier": [ 919 "dz6pHjaADkaFTbjr0JGBpw" 920 ], 921 "scope": [ 922 { 923 "mitigation-id": 12332, 924 "target-ip": [ 925 "2001:db8:6401::1", 926 "2001:db8:6401::2" 927 ], 928 "target-port-range": [ 929 { 930 "lower-port": 80 931 }, 932 { 933 "lower-port": 443 934 }, 935 { 936 "lower-port": 8080 937 } 938 ], 939 "target-protocol": [ 940 6 941 ] 942 } 943 ] 944 } 945 } 947 The CBOR encoding format is shown below: 949 A1 # map(1) 950 01 # unsigned(1) 951 A2 # map(2) 952 18 20 # unsigned(32) 953 81 # array(1) 954 76 # text(22) 955 647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw" 956 02 # unsigned(2) 957 81 # array(1) 958 A4 # map(4) 959 03 # unsigned(3) 960 19 302C # unsigned(12332) 961 04 # unsigned(4) 962 82 # array(2) 963 70 # text(16) 964 323030313A6462383A363430313A3A31 # "2001:db8:6401::1" 965 70 # text(16) 966 323030313A6462383A363430313A3A32 # "2001:db8:6401::2" 967 05 # unsigned(5) 968 83 # array(3) 969 A1 # map(1) 970 06 # unsigned(6) 971 18 50 # unsigned(80) 972 A1 # map(1) 973 06 # unsigned(6) 974 19 01BB # unsigned(443) 975 A1 # map(1) 976 06 # unsigned(6) 977 19 1F90 # unsigned(8080) 978 08 # unsigned(8) 979 81 # array(1) 980 06 # unsigned(6) 982 Figure 7: PUT for DOTS signal 984 The DOTS server indicates the result of processing the PUT request 985 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 986 codes are some sort of invalid requests. Figure 8 shows a PUT 987 response for CoAP 2.xx response codes. 989 { 990 "mitigation-scope": { 991 "client-identifier": [ 992 "string" 993 ], 994 "scope": [ 995 { 996 "mitigation-id": integer, 997 "lifetime": integer 998 } 999 ] 1000 } 1001 } 1003 Figure 8: 2.xx response body 1005 COAP 5.xx codes are returned if the DOTS server has erred or is 1006 currently unavailable to provide mitigation in response to the 1007 mitigation request from the DOTS client. 1009 If the DOTS server does not find the 'mitigation-id' parameter value 1010 conveyed in the PUT request in its configuration data, then the 1011 server MAY accept the mitigation request by sending back a 2.01 1012 (Created) response to the DOTS client; the DOTS server will 1013 consequently try to mitigate the attack. 1015 If the DOTS server finds the 'mitigation-id' parameter value conveyed 1016 in the PUT request in its configuration data, then the server MAY 1017 update the mitigation request, and a 2.04 (Changed) response is 1018 returned to indicate a successful update of the mitigation request. 1020 If the request is missing one or more mandatory attributes, then 4.00 1021 (Bad Request) will be returned in the response or if the request 1022 contains invalid or unknown parameters then 4.02 (Invalid query) is 1023 returned in the response. 1025 For a mitigation request to continue beyond the initial negotiated 1026 lifetime, the DOTS client need to refresh the current mitigation 1027 request by sending a new PUT request. The PUT request MUST use the 1028 same 'mitigation-id' value, and MUST repeat all the other parameters 1029 as sent in the original mitigation request apart from a possible 1030 change to the lifetime parameter value. 1032 A DOTS gateway MUST update the 'client-identifier' list in the 1033 response to remove the 'client-identifier' value it had added in the 1034 corresponding request before forwarding the response to the DOTS 1035 client. 1037 5.4.2. Withdraw a DOTS Signal 1039 A DELETE request is used to withdraw a DOTS signal from a DOTS server 1040 (Figure 9). 1042 Header: DELETE (Code=0.04) 1043 Uri-Host: "host" 1044 Uri-Path: ".well-known" 1045 Uri-Path: "dots" 1046 Uri-Path: "version" 1047 Uri-Path: "mitigate" 1048 Content-Format: "application/cbor" 1049 { 1050 "mitigation-scope": { 1051 "client-identifier": [ 1052 "string" 1053 ], 1054 "scope": [ 1055 { 1056 "mitigation-id": integer 1057 } 1058 ] 1059 } 1060 } 1062 Figure 9: Withdraw DOTS signal 1064 The DOTS server immediately acknowledges a DOTS client's request to 1065 withdraw the DOTS signal using 2.02 (Deleted) response code with no 1066 response payload. A 2.02 (Deleted) Response Code is returned even if 1067 the 'mitigation-id' parameter value conveyed in the DELETE request 1068 does not exist in its configuration data before the request. 1070 If the DOTS server finds the 'mitigation-id' parameter value conveyed 1071 in the DELETE request in its configuration data, then to protect 1072 against route or DNS flapping caused by a client rapidly toggling 1073 mitigation, and to dampen the effect of oscillating attacks, DOTS 1074 servers MAY allow mitigation to continue for a limited period after 1075 acknowledging a DOTS client's withdrawal of a mitigation request. 1076 During this period, the DOTS server status messages SHOULD indicate 1077 that mitigation is active but terminating. The initial active-but- 1078 terminating period SHOULD be sufficiently long to absorb latency 1079 incurred by route propagation. The active-but-terminating period 1080 SHOULD be set by default to 120 seconds. If the client requests 1081 mitigation again before the initial active-but-terminating period 1082 elapses, the DOTS server MAY exponentially increase the active-but- 1083 terminating period up to a maximum of 300 seconds (5 minutes). After 1084 the active-but-terminating period elapses, the DOTS server MUST treat 1085 the mitigation as terminated, as the DOTS client is no longer 1086 responsible for the mitigation. For example, if there is a financial 1087 relationship between the DOTS client and server domains, the DOTS 1088 client ceases incurring cost at this point. 1090 5.4.3. Retrieving a DOTS Signal 1092 A GET request is used to retrieve information (including status) of a 1093 DOTS signal from a DOTS server (Figure 10). If the DOTS server does 1094 not find the 'mitigation-id' parameter value conveyed in the GET 1095 request in its configuration data, then it responds with a 4.04 (Not 1096 Found) error response code. The 'c' (content) parameter and its 1097 permitted values defined in [I-D.ietf-core-comi] can be used to 1098 retrieve non-configuration data (attack mitigation status) or 1099 configuration data or both. The DOTS server SHOULD support this 1100 optional filtering capability but can safely ignore it if not 1101 supported. 1103 The examples below assume the default of "c=a". 1105 1) To retrieve all DOTS signals signaled by the DOTS client. 1107 Header: GET (Code=0.01) 1108 Uri-Host: "host" 1109 Uri-Path: ".well-known" 1110 Uri-Path: "dots" 1111 Uri-Path: "version" 1112 Uri-Path: "mitigate" 1113 Observe : 0 1114 { 1115 "mitigation-scope": { 1116 "client-identifier": [ 1117 "string" 1118 ] 1119 } 1120 } 1122 2) To retrieve a specific DOTS signal signaled by the DOTS client. 1123 The configuration data in the response will be formatted in the 1124 same order it was processed at the DOTS server. 1126 Header: GET (Code=0.01) 1127 Uri-Host: "host" 1128 Uri-Path: ".well-known" 1129 Uri-Path: "dots" 1130 Uri-Path: "version" 1131 Uri-Path: "mitigate" 1132 Observe : 0 1133 Content-Format: "application/cbor" 1134 { 1135 "mitigation-scope": { 1136 "client-identifier": [ 1137 "string" 1138 ], 1139 "scope": [ 1140 { 1141 "mitigation-id": integer 1142 } 1143 ] 1144 } 1145 } 1147 Figure 10: GET to retrieve the rules 1149 Figure 11 shows a response example of all the active mitigation 1150 requests associated with the DOTS client on the DOTS server and the 1151 mitigation status of each mitigation request. 1153 { 1154 "mitigation-scope": { 1155 "scope": [ 1156 { 1157 "mitigation-id": 12332, 1158 "mitigation-start": 1507818434.00, 1159 "target-protocol": [ 1160 17 1161 ], 1162 "lifetime":1800, 1163 "status":2, 1164 "bytes-dropped": 134334555, 1165 "bps-dropped": 43344, 1166 "pkts-dropped": 333334444, 1167 "pps-dropped": 432432 1168 }, 1169 { 1170 "mitigation-id": 12333, 1171 "mitigation-start": 1507818393.00, 1172 "target-protocol": [ 1173 6 1174 ], 1175 "lifetime":1800, 1176 "status":3 1177 "bytes-dropped": 0, 1178 "bps-dropped": 0, 1179 "pkts-dropped": 0, 1180 "pps-dropped": 0 1181 } 1182 ] 1183 } 1184 } 1186 Figure 11: Response body 1188 The mitigation status parameters are described below. 1190 lifetime: The remaining lifetime of the mitigation request in 1191 seconds. 1193 mitigation-start: Mitigation start time is represented in seconds 1194 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 1195 [RFC7049]). The encoding is modified so that the leading tag 1 1196 (epoch-based date/time) MUST be omitted. 1198 bytes-dropped: The total dropped byte count for the mitigation 1199 request since the attack mitigation is triggered. The count wraps 1200 around when it reaches the maximum value of unsigned integer. 1201 This is an optional attribute. 1203 bps-dropped: The average dropped bytes per second for the mitigation 1204 request since the attack mitigation is triggered. This SHOULD be 1205 a five-minute average. This is an optional attribute. 1207 pkts-dropped: The total dropped packet count for the mitigation 1208 request since the attack mitigation is triggered. This is an 1209 optional attribute. 1211 pps-dropped: The average dropped packets per second for the 1212 mitigation request since the attack mitigation is triggered. This 1213 SHOULD be a five-minute average. This is an optional attribute. 1215 status: Status of attack mitigation. The 'status' parameter is a 1216 mandatory attribute. 1218 The various possible values of 'status' parameter are explained 1219 below: 1221 /--------------------+---------------------------------------------------\ 1222 | Parameter value | Description | 1223 +--------------------+---------------------------------------------------+ 1224 | 1 | Attack mitigation is in progress | 1225 | | (e.g., changing the network path to re-route the | 1226 | | inbound traffic to DOTS mitigator). | 1227 +--------------------+---------------------------------------------------+ 1228 | 2 | Attack is successfully mitigated | 1229 | | (e.g., traffic is redirected to a DDOS mitigator | 1230 | | and attack traffic is dropped). | 1231 +--------------------+---------------------------------------------------+ 1232 | 3 | Attack has stopped and the DOTS client | 1233 | | can withdraw the mitigation request. | 1234 +--------------------+---------------------------------------------------+ 1235 | 4 | Attack has exceeded the mitigation provider | 1236 | | capability. | 1237 +--------------------+---------------------------------------------------+ 1238 | 5 | DOTS client has withdrawn the mitigation request | 1239 | | and the mitigation is active but terminating. | 1240 \--------------------+---------------------------------------------------/ 1242 The observe option defined in [RFC7641] extends the CoAP core 1243 protocol with a mechanism for a CoAP client to "observe" a resource 1244 on a CoAP server: the client retrieves a representation of the 1245 resource and requests this representation be updated by the server as 1246 long as the client is interested in the resource. A DOTS client 1247 conveys the observe option set to 0 in the GET request to receive 1248 unsolicited notifications of attack mitigation status from the DOTS 1249 server. Unidirectional notifications within the bidirectional signal 1250 channel allows unsolicited message delivery, enabling asynchronous 1251 notifications between the agents. Due to the higher likelihood of 1252 packet loss during a DDoS attack, DOTS server periodically sends 1253 attack mitigation status to the DOTS client and also notifies the 1254 DOTS client whenever the status of the attack mitigation changes. If 1255 the DOTS server cannot maintain a RTT estimate then it SHOULD NOT 1256 send more than one unsolicited notification every 3 seconds, and 1257 SHOULD use an even less aggressive rate when possible (case 2 in 1258 Section 3.1.3 of [RFC8085]). A DOTS client that is no longer 1259 interested in receiving notifications from the DOTS server can simply 1260 "forget" the observation. When the DOTS server then sends the next 1261 notification, the DOTS client will not recognize the token in the 1262 message and thus will return a Reset message. This causes the DOTS 1263 server to remove the associated entry. Alternatively, the DOTS 1264 client can explicitly deregister by issuing a GET request that has 1265 the Token field set to the token of the observation to be cancelled 1266 and includes an Observe Option with the value set to 1 (deregister). 1268 DOTS Client DOTS Server 1269 | | 1270 | GET / | 1271 | Token: 0x4a | Registration 1272 | Observe: 0 | 1273 +------------------------------>| 1274 | | 1275 | 2.05 Content | 1276 | Token: 0x4a | Notification of 1277 | Observe: 12 | the current state 1278 | status: "mitigation | 1279 | in progress" | 1280 |<------------------------------+ 1281 | 2.05 Content | 1282 | Token: 0x4a | Notification upon 1283 | Observe: 44 | a state change 1284 | status: "mitigation | 1285 | complete" | 1286 |<------------------------------+ 1287 | 2.05 Content | 1288 | Token: 0x4a | Notification upon 1289 | Observe: 60 | a state change 1290 | status: "attack stopped" | 1291 |<------------------------------+ 1292 | | 1294 Figure 12: Notifications of attack mitigation status 1296 5.4.3.1. Mitigation Status 1298 The DOTS client can send the GET request at frequent intervals 1299 without the Observe option to retrieve the configuration data of the 1300 mitigation request and non-configuration data (i.e., the attack 1301 status). The frequency of polling the DOTS server to get the 1302 mitigation status should follow the transmission guidelines given in 1303 Section 3.1.3 of [RFC8085]. If the DOTS server has been able to 1304 mitigate the attack and the attack has stopped, the DOTS server 1305 indicates as such in the status, and the DOTS client recalls the 1306 mitigation request by issuing a DELETE for the mitigation-id. 1308 A DOTS client should react to the status of the attack from the DOTS 1309 server and not the fact that it has recognized, using its own means, 1310 that the attack has been mitigated. This ensures that the DOTS 1311 client does not recall a mitigation request in a premature fashion 1312 because it is possible that the DOTS client does not sense the DDOS 1313 attack on its resources but the DOTS server could be actively 1314 mitigating the attack and the attack is not completely averted. 1316 5.4.4. Efficacy Update from DOTS Client 1318 While DDoS mitigation is active, due to the likelihood of packet 1319 loss, a DOTS client MAY periodically transmit DOTS mitigation 1320 efficacy updates to the relevant DOTS server. A PUT request 1321 (Figure 13) is used to convey the mitigation efficacy update to the 1322 DOTS server. 1324 The PUT request MUST include all the parameters used in the PUT 1325 request to convey the DOTS signal (Section 5.4.1) unchanged apart 1326 from the lifetime parameter value. If this is not the case, the DOTS 1327 server MUST reject the request with a 4.02 error response code. 1329 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1330 value is used to make the PUT request conditional on the current 1331 existence of the mitigation request. If UDP is used as transport, 1332 CoAP requests may arrive out-of-order. For example, the DOTS client 1333 may send a PUT request to convey an efficacy update to the DOTS 1334 server followed by a DELETE request to withdraw the mitigation 1335 request, but the DELETE request arrives at the DOTS server before the 1336 PUT request. To handle out-of-order delivery of requests, if an If- 1337 Match option is present in the PUT request and the 'mitigation-id' in 1338 the request matches a mitigation request from that DOTS client, then 1339 the request is processed. If no match is found, the PUT request is 1340 silently ignored. 1342 Header: PUT (Code=0.03) 1343 Uri-Host: "host" 1344 Uri-Path: ".well-known" 1345 Uri-Path: "dots" 1346 Uri-Path: "version" 1347 Uri-Path: "mitigate" 1348 Content-Format: "application/cbor" 1349 { 1350 "mitigation-scope": { 1351 "client-identifier": [ 1352 "string" 1353 ], 1354 "scope": [ 1355 { 1356 "mitigation-id": integer, 1357 "target-ip": [ 1358 "string" 1359 ], 1360 "target-port-range": [ 1361 { 1362 "lower-port": integer, 1363 "upper-port": integer 1364 } 1365 ], 1366 "target-protocol": [ 1367 integer 1368 ], 1369 "fqdn": [ 1370 "string" 1371 ], 1372 "uri": [ 1373 "string" 1374 ], 1375 "alias-name": [ 1376 "string" 1377 ], 1378 "lifetime": integer, 1379 "attack-status": integer 1380 } 1381 ] 1382 } 1383 } 1385 Figure 13: Efficacy Update 1387 The 'attack-status' parameter is a mandatory attribute when doing a 1388 efficacy update. The various possible values contained in the 1389 'attack-status' parameter are described below: 1391 /--------------------+------------------------------------------------------\ 1392 | Parameter value | Description | 1393 +--------------------+------------------------------------------------------+ 1394 | 1 | DOTS client determines that it is still under attack.| 1395 +--------------------+------------------------------------------------------+ 1396 | 2 | DOTS client determines that the attack is | 1397 | | successfully mitigated | 1398 | | (e.g., attack traffic is not seen). | 1399 \--------------------+------------------------------------------------------/ 1401 The DOTS server indicates the result of processing a PUT request 1402 using CoAP response codes. The response code 2.04 (Changed) is 1403 returned if the DOTS server has accepted the mitigation efficacy 1404 update. The error response code 5.03 (Service Unavailable) is 1405 returned if the DOTS server has erred or is incapable of performing 1406 the mitigation. 1408 5.5. DOTS Signal Channel Session Configuration 1410 The DOTS client can negotiate, configure, and retrieve the DOTS 1411 signal channel session behavior. The DOTS signal channel can be 1412 used, for example, to configure the following: 1414 a. Heartbeat interval: DOTS agents regularly send heartbeats (CoAP 1415 Ping/Pong) to each other after mutual authentication in order to 1416 keep the DOTS signal channel open, heartbeat messages are 1417 exchanged between the DOTS agents every heartbeat-interval 1418 seconds to detect the current status of the DOTS signal channel 1419 session. 1421 b. Missing heartbeats allowed: This variable indicates the maximum 1422 number of consecutive heartbeat messages for which a DOTS agent 1423 did not receive a response before concluding that the session is 1424 disconnected or defunct. 1426 c. Acceptable signal loss ratio: Maximum retransmissions, 1427 retransmission timeout value and other message transmission 1428 parameters for the DOTS signal channel. 1430 Reliability is provided to requests and responses by marking them as 1431 Confirmable (CON) messages. DOTS signal channel session 1432 configuration requests and responses are marked as Confirmable (CON) 1433 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1434 message is retransmitted using a default timeout and exponential 1435 back-off between retransmissions, until the DOTS server sends an 1436 Acknowledgement message (ACK) with the same Message ID conveyed from 1437 the DOTS client. Message transmission parameters are defined in 1438 Section 4.8 of [RFC7252]. Reliability is provided to the responses 1439 by marking them as Confirmable (CON) messages. The DOTS server can 1440 either piggyback the response in the acknowledgement message or if 1441 the DOTS server is not able to respond immediately to a request 1442 carried in a Confirmable message, it simply responds with an Empty 1443 Acknowledgement message so that the DOTS client can stop 1444 retransmitting the request. Empty Acknowledgement message is 1445 explained in Section 2.2 of [RFC7252]. When the response is ready, 1446 the server sends it in a new Confirmable message which then in turn 1447 needs to be acknowledged by the DOTS client (see Sections 5.2.1 and 1448 Sections 5.2.2 of [RFC7252]). Requests and responses exchanged 1449 between DOTS agents during peacetime are marked as Confirmable 1450 messages. 1452 Implementation Note: A DOTS client that receives a response in a CON 1453 message may want to clean up the message state right after sending 1454 the ACK. If that ACK is lost and the DOTS server retransmits the 1455 CON, the DOTS client may no longer have any state to which to 1456 correlate this response, making the retransmission an unexpected 1457 message; the DOTS client will send a Reset message so it does not 1458 receive any more retransmissions. This behavior is normal and not an 1459 indication of an error (see Section 5.3.2 of [RFC7252] for more 1460 details). 1462 5.5.1. Discover Configuration Parameters 1464 A GET request is used to obtain acceptable and current configuration 1465 parameters on the DOTS server for DOTS signal channel session 1466 configuration. Figure 14 shows how to obtain acceptable 1467 configuration parameters for the server. 1469 Header: GET (Code=0.01) 1470 Uri-Host: "host" 1471 Uri-Path: ".well-known" 1472 Uri-Path: "dots" 1473 Uri-Path: "version" 1474 Uri-Path: "config" 1476 Figure 14: GET to retrieve configuration 1478 The DOTS server in the 2.05 (Content) response conveys the current, 1479 minimum and maximum attribute values acceptable by the DOTS server. 1481 Content-Format: "application/cbor" 1482 { 1483 "heartbeat-interval": { 1484 "CurrentValue": integer, 1485 "MinValue": integer, 1486 "MaxValue" : integer, 1487 }, 1488 "missing-hb-allowed": { 1489 "CurrentValue": integer, 1490 "MinValue": integer, 1491 "MaxValue" : integer, 1492 }, 1493 "max-retransmit": { 1494 "CurrentValue": integer, 1495 "MinValue": integer, 1496 "MaxValue" : integer, 1497 }, 1498 "ack-timeout": { 1499 "CurrentValue": integer, 1500 "MinValue": integer, 1501 "MaxValue" : integer, 1502 }, 1503 "ack-random-factor": { 1504 "CurrentValue": number, 1505 "MinValue": number, 1506 "MaxValue" : number, 1507 }, 1508 "trigger-mitigation": { 1509 "CurrentValue": boolean, 1510 } 1511 } 1513 Figure 15: GET response body 1515 Figure 16 shows an example of acceptable and current configuration 1516 parameters on the DOTS server for DOTS signal channel session 1517 configuration. 1519 Content-Format: "application/cbor" 1520 { 1521 "heartbeat-interval": { 1522 "CurrentValue": 30, 1523 "MinValue": 15, 1524 "MaxValue" : 240, 1525 }, 1526 "missing-hb-allowed": { 1527 "CurrentValue": 5, 1528 "MinValue": 3, 1529 "MaxValue" : 9, 1530 }, 1531 "max-retransmit": { 1532 "CurrentValue": 3, 1533 "MinValue": 2, 1534 "MaxValue" : 15, 1535 }, 1536 "ack-timeout": { 1537 "CurrentValue": 2, 1538 "MinValue": 1, 1539 "MaxValue" : 30, 1540 }, 1541 "ack-random-factor": { 1542 "CurrentValue": 1.5, 1543 "MinValue": 1.1, 1544 "MaxValue" : 4.0, 1545 }, 1546 "trigger-mitigation": { 1547 "CurrentValue": true, 1548 } 1549 } 1551 Figure 16: configuration response body 1553 5.5.2. Convey DOTS Signal Channel Session Configuration 1555 A PUT request is used to convey the configuration parameters for the 1556 signaling channel (e.g., heartbeat interval, maximum 1557 retransmissions). Message transmission parameters for CoAP are 1558 defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of 1559 transmission parameter values are ack_timeout (2 seconds), max- 1560 retransmit (3), ack-random-factor (1.5). In addition to those 1561 parameters, the RECOMMENDED specific DOTS transmission parameter 1562 values are heartbeat-interval (30 seconds) and missing-hb-allowed 1563 (5). 1565 Note: heartbeat-interval should be tweaked to also assist DOTS 1566 messages for NAT traversal (SIG-010 of 1568 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 1569 messages must not be sent more frequently than once every 15 1570 seconds and should use longer intervals when possible. 1571 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 1572 minutes or longer, but experience shows that sending packets every 1573 15 to 30 seconds is necessary to prevent the majority of 1574 middleboxes from losing state for UDP flows. From that 1575 standpoint, this specification recommends a minimum heartbeat- 1576 interval of 15 seconds and a maximum heartbeat-interval of 240 1577 seconds. The recommended value of 30 seconds is selected to 1578 anticipate the expiry of NAT state. 1580 A heartbeat-interval of 30 second may be seen as too chatty in 1581 some deployments. For such deployments, DOTS agents may negotiate 1582 longer heartbeat-interval values to avoid overloading the network 1583 with too frequent keepalives. 1585 When a confirmable "CoAP ping" is sent, and if there is no response, 1586 the "CoAP ping" will get retransmitted max-retransmit number of times 1587 by the CoAP layer using an initial timeout set to a random duration 1588 between ack_timeout and (ack-timeout*ack-random-factor) and 1589 exponential back-off between retransmissions. By choosing the 1590 recommended transmission parameters, the "CoAP ping" will timeout 1591 after 45 seconds. If the DOTS agent does not receive any response 1592 from the peer DOTS agent for missing-hb-allowed number of consecutive 1593 "CoAP ping" confirmable messages, then it concludes that the DOTS 1594 signal channel session is disconnected. A DOTS client MUST NOT 1595 transmit a "CoAP ping" while waiting for the previous "CoAP ping" 1596 response from the same DOTS server. 1598 If the DOTS agent wishes to change the default values of message 1599 transmission parameters, then it should follow the guidance given in 1600 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 1601 values for message transmission parameters and default values for 1602 non-negotiated message transmission parameters. 1604 The signaling channel session configuration is applicable to a single 1605 DOTS signal channel session between the DOTS agents. 1607 Header: PUT (Code=0.03) 1608 Uri-Host: "host" 1609 Uri-Path: ".well-known" 1610 Uri-Path: "dots" 1611 Uri-Path: "version" 1612 Uri-Path: "config" 1613 Content-Format: "application/cbor" 1614 { 1615 "signal-config": { 1616 "session-id": integer, 1617 "heartbeat-interval": integer, 1618 "missing-hb-allowed": integer, 1619 "max-retransmit": integer, 1620 "ack-timeout": integer, 1621 "ack-random-factor": number 1622 "trigger-mitigation": boolean 1623 } 1624 } 1626 Figure 17: PUT to convey the DOTS signal channel session 1627 configuration data. 1629 The parameters are described below: 1631 session-id: Identifier for the DOTS signal channel session 1632 configuration data represented as an integer. This identifier 1633 MUST be generated by the DOTS client. This document does not make 1634 any assumption about how this identifier is generated. This is a 1635 mandatory attribute. 1637 heartbeat-interval: Time interval in seconds between two 1638 consecutive heartbeat messages. This is an optional attribute. 1640 missing-hb-allowed: Maximum number of consecutive heartbeat 1641 messages for which the DOTS agent did not receive a response 1642 before concluding that the session is disconnected. This is an 1643 optional attribute. 1645 max-retransmit: Maximum number of retransmissions for a message 1646 (referred to as MAX_RETRANSMIT parameter in CoAP). This is an 1647 optional attribute. 1649 ack-timeout: Timeout value in seconds used to calculate the initial 1650 retransmission timeout value (referred to as ACK_TIMEOUT parameter 1651 in CoAP). This is an optional attribute. 1653 ack-random-factor: Random factor used to influence the timing of 1654 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1655 CoAP). This is an optional attribute. 1657 trigger-mitigation: If the parameter value is set to 'false', then 1658 DDoS mitigation is triggered only when the DOTS signal channel 1659 session is lost. Automated mitigation on loss of signal is 1660 discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. If 1661 the DOTS client ceases to respond to heartbeat messages, then the 1662 DOTS server can detect that the DOTS session is lost. The default 1663 value of the parameter is 'true'. This is an optional attribute. 1665 In the PUT request at least one of the attributes heartbeat-interval, 1666 missing-hb-allowed, max-retransmit, ack-timeout, ack-random-factor, 1667 and trigger-mitigation MUST be present. The PUT request with higher 1668 numeric session-id value over-rides the DOTS signal channel session 1669 configuration data installed by a PUT request with a lower numeric 1670 session-id value. 1672 Figure 18 shows a PUT request example to convey the configuration 1673 parameters for the DOTS signal channel. 1675 Header: PUT (Code=0.03) 1676 Uri-Host: "www.example.com" 1677 Uri-Path: ".well-known" 1678 Uri-Path: "dots" 1679 Uri-Path: "v1" 1680 Uri-Path: "config" 1681 Content-Format: "application/cbor" 1682 { 1683 "signal-config": { 1684 "session-id": 1234534333242, 1685 "heartbeat-interval": 91, 1686 "missing-hb-allowed": 3, 1687 "max-retransmit": 7, 1688 "ack-timeout": 5, 1689 "ack-random-factor": 1.5, 1690 "trigger-mitigation": false 1691 } 1692 } 1694 Figure 18: PUT to convey the configuration parameters 1696 The DOTS server indicates the result of processing the PUT request 1697 using CoAP response codes: 1699 o If the DOTS server finds the 'session-id' parameter value conveyed 1700 in the PUT request in its configuration data and if the DOTS 1701 server has accepted the updated configuration parameters, then 1702 2.04 (Changed) code is returned in the response. 1704 o If the DOTS server does not find the 'session-id' parameter value 1705 conveyed in the PUT request in its configuration data and if the 1706 DOTS server has accepted the configuration parameters, then a 1707 response code 2.01 (Created) is returned in the response. 1709 o If the request is missing one or more mandatory attributes, then 1710 4.00 (Bad Request) is returned in the response. 1712 o If the request contains one or more invalid or unknown parameters, 1713 then 4.02 (Invalid query) code is returned in the response. 1715 o Response code 4.22 (Unprocessable Entity) is returned in the 1716 response, if any of the heartbeat-interval, missing-hb-allowed, 1717 max-retransmit, target-protocol, ack-timeout, and ack-random- 1718 factor attribute values are not acceptable to the DOTS server. 1719 Upon receipt of the 4.22 error response code, the DOTS client 1720 should request the maximum and minimum attribute values acceptable 1721 to the DOTS server (Section 5.5.1). The DOTS client may re-try 1722 and send the PUT request with updated attribute values acceptable 1723 to the DOTS server. 1725 5.5.3. Delete DOTS Signal Channel Session Configuration 1727 A DELETE request is used to delete the installed DOTS signal channel 1728 session configuration data (Figure 19). 1730 Header: DELETE (Code=0.04) 1731 Uri-Host: "host" 1732 Uri-Path: ".well-known" 1733 Uri-Path: "dots" 1734 Uri-Path: "version" 1735 Uri-Path: "config" 1736 Content-Format: "application/cbor" 1738 Figure 19: DELETE configuration 1740 The DOTS server resets the DOTS signal channel session configuration 1741 back to the default values and acknowledges a DOTS client's request 1742 to remove the DOTS signal channel session configuration using 2.02 1743 (Deleted) response code. 1745 5.6. Redirected Signaling 1747 Redirected Signaling is discussed in detail in Section 3.2.2 of 1748 [I-D.ietf-dots-architecture]. If the DOTS server wants to redirect 1749 the DOTS client to an alternative DOTS server for a signaling session 1750 then the response code 3.00 (alternate server) will be returned in 1751 the response to the client. The DOTS server can return the error 1752 response code 3.00 in response to a PUT request from the DOTS client 1753 or convey the error response code 3.00 in a unidirectional 1754 notification response from the DOTS server. 1756 The DOTS server in the error response conveys the alternate DOTS 1757 server FQDN, and the alternate DOTS server IP addresses and time to 1758 live values in the CBOR body. 1760 { 1761 "alt-server": "string", 1762 "alt-server-record": [ 1763 { 1764 "addr": "string", 1765 "ttl" : integer, 1766 } 1767 ] 1768 } 1770 Figure 20: Error response body 1772 The parameters are described below: 1774 alt-server: FQDN of an alternate DOTS server. 1776 addr: IP address of an alternate DOTS server. 1778 ttl: Time to live (TTL) represented as an integer number of seconds. 1780 Figure 21 shows a 3.00 response example to convey the DOTS alternate 1781 server www.example-alt.com, its IP addresses 2001:db8:6401::1 and 1782 2001:db8:6401::2, and TTL values 3600 and 1800. 1784 { 1786 "alt-server": "www.example-alt.com", 1787 "alt-server-record": [ 1788 { 1789 "ttl" : 3600, 1790 "addr": "2001:db8:6401::1" 1791 }, 1792 { 1793 "ttl" : 1800, 1794 "addr": "2001:db8:6401::2" 1795 } 1796 ] 1797 } 1799 Figure 21: Example of error response body 1801 When the DOTS client receives 3.00 response, it considers the current 1802 request as having failed, but SHOULD try the request with the 1803 alternate DOTS server. During a DDOS attack, the DNS server may be 1804 subjected to DDOS attack, alternate DOTS server IP addresses conveyed 1805 in the 3.00 response help the DOTS client to skip DNS lookup of the 1806 alternate DOTS server and can try to establish UDP or TCP session 1807 with the alternate DOTS server IP addresses. The DOTS client SHOULD 1808 implement DNS64 function to handle the scenario where IPv6-only DOTS 1809 client communicates with IPv4-only alternate DOTS server. 1811 5.7. Heartbeat Mechanism 1813 To provide a metric of signal health and distinguish an 'idle' signal 1814 channel from a 'disconnected' or 'defunct' session, the DOTS agent 1815 sends a heartbeat over the signal channel to maintain its half of the 1816 channel. The DOTS agent similarly expects a heartbeat from its peer 1817 DOTS agent, and may consider a session terminated in the extended 1818 absence of a peer agent heartbeat. 1820 While the communication between the DOTS agents is quiescent, the 1821 DOTS client will probe the DOTS server to ensure it has maintained 1822 cryptographic state and vice versa. Such probes can also keep alive 1823 firewall and/or NAT bindings. This probing reduces the frequency of 1824 establishing a new handshake when a DOTS signal needs to be conveyed 1825 to the DOTS server. 1827 In case of a volumetric DDoS attack saturating the incoming link to 1828 the DOTS client, all traffic from the DOTS server to the DOTS client 1829 will likely be dropped, although the DOTS server receives heartbeat 1830 requests and DOTS messages from the DOTS client. In this scenario, 1831 the DOTS agents MUST behave differently to handle message 1832 transmission and DOTS session liveliness during link saturation: 1834 o The DOTS client MUST NOT consider the DOTS session terminated even 1835 after maximum "missing-hb-allowed" threshold is reached. The DOTS 1836 client SHOULD continue to use the current DOTS session, and send 1837 heartbeat requests over the current DOTS session, so the DOTS 1838 server knows the DOTS client has not disconnected the DOTS 1839 session. After the maximum "missing-hb-allowed" threshold is 1840 reached, the DOTS client SHOULD try (D)TLS session resumption. 1841 The DOTS client SHOULD send mitigation requests over the current 1842 DOTS session, and in parallel, try (D)TLS session resumption or 1843 0-RTT mode in DTLS 1.3 to piggyback the mitigation request in the 1844 ClientHello message. Once the link is no longer statured, if 1845 traffic from the DOTS server reaches the DOTS client over the 1846 current DOTS session, the DOTS client can stop (D)TLS session 1847 resumption or if (D)TLS session resumption is successful then 1848 disconnect the current DOTS session. 1850 o If the DOTS server does not receive any traffic from the peer DOTS 1851 client, then the DOTS server sends heartbeat requests to the DOTS 1852 client and after maximum "missing-hb-allowed" threshold is 1853 reached, the DOTS server concludes the session is disconnected. 1855 In DOTS over UDP, heartbeat messages may be exchanged between the 1856 DOTS agents using the "COAP ping" mechanism defined in Section 4.2 of 1857 [RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable 1858 message and the peer DOTS agent will respond by sending an Reset 1859 message. 1861 In DOTS over TCP, heartbeat messages can be exchanged between the 1862 DOTS agents using the Ping and Pong messages specified in Section 4.4 1863 of [I-D.ietf-core-coap-tcp-tls]. That is, the DOTS agent sends a 1864 Ping message and the peer DOTS agent would respond by sending a 1865 single Pong message. 1867 6. Mapping parameters to CBOR 1869 All parameters in the payload in the DOTS signal channel MUST be 1870 mapped to CBOR types as follows and are given an integer key to save 1871 space. The recipient of the payload MAY reject the information if it 1872 is not suitably mapped. 1874 /--------------------+------------------------+--------------------------\ 1875 | Parameter name | CBOR key | CBOR major type of value | 1876 +--------------------+------------------------+--------------------------+ 1877 | mitigation-scope | 1 | 5 (map) | 1878 | scope | 2 | 5 (map) | 1879 | mitigation-id | 3 | 0 (unsigned) | 1880 | target-ip | 4 | 4 (array) | 1881 | target-port-range | 5 | 4 | 1882 | lower-port | 6 | 0 | 1883 | upper-port | 7 | 0 | 1884 | target-protocol | 8 | 4 | 1885 | fqdn | 9 | 4 | 1886 | uri | 10 | 4 | 1887 | alias-name | 11 | 4 | 1888 | lifetime | 12 | 0 | 1889 | attack-status | 13 | 0 | 1890 | signal-config | 14 | 5 | 1891 | heartbeat-interval | 15 | 0 | 1892 | max-retransmit | 16 | 0 | 1893 | ack-timeout | 17 | 0 | 1894 | ack-random-factor | 18 | 7 | 1895 | MinValue | 19 | 0 | 1896 | MaxValue | 20 | 0 | 1897 | status | 21 | 0 | 1898 | bytes-dropped | 22 | 0 | 1899 | bps-dropped | 23 | 0 | 1900 | pkts-dropped | 24 | 0 | 1901 | pps-dropped | 25 | 0 | 1902 | session-id | 26 | 0 | 1903 | trigger-mitigation | 27 | 7 (simple types) | 1904 | missing-hb-allowed | 28 | 0 | 1905 | CurrentValue | 29 | 0 | 1906 | mitigation-start | 30 | 7 (floating-point) | 1907 | target-prefix | 31 | 4 (array) | 1908 | client-identifier | 32 | 2 (byte string) | 1909 | alt-server | 33 | 2 | 1910 | alt-server-record | 34 | 4 | 1911 | addr | 35 | 2 | 1912 | ttl | 36 | 0 | 1913 \--------------------+------------------------+--------------------------/ 1915 Figure 22: CBOR mappings used in DOTS signal channel message 1917 7. (D)TLS Protocol Profile and Performance considerations 1919 This section defines the (D)TLS protocol profile of DOTS signal 1920 channel over (D)TLS and DOTS data channel over TLS. 1922 There are known attacks on (D)TLS, such as machine-in-the-middle and 1923 protocol downgrade. These are general attacks on (D)TLS and not 1924 specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for 1925 discussion of these security issues. DOTS agents MUST adhere to the 1926 (D)TLS implementation recommendations and security considerations of 1927 [RFC7525] except with respect to (D)TLS version. Since encryption of 1928 DOTS using (D)TLS is virtually a green-field deployment DOTS agents 1929 MUST implement only (D)TLS 1.2 or later. 1931 Implementations compliant with this profile MUST implement all of the 1932 following items: 1934 o DOTS agents MUST support DTLS record replay detection (Section 3.3 1935 of [RFC6347]) to protect against replay attacks. 1937 o DOTS client can use (D)TLS session resumption without server-side 1938 state [RFC5077] to resume session and convey the DOTS signal. 1940 o Raw public keys [RFC7250] which reduce the size of the 1941 ServerHello, and can be used by servers that cannot obtain 1942 certificates (e.g., DOTS gateways on private networks). 1944 Implementations compliant with this profile SHOULD implement all of 1945 the following items to reduce the delay required to deliver a DOTS 1946 signal: 1948 o TLS False Start [RFC7918] which reduces round-trips by allowing 1949 the TLS second flight of messages (ChangeCipherSpec) to also 1950 contain the DOTS signal. 1952 o Cached Information Extension [RFC7924] which avoids transmitting 1953 the server's certificate and certificate chain if the client has 1954 cached that information from a previous TLS handshake. 1956 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 1957 convey DOTS signal. 1959 7.1. MTU and Fragmentation Issues 1961 To avoid DOTS signal message fragmentation and the consequently 1962 decreased probability of message delivery, DOTS agents MUST ensure 1963 that the DTLS record MUST fit within a single datagram. If the Path 1964 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 1965 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 1966 is used to convey the DOTS signal messages then the DOTS client must 1967 consider the amount of record expansion expected by the DTLS 1968 processing when calculating the size of CoAP message that fits within 1969 the path MTU. Path MTU MUST be greater than or equal to [CoAP 1970 message size + DTLS overhead of 13 octets + authentication overhead 1971 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 1972 of [RFC6347]]. If the request size exceeds the Path MTU then the 1973 DOTS client MUST split the DOTS signal into separate messages, for 1974 example the list of addresses in the 'target-ip' parameter could be 1975 split into multiple lists and each list conveyed in a new PUT 1976 request. 1978 Implementation Note: DOTS choice of message size parameters works 1979 well with IPv6 and with most of today's IPv4 paths. However, with 1980 IPv4, it is harder to absolutely ensure that there is no IP 1981 fragmentation. If IPv4 support on unusual networks is a 1982 consideration and path MTU is unknown, implementations may want to 1983 limit themselves to more conservative IPv4 datagram sizes such as 576 1984 bytes, as per [RFC0791] IP packets up to 576 bytes should never need 1985 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal 1986 over a UDP datagram will generally avoid IP fragmentation. 1988 8. (D)TLS 1.3 considerations 1990 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 1991 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 1992 [I-D.rescorla-tls-dtls13] is based on the TLS 1.3 protocol and 1993 provides equivalent security guarantees. (D)TLS 1.3 provides two 1994 basic handshake modes of interest to DOTS signal channel: 1996 o Absent packet loss, a full handshake in which the DOTS client is 1997 able to send the DOTS signal message after one round trip and the 1998 DOTS server immediately after receiving the first DOTS signal 1999 message from the client. 2001 o 0-RTT mode in which the DOTS client can authenticate itself and 2002 send DOTS signal message on its first flight, thus reducing 2003 handshake latency. 0-RTT only works if the DOTS client has 2004 previously communicated with that DOTS server, which is very 2005 likely with the DOTS signal channel. The DOTS client SHOULD 2006 establish a (D)TLS session with the DOTS server during peacetime 2007 and share a PSK. During DDOS attack, the DOTS client can use the 2008 (D)TLS session to convey the DOTS signal message and if there is 2009 no response from the server after multiple re-tries then the DOTS 2010 client can resume the (D)TLS session in 0-RTT mode using PSK. A 2011 simplified TLS 1.3 handshake with 0-RTT DOTS signal message 2012 exchange is shown in Figure 23. 2014 DOTS Client DOTS Server 2016 ClientHello 2017 (Finished) 2018 (0-RTT DOTS signal message) 2019 (end_of_early_data) --------> 2020 ServerHello 2021 {EncryptedExtensions} 2022 {ServerConfiguration} 2023 {Certificate} 2024 {CertificateVerify} 2025 {Finished} 2026 <-------- [DOTS signal message] 2027 {Finished} --------> 2029 [DOTS signal message] <-------> [DOTS signal message] 2031 Figure 23: TLS 1.3 handshake with 0-RTT 2033 9. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 2035 (D)TLS based on client certificate can be used for mutual 2036 authentication between DOTS agents. If a DOTS gateway is involved, 2037 DOTS clients and DOTS gateway MUST perform mutual authentication; 2038 only authorized DOTS clients are allowed to send DOTS signals to a 2039 DOTS gateway. DOTS gateway and DOTS server MUST perform mutual 2040 authentication; DOTS server only allows DOTS signals from authorized 2041 DOTS gateway, creating a two-link chain of transitive authentication 2042 between the DOTS client and the DOTS server. 2044 +-------------------------------------------------+ 2045 | example.com domain +---------+ | 2046 | | AAA | | 2047 | +---------------+ | Server | | 2048 | | Application | +------+--+ | 2049 | | server + ^ 2050 | | (DOTS client) |<-----------------+ | | 2051 | +---------------+ | | | example.net domain 2052 | V V | 2053 | +-------------+ | +---------------+ 2054 | +--------------+ | | | | | 2055 | | Guest +<-----x----->+ +<---------------->+ DOTS | 2056 | | (DOTS client)| | DOTS | | | Server | 2057 | +--------------+ | Gateway | | | | 2058 | +----+--------+ | +---------------+ 2059 | ^ | 2060 | | | 2061 | +----------------+ | | 2062 | | DDOS detector | | | 2063 | | (DOTS client) +<--------------+ | 2064 | +----------------+ | 2065 | | 2066 +-------------------------------------------------+ 2068 Figure 24: Example of Authentication and Authorization of DOTS Agents 2070 In the example depicted in Figure 24, the DOTS gateway and DOTS 2071 clients within the 'example.com' domain mutually authenticate with 2072 each other. After the DOTS gateway validates the identity of a DOTS 2073 client, it communicates with the AAA server in the 'example.com' 2074 domain to determine if the DOTS client is authorized to request DDOS 2075 mitigation. If the DOTS client is not authorized, a 4.01 2076 (Unauthorized) is returned in the response to the DOTS client. In 2077 this example, the DOTS gateway only allows the application server and 2078 DDOS detector to request DDOS mitigation, but does not permit the 2079 user of type 'guest' to request DDOS mitigation. 2081 Also, DOTS gateway and DOTS server located in different domains MUST 2082 perform mutual authentication (e.g., using certificates). A DOTS 2083 server will only allow a DOTS gateway with a certificate for a 2084 particular domain to request mitigation for that domain. In 2085 reference to Figure 24, the DOTS server only allows the DOTS gateway 2086 to request mitigation for 'example.com' domain and not for other 2087 domains. 2089 10. IANA Considerations 2091 This specification registers a default port, new URI suffix in the 2092 Well-Known URIs registry, new CoAP response code, new parameters for 2093 DOTS signal channel and establishes registries for mappings to CBOR. 2095 10.1. DOTS Signal Channel UDP and TCP Port Number 2097 IANA has assigned the port number TBD to the DOTS signal channel 2098 protocol, for both UDP and TCP. 2100 10.2. Well-Known 'dots' URI 2102 This memo registers the 'dots' well-known URI in the Well-Known URIs 2103 registry as defined by [RFC5785]. 2105 URI suffix: dots 2107 Change controller: IETF 2109 Specification document(s): This RFC 2111 Related information: None 2113 10.3. CoAP Response Code 2115 The following entry is added to the "CoAP Response Codes" sub- 2116 registry: 2118 +------+------------------------------+-----------+ 2119 | Code | Description | Reference | 2120 +------+------------------------------+-----------+ 2121 | 3.00 | Alternate server | [RFCXXXX] | 2122 +------+------------------------------+-----------+ 2124 Figure 25: CoAP Response Code 2126 [Note to RFC Editor: Please replace XXXX with the RFC number of this 2127 specification.] 2129 10.4. DOTS signal channel CBOR Mappings Registry 2131 A new registry will be requested from IANA, entitled "DOTS signal 2132 channel CBOR Mappings Registry". The registry is to be created as 2133 Expert Review Required. 2135 10.4.1. Registration Template 2137 Parameter name: 2138 Parameter names (e.g., "target_ip") in the DOTS signal channel. 2140 CBOR Key Value: 2141 Key value for the parameter. The key value MUST be an integer in 2142 the range of 1 to 65536. The key values in the range of 32768 to 2143 65536 are assigned for Vendor-Specific parameters. 2145 CBOR Major Type: 2146 CBOR Major type and optional tag for the claim. 2148 Change Controller: 2149 For Standards Track RFCs, list the "IESG". For others, give the 2150 name of the responsible party. Other details (e.g., postal 2151 address, email address, home page URI) may also be included. 2153 Specification Document(s): 2154 Reference to the document or documents that specify the parameter, 2155 preferably including URIs that can be used to retrieve copies of 2156 the documents. An indication of the relevant sections may also be 2157 included but is not required. 2159 10.4.2. Initial Registry Contents 2161 o Parameter Name: "mitigation-scope" 2162 o CBOR Key Value: 1 2163 o CBOR Major Type: 5 2164 o Change Controller: IESG 2165 o Specification Document(s): this document 2167 o Parameter Name: "scope" 2168 o CBOR Key Value: 2 2169 o CBOR Major Type: 5 2170 o Change Controller: IESG 2171 o Specification Document(s): this document 2173 o Parameter Name: "mitigation-id" 2174 o CBOR Key Value: 3 2175 o CBOR Major Type: 0 2176 o Change Controller: IESG 2177 o Specification Document(s): this document 2179 o Parameter Name:target-ip 2180 o CBOR Key Value: 4 2181 o CBOR Major Type: 4 2182 o Change Controller: IESG 2183 o Specification Document(s): this document 2185 o Parameter Name: target-port-range 2186 o CBOR Key Value: 5 2187 o CBOR Major Type: 4 2188 o Change Controller: IESG 2189 o Specification Document(s): this document 2191 o Parameter Name: "lower-port" 2192 o CBOR Key Value: 6 2193 o CBOR Major Type: 0 2194 o Change Controller: IESG 2195 o Specification Document(s): this document 2197 o Parameter Name: "upper-port" 2198 o CBOR Key Value: 7 2199 o CBOR Major Type: 0 2200 o Change Controller: IESG 2201 o Specification Document(s): this document 2203 o Parameter Name: target-protocol 2204 o CBOR Key Value: 8 2205 o CBOR Major Type: 4 2206 o Change Controller: IESG 2207 o Specification Document(s): this document 2209 o Parameter Name: "fqdn" 2210 o CBOR Key Value: 9 2211 o CBOR Major Type: 4 2212 o Change Controller: IESG 2213 o Specification Document(s): this document 2215 o Parameter Name: "uri" 2216 o CBOR Key Value: 10 2217 o CBOR Major Type: 4 2218 o Change Controller: IESG 2219 o Specification Document(s): this document 2221 o Parameter Name: alias-name 2222 o CBOR Key Value: 11 2223 o CBOR Major Type: 4 2224 o Change Controller: IESG 2225 o Specification Document(s): this document 2227 o Parameter Name: "lifetime" 2228 o CBOR Key Value: 12 2229 o CBOR Major Type: 0 2230 o Change Controller: IESG 2231 o Specification Document(s): this document 2233 o Parameter Name: attack-status 2234 o CBOR Key Value: 13 2235 o CBOR Major Type: 0 2236 o Change Controller: IESG 2237 o Specification Document(s): this document 2239 o Parameter Name: signal-config 2240 o CBOR Key Value: 14 2241 o CBOR Major Type: 5 2242 o Change Controller: IESG 2243 o Specification Document(s): this document 2245 o Parameter Name: heartbeat-interval 2246 o CBOR Key Value: 15 2247 o CBOR Major Type: 0 2248 o Change Controller: IESG 2249 o Specification Document(s): this document 2251 o Parameter Name: max-retransmit 2252 o CBOR Key Value: 16 2253 o CBOR Major Type: 0 2254 o Change Controller: IESG 2255 o Specification Document(s): this document 2257 o Parameter Name: ack-timeout 2258 o CBOR Key Value: 17 2259 o CBOR Major Type: 0 2260 o Change Controller: IESG 2261 o Specification Document(s): this document 2263 o Parameter Name: ack-random-factor 2264 o CBOR Key Value: 18 2265 o CBOR Major Type: 7 2266 o Change Controller: IESG 2267 o Specification Document(s): this document 2269 o Parameter Name: MinValue 2270 o CBOR Key Value: 19 2271 o CBOR Major Type: 0 2272 o Change Controller: IESG 2273 o Specification Document(s): this document 2275 o Parameter Name: MaxValue 2276 o CBOR Key Value: 20 2277 o CBOR Major Type: 0 2278 o Change Controller: IESG 2279 o Specification Document(s): this document 2281 o Parameter Name: status 2282 o CBOR Key Value: 21 2283 o CBOR Major Type: 0 2284 o Change Controller: IESG 2285 o Specification Document(s): this document 2287 o Parameter Name: bytes-dropped 2288 o CBOR Key Value: 22 2289 o CBOR Major Type: 0 2290 o Change Controller: IESG 2291 o Specification Document(s): this document 2293 o Parameter Name: bps-dropped 2294 o CBOR Key Value: 23 2295 o CBOR Major Type: 0 2296 o Change Controller: IESG 2297 o Specification Document(s): this document 2299 o Parameter Name: pkts-dropped 2300 o CBOR Key Value: 24 2301 o CBOR Major Type: 0 2302 o Change Controller: IESG 2303 o Specification Document(s): this document 2305 o Parameter Name: pps-dropped 2306 o CBOR Key Value: 25 2307 o CBOR Major Type: 0 2308 o Change Controller: IESG 2309 o Specification Document(s): this document 2311 o Parameter Name: session-id 2312 o CBOR Key Value: 26 2313 o CBOR Major Type: 0 2314 o Change Controller: IESG 2315 o Specification Document(s): this document 2317 o Parameter Name: trigger-mitigation 2318 o CBOR Key Value: 27 2319 o CBOR Major Type: 7 2320 o Change Controller: IESG 2321 o Specification Document(s): this document 2323 o Parameter Name: missing-hb-allowed 2324 o CBOR Key Value: 28 2325 o CBOR Major Type: 0 2326 o Change Controller: IESG 2327 o Specification Document(s): this document 2329 o Parameter Name: CurrentValue 2330 o CBOR Key Value: 29 2331 o CBOR Major Type: 0 2332 o Change Controller: IESG 2333 o Specification Document(s): this document 2335 o Parameter Name:mitigation-start 2336 o CBOR Key Value: 30 2337 o CBOR Major Type: 7 2338 o Change Controller: IESG 2339 o Specification Document(s): this document 2341 o Parameter Name:target-prefix 2342 o CBOR Key Value: 31 2343 o CBOR Major Type: 4 2344 o Change Controller: IESG 2345 o Specification Document(s): this document 2347 o Parameter Name:client-identifier 2348 o CBOR Key Value: 32 2349 o CBOR Major Type: 2 2350 o Change Controller: IESG 2351 o Specification Document(s): this document 2353 o Parameter Name:alt-server 2354 o CBOR Key Value: 33 2355 o CBOR Major Type: 2 2356 o Change Controller: IESG 2357 o Specification Document(s): this document 2359 o Parameter Name:alt-server-record 2360 o CBOR Key Value: 34 2361 o CBOR Major Type: 4 2362 o Change Controller: IESG 2363 o Specification Document(s): this document 2365 o Parameter Name:addr 2366 o CBOR Key Value: 35 2367 o CBOR Major Type: 2 2368 o Change Controller: IESG 2369 o Specification Document(s): this document 2371 o Parameter Name:ttl 2372 o CBOR Key Value: 36 2373 o CBOR Major Type: 0 2374 o Change Controller: IESG 2375 o Specification Document(s): this document 2377 11. Implementation Status 2379 [Note to RFC Editor: Please remove this section and reference to 2380 [RFC7942] prior to publication.] 2382 This section records the status of known implementations of the 2383 protocol defined by this specification at the time of posting of this 2384 Internet-Draft, and is based on a proposal described in [RFC7942]. 2385 The description of implementations in this section is intended to 2386 assist the IETF in its decision processes in progressing drafts to 2387 RFCs. Please note that the listing of any individual implementation 2388 here does not imply endorsement by the IETF. Furthermore, no effort 2389 has been spent to verify the information presented here that was 2390 supplied by IETF contributors. This is not intended as, and must not 2391 be construed to be, a catalog of available implementations or their 2392 features. Readers are advised to note that other implementations may 2393 exist. 2395 According to [RFC7942], "this will allow reviewers and working groups 2396 to assign due consideration to documents that have the benefit of 2397 running code, which may serve as evidence of valuable experimentation 2398 and feedback that have made the implemented protocols more mature. 2399 It is up to the individual working groups to use this information as 2400 they see fit". 2402 11.1. nttdots 2404 Organization: NTT Communication is developing a DOTS client and 2405 DOTS server software based on DOTS signal channel specified in 2406 this draft. It will be open-sourced. 2407 Description: Early implementation of DOTS protocol. It is aimed to 2408 implement a full DOTS protocol spec in accordance with maturing of 2409 DOTS protocol itself. 2410 Implementation: https://github.com/nttdots/go-dots 2411 Level of maturity: It is a early implementation of DOTS protocol. 2412 Messaging between DOTS clients and DOTS servers has been tested. 2413 Level of maturity will increase in accordance with maturing of 2414 DOTS protocol itself. 2415 Coverage: Capability of DOTS client: sending DOTS messages to the 2416 DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS 2417 server: receiving dots-signal, validating received dots-signal, 2418 starting mitigation by handing over the dots-signal to DDOS 2419 mitigator. 2420 Licensing: It will be open-sourced with BSD 3-clause license. 2422 Implementation experience: It is implemented in Go-lang. Core 2423 specification of signaling is mature to be implemented, however, 2424 finding good libraries(like DTLS, CoAP) is rather difficult. 2425 Contact: Kaname Nishizuka 2427 12. Security Considerations 2429 Authenticated encryption MUST be used for data confidentiality and 2430 message integrity. (D)TLS based on client certificate MUST be used 2431 for mutual authentication. The interaction between the DOTS agents 2432 requires Datagram Transport Layer Security (DTLS) and Transport Layer 2433 Security (TLS) with a cipher suite offering confidentiality 2434 protection and the guidance given in [RFC7525] MUST be followed to 2435 avoid attacks on (D)TLS. 2437 A single DOTS signal channel between DOTS agents can be used to 2438 exchange multiple DOTS signal messages. To reduce DOTS client and 2439 DOTS server workload, DOTS client SHOULD re-use the (D)TLS session. 2441 If TCP is used between DOTS agents, an attacker may be able to inject 2442 RST packets, bogus application segments, etc., regardless of whether 2443 TLS authentication is used. Because the application data is TLS 2444 protected, this will not result in the application receiving bogus 2445 data, but it will constitute a DoS on the connection. This attack 2446 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 2447 any bogus packets injected by an attacker will be rejected by the 2448 TCP-AO integrity check and therefore will never reach the TLS layer. 2450 In order to prevent leaking internal information outside a client- 2451 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 2452 the identity of internal DOTS clients (client-identifier) unless 2453 explicitly configured to do so. 2455 Special care should be taken in order to ensure that the activation 2456 of the proposed mechanism won't have an impact on the stability of 2457 the network (including connectivity and services delivered over that 2458 network). 2460 Involved functional elements in the cooperation system must establish 2461 exchange instructions and notification over a secure and 2462 authenticated channel. Adequate filters can be enforced to avoid 2463 that nodes outside a trusted domain can inject request such as 2464 deleting filtering rules. Nevertheless, attacks can be initiated 2465 from within the trusted domain if an entity has been corrupted. 2466 Adequate means to monitor trusted nodes should also be enabled. 2468 13. Contributors 2470 The following individuals have contributed to this document: 2472 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 2473 mgeller@cisco.com 2475 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 2476 Email: rgm@htt-consult.com 2478 Dan Wing Email: dwing-ietf@fuggles.com 2480 14. Acknowledgements 2482 Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, 2483 Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang 2484 Xia, Jon Shallow, and Gilbert Clark for the discussion and comments. 2486 15. References 2488 15.1. Normative References 2490 [I-D.ietf-core-coap-tcp-tls] 2491 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 2492 Silverajan, B., and B. Raymor, "CoAP (Constrained 2493 Application Protocol) over TCP, TLS, and WebSockets", 2494 draft-ietf-core-coap-tcp-tls-10 (work in progress), 2495 October 2017. 2497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2498 Requirement Levels", BCP 14, RFC 2119, 2499 DOI 10.17487/RFC2119, March 1997, 2500 . 2502 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2503 (TLS) Protocol Version 1.2", RFC 5246, 2504 DOI 10.17487/RFC5246, August 2008, 2505 . 2507 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2508 Uniform Resource Identifiers (URIs)", RFC 5785, 2509 DOI 10.17487/RFC5785, April 2010, 2510 . 2512 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2513 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 2514 June 2010, . 2516 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2517 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2518 DOI 10.17487/RFC6234, May 2011, 2519 . 2521 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2522 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2523 January 2012, . 2525 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 2526 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 2527 Transport Layer Security (TLS) and Datagram Transport 2528 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 2529 June 2014, . 2531 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2532 Application Protocol (CoAP)", RFC 7252, 2533 DOI 10.17487/RFC7252, June 2014, 2534 . 2536 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2537 "Recommendations for Secure Use of Transport Layer 2538 Security (TLS) and Datagram Transport Layer Security 2539 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2540 2015, . 2542 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2543 Application Protocol (CoAP)", RFC 7641, 2544 DOI 10.17487/RFC7641, September 2015, 2545 . 2547 15.2. Informative References 2549 [I-D.ietf-core-comi] 2550 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 2551 Management Interface", draft-ietf-core-comi-01 (work in 2552 progress), July 2017. 2554 [I-D.ietf-core-yang-cbor] 2555 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 2556 Minaburo, "CBOR Encoding of Data Modeled with YANG", 2557 draft-ietf-core-yang-cbor-05 (work in progress), August 2558 2017. 2560 [I-D.ietf-dots-architecture] 2561 Mortensen, A., Andreasen, F., Reddy, T., 2562 christopher_gray3@cable.comcast.com, c., Compton, R., and 2563 N. Teague, "Distributed-Denial-of-Service Open Threat 2564 Signaling (DOTS) Architecture", draft-ietf-dots- 2565 architecture-05 (work in progress), October 2017. 2567 [I-D.ietf-dots-data-channel] 2568 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 2569 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 2570 Service Open Threat Signaling (DOTS) Data Channel", draft- 2571 ietf-dots-data-channel-06 (work in progress), October 2572 2017. 2574 [I-D.ietf-dots-requirements] 2575 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 2576 Denial of Service (DDoS) Open Threat Signaling 2577 Requirements", draft-ietf-dots-requirements-07 (work in 2578 progress), October 2017. 2580 [I-D.ietf-dots-use-cases] 2581 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 2582 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 2583 Open Threat Signaling", draft-ietf-dots-use-cases-09 (work 2584 in progress), November 2017. 2586 [I-D.ietf-tls-tls13] 2587 Rescorla, E., "The Transport Layer Security (TLS) Protocol 2588 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 2589 July 2017. 2591 [I-D.rescorla-tls-dtls13] 2592 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2593 Datagram Transport Layer Security (DTLS) Protocol Version 2594 1.3", draft-rescorla-tls-dtls13-01 (work in progress), 2595 March 2017. 2597 [proto_numbers] 2598 "IANA, "Protocol Numbers"", 2011, 2599 . 2601 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2602 DOI 10.17487/RFC0791, September 1981, 2603 . 2605 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2606 Congestion Control Protocol (DCCP)", RFC 4340, 2607 DOI 10.17487/RFC4340, March 2006, 2608 . 2610 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2611 (CIDR): The Internet Address Assignment and Aggregation 2612 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2613 2006, . 2615 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 2616 Denial-of-Service Considerations", RFC 4732, 2617 DOI 10.17487/RFC4732, December 2006, 2618 . 2620 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 2621 Translation (NAT) Behavioral Requirements for Unicast 2622 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2623 2007, . 2625 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2626 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2627 . 2629 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 2630 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 2631 . 2633 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2634 "Transport Layer Security (TLS) Session Resumption without 2635 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 2636 January 2008, . 2638 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2639 the Network Configuration Protocol (NETCONF)", RFC 6020, 2640 DOI 10.17487/RFC6020, October 2010, 2641 . 2643 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 2644 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2645 2012, . 2647 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 2648 "Default Address Selection for Internet Protocol Version 6 2649 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 2650 . 2652 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2653 "Enrollment over Secure Transport", RFC 7030, 2654 DOI 10.17487/RFC7030, October 2013, 2655 . 2657 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2658 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2659 October 2013, . 2661 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2662 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2663 . 2665 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 2666 NETCONF Protocol over Transport Layer Security (TLS) with 2667 Mutual X.509 Authentication", RFC 7589, 2668 DOI 10.17487/RFC7589, June 2015, 2669 . 2671 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 2672 Layer Security (TLS) False Start", RFC 7918, 2673 DOI 10.17487/RFC7918, August 2016, 2674 . 2676 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 2677 (TLS) Cached Information Extension", RFC 7924, 2678 DOI 10.17487/RFC7924, July 2016, 2679 . 2681 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2682 Code: The Implementation Status Section", BCP 205, 2683 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2684 . 2686 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2687 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2688 March 2017, . 2690 Authors' Addresses 2692 Tirumaleswar Reddy 2693 McAfee, Inc. 2694 Embassy Golf Link Business Park 2695 Bangalore, Karnataka 560071 2696 India 2698 Email: kondtir@gmail.com 2699 Mohamed Boucadair 2700 Orange 2701 Rennes 35000 2702 France 2704 Email: mohamed.boucadair@orange.com 2706 Prashanth Patil 2707 Cisco Systems, Inc. 2709 Email: praspati@cisco.com 2711 Andrew Mortensen 2712 Arbor Networks, Inc. 2713 2727 S. State St 2714 Ann Arbor, MI 48104 2715 United States 2717 Email: amortensen@arbor.net 2719 Nik Teague 2720 Verisign, Inc. 2721 United States 2723 Email: nteague@verisign.com