idnits 2.17.00 (12 Aug 2021) /tmp/idnits35067/draft-ietf-dots-signal-channel-08.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 23, 2017) is 1639 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 2143, but not defined == Unused Reference: 'RFC7469' is defined on line 2705, but no explicit reference was found in the text == Outdated reference: draft-ietf-core-coap-tcp-tls has been published as RFC 8323 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-11) exists of draft-ietf-core-comi-01 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-05 == Outdated reference: draft-ietf-dots-architecture has been published as RFC 8811 == Outdated reference: draft-ietf-dots-data-channel has been published as RFC 8783 == Outdated reference: draft-ietf-dots-requirements has been published as RFC 8612 == Outdated reference: draft-ietf-dots-use-cases has been published as RFC 8903 == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair 5 Expires: May 27, 2018 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 November 23, 2017 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel 16 draft-ietf-dots-signal-channel-08 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 27, 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 . . . . . . . . . . . . . . 45 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 . . . . . . . . . . . . . . . . . 58 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 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 RECOMMENDED 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. A lifetime of 0 in the request is an 823 invalid value. 825 DOTS clients MUST include this parameter in their mitigation 826 requests. Upon the expiry of this lifetime, and if the request is 827 not refreshed, the mitigation request is removed. The request can 828 be refreshed by sending the same request again. The server MAY 829 refuse indefinite lifetime, for policy reasons; the granted 830 lifetime value is returned in the response. DOTS clients MUST be 831 prepared to not be granted mitigations with indefinite lifetimes. 832 The server MUST always indicate the actual lifetime in the 833 response and the remaining lifetime in status messages sent to the 834 client. This is a mandatory attribute. 836 The CBOR key values for the parameters are defined in Section 6. 837 Section 10 defines how the CBOR key values can be allocated to 838 standards bodies and vendors. 840 FQDN and URI mitigation scopes may be thought of as a form of scope 841 alias, in which the addresses to which the domain name or URI resolve 842 represent the full scope of the mitigation. 844 In the PUT request at least one of the attributes 'target-ip' or 845 'target-prefix' or 'fqdn' or 'uri 'or 'alias-name' MUST be present. 846 If the attribute value is empty, then the attribute MUST NOT be 847 present in the request. DOTS agents can safely ignore Vendor- 848 Specific parameters they don't 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 from a DOTS client are overlapping if 856 there is a common IP address, IP prefix, FQDN, URI, or alias-name. 857 To avoid maintaining a long list of overlapping mitigation requests 858 from a DOTS client and avoid error-prone provisioning of mitigation 859 requests from a DOTS client, the overlapped lower numeric 860 'mitigation-id' MUST be automatically deleted and no longer available 861 at the DOTS server. 863 The Uri-Path option carries a major and minor version nomenclature to 864 manage versioning and DOTS signal channel in this specification uses 865 v1 major version. 867 If the DOTS client is using the certificate provisioned by the 868 Enrollment over Secure Transport (EST) server [RFC7030] in the DOTS 869 gateway-domain to authenticate itself to the DOTS gateway, then the 870 'client-identifier' value can be the output of a cryptographic hash 871 algorithm whose input is the DER-encoded ASN.1 representation of the 872 Subject Public Key Info (SPKI) of an X.509 certificate. In this 873 version of the specification, the cryptographic hash algorithm used 874 is SHA-256 [RFC6234]. The output of the cryptographic hash algorithm 875 is truncated to 16 bytes; truncation is done by stripping off the 876 final 16 bytes. The truncated output is base64url encoded. If the 877 'client-identifier' value is already present in the mitigation 878 request received from the DOTS client, the DOTS gateway MAY compute 879 the 'client-identifier' value, as discussed above, and add the 880 computed 'client-identifier' value to the end of the 'client- 881 identifier' list. The DOTS server MUST NOT use the 'client- 882 identifier' for the DOTS client authentication process. 884 In both DOTS signal and data channel sessions, the DOTS client MUST 885 authenticate itself to the DOTS server (Section 9). The DOTS server 886 may use the algorithm in Section 7 of [RFC7589] to derive the DOTS 887 client identity or username from the client certificate. The DOTS 888 client identity allows the DOTS server to accept mitigation requests 889 with scopes which the DOTS client is authorized to manage. The DOTS 890 server couples the DOTS signal and data channel sessions using the 891 DOTS client identity and the 'client-identifier' parameter value, so 892 the DOTS server can validate whether the aliases conveyed in the 893 mitigation request were indeed created by the same DOTS client using 894 the DOTS data channel session. If the aliases were not created by 895 the DOTS client, the DOTS server returns 4.00 (Bad Request) in the 896 response. 898 The DOTS server couples the DOTS signal channel sessions using the 899 DOTS client identity and the 'client-identifier' parameter value, and 900 the DOTS server uses 'mitigation-id' parameter value to detect 901 duplicate mitigation requests. If the mitigation request contains 902 both alias-name and other parameters identifying the target resources 903 (such as, 'target-ip', 'target-prefix', 'target-port-range', 'fqdn', 904 or 'uri'), then the DOTS server appends the parameter values in 905 'alias-name' with the corresponding parameter values in 'target-ip', 906 'target-prefix', 'target-port-range', 'fqdn', or 'uri'. 908 Figure 7 shows a PUT request example to signal that ports 80, 8080, 909 and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are 910 being attacked (illustrated in JSON diagnostic notation). 912 Header: PUT (Code=0.03) 913 Uri-Host: "www.example.com" 914 Uri-Path: ".well-known" 915 Uri-Path: "dots" 916 Uri-Path: "v1" 917 Uri-Path: "mitigate" 918 Content-Format: "application/cbor" 919 { 920 "mitigation-scope": { 921 "client-identifier": [ 922 "dz6pHjaADkaFTbjr0JGBpw" 923 ], 924 "scope": [ 925 { 926 "mitigation-id": 12332, 927 "target-ip": [ 928 "2001:db8:6401::1", 929 "2001:db8:6401::2" 930 ], 931 "target-port-range": [ 932 { 933 "lower-port": 80 934 }, 935 { 936 "lower-port": 443 937 }, 938 { 939 "lower-port": 8080 940 } 941 ], 942 "target-protocol": [ 943 6 944 ] 945 } 947 ] 948 } 949 } 951 The CBOR encoding format is shown below: 953 A1 # map(1) 954 01 # unsigned(1) 955 A2 # map(2) 956 18 20 # unsigned(32) 957 81 # array(1) 958 76 # text(22) 959 647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw" 960 02 # unsigned(2) 961 81 # array(1) 962 A4 # map(4) 963 03 # unsigned(3) 964 19 302C # unsigned(12332) 965 04 # unsigned(4) 966 82 # array(2) 967 70 # text(16) 968 323030313A6462383A363430313A3A31 # "2001:db8:6401::1" 969 70 # text(16) 970 323030313A6462383A363430313A3A32 # "2001:db8:6401::2" 971 05 # unsigned(5) 972 83 # array(3) 973 A1 # map(1) 974 06 # unsigned(6) 975 18 50 # unsigned(80) 976 A1 # map(1) 977 06 # unsigned(6) 978 19 01BB # unsigned(443) 979 A1 # map(1) 980 06 # unsigned(6) 981 19 1F90 # unsigned(8080) 982 08 # unsigned(8) 983 81 # array(1) 984 06 # unsigned(6) 986 Figure 7: PUT for DOTS signal 988 The DOTS server indicates the result of processing the PUT request 989 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 990 codes are some sort of invalid requests. Figure 8 shows a PUT 991 response for CoAP 2.xx response codes. 993 { 994 "mitigation-scope": { 995 "client-identifier": [ 996 "string" 997 ], 998 "scope": [ 999 { 1000 "mitigation-id": integer, 1001 "lifetime": integer 1002 } 1003 ] 1004 } 1005 } 1007 Figure 8: 2.xx response body 1009 COAP 5.xx codes are returned if the DOTS server has erred or is 1010 currently unavailable to provide mitigation in response to the 1011 mitigation request from the DOTS client. 1013 If the DOTS server does not find the 'mitigation-id' parameter value 1014 conveyed in the PUT request in its configuration data, then the 1015 server MAY accept the mitigation request by sending back a 2.01 1016 (Created) response to the DOTS client; the DOTS server will 1017 consequently try to mitigate the attack. 1019 If the DOTS server finds the 'mitigation-id' parameter value conveyed 1020 in the PUT request in its configuration data, then the server MAY 1021 update the mitigation request, and a 2.04 (Changed) response is 1022 returned to indicate a successful update of the mitigation request. 1024 If the request is missing one or more mandatory attributes, then 4.00 1025 (Bad Request) will be returned in the response or if the request 1026 contains invalid or unknown parameters then 4.02 (Invalid query) is 1027 returned in the response. 1029 For a mitigation request to continue beyond the initial negotiated 1030 lifetime, the DOTS client need to refresh the current mitigation 1031 request by sending a new PUT request. The PUT request MUST use the 1032 same 'mitigation-id' value, and MUST repeat all the other parameters 1033 as sent in the original mitigation request apart from a possible 1034 change to the lifetime parameter value. 1036 A DOTS gateway MUST update the 'client-identifier' list in the 1037 response to remove the 'client-identifier' value it had added in the 1038 corresponding request before forwarding the response to the DOTS 1039 client. 1041 5.4.2. Withdraw a DOTS Signal 1043 A DELETE request is used to withdraw a DOTS signal from a DOTS server 1044 (Figure 9). 1046 Header: DELETE (Code=0.04) 1047 Uri-Host: "host" 1048 Uri-Path: ".well-known" 1049 Uri-Path: "dots" 1050 Uri-Path: "version" 1051 Uri-Path: "mitigate" 1052 Content-Format: "application/cbor" 1053 { 1054 "mitigation-scope": { 1055 "client-identifier": [ 1056 "string" 1057 ], 1058 "scope": [ 1059 { 1060 "mitigation-id": integer 1061 } 1062 ] 1063 } 1064 } 1066 Figure 9: Withdraw DOTS signal 1068 The DOTS server immediately acknowledges a DOTS client's request to 1069 withdraw the DOTS signal using 2.02 (Deleted) response code with no 1070 response payload. A 2.02 (Deleted) Response Code is returned even if 1071 the 'mitigation-id' parameter value conveyed in the DELETE request 1072 does not exist in its configuration data before the request. 1074 If the DOTS server finds the 'mitigation-id' parameter value conveyed 1075 in the DELETE request in its configuration data, then to protect 1076 against route or DNS flapping caused by a client rapidly toggling 1077 mitigation, and to dampen the effect of oscillating attacks, DOTS 1078 servers MAY allow mitigation to continue for a limited period after 1079 acknowledging a DOTS client's withdrawal of a mitigation request. 1080 During this period, the DOTS server status messages SHOULD indicate 1081 that mitigation is active but terminating. The initial active-but- 1082 terminating period SHOULD be sufficiently long to absorb latency 1083 incurred by route propagation. The active-but-terminating period 1084 SHOULD be set by default to 120 seconds. If the client requests 1085 mitigation again before the initial active-but-terminating period 1086 elapses, the DOTS server MAY exponentially increase the active-but- 1087 terminating period up to a maximum of 300 seconds (5 minutes). After 1088 the active-but-terminating period elapses, the DOTS server MUST treat 1089 the mitigation as terminated, as the DOTS client is no longer 1090 responsible for the mitigation. For example, if there is a financial 1091 relationship between the DOTS client and server domains, the DOTS 1092 client ceases incurring cost at this point. 1094 5.4.3. Retrieving a DOTS Signal 1096 A GET request is used to retrieve information (including status) of a 1097 DOTS signal from a DOTS server (Figure 10). If the DOTS server does 1098 not find the 'mitigation-id' parameter value conveyed in the GET 1099 request in its configuration data, then it responds with a 4.04 (Not 1100 Found) error response code. The 'c' (content) parameter and its 1101 permitted values defined in [I-D.ietf-core-comi] can be used to 1102 retrieve non-configuration data (attack mitigation status) or 1103 configuration data or both. The DOTS server SHOULD support this 1104 optional filtering capability but can safely ignore it if not 1105 supported. 1107 The examples below assume the default of "c=a". 1109 1) To retrieve all DOTS signals signaled by the DOTS client. 1111 Header: GET (Code=0.01) 1112 Uri-Host: "host" 1113 Uri-Path: ".well-known" 1114 Uri-Path: "dots" 1115 Uri-Path: "version" 1116 Uri-Path: "mitigate" 1117 Observe : 0 1118 { 1119 "mitigation-scope": { 1120 "client-identifier": [ 1121 "string" 1122 ] 1123 } 1124 } 1126 2) To retrieve a specific DOTS signal signaled by the DOTS client. 1127 The configuration data in the response will be formatted in the 1128 same order it was processed at the DOTS server. 1130 Header: GET (Code=0.01) 1131 Uri-Host: "host" 1132 Uri-Path: ".well-known" 1133 Uri-Path: "dots" 1134 Uri-Path: "version" 1135 Uri-Path: "mitigate" 1136 Observe : 0 1137 Content-Format: "application/cbor" 1138 { 1139 "mitigation-scope": { 1140 "client-identifier": [ 1141 "string" 1142 ], 1143 "scope": [ 1144 { 1145 "mitigation-id": integer 1146 } 1147 ] 1148 } 1149 } 1151 Figure 10: GET to retrieve the rules 1153 Figure 11 shows a response example of all the active mitigation 1154 requests associated with the DOTS client on the DOTS server and the 1155 mitigation status of each mitigation request. 1157 { 1158 "mitigation-scope": { 1159 "scope": [ 1160 { 1161 "mitigation-id": 12332, 1162 "mitigation-start": 1507818434.00, 1163 "target-protocol": [ 1164 17 1165 ], 1166 "lifetime":1800, 1167 "status":2, 1168 "bytes-dropped": 134334555, 1169 "bps-dropped": 43344, 1170 "pkts-dropped": 333334444, 1171 "pps-dropped": 432432 1172 }, 1173 { 1174 "mitigation-id": 12333, 1175 "mitigation-start": 1507818393.00, 1176 "target-protocol": [ 1177 6 1178 ], 1179 "lifetime":1800, 1180 "status":3 1181 "bytes-dropped": 0, 1182 "bps-dropped": 0, 1183 "pkts-dropped": 0, 1184 "pps-dropped": 0 1185 } 1186 ] 1187 } 1188 } 1190 Figure 11: Response body 1192 The mitigation status parameters are described below. 1194 lifetime: The remaining lifetime of the mitigation request in 1195 seconds. 1197 mitigation-start: Mitigation start time is represented in seconds 1198 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 1199 [RFC7049]). The encoding is modified so that the leading tag 1 1200 (epoch-based date/time) MUST be omitted. 1202 bytes-dropped: The total dropped byte count for the mitigation 1203 request since the attack mitigation is triggered. The count wraps 1204 around when it reaches the maximum value of unsigned integer. 1205 This is an optional attribute. 1207 bps-dropped: The average dropped bytes per second for the mitigation 1208 request since the attack mitigation is triggered. This SHOULD be 1209 a five-minute average. This is an optional attribute. 1211 pkts-dropped: The total dropped packet count for the mitigation 1212 request since the attack mitigation is triggered. This is an 1213 optional attribute. 1215 pps-dropped: The average dropped packets per second for the 1216 mitigation request since the attack mitigation is triggered. This 1217 SHOULD be a five-minute average. This is an optional attribute. 1219 status: Status of attack mitigation. The 'status' parameter is a 1220 mandatory attribute. 1222 The various possible values of 'status' parameter are explained 1223 below: 1225 /--------------------+---------------------------------------------------\ 1226 | Parameter value | Description | 1227 +--------------------+---------------------------------------------------+ 1228 | 1 | Attack mitigation is in progress | 1229 | | (e.g., changing the network path to re-route the | 1230 | | inbound traffic to DOTS mitigator). | 1231 +--------------------+---------------------------------------------------+ 1232 | 2 | Attack is successfully mitigated | 1233 | | (e.g., traffic is redirected to a DDOS mitigator | 1234 | | and attack traffic is dropped). | 1235 +--------------------+---------------------------------------------------+ 1236 | 3 | Attack has stopped and the DOTS client | 1237 | | can withdraw the mitigation request. | 1238 +--------------------+---------------------------------------------------+ 1239 | 4 | Attack has exceeded the mitigation provider | 1240 | | capability. | 1241 +--------------------+---------------------------------------------------+ 1242 | 5 | DOTS client has withdrawn the mitigation request | 1243 | | and the mitigation is active but terminating. | 1244 \--------------------+---------------------------------------------------/ 1246 The observe option defined in [RFC7641] extends the CoAP core 1247 protocol with a mechanism for a CoAP client to "observe" a resource 1248 on a CoAP server: the client retrieves a representation of the 1249 resource and requests this representation be updated by the server as 1250 long as the client is interested in the resource. A DOTS client 1251 conveys the observe option set to 0 in the GET request to receive 1252 unsolicited notifications of attack mitigation status from the DOTS 1253 server. Unidirectional notifications within the bidirectional signal 1254 channel allows unsolicited message delivery, enabling asynchronous 1255 notifications between the agents. Due to the higher likelihood of 1256 packet loss during a DDoS attack, DOTS server periodically sends 1257 attack mitigation status to the DOTS client and also notifies the 1258 DOTS client whenever the status of the attack mitigation changes. If 1259 the DOTS server cannot maintain a RTT estimate then it SHOULD NOT 1260 send more than one unsolicited notification every 3 seconds, and 1261 SHOULD use an even less aggressive rate when possible (case 2 in 1262 Section 3.1.3 of [RFC8085]). A DOTS client that is no longer 1263 interested in receiving notifications from the DOTS server can simply 1264 "forget" the observation. When the DOTS server then sends the next 1265 notification, the DOTS client will not recognize the token in the 1266 message and thus will return a Reset message. This causes the DOTS 1267 server to remove the associated entry. Alternatively, the DOTS 1268 client can explicitly deregister by issuing a GET request that has 1269 the Token field set to the token of the observation to be cancelled 1270 and includes an Observe Option with the value set to 1 (deregister). 1272 DOTS Client DOTS Server 1273 | | 1274 | GET / | 1275 | Token: 0x4a | Registration 1276 | Observe: 0 | 1277 +------------------------------>| 1278 | | 1279 | 2.05 Content | 1280 | Token: 0x4a | Notification of 1281 | Observe: 12 | the current state 1282 | status: "mitigation | 1283 | in progress" | 1284 |<------------------------------+ 1285 | 2.05 Content | 1286 | Token: 0x4a | Notification upon 1287 | Observe: 44 | a state change 1288 | status: "mitigation | 1289 | complete" | 1290 |<------------------------------+ 1291 | 2.05 Content | 1292 | Token: 0x4a | Notification upon 1293 | Observe: 60 | a state change 1294 | status: "attack stopped" | 1295 |<------------------------------+ 1296 | | 1298 Figure 12: Notifications of attack mitigation status 1300 5.4.3.1. Mitigation Status 1302 The DOTS client can send the GET request at frequent intervals 1303 without the Observe option to retrieve the configuration data of the 1304 mitigation request and non-configuration data (i.e., the attack 1305 status). The frequency of polling the DOTS server to get the 1306 mitigation status should follow the transmission guidelines given in 1307 Section 3.1.3 of [RFC8085]. If the DOTS server has been able to 1308 mitigate the attack and the attack has stopped, the DOTS server 1309 indicates as such in the status, and the DOTS client recalls the 1310 mitigation request by issuing a DELETE for the mitigation-id. 1312 A DOTS client should react to the status of the attack from the DOTS 1313 server and not the fact that it has recognized, using its own means, 1314 that the attack has been mitigated. This ensures that the DOTS 1315 client does not recall a mitigation request in a premature fashion 1316 because it is possible that the DOTS client does not sense the DDOS 1317 attack on its resources but the DOTS server could be actively 1318 mitigating the attack and the attack is not completely averted. 1320 5.4.4. Efficacy Update from DOTS Client 1322 While DDoS mitigation is active, due to the likelihood of packet 1323 loss, a DOTS client MAY periodically transmit DOTS mitigation 1324 efficacy updates to the relevant DOTS server. A PUT request 1325 (Figure 13) is used to convey the mitigation efficacy update to the 1326 DOTS server. 1328 The PUT request MUST include all the parameters used in the PUT 1329 request to convey the DOTS signal (Section 5.4.1) unchanged apart 1330 from the lifetime parameter value. If this is not the case, the DOTS 1331 server MUST reject the request with a 4.02 error response code. 1333 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1334 value is used to make the PUT request conditional on the current 1335 existence of the mitigation request. If UDP is used as transport, 1336 CoAP requests may arrive out-of-order. For example, the DOTS client 1337 may send a PUT request to convey an efficacy update to the DOTS 1338 server followed by a DELETE request to withdraw the mitigation 1339 request, but the DELETE request arrives at the DOTS server before the 1340 PUT request. To handle out-of-order delivery of requests, if an If- 1341 Match option is present in the PUT request and the 'mitigation-id' in 1342 the request matches a mitigation request from that DOTS client, then 1343 the request is processed. If no match is found, the PUT request is 1344 silently ignored. 1346 Header: PUT (Code=0.03) 1347 Uri-Host: "host" 1348 Uri-Path: ".well-known" 1349 Uri-Path: "dots" 1350 Uri-Path: "version" 1351 Uri-Path: "mitigate" 1352 Content-Format: "application/cbor" 1353 { 1354 "mitigation-scope": { 1355 "client-identifier": [ 1356 "string" 1357 ], 1358 "scope": [ 1359 { 1360 "mitigation-id": integer, 1361 "target-ip": [ 1362 "string" 1363 ], 1364 "target-port-range": [ 1365 { 1366 "lower-port": integer, 1367 "upper-port": integer 1368 } 1369 ], 1370 "target-protocol": [ 1371 integer 1372 ], 1373 "fqdn": [ 1374 "string" 1375 ], 1376 "uri": [ 1377 "string" 1378 ], 1379 "alias-name": [ 1380 "string" 1381 ], 1382 "lifetime": integer, 1383 "attack-status": integer 1384 } 1385 ] 1386 } 1387 } 1389 Figure 13: Efficacy Update 1391 The 'attack-status' parameter is a mandatory attribute when doing a 1392 efficacy update. The various possible values contained in the 1393 'attack-status' parameter are described below: 1395 /--------------------+------------------------------------------------------\ 1396 | Parameter value | Description | 1397 +--------------------+------------------------------------------------------+ 1398 | 1 | DOTS client determines that it is still under attack.| 1399 +--------------------+------------------------------------------------------+ 1400 | 2 | DOTS client determines that the attack is | 1401 | | successfully mitigated | 1402 | | (e.g., attack traffic is not seen). | 1403 \--------------------+------------------------------------------------------/ 1405 The DOTS server indicates the result of processing a PUT request 1406 using CoAP response codes. The response code 2.04 (Changed) is 1407 returned if the DOTS server has accepted the mitigation efficacy 1408 update. The error response code 5.03 (Service Unavailable) is 1409 returned if the DOTS server has erred or is incapable of performing 1410 the mitigation. 1412 5.5. DOTS Signal Channel Session Configuration 1414 The DOTS client can negotiate, configure, and retrieve the DOTS 1415 signal channel session behavior. The DOTS signal channel can be 1416 used, for example, to configure the following: 1418 a. Heartbeat interval: DOTS agents regularly send heartbeats (CoAP 1419 Ping/Pong) to each other after mutual authentication in order to 1420 keep the DOTS signal channel open, heartbeat messages are 1421 exchanged between the DOTS agents every heartbeat-interval 1422 seconds to detect the current status of the DOTS signal channel 1423 session. 1425 b. Missing heartbeats allowed: This variable indicates the maximum 1426 number of consecutive heartbeat messages for which a DOTS agent 1427 did not receive a response before concluding that the session is 1428 disconnected or defunct. 1430 c. Acceptable signal loss ratio: Maximum retransmissions, 1431 retransmission timeout value and other message transmission 1432 parameters for the DOTS signal channel. 1434 Reliability is provided to requests and responses by marking them as 1435 Confirmable (CON) messages. DOTS signal channel session 1436 configuration requests and responses are marked as Confirmable (CON) 1437 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1438 message is retransmitted using a default timeout and exponential 1439 back-off between retransmissions, until the DOTS server sends an 1440 Acknowledgement message (ACK) with the same Message ID conveyed from 1441 the DOTS client. Message transmission parameters are defined in 1442 Section 4.8 of [RFC7252]. Reliability is provided to the responses 1443 by marking them as Confirmable (CON) messages. The DOTS server can 1444 either piggyback the response in the acknowledgement message or if 1445 the DOTS server is not able to respond immediately to a request 1446 carried in a Confirmable message, it simply responds with an Empty 1447 Acknowledgement message so that the DOTS client can stop 1448 retransmitting the request. Empty Acknowledgement message is 1449 explained in Section 2.2 of [RFC7252]. When the response is ready, 1450 the server sends it in a new Confirmable message which then in turn 1451 needs to be acknowledged by the DOTS client (see Sections 5.2.1 and 1452 Sections 5.2.2 of [RFC7252]). Requests and responses exchanged 1453 between DOTS agents during peacetime are marked as Confirmable 1454 messages. 1456 Implementation Note: A DOTS client that receives a response in a CON 1457 message may want to clean up the message state right after sending 1458 the ACK. If that ACK is lost and the DOTS server retransmits the 1459 CON, the DOTS client may no longer have any state to which to 1460 correlate this response, making the retransmission an unexpected 1461 message; the DOTS client will send a Reset message so it does not 1462 receive any more retransmissions. This behavior is normal and not an 1463 indication of an error (see Section 5.3.2 of [RFC7252] for more 1464 details). 1466 5.5.1. Discover Configuration Parameters 1468 A GET request is used to obtain acceptable and current configuration 1469 parameters on the DOTS server for DOTS signal channel session 1470 configuration. Figure 14 shows how to obtain acceptable 1471 configuration parameters for the server. 1473 Header: GET (Code=0.01) 1474 Uri-Host: "host" 1475 Uri-Path: ".well-known" 1476 Uri-Path: "dots" 1477 Uri-Path: "version" 1478 Uri-Path: "config" 1480 Figure 14: GET to retrieve configuration 1482 The DOTS server in the 2.05 (Content) response conveys the current, 1483 minimum and maximum attribute values acceptable by the DOTS server. 1485 Content-Format: "application/cbor" 1486 { 1487 "heartbeat-interval": { 1488 "CurrentValue": integer, 1489 "MinValue": integer, 1490 "MaxValue" : integer, 1491 }, 1492 "missing-hb-allowed": { 1493 "CurrentValue": integer, 1494 "MinValue": integer, 1495 "MaxValue" : integer, 1496 }, 1497 "max-retransmit": { 1498 "CurrentValue": integer, 1499 "MinValue": integer, 1500 "MaxValue" : integer, 1501 }, 1502 "ack-timeout": { 1503 "CurrentValue": integer, 1504 "MinValue": integer, 1505 "MaxValue" : integer, 1506 }, 1507 "ack-random-factor": { 1508 "CurrentValue": number, 1509 "MinValue": number, 1510 "MaxValue" : number, 1511 }, 1512 "trigger-mitigation": { 1513 "CurrentValue": boolean, 1514 } 1515 } 1517 Figure 15: GET response body 1519 Figure 16 shows an example of acceptable and current configuration 1520 parameters on the DOTS server for DOTS signal channel session 1521 configuration. 1523 Content-Format: "application/cbor" 1524 { 1525 "heartbeat-interval": { 1526 "CurrentValue": 30, 1527 "MinValue": 15, 1528 "MaxValue" : 240, 1529 }, 1530 "missing-hb-allowed": { 1531 "CurrentValue": 5, 1532 "MinValue": 3, 1533 "MaxValue" : 9, 1534 }, 1535 "max-retransmit": { 1536 "CurrentValue": 3, 1537 "MinValue": 2, 1538 "MaxValue" : 15, 1539 }, 1540 "ack-timeout": { 1541 "CurrentValue": 2, 1542 "MinValue": 1, 1543 "MaxValue" : 30, 1544 }, 1545 "ack-random-factor": { 1546 "CurrentValue": 1.5, 1547 "MinValue": 1.1, 1548 "MaxValue" : 4.0, 1549 }, 1550 "trigger-mitigation": { 1551 "CurrentValue": true, 1552 } 1553 } 1555 Figure 16: configuration response body 1557 5.5.2. Convey DOTS Signal Channel Session Configuration 1559 A PUT request is used to convey the configuration parameters for the 1560 signaling channel (e.g., heartbeat interval, maximum 1561 retransmissions). Message transmission parameters for CoAP are 1562 defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of 1563 transmission parameter values are ack_timeout (2 seconds), max- 1564 retransmit (3), ack-random-factor (1.5). In addition to those 1565 parameters, the RECOMMENDED specific DOTS transmission parameter 1566 values are heartbeat-interval (30 seconds) and missing-hb-allowed 1567 (5). 1569 Note: heartbeat-interval should be tweaked to also assist DOTS 1570 messages for NAT traversal (SIG-010 of 1572 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 1573 messages must not be sent more frequently than once every 15 1574 seconds and should use longer intervals when possible. 1575 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 1576 minutes or longer, but experience shows that sending packets every 1577 15 to 30 seconds is necessary to prevent the majority of 1578 middleboxes from losing state for UDP flows. From that 1579 standpoint, this specification recommends a minimum heartbeat- 1580 interval of 15 seconds and a maximum heartbeat-interval of 240 1581 seconds. The recommended value of 30 seconds is selected to 1582 anticipate the expiry of NAT state. 1584 A heartbeat-interval of 30 second may be seen as too chatty in 1585 some deployments. For such deployments, DOTS agents may negotiate 1586 longer heartbeat-interval values to avoid overloading the network 1587 with too frequent keepalives. 1589 When a confirmable "CoAP ping" is sent, and if there is no response, 1590 the "CoAP ping" will get retransmitted max-retransmit number of times 1591 by the CoAP layer using an initial timeout set to a random duration 1592 between ack_timeout and (ack-timeout*ack-random-factor) and 1593 exponential back-off between retransmissions. By choosing the 1594 recommended transmission parameters, the "CoAP ping" will timeout 1595 after 45 seconds. If the DOTS agent does not receive any response 1596 from the peer DOTS agent for missing-hb-allowed number of consecutive 1597 "CoAP ping" confirmable messages, then it concludes that the DOTS 1598 signal channel session is disconnected. A DOTS client MUST NOT 1599 transmit a "CoAP ping" while waiting for the previous "CoAP ping" 1600 response from the same DOTS server. 1602 If the DOTS agent wishes to change the default values of message 1603 transmission parameters, then it should follow the guidance given in 1604 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 1605 values for message transmission parameters and default values for 1606 non-negotiated message transmission parameters. 1608 The signaling channel session configuration is applicable to a single 1609 DOTS signal channel session between the DOTS agents. 1611 Header: PUT (Code=0.03) 1612 Uri-Host: "host" 1613 Uri-Path: ".well-known" 1614 Uri-Path: "dots" 1615 Uri-Path: "version" 1616 Uri-Path: "config" 1617 Content-Format: "application/cbor" 1618 { 1619 "signal-config": { 1620 "session-id": integer, 1621 "heartbeat-interval": integer, 1622 "missing-hb-allowed": integer, 1623 "max-retransmit": integer, 1624 "ack-timeout": integer, 1625 "ack-random-factor": number 1626 "trigger-mitigation": boolean 1627 } 1628 } 1630 Figure 17: PUT to convey the DOTS signal channel session 1631 configuration data. 1633 The parameters are described below: 1635 session-id: Identifier for the DOTS signal channel session 1636 configuration data represented as an integer. This identifier 1637 MUST be generated by the DOTS client. This document does not make 1638 any assumption about how this identifier is generated. This is a 1639 mandatory attribute. 1641 heartbeat-interval: Time interval in seconds between two 1642 consecutive heartbeat messages. This is an optional attribute. 1644 missing-hb-allowed: Maximum number of consecutive heartbeat 1645 messages for which the DOTS agent did not receive a response 1646 before concluding that the session is disconnected. This is an 1647 optional attribute. 1649 max-retransmit: Maximum number of retransmissions for a message 1650 (referred to as MAX_RETRANSMIT parameter in CoAP). This is an 1651 optional attribute. 1653 ack-timeout: Timeout value in seconds used to calculate the initial 1654 retransmission timeout value (referred to as ACK_TIMEOUT parameter 1655 in CoAP). This is an optional attribute. 1657 ack-random-factor: Random factor used to influence the timing of 1658 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1659 CoAP). This is an optional attribute. 1661 trigger-mitigation: If the parameter value is set to 'false', then 1662 DDoS mitigation is triggered only when the DOTS signal channel 1663 session is lost. Automated mitigation on loss of signal is 1664 discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. If 1665 the DOTS client ceases to respond to heartbeat messages, then the 1666 DOTS server can detect that the DOTS session is lost. The default 1667 value of the parameter is 'true'. This is an optional attribute. 1669 In the PUT request at least one of the attributes heartbeat-interval, 1670 missing-hb-allowed, max-retransmit, ack-timeout, ack-random-factor, 1671 and trigger-mitigation MUST be present. The PUT request with higher 1672 numeric session-id value over-rides the DOTS signal channel session 1673 configuration data installed by a PUT request with a lower numeric 1674 session-id value. 1676 Figure 18 shows a PUT request example to convey the configuration 1677 parameters for the DOTS signal channel. 1679 Header: PUT (Code=0.03) 1680 Uri-Host: "www.example.com" 1681 Uri-Path: ".well-known" 1682 Uri-Path: "dots" 1683 Uri-Path: "v1" 1684 Uri-Path: "config" 1685 Content-Format: "application/cbor" 1686 { 1687 "signal-config": { 1688 "session-id": 1234534333242, 1689 "heartbeat-interval": 91, 1690 "missing-hb-allowed": 3, 1691 "max-retransmit": 7, 1692 "ack-timeout": 5, 1693 "ack-random-factor": 1.5, 1694 "trigger-mitigation": false 1695 } 1696 } 1698 Figure 18: PUT to convey the configuration parameters 1700 The DOTS server indicates the result of processing the PUT request 1701 using CoAP response codes: 1703 o If the DOTS server finds the 'session-id' parameter value conveyed 1704 in the PUT request in its configuration data and if the DOTS 1705 server has accepted the updated configuration parameters, then 1706 2.04 (Changed) code is returned in the response. 1708 o If the DOTS server does not find the 'session-id' parameter value 1709 conveyed in the PUT request in its configuration data and if the 1710 DOTS server has accepted the configuration parameters, then a 1711 response code 2.01 (Created) is returned in the response. 1713 o If the request is missing one or more mandatory attributes, then 1714 4.00 (Bad Request) is returned in the response. 1716 o If the request contains one or more invalid or unknown parameters, 1717 then 4.02 (Invalid query) code is returned in the response. 1719 o Response code 4.22 (Unprocessable Entity) is returned in the 1720 response, if any of the heartbeat-interval, missing-hb-allowed, 1721 max-retransmit, target-protocol, ack-timeout, and ack-random- 1722 factor attribute values are not acceptable to the DOTS server. 1723 Upon receipt of the 4.22 error response code, the DOTS client 1724 should request the maximum and minimum attribute values acceptable 1725 to the DOTS server (Section 5.5.1). The DOTS client may re-try 1726 and send the PUT request with updated attribute values acceptable 1727 to the DOTS server. 1729 5.5.3. Delete DOTS Signal Channel Session Configuration 1731 A DELETE request is used to delete the installed DOTS signal channel 1732 session configuration data (Figure 19). 1734 Header: DELETE (Code=0.04) 1735 Uri-Host: "host" 1736 Uri-Path: ".well-known" 1737 Uri-Path: "dots" 1738 Uri-Path: "version" 1739 Uri-Path: "config" 1740 Content-Format: "application/cbor" 1742 Figure 19: DELETE configuration 1744 The DOTS server resets the DOTS signal channel session configuration 1745 back to the default values and acknowledges a DOTS client's request 1746 to remove the DOTS signal channel session configuration using 2.02 1747 (Deleted) response code. 1749 5.6. Redirected Signaling 1751 Redirected Signaling is discussed in detail in Section 3.2.2 of 1752 [I-D.ietf-dots-architecture]. If the DOTS server wants to redirect 1753 the DOTS client to an alternative DOTS server for a signaling session 1754 then the response code 3.00 (alternate server) will be returned in 1755 the response to the client. The DOTS server can return the error 1756 response code 3.00 in response to a PUT request from the DOTS client 1757 or convey the error response code 3.00 in a unidirectional 1758 notification response from the DOTS server. 1760 The DOTS server in the error response conveys the alternate DOTS 1761 server FQDN, and the alternate DOTS server IP addresses and time to 1762 live values in the CBOR body. 1764 { 1765 "alt-server": "string", 1766 "alt-server-record": [ 1767 { 1768 "addr": "string", 1769 "ttl" : integer, 1770 } 1771 ] 1772 } 1774 Figure 20: Error response body 1776 The parameters are described below: 1778 alt-server: FQDN of an alternate DOTS server. 1780 addr: IP address of an alternate DOTS server. 1782 ttl: Time to live (TTL) represented as an integer number of seconds. 1784 Figure 21 shows a 3.00 response example to convey the DOTS alternate 1785 server www.example-alt.com, its IP addresses 2001:db8:6401::1 and 1786 2001:db8:6401::2, and TTL values 3600 and 1800. 1788 { 1790 "alt-server": "www.example-alt.com", 1791 "alt-server-record": [ 1792 { 1793 "ttl" : 3600, 1794 "addr": "2001:db8:6401::1" 1795 }, 1796 { 1797 "ttl" : 1800, 1798 "addr": "2001:db8:6401::2" 1799 } 1800 ] 1801 } 1803 Figure 21: Example of error response body 1805 When the DOTS client receives 3.00 response, it considers the current 1806 request as having failed, but SHOULD try the request with the 1807 alternate DOTS server. During a DDOS attack, the DNS server may be 1808 subjected to DDOS attack, alternate DOTS server IP addresses conveyed 1809 in the 3.00 response help the DOTS client to skip DNS lookup of the 1810 alternate DOTS server and can try to establish UDP or TCP session 1811 with the alternate DOTS server IP addresses. The DOTS client SHOULD 1812 implement DNS64 function to handle the scenario where IPv6-only DOTS 1813 client communicates with IPv4-only alternate DOTS server. 1815 5.7. Heartbeat Mechanism 1817 To provide a metric of signal health and distinguish an 'idle' signal 1818 channel from a 'disconnected' or 'defunct' session, the DOTS agent 1819 sends a heartbeat over the signal channel to maintain its half of the 1820 channel. The DOTS agent similarly expects a heartbeat from its peer 1821 DOTS agent, and may consider a session terminated in the extended 1822 absence of a peer agent heartbeat. 1824 While the communication between the DOTS agents is quiescent, the 1825 DOTS client will probe the DOTS server to ensure it has maintained 1826 cryptographic state and vice versa. Such probes can also keep alive 1827 firewall and/or NAT bindings. This probing reduces the frequency of 1828 establishing a new handshake when a DOTS signal needs to be conveyed 1829 to the DOTS server. 1831 In case of a volumetric DDoS attack saturating the incoming link to 1832 the DOTS client, all traffic from the DOTS server to the DOTS client 1833 will likely be dropped, although the DOTS server receives heartbeat 1834 requests and DOTS messages from the DOTS client. In this scenario, 1835 the DOTS agents MUST behave differently to handle message 1836 transmission and DOTS session liveliness during link saturation: 1838 o The DOTS client MUST NOT consider the DOTS session terminated even 1839 after maximum "missing-hb-allowed" threshold is reached. The DOTS 1840 client SHOULD continue to use the current DOTS session, and send 1841 heartbeat requests over the current DOTS session, so the DOTS 1842 server knows the DOTS client has not disconnected the DOTS 1843 session. After the maximum "missing-hb-allowed" threshold is 1844 reached, the DOTS client SHOULD try (D)TLS session resumption. 1845 The DOTS client SHOULD send mitigation requests over the current 1846 DOTS session, and in parallel, try (D)TLS session resumption or 1847 0-RTT mode in DTLS 1.3 to piggyback the mitigation request in the 1848 ClientHello message. Once the link is no longer statured, if 1849 traffic from the DOTS server reaches the DOTS client over the 1850 current DOTS session, the DOTS client can stop (D)TLS session 1851 resumption or if (D)TLS session resumption is successful then 1852 disconnect the current DOTS session. 1854 o If the DOTS server does not receive any traffic from the peer DOTS 1855 client, then the DOTS server sends heartbeat requests to the DOTS 1856 client and after maximum "missing-hb-allowed" threshold is 1857 reached, the DOTS server concludes the session is disconnected. 1859 In DOTS over UDP, heartbeat messages may be exchanged between the 1860 DOTS agents using the "COAP ping" mechanism defined in Section 4.2 of 1861 [RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable 1862 message and the peer DOTS agent will respond by sending an Reset 1863 message. 1865 In DOTS over TCP, heartbeat messages can be exchanged between the 1866 DOTS agents using the Ping and Pong messages specified in Section 4.4 1867 of [I-D.ietf-core-coap-tcp-tls]. That is, the DOTS agent sends a 1868 Ping message and the peer DOTS agent would respond by sending a 1869 single Pong message. 1871 6. Mapping parameters to CBOR 1873 All parameters in the payload in the DOTS signal channel MUST be 1874 mapped to CBOR types as follows and are given an integer key to save 1875 space. The recipient of the payload MAY reject the information if it 1876 is not suitably mapped. 1878 /--------------------+------------------------+--------------------------\ 1879 | Parameter name | CBOR key | CBOR major type of value | 1880 +--------------------+------------------------+--------------------------+ 1881 | mitigation-scope | 1 | 5 (map) | 1882 | scope | 2 | 5 (map) | 1883 | mitigation-id | 3 | 0 (unsigned) | 1884 | target-ip | 4 | 4 (array) | 1885 | target-port-range | 5 | 4 | 1886 | lower-port | 6 | 0 | 1887 | upper-port | 7 | 0 | 1888 | target-protocol | 8 | 4 | 1889 | fqdn | 9 | 4 | 1890 | uri | 10 | 4 | 1891 | alias-name | 11 | 4 | 1892 | lifetime | 12 | 0 | 1893 | attack-status | 13 | 0 | 1894 | signal-config | 14 | 5 | 1895 | heartbeat-interval | 15 | 0 | 1896 | max-retransmit | 16 | 0 | 1897 | ack-timeout | 17 | 0 | 1898 | ack-random-factor | 18 | 7 | 1899 | MinValue | 19 | 0 | 1900 | MaxValue | 20 | 0 | 1901 | status | 21 | 0 | 1902 | bytes-dropped | 22 | 0 | 1903 | bps-dropped | 23 | 0 | 1904 | pkts-dropped | 24 | 0 | 1905 | pps-dropped | 25 | 0 | 1906 | session-id | 26 | 0 | 1907 | trigger-mitigation | 27 | 7 (simple types) | 1908 | missing-hb-allowed | 28 | 0 | 1909 | CurrentValue | 29 | 0 | 1910 | mitigation-start | 30 | 7 (floating-point) | 1911 | target-prefix | 31 | 4 (array) | 1912 | client-identifier | 32 | 2 (byte string) | 1913 | alt-server | 33 | 2 | 1914 | alt-server-record | 34 | 4 | 1915 | addr | 35 | 2 | 1916 | ttl | 36 | 0 | 1917 \--------------------+------------------------+--------------------------/ 1919 Figure 22: CBOR mappings used in DOTS signal channel message 1921 7. (D)TLS Protocol Profile and Performance considerations 1923 This section defines the (D)TLS protocol profile of DOTS signal 1924 channel over (D)TLS and DOTS data channel over TLS. 1926 There are known attacks on (D)TLS, such as machine-in-the-middle and 1927 protocol downgrade. These are general attacks on (D)TLS and not 1928 specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for 1929 discussion of these security issues. DOTS agents MUST adhere to the 1930 (D)TLS implementation recommendations and security considerations of 1931 [RFC7525] except with respect to (D)TLS version. Since encryption of 1932 DOTS using (D)TLS is virtually a green-field deployment DOTS agents 1933 MUST implement only (D)TLS 1.2 or later. 1935 When a DOTS client is configured with a domain name of the DOTS 1936 server, and connects to its configured DOTS server, the server may 1937 present it with a PKIX certificate. In order to ensure proper 1938 authentication, DOTS client MUST verify the entire certification path 1939 per [RFC5280]. The DOTS client additionaly uses [RFC6125] validation 1940 techniques to compare the domain name to the certificate provided. 1942 A key challenge to deploying DOTS is provisioning DOTS clients, 1943 including the distribution of keying material to DOTS clients to make 1944 possible the required mutual authentication of DOTS agents. This 1945 specification relies on EST to overcome this. EST defines a method 1946 of certificate enrollment by which domains operating DOTS servers may 1947 provision DOTS clients with all necessary cryptographic keying 1948 material, including a private key and certificate with which to 1949 authenticate itself. This document does not specify which EST 1950 mechanism the DOTS client uses to achieve initial enrollment. 1952 Implementations compliant with this profile MUST implement all of the 1953 following items: 1955 o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect 1956 against replay attacks. 1958 o (D)TLS session resumption without server-side state [RFC5077] to 1959 resume session and convey the DOTS signal. 1961 o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduce 1962 the size of the ServerHello, and can be used by DOTS agents that 1963 cannot obtain certificates (e.g., DOTS clients and DOTS gateways 1964 on private networks). 1966 Implementations compliant with this profile SHOULD implement all of 1967 the following items to reduce the delay required to deliver a DOTS 1968 signal: 1970 o TLS False Start [RFC7918] which reduces round-trips by allowing 1971 the TLS second flight of messages (ChangeCipherSpec) to also 1972 contain the DOTS signal. 1974 o Cached Information Extension [RFC7924] which avoids transmitting 1975 the server's certificate and certificate chain if the client has 1976 cached that information from a previous TLS handshake. 1978 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 1979 convey DOTS signal. 1981 7.1. MTU and Fragmentation Issues 1983 To avoid DOTS signal message fragmentation and the consequently 1984 decreased probability of message delivery, DOTS agents MUST ensure 1985 that the DTLS record MUST fit within a single datagram. If the Path 1986 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 1987 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 1988 is used to convey the DOTS signal messages then the DOTS client must 1989 consider the amount of record expansion expected by the DTLS 1990 processing when calculating the size of CoAP message that fits within 1991 the path MTU. Path MTU MUST be greater than or equal to [CoAP 1992 message size + DTLS overhead of 13 octets + authentication overhead 1993 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 1994 of [RFC6347]]. If the request size exceeds the Path MTU then the 1995 DOTS client MUST split the DOTS signal into separate messages, for 1996 example the list of addresses in the 'target-ip' parameter could be 1997 split into multiple lists and each list conveyed in a new PUT 1998 request. 2000 Implementation Note: DOTS choice of message size parameters works 2001 well with IPv6 and with most of today's IPv4 paths. However, with 2002 IPv4, it is harder to absolutely ensure that there is no IP 2003 fragmentation. If IPv4 support on unusual networks is a 2004 consideration and path MTU is unknown, implementations may want to 2005 limit themselves to more conservative IPv4 datagram sizes such as 576 2006 bytes, as per [RFC0791] IP packets up to 576 bytes should never need 2007 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal 2008 over a UDP datagram will generally avoid IP fragmentation. 2010 8. (D)TLS 1.3 considerations 2012 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 2013 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 2014 [I-D.rescorla-tls-dtls13] is based on the TLS 1.3 protocol and 2015 provides equivalent security guarantees. (D)TLS 1.3 provides two 2016 basic handshake modes of interest to DOTS signal channel: 2018 o Absent packet loss, a full handshake in which the DOTS client is 2019 able to send the DOTS signal message after one round trip and the 2020 DOTS server immediately after receiving the first DOTS signal 2021 message from the client. 2023 o 0-RTT mode in which the DOTS client can authenticate itself and 2024 send DOTS signal message on its first flight, thus reducing 2025 handshake latency. 0-RTT only works if the DOTS client has 2026 previously communicated with that DOTS server, which is very 2027 likely with the DOTS signal channel. The DOTS client SHOULD 2028 establish a (D)TLS session with the DOTS server during peacetime 2029 and share a PSK. During DDOS attack, the DOTS client can use the 2030 (D)TLS session to convey the DOTS signal message and if there is 2031 no response from the server after multiple re-tries then the DOTS 2032 client can resume the (D)TLS session in 0-RTT mode using PSK. A 2033 simplified TLS 1.3 handshake with 0-RTT DOTS signal message 2034 exchange is shown in Figure 23. 2036 DOTS Client DOTS Server 2038 ClientHello 2039 (Finished) 2040 (0-RTT DOTS signal message) 2041 (end_of_early_data) --------> 2042 ServerHello 2043 {EncryptedExtensions} 2044 {ServerConfiguration} 2045 {Certificate} 2046 {CertificateVerify} 2047 {Finished} 2048 <-------- [DOTS signal message] 2049 {Finished} --------> 2051 [DOTS signal message] <-------> [DOTS signal message] 2053 Figure 23: TLS 1.3 handshake with 0-RTT 2055 9. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 2057 (D)TLS based on client certificate can be used for mutual 2058 authentication between DOTS agents. If a DOTS gateway is involved, 2059 DOTS clients and DOTS gateway MUST perform mutual authentication; 2060 only authorized DOTS clients are allowed to send DOTS signals to a 2061 DOTS gateway. DOTS gateway and DOTS server MUST perform mutual 2062 authentication; DOTS server only allows DOTS signals from authorized 2063 DOTS gateway, creating a two-link chain of transitive authentication 2064 between the DOTS client and the DOTS server. 2066 +-------------------------------------------------+ 2067 | example.com domain +---------+ | 2068 | | AAA | | 2069 | +---------------+ | Server | | 2070 | | Application | +------+--+ | 2071 | | server + ^ 2072 | | (DOTS client) |<-----------------+ | | 2073 | +---------------+ | | | example.net domain 2074 | V V | 2075 | +-------------+ | +---------------+ 2076 | +--------------+ | | | | | 2077 | | Guest +<-----x----->+ +<---------------->+ DOTS | 2078 | | (DOTS client)| | DOTS | | | Server | 2079 | +--------------+ | Gateway | | | | 2080 | +----+--------+ | +---------------+ 2081 | ^ | 2082 | | | 2083 | +----------------+ | | 2084 | | DDOS detector | | | 2085 | | (DOTS client) +<--------------+ | 2086 | +----------------+ | 2087 | | 2088 +-------------------------------------------------+ 2090 Figure 24: Example of Authentication and Authorization of DOTS Agents 2092 In the example depicted in Figure 24, the DOTS gateway and DOTS 2093 clients within the 'example.com' domain mutually authenticate with 2094 each other. After the DOTS gateway validates the identity of a DOTS 2095 client, it communicates with the AAA server in the 'example.com' 2096 domain to determine if the DOTS client is authorized to request DDOS 2097 mitigation. If the DOTS client is not authorized, a 4.01 2098 (Unauthorized) is returned in the response to the DOTS client. In 2099 this example, the DOTS gateway only allows the application server and 2100 DDOS detector to request DDOS mitigation, but does not permit the 2101 user of type 'guest' to request DDOS mitigation. 2103 Also, DOTS gateway and DOTS server located in different domains MUST 2104 perform mutual authentication (e.g., using certificates). A DOTS 2105 server will only allow a DOTS gateway with a certificate for a 2106 particular domain to request mitigation for that domain. In 2107 reference to Figure 24, the DOTS server only allows the DOTS gateway 2108 to request mitigation for 'example.com' domain and not for other 2109 domains. 2111 10. IANA Considerations 2113 This specification registers a default port, new URI suffix in the 2114 Well-Known URIs registry, new CoAP response code, new parameters for 2115 DOTS signal channel and establishes registries for mappings to CBOR. 2117 10.1. DOTS Signal Channel UDP and TCP Port Number 2119 IANA has assigned the port number TBD to the DOTS signal channel 2120 protocol, for both UDP and TCP. 2122 10.2. Well-Known 'dots' URI 2124 This memo registers the 'dots' well-known URI in the Well-Known URIs 2125 registry as defined by [RFC5785]. 2127 URI suffix: dots 2129 Change controller: IETF 2131 Specification document(s): This RFC 2133 Related information: None 2135 10.3. CoAP Response Code 2137 The following entry is added to the "CoAP Response Codes" sub- 2138 registry: 2140 +------+------------------------------+-----------+ 2141 | Code | Description | Reference | 2142 +------+------------------------------+-----------+ 2143 | 3.00 | Alternate server | [RFCXXXX] | 2144 +------+------------------------------+-----------+ 2146 Figure 25: CoAP Response Code 2148 [Note to RFC Editor: Please replace XXXX with the RFC number of this 2149 specification.] 2151 10.4. DOTS signal channel CBOR Mappings Registry 2153 A new registry will be requested from IANA, entitled "DOTS signal 2154 channel CBOR Mappings Registry". The registry is to be created as 2155 Expert Review Required. 2157 10.4.1. Registration Template 2159 Parameter name: 2160 Parameter names (e.g., "target_ip") in the DOTS signal channel. 2162 CBOR Key Value: 2163 Key value for the parameter. The key value MUST be an integer in 2164 the range of 1 to 65536. The key values in the range of 32768 to 2165 65536 are assigned for Vendor-Specific parameters. 2167 CBOR Major Type: 2168 CBOR Major type and optional tag for the claim. 2170 Change Controller: 2171 For Standards Track RFCs, list the "IESG". For others, give the 2172 name of the responsible party. Other details (e.g., postal 2173 address, email address, home page URI) may also be included. 2175 Specification Document(s): 2176 Reference to the document or documents that specify the parameter, 2177 preferably including URIs that can be used to retrieve copies of 2178 the documents. An indication of the relevant sections may also be 2179 included but is not required. 2181 10.4.2. Initial Registry Contents 2183 o Parameter Name: "mitigation-scope" 2184 o CBOR Key Value: 1 2185 o CBOR Major Type: 5 2186 o Change Controller: IESG 2187 o Specification Document(s): this document 2189 o Parameter Name: "scope" 2190 o CBOR Key Value: 2 2191 o CBOR Major Type: 5 2192 o Change Controller: IESG 2193 o Specification Document(s): this document 2195 o Parameter Name: "mitigation-id" 2196 o CBOR Key Value: 3 2197 o CBOR Major Type: 0 2198 o Change Controller: IESG 2199 o Specification Document(s): this document 2201 o Parameter Name:target-ip 2202 o CBOR Key Value: 4 2203 o CBOR Major Type: 4 2204 o Change Controller: IESG 2205 o Specification Document(s): this document 2207 o Parameter Name: target-port-range 2208 o CBOR Key Value: 5 2209 o CBOR Major Type: 4 2210 o Change Controller: IESG 2211 o Specification Document(s): this document 2213 o Parameter Name: "lower-port" 2214 o CBOR Key Value: 6 2215 o CBOR Major Type: 0 2216 o Change Controller: IESG 2217 o Specification Document(s): this document 2219 o Parameter Name: "upper-port" 2220 o CBOR Key Value: 7 2221 o CBOR Major Type: 0 2222 o Change Controller: IESG 2223 o Specification Document(s): this document 2225 o Parameter Name: target-protocol 2226 o CBOR Key Value: 8 2227 o CBOR Major Type: 4 2228 o Change Controller: IESG 2229 o Specification Document(s): this document 2231 o Parameter Name: "fqdn" 2232 o CBOR Key Value: 9 2233 o CBOR Major Type: 4 2234 o Change Controller: IESG 2235 o Specification Document(s): this document 2237 o Parameter Name: "uri" 2238 o CBOR Key Value: 10 2239 o CBOR Major Type: 4 2240 o Change Controller: IESG 2241 o Specification Document(s): this document 2243 o Parameter Name: alias-name 2244 o CBOR Key Value: 11 2245 o CBOR Major Type: 4 2246 o Change Controller: IESG 2247 o Specification Document(s): this document 2249 o Parameter Name: "lifetime" 2250 o CBOR Key Value: 12 2251 o CBOR Major Type: 0 2252 o Change Controller: IESG 2253 o Specification Document(s): this document 2255 o Parameter Name: attack-status 2256 o CBOR Key Value: 13 2257 o CBOR Major Type: 0 2258 o Change Controller: IESG 2259 o Specification Document(s): this document 2261 o Parameter Name: signal-config 2262 o CBOR Key Value: 14 2263 o CBOR Major Type: 5 2264 o Change Controller: IESG 2265 o Specification Document(s): this document 2267 o Parameter Name: heartbeat-interval 2268 o CBOR Key Value: 15 2269 o CBOR Major Type: 0 2270 o Change Controller: IESG 2271 o Specification Document(s): this document 2273 o Parameter Name: max-retransmit 2274 o CBOR Key Value: 16 2275 o CBOR Major Type: 0 2276 o Change Controller: IESG 2277 o Specification Document(s): this document 2279 o Parameter Name: ack-timeout 2280 o CBOR Key Value: 17 2281 o CBOR Major Type: 0 2282 o Change Controller: IESG 2283 o Specification Document(s): this document 2285 o Parameter Name: ack-random-factor 2286 o CBOR Key Value: 18 2287 o CBOR Major Type: 7 2288 o Change Controller: IESG 2289 o Specification Document(s): this document 2291 o Parameter Name: MinValue 2292 o CBOR Key Value: 19 2293 o CBOR Major Type: 0 2294 o Change Controller: IESG 2295 o Specification Document(s): this document 2297 o Parameter Name: MaxValue 2298 o CBOR Key Value: 20 2299 o CBOR Major Type: 0 2300 o Change Controller: IESG 2301 o Specification Document(s): this document 2303 o Parameter Name: status 2304 o CBOR Key Value: 21 2305 o CBOR Major Type: 0 2306 o Change Controller: IESG 2307 o Specification Document(s): this document 2309 o Parameter Name: bytes-dropped 2310 o CBOR Key Value: 22 2311 o CBOR Major Type: 0 2312 o Change Controller: IESG 2313 o Specification Document(s): this document 2315 o Parameter Name: bps-dropped 2316 o CBOR Key Value: 23 2317 o CBOR Major Type: 0 2318 o Change Controller: IESG 2319 o Specification Document(s): this document 2321 o Parameter Name: pkts-dropped 2322 o CBOR Key Value: 24 2323 o CBOR Major Type: 0 2324 o Change Controller: IESG 2325 o Specification Document(s): this document 2327 o Parameter Name: pps-dropped 2328 o CBOR Key Value: 25 2329 o CBOR Major Type: 0 2330 o Change Controller: IESG 2331 o Specification Document(s): this document 2333 o Parameter Name: session-id 2334 o CBOR Key Value: 26 2335 o CBOR Major Type: 0 2336 o Change Controller: IESG 2337 o Specification Document(s): this document 2339 o Parameter Name: trigger-mitigation 2340 o CBOR Key Value: 27 2341 o CBOR Major Type: 7 2342 o Change Controller: IESG 2343 o Specification Document(s): this document 2345 o Parameter Name: missing-hb-allowed 2346 o CBOR Key Value: 28 2347 o CBOR Major Type: 0 2348 o Change Controller: IESG 2349 o Specification Document(s): this document 2351 o Parameter Name: CurrentValue 2352 o CBOR Key Value: 29 2353 o CBOR Major Type: 0 2354 o Change Controller: IESG 2355 o Specification Document(s): this document 2357 o Parameter Name:mitigation-start 2358 o CBOR Key Value: 30 2359 o CBOR Major Type: 7 2360 o Change Controller: IESG 2361 o Specification Document(s): this document 2363 o Parameter Name:target-prefix 2364 o CBOR Key Value: 31 2365 o CBOR Major Type: 4 2366 o Change Controller: IESG 2367 o Specification Document(s): this document 2369 o Parameter Name:client-identifier 2370 o CBOR Key Value: 32 2371 o CBOR Major Type: 2 2372 o Change Controller: IESG 2373 o Specification Document(s): this document 2375 o Parameter Name:alt-server 2376 o CBOR Key Value: 33 2377 o CBOR Major Type: 2 2378 o Change Controller: IESG 2379 o Specification Document(s): this document 2381 o Parameter Name:alt-server-record 2382 o CBOR Key Value: 34 2383 o CBOR Major Type: 4 2384 o Change Controller: IESG 2385 o Specification Document(s): this document 2387 o Parameter Name:addr 2388 o CBOR Key Value: 35 2389 o CBOR Major Type: 2 2390 o Change Controller: IESG 2391 o Specification Document(s): this document 2393 o Parameter Name:ttl 2394 o CBOR Key Value: 36 2395 o CBOR Major Type: 0 2396 o Change Controller: IESG 2397 o Specification Document(s): this document 2399 11. Implementation Status 2401 [Note to RFC Editor: Please remove this section and reference to 2402 [RFC7942] prior to publication.] 2404 This section records the status of known implementations of the 2405 protocol defined by this specification at the time of posting of this 2406 Internet-Draft, and is based on a proposal described in [RFC7942]. 2407 The description of implementations in this section is intended to 2408 assist the IETF in its decision processes in progressing drafts to 2409 RFCs. Please note that the listing of any individual implementation 2410 here does not imply endorsement by the IETF. Furthermore, no effort 2411 has been spent to verify the information presented here that was 2412 supplied by IETF contributors. This is not intended as, and must not 2413 be construed to be, a catalog of available implementations or their 2414 features. Readers are advised to note that other implementations may 2415 exist. 2417 According to [RFC7942], "this will allow reviewers and working groups 2418 to assign due consideration to documents that have the benefit of 2419 running code, which may serve as evidence of valuable experimentation 2420 and feedback that have made the implemented protocols more mature. 2421 It is up to the individual working groups to use this information as 2422 they see fit". 2424 11.1. nttdots 2426 Organization: NTT Communication is developing a DOTS client and 2427 DOTS server software based on DOTS signal channel specified in 2428 this draft. It will be open-sourced. 2429 Description: Early implementation of DOTS protocol. It is aimed to 2430 implement a full DOTS protocol spec in accordance with maturing of 2431 DOTS protocol itself. 2432 Implementation: https://github.com/nttdots/go-dots 2433 Level of maturity: It is a early implementation of DOTS protocol. 2434 Messaging between DOTS clients and DOTS servers has been tested. 2435 Level of maturity will increase in accordance with maturing of 2436 DOTS protocol itself. 2437 Coverage: Capability of DOTS client: sending DOTS messages to the 2438 DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS 2439 server: receiving dots-signal, validating received dots-signal, 2440 starting mitigation by handing over the dots-signal to DDOS 2441 mitigator. 2442 Licensing: It will be open-sourced with BSD 3-clause license. 2444 Implementation experience: It is implemented in Go-lang. Core 2445 specification of signaling is mature to be implemented, however, 2446 finding good libraries(like DTLS, CoAP) is rather difficult. 2447 Contact: Kaname Nishizuka 2449 12. Security Considerations 2451 Authenticated encryption MUST be used for data confidentiality and 2452 message integrity. (D)TLS based on client certificate MUST be used 2453 for mutual authentication. The interaction between the DOTS agents 2454 requires Datagram Transport Layer Security (DTLS) and Transport Layer 2455 Security (TLS) with a cipher suite offering confidentiality 2456 protection and the guidance given in [RFC7525] MUST be followed to 2457 avoid attacks on (D)TLS. 2459 A single DOTS signal channel between DOTS agents can be used to 2460 exchange multiple DOTS signal messages. To reduce DOTS client and 2461 DOTS server workload, DOTS client SHOULD re-use the (D)TLS session. 2463 If TCP is used between DOTS agents, an attacker may be able to inject 2464 RST packets, bogus application segments, etc., regardless of whether 2465 TLS authentication is used. Because the application data is TLS 2466 protected, this will not result in the application receiving bogus 2467 data, but it will constitute a DoS on the connection. This attack 2468 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 2469 any bogus packets injected by an attacker will be rejected by the 2470 TCP-AO integrity check and therefore will never reach the TLS layer. 2472 In order to prevent leaking internal information outside a client- 2473 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 2474 the identity of internal DOTS clients (client-identifier) unless 2475 explicitly configured to do so. 2477 Special care should be taken in order to ensure that the activation 2478 of the proposed mechanism won't have an impact on the stability of 2479 the network (including connectivity and services delivered over that 2480 network). 2482 Involved functional elements in the cooperation system must establish 2483 exchange instructions and notification over a secure and 2484 authenticated channel. Adequate filters can be enforced to avoid 2485 that nodes outside a trusted domain can inject request such as 2486 deleting filtering rules. Nevertheless, attacks can be initiated 2487 from within the trusted domain if an entity has been corrupted. 2488 Adequate means to monitor trusted nodes should also be enabled. 2490 13. Contributors 2492 The following individuals have contributed to this document: 2494 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 2495 mgeller@cisco.com 2497 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 2498 Email: rgm@htt-consult.com 2500 Dan Wing Email: dwing-ietf@fuggles.com 2502 14. Acknowledgements 2504 Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, 2505 Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang 2506 Xia, Jon Shallow, and Gilbert Clark for the discussion and comments. 2508 15. References 2510 15.1. Normative References 2512 [I-D.ietf-core-coap-tcp-tls] 2513 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 2514 Silverajan, B., and B. Raymor, "CoAP (Constrained 2515 Application Protocol) over TCP, TLS, and WebSockets", 2516 draft-ietf-core-coap-tcp-tls-10 (work in progress), 2517 October 2017. 2519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2520 Requirement Levels", BCP 14, RFC 2119, 2521 DOI 10.17487/RFC2119, March 1997, 2522 . 2524 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 2525 Ciphersuites for Transport Layer Security (TLS)", 2526 RFC 4279, DOI 10.17487/RFC4279, December 2005, 2527 . 2529 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2530 (TLS) Protocol Version 1.2", RFC 5246, 2531 DOI 10.17487/RFC5246, August 2008, 2532 . 2534 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2535 Housley, R., and W. Polk, "Internet X.509 Public Key 2536 Infrastructure Certificate and Certificate Revocation List 2537 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2538 . 2540 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2541 Uniform Resource Identifiers (URIs)", RFC 5785, 2542 DOI 10.17487/RFC5785, April 2010, 2543 . 2545 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2546 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 2547 June 2010, . 2549 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2550 Verification of Domain-Based Application Service Identity 2551 within Internet Public Key Infrastructure Using X.509 2552 (PKIX) Certificates in the Context of Transport Layer 2553 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2554 2011, . 2556 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2557 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2558 DOI 10.17487/RFC6234, May 2011, 2559 . 2561 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2562 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2563 January 2012, . 2565 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 2566 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 2567 Transport Layer Security (TLS) and Datagram Transport 2568 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 2569 June 2014, . 2571 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2572 Application Protocol (CoAP)", RFC 7252, 2573 DOI 10.17487/RFC7252, June 2014, 2574 . 2576 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2577 "Recommendations for Secure Use of Transport Layer 2578 Security (TLS) and Datagram Transport Layer Security 2579 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2580 2015, . 2582 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2583 Application Protocol (CoAP)", RFC 7641, 2584 DOI 10.17487/RFC7641, September 2015, 2585 . 2587 15.2. Informative References 2589 [I-D.ietf-core-comi] 2590 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 2591 Management Interface", draft-ietf-core-comi-01 (work in 2592 progress), July 2017. 2594 [I-D.ietf-core-yang-cbor] 2595 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 2596 Minaburo, "CBOR Encoding of Data Modeled with YANG", 2597 draft-ietf-core-yang-cbor-05 (work in progress), August 2598 2017. 2600 [I-D.ietf-dots-architecture] 2601 Mortensen, A., Andreasen, F., Reddy, T., 2602 christopher_gray3@cable.comcast.com, c., Compton, R., and 2603 N. Teague, "Distributed-Denial-of-Service Open Threat 2604 Signaling (DOTS) Architecture", draft-ietf-dots- 2605 architecture-05 (work in progress), October 2017. 2607 [I-D.ietf-dots-data-channel] 2608 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 2609 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 2610 Service Open Threat Signaling (DOTS) Data Channel", draft- 2611 ietf-dots-data-channel-07 (work in progress), November 2612 2017. 2614 [I-D.ietf-dots-requirements] 2615 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 2616 Denial of Service (DDoS) Open Threat Signaling 2617 Requirements", draft-ietf-dots-requirements-07 (work in 2618 progress), October 2017. 2620 [I-D.ietf-dots-use-cases] 2621 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 2622 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 2623 Open Threat Signaling", draft-ietf-dots-use-cases-09 (work 2624 in progress), November 2017. 2626 [I-D.ietf-tls-tls13] 2627 Rescorla, E., "The Transport Layer Security (TLS) Protocol 2628 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 2629 July 2017. 2631 [I-D.rescorla-tls-dtls13] 2632 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2633 Datagram Transport Layer Security (DTLS) Protocol Version 2634 1.3", draft-rescorla-tls-dtls13-01 (work in progress), 2635 March 2017. 2637 [proto_numbers] 2638 "IANA, "Protocol Numbers"", 2011, 2639 . 2641 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2642 DOI 10.17487/RFC0791, September 1981, 2643 . 2645 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2646 Congestion Control Protocol (DCCP)", RFC 4340, 2647 DOI 10.17487/RFC4340, March 2006, 2648 . 2650 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2651 (CIDR): The Internet Address Assignment and Aggregation 2652 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2653 2006, . 2655 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 2656 Denial-of-Service Considerations", RFC 4732, 2657 DOI 10.17487/RFC4732, December 2006, 2658 . 2660 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 2661 Translation (NAT) Behavioral Requirements for Unicast 2662 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2663 2007, . 2665 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2666 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2667 . 2669 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 2670 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 2671 . 2673 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2674 "Transport Layer Security (TLS) Session Resumption without 2675 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 2676 January 2008, . 2678 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2679 the Network Configuration Protocol (NETCONF)", RFC 6020, 2680 DOI 10.17487/RFC6020, October 2010, 2681 . 2683 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 2684 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2685 2012, . 2687 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 2688 "Default Address Selection for Internet Protocol Version 6 2689 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 2690 . 2692 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2693 "Enrollment over Secure Transport", RFC 7030, 2694 DOI 10.17487/RFC7030, October 2013, 2695 . 2697 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2698 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2699 October 2013, . 2701 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2702 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2703 . 2705 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 2706 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2707 2015, . 2709 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 2710 NETCONF Protocol over Transport Layer Security (TLS) with 2711 Mutual X.509 Authentication", RFC 7589, 2712 DOI 10.17487/RFC7589, June 2015, 2713 . 2715 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 2716 Layer Security (TLS) False Start", RFC 7918, 2717 DOI 10.17487/RFC7918, August 2016, 2718 . 2720 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 2721 (TLS) Cached Information Extension", RFC 7924, 2722 DOI 10.17487/RFC7924, July 2016, 2723 . 2725 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2726 Code: The Implementation Status Section", BCP 205, 2727 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2728 . 2730 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2731 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2732 March 2017, . 2734 Authors' Addresses 2736 Tirumaleswar Reddy 2737 McAfee, Inc. 2738 Embassy Golf Link Business Park 2739 Bangalore, Karnataka 560071 2740 India 2742 Email: kondtir@gmail.com 2744 Mohamed Boucadair 2745 Orange 2746 Rennes 35000 2747 France 2749 Email: mohamed.boucadair@orange.com 2751 Prashanth Patil 2752 Cisco Systems, Inc. 2754 Email: praspati@cisco.com 2756 Andrew Mortensen 2757 Arbor Networks, Inc. 2758 2727 S. State St 2759 Ann Arbor, MI 48104 2760 United States 2762 Email: amortensen@arbor.net 2764 Nik Teague 2765 Verisign, Inc. 2766 United States 2768 Email: nteague@verisign.com