idnits 2.17.00 (12 Aug 2021) /tmp/idnits59315/draft-ietf-dots-signal-channel-05.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 85 instances of too long lines in the document, the longest one being 25 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 367 has weird spacing: '...er-port ine...' == Line 368 has weird spacing: '...er-port ine...' -- The document date (October 12, 2017) is 1681 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1998, but not defined == Outdated reference: draft-ietf-core-coap-tcp-tls has been published as RFC 8323 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** 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: 4 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair 5 Expires: April 15, 2018 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 October 12, 2017 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel 16 draft-ietf-dots-signal-channel-05 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 April 15, 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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 8 70 5.2.3. Session Configuration YANG Module Tree Structure . . 11 71 5.2.4. Session Configuration YANG Module . . . . . . . . . . 12 72 5.3. Mitigation Request . . . . . . . . . . . . . . . . . . . 14 73 5.3.1. Requesting mitigation . . . . . . . . . . . . . . . . 15 74 5.3.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 22 75 5.3.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 23 76 5.3.4. Efficacy Update from DOTS Client . . . . . . . . . . 28 77 5.4. DOTS Signal Channel Session Configuration . . . . . . . . 30 78 5.4.1. Discover Configuration Parameters . . . . . . . . . . 31 79 5.4.2. Convey DOTS Signal Channel Session Configuration . . 33 80 5.4.3. Delete DOTS Signal Channel Session Configuration . . 37 81 5.4.4. Retrieving DOTS Signal Channel Session Configuration 38 82 5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 38 83 5.6. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 39 84 6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 40 85 7. (D)TLS Protocol Profile and Performance considerations . . . 41 86 7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 42 87 8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 43 88 9. Mutual Authentication of DOTS Agents & Authorization of DOTS 89 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 91 10.1. CoAP Response Code . . . . . . . . . . . . . . . . . . . 46 92 10.2. DOTS signal channel CBOR Mappings Registry . . . . . . . 46 93 10.2.1. Registration Template . . . . . . . . . . . . . . . 46 94 10.2.2. Initial Registry Contents . . . . . . . . . . . . . 47 95 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 51 96 11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 51 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 52 99 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 100 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 102 15.1. Normative References . . . . . . . . . . . . . . . . . . 53 103 15.2. Informative References . . . . . . . . . . . . . . . . . 54 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 106 1. Introduction 108 A distributed denial-of-service (DDoS) attack is an attempt to make 109 machines or network resources unavailable to their intended users. 110 In most cases, sufficient scale can be achieved by compromising 111 enough end-hosts and using those infected hosts to perpetrate and 112 amplify the attack. The victim in this attack can be an application 113 server, a host, a router, a firewall, or an entire network. 115 In many cases, it may not be possible for an network administrators 116 to determine the causes of an attack, but instead just realize that 117 certain resources seem to be under attack. This document defines a 118 lightweight protocol permitting a DOTS client to request mitigation 119 from one or more DOTS servers for protection against detected, 120 suspected, or anticipated attacks . This protocol enables cooperation 121 between DOTS agents to permit a highly-automated network defense that 122 is robust, reliable and secure. 124 The requirements for DOTS signal channel protocol are obtained from 125 [I-D.ietf-dots-requirements]. 127 This document satisfies all the use cases discussed in 128 [I-D.ietf-dots-use-cases] except the Third-party DOTS notifications 129 use case in Section 3.2.3 of [I-D.ietf-dots-use-cases] which is an 130 optional feature and not a core use case. Third-party DOTS 131 notifications are not part of the DOTS requirements document. 132 Moreover, the DOTS architecture does not assess whether that use case 133 may have an impact on the architecture itself and/or the DOTS trust 134 model. 136 This is a companion document to the DOTS data channel specification 137 [I-D.ietf-dots-data-channel] that defines a configuration and bulk 138 data exchange mechanism supporting the DOTS signal channel. 140 2. Notational Conventions and Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in 145 [RFC2119]. 147 (D)TLS: For brevity this term is used for statements that apply to 148 both Transport Layer Security [RFC5246] and Datagram Transport Layer 149 Security [RFC6347]. Specific terms will be used for any statement 150 that applies to either protocol alone. 152 The reader should be familiar with the terms defined in 153 [I-D.ietf-dots-architecture]. 155 3. Solution Overview 157 Network applications have finite resources like CPU cycles, number of 158 processes or threads they can create and use, maximum number of 159 simultaneous connections it can handle, limited resources of the 160 control plane, etc. When processing network traffic, such 161 applications are supposed to use these resources to offer the 162 intended task in the most efficient fashion. However, an attacker 163 may be able to prevent an application from performing its intended 164 task by causing the application to exhaust the finite supply of a 165 specific resource. 167 TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the 168 victim and ACK-flood is a CPU exhaustion attack on the victim 169 ([RFC4987]). Attacks on the link are carried out by sending enough 170 traffic such that the link becomes excessively congested, and 171 legitimate traffic suffers high packet loss. Stateful firewalls can 172 also be attacked by sending traffic that causes the firewall to hold 173 excessive state. The firewall then runs out of memory, and can no 174 longer instantiate the state required to pass legitimate flows. 175 Other possible DDoS attacks are discussed in [RFC4732]. 177 In each of the cases described above, the possible arrangements 178 between the DOTS client and DOTS server to mitigate the attack are 179 discussed in [I-D.ietf-dots-use-cases]. An example of network 180 diagram showing a deployment of these elements is shown in Figure 1. 181 Architectural relationships between involved DOTS agents is explained 182 in [I-D.ietf-dots-architecture]. In this example, the DOTS server is 183 operating on the access network. 185 Network 186 Resource CPE router Access network __________ 187 +-----------+ +--------------+ +-------------+ / \ 188 | |____| |_______| |___ | Internet | 189 |DOTS client| | DOTS gateway | | DOTS server | | | 190 | | | | | | | | 191 +-----------+ +--------------+ +-------------+ \__________/ 193 Figure 1: Sample DOTS Deployment (1) 195 The DOTS server can also be running on the Internet, as depicted in 196 Figure 2. 198 Network DDoS mitigation 199 Resource CPE router __________ service 200 +-----------+ +-------------+ / \ +-------------+ 201 | |____| |_______| |___ | | 202 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 203 | | | | | | | | 204 +-----------+ +-------------+ \__________/ +-------------+ 206 Figure 2: Sample DOTS Deployment (2) 208 In typical deployments, the DOTS client belongs to a different 209 administrative domain than the DOTS server. For example, the DOTS 210 client is a firewall protecting services owned and operated by an 211 domain, while the DOTS server is owned and operated by a different 212 domain providing DDoS mitigation services. That domain providing 213 DDoS mitigation service might, or might not, also provide Internet 214 access service to the website operator. 216 The DOTS server may (not) be co-located with the DOTS mitigator. In 217 typical deployments, the DOTS server belongs to the same 218 administrative domain as the mitigator. 220 The DOTS client can communicate directly with the DOTS server or 221 indirectly via a DOTS gateway. 223 This document focuses on the DOTS signal channel. 225 4. Happy Eyeballs for DOTS Signal Channel 227 DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS 228 [RFC5246] over TCP. A DOTS client can use DNS to determine the IP 229 address(es) of a DOTS server or a DOTS client may be provided with 230 the list of DOTS server IP addresses. The DOTS client MUST know a 231 DOTS server's domain name; hard-coding the domain name of the DOTS 232 server into software is NOT RECOMMENDED in case the domain name is 233 not valid or needs to change for legal or other reasons. The DOTS 234 client performs A and/or AAAA record lookup of the domain name and 235 the result will be a list of IP addresses, each of which can be used 236 to contact the DOTS server using UDP and TCP. 238 If an IPv4 path to reach a DOTS server is found, but the DOTS 239 server's IPv6 path is not working, a dual-stack DOTS client can 240 experience a significant connection delay compared to an IPv4-only 241 DOTS client. The other problem is that if a middlebox between the 242 DOTS client and DOTS server is configured to block UDP, the DOTS 243 client will fail to establish a DTLS session with the DOTS server and 244 will, then, have to fall back to TLS over TCP incurring significant 245 connection delays. [I-D.ietf-dots-requirements] discusses that DOTS 246 client and server will have to support both connectionless and 247 connection-oriented protocols. 249 To overcome these connection setup problems, the DOTS client can try 250 connecting to the DOTS server using both IPv6 and IPv4, and try both 251 DTLS over UDP and TLS over TCP in a fashion similar to the Happy 252 Eyeballs mechanism [RFC6555]. These connection attempts are 253 performed by the DOTS client when its initializes, and the client 254 uses that information for its subsequent alert to the DOTS server. 255 In order of preference (most preferred first), it is UDP over IPv6, 256 UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which 257 adheres to address preference order [RFC6724] and the DOTS preference 258 that UDP be used over TCP (to avoid TCP's head of line blocking). 260 DOTS client DOTS server 261 | | 262 |--DTLS ClientHello, IPv6 ---->X | 263 |--TCP SYN, IPv6-------------->X | 264 |--DTLS ClientHello, IPv4 ---->X | 265 |--TCP SYN, IPv4----------------------------------------->| 266 |--DTLS ClientHello, IPv6 ---->X | 267 |--TCP SYN, IPv6-------------->X | 268 |<-TCP SYNACK---------------------------------------------| 269 |--DTLS ClientHello, IPv4 ---->X | 270 |--TCP ACK----------------------------------------------->| 271 |<------------Establish TLS Session---------------------->| 272 |----------------DOTS signal----------------------------->| 273 | | 275 Figure 3: Happy Eyeballs 277 In reference to Figure 3, the DOTS client sends two TCP SYNs and two 278 DTLS ClientHello messages at the same time over IPv6 and IPv4. In 279 this example, it is assumed that the IPv6 path is broken and UDP is 280 dropped by a middle box but has little impact to the DOTS client 281 because there is no long delay before using IPv4 and TCP. The DOTS 282 client repeats the mechanism to discover if DOTS signaling with DTLS 283 over UDP becomes available from the DOTS server, so the DOTS client 284 can migrate the DOTS signal channel from TCP to UDP, but such probing 285 SHOULD NOT be done more frequently than every 24 hours and MUST NOT 286 be done more frequently than every 5 minutes. 288 5. DOTS Signal Channel 290 5.1. Overview 292 The DOTS signal channel is built on top of the Constrained 293 Application Protocol (CoAP) [RFC7252], a lightweight protocol 294 originally designed for constrained devices and networks. CoAP's 295 expectation of packet loss, support for asynchronous non-confirmable 296 messaging, congestion control, small message overhead limiting the 297 need for fragmentation, use of minimal resources, and support for 298 (D)TLS make it a good foundation on which to build the DOTS signaling 299 mechanism. 301 The DOTS signal channel is layered on existing standards (Figure 4). 303 TBD: The default port number for DOTS signal channel is 5684 304 (Section 12.7 of [RFC7252] and Section 10.4 of 305 [I-D.ietf-core-coap-tcp-tls]), for both UDP and TCP. 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, the DOTS server periodically 327 sends status messages to the client, including basic mitigation 328 feedback details. Mitigation remains active until the DOTS client 329 explicitly terminates mitigation, or the mitigation lifetime expires. 331 Messages exchanged between DOTS client and server are serialized 332 using Concise Binary Object Representation (CBOR) [RFC7049], CBOR is 333 a binary encoding designed for small code and message size. CBOR 334 encoded payloads are used to convey signal channel specific payload 335 messages that convey request parameters and response information such 336 as errors. This specification uses the encoding rules defined in 337 [I-D.ietf-core-yang-cbor] for representing mitigation scope and DOTS 338 signal channel session configuration data defined using YANG 339 (Section 5.2) as CBOR data. 341 DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The 342 payload included in CoAP responses with 2.xx and 3.xx Response Codes 343 MUST be of content type "application/cbor" (Section 5.5.1 of 344 [RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes 345 MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The 346 Diagnostic Payload may contain additional information to aid 347 troubleshooting. 349 5.2. DOTS Signal YANG Module 351 This document defines a YANG [RFC6020] module for mitigation scope 352 and DOTS signal channel session configuration data. 354 5.2.1. Mitigation Request YANG Module Tree Structure 356 This document defines the YANG module "ietf-dots-signal", which has 357 the following tree structure: 359 module: ietf-dots-signal 360 +--rw mitigation-scope 361 +--rw client-identifier* binary 362 +--rw scope* [mitigation-id] 363 +--rw mitigation-id int32 364 +--rw target-ip* inet:ip-address 365 +--rw target-prefix* inet:ip-prefix 366 +--rw target-port-range* [lower-port upper-port] 367 | +--rw lower-port inet:port-number 368 | +--rw upper-port inet:port-number 369 +--rw target-protocol* uint8 370 +--rw fqdn* inet:domain-name 371 +--rw uri* inet:uri 372 +--rw alias-name* string 373 +--rw lifetime? int32 375 5.2.2. Mitigation Request YANG Module 377 file "ietf-dots-signal@2017-10-04.yang" 379 module ietf-dots-signal { 380 yang-version 1.1; 381 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; 382 prefix "signal"; 383 import ietf-inet-types { 384 prefix "inet"; 385 } 387 organization "IETF DOTS Working Group"; 389 contact 390 "Konda, Tirumaleswar Reddy 391 Mohamed Boucadair 392 Prashanth Patil 393 Andrew Mortensen 394 Nik Teague "; 396 description 397 "This module contains YANG definition for DOTS 398 signal sent by the DOTS client to the DOTS server. 400 Copyright (c) 2017 IETF Trust and the persons identified as 401 authors of the code. All rights reserved. 403 Redistribution and use in source and binary forms, with or 404 without modification, is permitted pursuant to, and subject 405 to the license terms contained in, the Simplified BSD License 406 set forth in Section 4.c of the IETF Trust's Legal Provisions 407 Relating to IETF Documents 408 (http://trustee.ietf.org/license-info). 410 This version of this YANG module is part of RFC XXXX; see 411 the RFC itself for full legal notices."; 413 revision 2017-10-04 { 414 description 415 "Add units and fix some nits."; 416 reference 417 "-05"; 418 } 420 revision 2017-08-03 { 421 reference 422 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 423 } 425 container mitigation-scope { 426 description 427 "Top level container for a mitigation request."; 429 leaf-list client-identifier { 430 type binary; 431 description 432 "A client identifier conveyed by a DOTS gateway 433 to a remote DOTS server."; 434 } 436 list scope { 437 key mitigation-id; 438 description "Identifier for the mitigation request."; 440 leaf mitigation-id { 441 type int32; 442 description "Mitigation request identifier."; 443 } 444 leaf-list target-ip { 445 type inet:ip-address; 446 description 447 "IPv4 or IPv6 address identifying the target."; 448 } 450 leaf-list target-prefix { 451 type inet:ip-prefix; 452 description 453 "IPv4 or IPv6 prefix identifying the target."; 454 } 456 list target-port-range { 457 key "lower-port upper-port"; 459 description "Port range. When only lower-port is present, 460 it represents a single port."; 462 leaf lower-port { 463 type inet:port-number; 464 mandatory true; 465 description "Lower port number."; 466 } 468 leaf upper-port { 469 type inet:port-number; 470 must ". >= ../lower-port" { 471 error-message 472 "The upper port number must be greater than or 473 equal to lower port number."; 474 } 475 description "Upper port number."; 476 } 477 } 478 leaf-list target-protocol { 479 type uint8; 480 description "Identifies the target protocol number."; 481 } 483 leaf-list fqdn { 484 type inet:domain-name; 485 description "FQDN"; 486 } 488 leaf-list uri { 489 type inet:uri; 490 description "URI"; 491 } 493 leaf-list alias-name { 494 type string; 495 description "alias name"; 496 } 498 leaf lifetime { 499 type int32; 500 units "seconds"; 501 default 3600; 503 description 504 "Indicates the lifetime of the mitigation request."; 505 } 506 } 507 } 508 } 509 511 5.2.3. Session Configuration YANG Module Tree Structure 513 This document defines the YANG module "ietf-dots-signal-config", 514 which has the following structure: 516 module: ietf-dots-signal-config 517 +--rw signal-config 518 +--rw session-id? int32 519 +--rw heartbeat-interval? int16 520 +--rw missing-hb-allowed? int16 521 +--rw max-retransmit? int16 522 +--rw ack-timeout? int16 523 +--rw ack-random-factor? decimal64 524 +--rw trigger-mitigation? boolean 526 5.2.4. Session Configuration YANG Module 528 file "ietf-dots-signal-config@2017-10-04.yang" 530 module ietf-dots-signal-config { 531 yang-version 1.1; 532 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config"; 533 prefix "config"; 535 organization "IETF DOTS Working Group"; 537 contact 538 "Konda, Tirumaleswar Reddy 539 Mohamed Boucadair 540 Prashanth Patil 541 Andrew Mortensen 542 Nik Teague "; 544 description 545 "This module contains YANG definition for DOTS 546 signal channel session configuration. 548 Copyright (c) 2017 IETF Trust and the persons identified as 549 authors of the code. All rights reserved. 551 Redistribution and use in source and binary forms, with or 552 without modification, is permitted pursuant to, and subject 553 to the license terms contained in, the Simplified BSD License 554 set forth in Section 4.c of the IETF Trust's Legal Provisions 555 Relating to IETF Documents 556 (http://trustee.ietf.org/license-info). 558 This version of this YANG module is part of RFC XXXX; see 559 the RFC itself for full legal notices."; 561 revision 2017-10-04 { 562 description 563 "Add units/defaults and fix some nits."; 564 reference 565 "-05"; 566 } 568 revision 2016-11-28 { 569 reference 570 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 571 } 573 container signal-config { 574 description "Top level container for DOTS signal channel session 575 configuration."; 577 leaf session-id { 578 type int32; 579 description "An identifier for the DOTS signal channel 580 session configuration data."; 581 } 583 leaf heartbeat-interval { 584 type int16; 585 units "seconds"; 586 default 30; 588 description 589 "DOTS agents regularly send heartbeats to each other 590 after mutual authentication in order to keep 591 the DOTS signal channel open."; 592 } 594 leaf missing-hb-allowed { 595 type int16; 596 default 5; 598 description 599 "Maximum number of missing heartbeats allowed."; 600 } 602 leaf max-retransmit { 603 type int16; 604 default 3; 606 description 607 "Maximum number of retransmissions of a 608 Confirmable message."; 609 } 611 leaf ack-timeout { 612 type int16; 613 units "seconds"; 614 default 2; 616 description 617 "Initial retransmission timeout value."; 618 } 620 leaf ack-random-factor { 621 type decimal64 { 622 fraction-digits 2; 623 } 625 default 1.5; 627 description 628 "Random factor used to influence the timing of 629 retransmissions"; 630 } 631 leaf trigger-mitigation { 632 type boolean; 633 default true; 635 description 636 "If false, then mitigation is triggered 637 only when the DOTS server channel session is lost"; 638 } 639 } 640 } 641 643 5.3. Mitigation Request 645 The following methods are used to request or withdraw mitigation 646 requests: 648 PUT: DOTS clients use the PUT method to request mitigation 649 (Section 5.3.1). During active mitigation, DOTS clients may use 650 PUT requests to convey mitigation efficacy updates to the DOTS 651 server (Section 5.3.4). 653 DELETE: DOTS clients use the DELETE method to withdraw a request for 654 mitigation from the DOTS server (Section 5.3.2). 656 GET: DOTS clients may use the GET method to subscribe to DOTS server 657 status messages, or to retrieve the list of existing mitigations 658 (Section 5.3.3). 660 Mitigation request and response messages are marked as Non- 661 confirmable messages. DOTS agents SHOULD follow the data 662 transmission guidelines discussed in Section 3.1.3 of [RFC8085] and 663 control transmission behavior by not sending on average more than one 664 UDP datagram per RTT to the peer DOTS agent. 666 Requests marked by the DOTS client as Non-confirmable messages are 667 sent at regular intervals until a response is received from the DOTS 668 server and if the DOTS client cannot maintain a RTT estimate then it 669 SHOULD NOT send more than one Non-confirmable request every 3 670 seconds, and SHOULD use an even less aggressive rate when possible 671 (case 2 in Section 3.1.3 of [RFC8085]). 673 5.3.1. Requesting mitigation 675 When a DOTS client requires mitigation for any reason, the DOTS 676 client uses CoAP PUT method to send a mitigation request to the DOTS 677 server (Figure 5, illustrated in JSON diagnostic notation). The DOTS 678 server can enable mitigation on behalf of the DOTS client by 679 communicating the DOTS client's request to the mitigator and relaying 680 selected mitigator feedback to the requesting DOTS client. 682 Header: PUT (Code=0.03) 683 Uri-Host: "host" 684 Uri-Path: "version" 685 Uri-Path: "dots-signal" 686 Uri-Path: "signal" 687 Content-Type: "application/cbor" 688 { 689 "mitigation-scope": { 690 "client-identifer": "string", 691 "scope": [ 692 { 693 "mitigation-id": integer, 694 "target-ip": [ 695 "string" 696 ], 697 "target-prefix": [ 698 "string" 699 ], 700 "target-port-range": [ 701 { 702 "lower-port": integer, 703 "upper-port": integer 704 } 705 ], 706 "target-protocol": [ 707 integer 708 ], 709 "fqdn": [ 710 "string" 711 ], 712 "uri": [ 713 "string" 714 ], 715 "alias-name": [ 716 "string" 717 ], 718 "lifetime": integer 719 } 720 ] 721 } 722 } 724 Figure 5: PUT to convey DOTS signals 726 The parameters are described below. 728 client-identifer: The client identifer MAY be conveyed by the DOTS 729 gateway to propagate the DOTS client identity to the DOTS server. 731 The'client-identifier' value MUST be assigned by the DOTS gateway 732 in a manner that ensures that there is no probability that the 733 same value will be accidentally assigned to a different DOTS 734 client. The client-identifier attribute SHOULD NOT to be 735 advertised by the DOTS client. 737 mitigation-id: Identifier for the mitigation request represented 738 using an integer. This identifier MUST be unique for each 739 mitigation request bound to the DOTS client, i.e., the mitigation- 740 id parameter value in the mitigation request needs to be unique 741 relative to the mitigation-id parameter values of active 742 mitigation requests conveyed from the DOTS client to the DOTS 743 server. This identifier MUST be generated by the DOTS client. 744 This document does not make any assumption about how this 745 identifier is generated. This is a mandatory attribute. 747 target-ip: A list of IP addresses under attack. This is an optional 748 attribute. 750 target-prefix: A list of prefixes under attack. Prefixes are 751 represented using CIDR notation [RFC4632]. This is an optional 752 attribute. 754 target-port-range: A list of ports under attack. The port range, 755 lower-port for lower port number and upper-port for upper port 756 number. When only lower-port is present, it represents a single 757 port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g., 758 1024-65535). This is an optional attribute. 760 target-protocol: A list of protocols under attack. Values are taken 761 from the IANA protocol registry [proto_numbers]. The value 0 has 762 a special meaning for 'all protocols'. This is an optional 763 attribute. 765 fqdn: A list of Fully Qualified Domain Names. Fully Qualified 766 Domain Name (FQDN) is the full name of a system, rather than just 767 its hostname. For example, "venera" is a hostname, and 768 "venera.isi.edu" is an FQDN. This is an optional attribute. 770 uri: A list of Uniform Resource Identifiers (URI). This is an 771 optional attribute. 773 alias-name: A list of aliases. Aliases can be created using the 774 DOTS data channel (Section 3.1.1 of [I-D.ietf-dots-data-channel]) 775 or direct configuration, or other means and then used in 776 subsequent signal channel exchanges to refer more efficiently to 777 the resources under attack. This is an optional attribute. 779 lifetime: Lifetime of the mitigation request in seconds. Upon the 780 expiry of this lifetime, and if the request is not refreshed, the 781 mitigation request is removed. The request can be refreshed by 782 sending the same request again. The default lifetime of the 783 mitigation request is 3600 seconds (60 minutes) -- this value was 784 chosen to be long enough so that refreshing is not typically a 785 burden on the DOTS client, while expiring the request where the 786 client has unexpectedly quit in a timely manner. A lifetime of 787 negative one (-1) indicates indefinite lifetime for the mitigation 788 request. The server MUST always indicate the actual lifetime in 789 the response and the remaining lifetime in status messages sent to 790 the client. This is an optional attribute in the request. 792 The CBOR key values for the parameters are defined in Section 6. 793 Section 10 defines how the CBOR key values can be allocated to 794 standards bodies and vendors. 796 FQDN and URI mitigation scopes may be thought of as a form of scope 797 alias, in which the addresses to which the domain name or URI resolve 798 represent the full scope of the mitigation. 800 In the PUT request at least one of the attributes target-ip or 801 target-prefix or fqdn or uri or alias-name MUST be present. DOTS 802 agents can safely ignore Vendor-Specific parameters they don't 803 understand. 805 The relative order of two mitigation requests from a DOTS client is 806 determined by comparing their respective 'mitigation-id' values. If 807 two mitigation requests have overlapping mitigation scopes, the 808 mitigation request with higher numeric 'mitigation-id' value will 809 override the mitigation request with a lower numeric 'mitigation-id' 810 value. Two mitigation-ids are overlapping if there is a common IP 811 address, IP prefix, FQDN, URI, or alias-name. The overlapped lower 812 numeric 'mitigation-id' MUST be automatically deleted and no longer 813 available at the DOTS server. 815 The Uri-Path option carries a major and minor version nomenclature to 816 manage versioning and DOTS signal channel in this specification uses 817 v1 major version. 819 If the DOTS client is using the certificate provisioned by the EST 820 server in the DOTS gateway-domain to authenticate itself to the DOTS 821 gateway, then the 'client-identifier' value will be the output of a 822 cryptographic hash algorithm whose input is the DER-encoded ASN.1 823 representation of the Subject Public Key Info (SPKI) of an X.509 824 certificate. The output of the cryptographic hash algorithm is 825 base64url encoded. In this version of the specification, the 826 cryptographic hash algorithm used is SHA-256 [RFC6234]. If the 827 'client-identifier' value is already present in the mitigation 828 request received from the DOTS client, the DOTS gateway computes the 829 'client-identifier' value, as discussed above, and adds the computed 830 'client-identifier' value to the end of the 'client-identifier' list. 832 In both DOTS signal and data channel sessions, the DOTS client MUST 833 authenticate itself to the DOTS server (Section 9). If the 'client- 834 identifier' value is not present in the mitigation request, the DOTS 835 server may use the algorithm in Section 7 of [RFC7589] to derive the 836 DOTS client identity or username from the client certificate. The 837 DOTS server couples the DOTS signal and data channel sessions using 838 the DOTS client identity, so the DOTS server can validate whether the 839 aliases conveyed in the mitigation request were indeed created by the 840 same DOTS client using the DOTS data channel session. If the aliases 841 were not created by the DOTS client, the DOTS server returns 4.00 842 (Bad Request) in the response. 844 The DOTS server couples the DOTS signal channel sessions using the 845 DOTS client identity, and the DOTS server uses 'mitigation-id' 846 parameter value to detect duplicate mitigation requests. If the 847 mitigation request contains both alias-name and other parameters 848 identifying the target resources (such as, target-ip, target-prefix, 849 target-port-range, fqdn, or uri), then the DOTS server appends the 850 parameter values in alias-name with the corresponding parameter 851 values in target-ip, target-prefix, target-port-range, fqdn, or uri. 853 Figure 6 shows a PUT request example to signal that ports 80, 8080, 854 and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are 855 being attacked (illustrated in JSON diagnostic notation). 857 Header: PUT (Code=0.03) 858 Uri-Host: "www.example.com" 859 Uri-Path: "v1" 860 Uri-Path: "dots-signal" 861 Uri-Path: "signal" 862 Content-Format: "application/cbor" 863 { 864 "mitigation-scope": { 865 "client-identifier": "E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=", 866 "scope": [ 867 { 868 "mitigation-id": 12332, 869 "target-ip": [ 870 "2001:db8:6401::1", 871 "2001:db8:6401::2" 872 ], 873 "target-port-range": [ 874 { 875 "lower-port": 80 876 }, 877 { 878 "lower-port": 443 879 }, 880 { 881 "lower-port": 8080 882 } 883 ], 884 "target-protocol": [ 885 6 886 ] 887 } 888 ] 889 } 890 } 892 The CBOR encoding format is shown below: 894 A1 # map(1) 895 01 # unsigned(1) 896 A2 # map(2) 897 18 20 # unsigned(32) 898 78 2C # text(44) 899 4539435A39494E4462642B326552516F7A59717162513279584C564B42392B786370724D462B34345531673D 900 # "E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=" 901 02 # unsigned(2) 902 81 # array(1) 903 A4 # map(4) 904 03 # unsigned(3) 905 19 302C # unsigned(12332) 906 04 # unsigned(4) 907 82 # array(2) 908 70 # text(16) 909 323030313A6462383A363430313A3A31 # "2001:db8:6401::1" 910 70 # text(16) 911 323030313A6462383A363430313A3A32 # "2001:db8:6401::2" 912 05 # unsigned(5) 913 83 # array(3) 914 A1 # map(1) 915 06 # unsigned(6) 916 18 50 # unsigned(80) 917 A1 # map(1) 918 06 # unsigned(6) 919 19 01BB # unsigned(443) 920 A1 # map(1) 921 06 # unsigned(6) 922 19 1F90 # unsigned(8080) 924 08 # unsigned(8) 925 81 # array(1) 926 06 # unsigned(6) 928 Figure 6: PUT for DOTS signal 930 The DOTS server indicates the result of processing the PUT request 931 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 932 codes are some sort of invalid requests. Figure 7 shows a PUT 933 response for CoAP 2.xx response codes. 935 { 936 "mitigation-scope": { 937 "client-identifer": "string", 938 "scope": [ 939 { 940 "mitigation-id": integer, 941 "lifetime": integer 942 } 943 ] 944 } 945 } 947 Figure 7: 2.xx response body 949 COAP 5.xx codes are returned if the DOTS server has erred or is 950 currently unavailable to provide mitigation in response to the 951 mitigation request from the DOTS client. 953 If the DOTS server does not find the 'mitigation-id' parameter value 954 conveyed in the PUT request in its configuration data, then the 955 server MAY accept the mitigation request by sending back a 2.01 956 (Created) response to the DOTS client; the DOTS server will 957 consequently try to mitigate the attack. 959 If the DOTS server finds the 'mitigation-id' parameter value conveyed 960 in the PUT request in its configuration data, then the server MAY 961 update the mitigation request, and a 2.04 (Changed) response is 962 returned to indicate a successful update of the mitigation request. 964 If the request is missing one or more mandatory attributes, then 4.00 965 (Bad Request) will be returned in the response or if the request 966 contains invalid or unknown parameters then 4.02 (Invalid query) is 967 returned in the response. 969 For a mitigation request to continue beyond the initial negotiated 970 lifetime, the DOTS client need to refresh the current mitigation 971 request by sending a new PUT request. The PUT request MUST use the 972 same 'mitigation-id' value, and MUST repeat all the other parameters 973 as sent in the original mitigation request apart from a possible 974 change to the lifetime parameter value. 976 5.3.2. Withdraw a DOTS Signal 978 A DELETE request is used to withdraw a DOTS signal from a DOTS server 979 (Figure 8). 981 Header: DELETE (Code=0.04) 982 Uri-Host: "host" 983 Uri-Path: "version" 984 Uri-Path: "dots-signal" 985 Uri-Path: "signal" 986 Content-Format: "application/cbor" 987 { 988 "mitigation-scope": { 989 "client-identifer": "string", 990 "scope": [ 991 { 992 "mitigation-id": integer 993 } 994 ] 995 } 996 } 998 Figure 8: Withdraw DOTS signal 1000 The DOTS server immediately acknowledges a DOTS client's request to 1001 withdraw the DOTS signal using 2.02 (Deleted) response code with no 1002 response payload. A 2.02 (Deleted) Response Code is returned even if 1003 the 'mitigation-id' parameter value conveyed in the DELETE request 1004 does not exist in its configuration data before the request. 1006 If the DOTS server finds the 'mitigation-id' parameter value conveyed 1007 in the DELETE request in its configuration data, then to protect 1008 against route or DNS flapping caused by a client rapidly toggling 1009 mitigation, and to dampen the effect of oscillating attacks, DOTS 1010 servers MAY allow mitigation to continue for a limited period after 1011 acknowledging a DOTS client's withdrawal of a mitigation request. 1012 During this period, the DOTS server status messages SHOULD indicate 1013 that mitigation is active but terminating. The active-but- 1014 terminating period MUST be set by default to 30 seconds. If the DOTS 1015 client requests mitigation again before that 30 second expires, the 1016 DOTS server MAY exponentially increase the active-but-terminating 1017 timeout up to a maximum of 240 seconds (4 minutes). After the 1018 active-but-terminating period expires, the DOTS server MUST treat the 1019 mitigation as terminated. That is, the DOTS client is no longer 1020 responsible for the mitigation. For example, if there is a financial 1021 relationship between the DOTS client and server domains, the DOTS 1022 client ceases incurring cost at this point. 1024 5.3.3. Retrieving a DOTS Signal 1026 A GET request is used to retrieve information (inclduding status) of 1027 a DOTS signal from a DOTS server (Figure 9). If the DOTS server does 1028 not find the 'mitigation-id' parameter value conveyed in the GET 1029 request in its configuration data, then it responds with a 4.04 (Not 1030 Found) error response code. The 'c' (content) parameter and its 1031 permitted values defined in [I-D.ietf-core-comi] can be used to 1032 retrieve non-configuration data or configuration data or both. 1034 1) To retrieve all DOTS signals signaled by the DOTS client. 1036 Header: GET (Code=0.01) 1037 Uri-Host: "host" 1038 Uri-Path: "version" 1039 Uri-Path: "dots-signal" 1040 Uri-Path: "signal" 1041 Observe : 0 1042 { 1043 "mitigation-scope": { 1044 "client-identifer": "string", 1045 } 1046 } 1048 2) To retrieve a specific DOTS signal signaled by the DOTS client. 1049 The configuration data in the response will be formatted in the 1050 same order it was processed at the DOTS server. 1052 Header: GET (Code=0.01) 1053 Uri-Host: "host" 1054 Uri-Path: "version" 1055 Uri-Path: "dots-signal" 1056 Uri-Path: "signal" 1057 Observe : 0 1058 Content-Format: "application/cbor" 1059 { 1060 "mitigation-scope": { 1061 "client-identifer": "string", 1062 "scope": [ 1063 { 1064 "mitigation-id": integer 1065 } 1066 ] 1067 } 1068 } 1070 Figure 9: GET to retrieve the rules 1072 Figure 10 shows a response example of all the active mitigation 1073 requests associated with the DOTS client on the DOTS server and the 1074 mitigation status of each mitigation request. 1076 { 1077 "mitigation-scope": { 1078 "scope": [ 1079 { 1080 "mitigation-id": 12332, 1081 "mitigation-start": 1507818434.00, 1082 "target-protocol": [ 1083 17 1084 ], 1085 "lifetime":1800, 1086 "status":2, 1087 "bytes-dropped": 134334555, 1088 "bps-dropped": 43344, 1089 "pkts-dropped": 333334444, 1090 "pps-dropped": 432432 1091 }, 1092 { 1093 "mitigation-id": 12333, 1094 "mitigation-start": 1507818393.00, 1095 "target-protocol": [ 1096 6 1097 ], 1098 "lifetime":1800, 1099 "status":3 1100 "bytes-dropped": 0, 1101 "bps-dropped": 0, 1102 "pkts-dropped": 0, 1103 "pps-dropped": 0 1104 } 1105 ] 1106 } 1107 } 1109 Figure 10: Response body 1111 The mitigation status parameters are described below. 1113 lifetime: The remaining lifetime of the mitigation request in 1114 seconds. 1116 mitigation-start: Mitigation start time is represented in seconds 1117 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 1118 [RFC7049]). The encoding is modified so that the leading tag 1 1119 (epoch-based date/time) MUST be omitted. 1121 bytes-dropped: The total dropped byte count for the mitigation 1122 request since the attack mitigation is triggered. The count wraps 1123 around when it reaches the maximum value of unsigned integer. 1124 This is an optional attribute. 1126 bps-dropped: The average dropped bytes per second for the mitigation 1127 request since the attack mitigation is triggered. This is an 1128 optional attribute. 1130 pkts-dropped: The total dropped packet count for the mitigation 1131 request since the attack mitigation is triggered. This is an 1132 optional attribute. 1134 pps-dropped: The average dropped packets per second for the 1135 mitigation request since the attack mitigation is triggered. This 1136 is an optional attribute. 1138 status: Status of attack mitigation. The 'status' parameter is a 1139 mandatory attribute. 1141 The various possible values of 'status' parameter are explained 1142 below: 1144 /--------------------+---------------------------------------------------\ 1145 | Parameter value | Description | 1146 +--------------------+---------------------------------------------------+ 1147 | 1 | Attack mitigation is in progress | 1148 | | (e.g., changing the network path to re-route the | 1149 | | inbound traffic to DOTS mitigator). | 1150 +--------------------+---------------------------------------------------+ 1151 | 2 | Attack is successfully mitigated | 1152 | | (e.g., traffic is redirected to a DDOS mitigator | 1153 | | and attack traffic is dropped). | 1154 +--------------------+---------------------------------------------------+ 1155 | 3 | Attack has stopped and the DOTS client | 1156 | | can withdraw the mitigation request. | 1157 +--------------------+---------------------------------------------------+ 1158 | 4 | Attack has exceeded the mitigation provider | 1159 | | capability. | 1160 +--------------------+---------------------------------------------------+ 1161 | 5 | DOTS client has withdrawn the mitigation request | 1162 | | and the mitigation is active but terminating. | 1163 \--------------------+---------------------------------------------------/ 1165 The observe option defined in [RFC7641] extends the CoAP core 1166 protocol with a mechanism for a CoAP client to "observe" a resource 1167 on a CoAP server: the client retrieves a representation of the 1168 resource and requests this representation be updated by the server as 1169 long as the client is interested in the resource. A DOTS client 1170 conveys the observe option set to 0 in the GET request to receive 1171 unsolicited notifications of attack mitigation status from the DOTS 1172 server. Unidirectional notifications within the bidirectional signal 1173 channel allows unsolicited message delivery, enabling asynchronous 1174 notifications between the agents. A DOTS client that is no longer 1175 interested in receiving notifications from the DOTS server can simply 1176 "forget" the observation. When the DOTS server then sends the next 1177 notification, the DOTS client will not recognize the token in the 1178 message and thus will return a Reset message. This causes the DOTS 1179 server to remove the associated entry. Alternatively, the DOTS 1180 client can explicitly deregister by issuing a GET request that has 1181 the Token field set to the token of the observation to be cancelled 1182 and includes an Observe Option with the value set to 1 (deregister). 1184 DOTS Client DOTS Server 1185 | | 1186 | GET / | 1187 | Token: 0x4a | Registration 1188 | Observe: 0 | 1189 +------------------------------>| 1190 | | 1191 | 2.05 Content | 1192 | Token: 0x4a | Notification of 1193 | Observe: 12 | the current state 1194 | status: "mitigation | 1195 | in progress" | 1196 |<------------------------------+ 1197 | 2.05 Content | 1198 | Token: 0x4a | Notification upon 1199 | Observe: 44 | a state change 1200 | status: "mitigation | 1201 | complete" | 1202 |<------------------------------+ 1203 | 2.05 Content | 1204 | Token: 0x4a | Notification upon 1205 | Observe: 60 | a state change 1206 | status: "attack stopped" | 1207 |<------------------------------+ 1208 | | 1210 Figure 11: Notifications of attack mitigation status 1212 5.3.3.1. Mitigation Status 1214 The DOTS client can send the GET request at frequent intervals 1215 without the Observe option to retrieve the configuration data of the 1216 mitigation request and non-configuration data (i.e., the attack 1217 status). The frequency of polling the DOTS server to get the 1218 mitigation status should follow the transmission guidelines given in 1219 Section 3.1.3 of [RFC8085]. If the DOTS server has been able to 1220 mitigate the attack and the attack has stopped, the DOTS server 1221 indicates as such in the status, and the DOTS client recalls the 1222 mitigation request by issuing a DELETE for the mitigation-id. 1224 A DOTS client should react to the status of the attack from the DOTS 1225 server and not the fact that it has recognized, using its own means, 1226 that the attack has been mitigated. This ensures that the DOTS 1227 client does not recall a mitigation request in a premature fashion 1228 because it is possible that the DOTS client does not sense the DDOS 1229 attack on its resources but the DOTS server could be actively 1230 mitigating the attack and the attack is not completely averted. 1232 5.3.4. Efficacy Update from DOTS Client 1234 While DDoS mitigation is active, a DOTS client MAY frequently 1235 transmit DOTS mitigation efficacy updates to the relevant DOTS 1236 server. A PUT request (Figure 12) is used to convey the mitigation 1237 efficacy update to the DOTS server. 1239 The PUT request MUST include all the parameters used in the PUT 1240 request to convey the DOTS signal (Section 5.3.1) unchanged apart 1241 from the lifetime parameter value. If this is not the case, the DOTS 1242 server MUST reject the request with a 4.02 error response code. 1244 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1245 value is used to make the PUT request conditional on the current 1246 existence of the mitigation request. If UDP is used as transport, 1247 CoAP requests may arrive out-of-order. For example, the DOTS client 1248 may send a PUT request to convey an efficacy update to the DOTS 1249 server followed by a DELETE request to withdraw the mitigation 1250 request, but the DELETE request arrives at the DOTS server before the 1251 PUT request. To handle out-of-order delivery of requests, if an If- 1252 Match option is present in the PUT request and the 'mitigation-id' in 1253 the request matches a mitigation request from that DOTS client, then 1254 the request is processed. If no match is found, the PUT request is 1255 silently ignored. 1257 Header: PUT (Code=0.03) 1258 Uri-Host: "host" 1259 Uri-Path: "version" 1260 Uri-Path: "dots-signal" 1261 Uri-Path: "signal" 1262 Content-Format: "application/cbor" 1263 { 1264 "mitigation-scope": { 1265 "client-identifer": "string", 1266 "scope": [ 1267 { 1268 "mitigation-id": integer, 1269 "target-ip": [ 1270 "string" 1271 ], 1272 "target-port-range": [ 1273 { 1274 "lower-port": integer, 1275 "upper-port": integer 1276 } 1277 ], 1278 "target-protocol": [ 1279 integer 1280 ], 1281 "fqdn": [ 1282 "string" 1283 ], 1284 "uri": [ 1285 "string" 1286 ], 1287 "alias-name": [ 1288 "string" 1289 ], 1290 "lifetime": integer, 1291 "attack-status": integer 1292 } 1293 ] 1294 } 1295 } 1297 Figure 12: Efficacy Update 1299 The 'attack-status' parameter is a mandatory attribute. The various 1300 possible values contained in the 'attack-status' parameter are 1301 described below: 1303 /--------------------+------------------------------------------------------\ 1304 | Parameter value | Description | 1305 +--------------------+------------------------------------------------------+ 1306 | 1 | DOTS client determines that it is still under attack.| 1307 +--------------------+------------------------------------------------------+ 1308 | 2 | DOTS client determines that the attack is | 1309 | | successfully mitigated | 1310 | | (e.g., attack traffic is not seen). | 1311 \--------------------+------------------------------------------------------/ 1313 The DOTS server indicates the result of processing a PUT request 1314 using CoAP response codes. The response code 2.04 (Changed) is 1315 returned if the DOTS server has accepted the mitigation efficacy 1316 update. The error response code 5.03 (Service Unavailable) is 1317 returned if the DOTS server has erred or is incapable of performing 1318 the mitigation. 1320 5.4. DOTS Signal Channel Session Configuration 1322 The DOTS client can negotiate, configure, and retrieve the DOTS 1323 signal channel session behavior. The DOTS signal channel can be 1324 used, for example, to configure the following: 1326 a. Heartbeat interval: DOTS agents regularly send heartbeats (Ping/ 1327 Pong) to each other after mutual authentication in order to keep 1328 the DOTS signal channel open, heartbeat messages are exchanged 1329 between the DOTS agents every heartbeat-interval seconds to 1330 detect the current status of the DOTS signal channel session. 1332 b. Missing heartbeats allowed: This variable indicates the maximum 1333 number of consecutive heartbeat messages for which a DOTS agent 1334 did not receive a response before concluding that the session is 1335 disconnected or defunct. 1337 c. Acceptable signal loss ratio: Maximum retransmissions, 1338 retransmission timeout value and other message transmission 1339 parameters for the DOTS signal channel. 1341 Reliability is provided to requests and responses by marking them as 1342 Confirmable (CON) messages. DOTS signal channel session 1343 configuration requests and responses are marked as Confirmable (CON) 1344 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1345 message is retransmitted using a default timeout and exponential 1346 back-off between retransmissions, until the DOTS server sends an 1347 Acknowledgement message (ACK) with the same Message ID conveyed from 1348 the DOTS client. Message transmission parameters are defined in 1349 Section 4.8 of [RFC7252]. Reliability is provided to the responses 1350 by marking them as Confirmable (CON) messages. The DOTS server can 1351 either piggyback the response in the acknowledgement message or if 1352 the DOTS server is not able to respond immediately to a request 1353 carried in a Confirmable message, it simply responds with an Empty 1354 Acknowledgement message so that the DOTS client can stop 1355 retransmitting the request. Empty Acknowledgement message is 1356 explained in Section 2.2 of [RFC7252]. When the response is ready, 1357 the server sends it in a new Confirmable message which then in turn 1358 needs to be acknowledged by the DOTS client (see Sections 5.2.1 and 1359 Sections 5.2.2 of [RFC7252]). Requests and responses exchanged 1360 between DOTS agents during peacetime are marked as Confirmable 1361 messages. 1363 Implementation Note: A DOTS client that receives a response in a CON 1364 message may want to clean up the message state right after sending 1365 the ACK. If that ACK is lost and the DOTS server retransmits the 1366 CON, the DOTS client may no longer have any state to which to 1367 correlate this response, making the retransmission an unexpected 1368 message; the DOTS client will send a Reset message so it does not 1369 receive any more retransmissions. This behavior is normal and not an 1370 indication of an error (see Section 5.3.2 of [RFC7252] for more 1371 details). 1373 5.4.1. Discover Configuration Parameters 1375 A GET request is used to obtain acceptable and current configuration 1376 parameters on the DOTS server for DOTS signal channel session 1377 configuration. Figure 13 shows how to obtain acceptable 1378 configuration parameters for the server. 1380 Header: GET (Code=0.01) 1381 Uri-Host: "host" 1382 Uri-Path: "version" 1383 Uri-Path: "dots-signal" 1384 Uri-Path: "config" 1386 Figure 13: GET to retrieve configuration 1388 The DOTS server in the 2.05 (Content) response conveys the minimum 1389 and maximum attribute values acceptable by the DOTS server. 1391 Content-Format: "application/cbor" 1392 { 1393 "heartbeat-interval": { 1394 "CurrentValue": integer, 1395 "MinValue": integer, 1396 "MaxValue" : integer, 1397 }, 1398 "missing-hb-allowed": { 1399 "CurrentValue": integer, 1400 "MinValue": integer, 1401 "MaxValue" : integer, 1402 }, 1403 "max-retransmit": { 1404 "CurrentValue": integer, 1405 "MinValue": integer, 1406 "MaxValue" : integer, 1407 }, 1408 "ack-timeout": { 1409 "CurrentValue": integer, 1410 "MinValue": integer, 1411 "MaxValue" : integer, 1412 }, 1413 "ack-random-factor": { 1414 "CurrentValue": number, 1415 "MinValue": number, 1416 "MaxValue" : number, 1417 } 1418 } 1420 Figure 14: GET response body 1422 Figure 15 shows an example of acceptable and current configuration 1423 parameters on the DOTS server for DOTS signal channel session 1424 configuration. 1426 Content-Format: "application/cbor" 1427 { 1428 "heartbeat-interval": { 1429 "CurrentValue": 30, 1430 "MinValue": 15, 1431 "MaxValue" : 240, 1432 }, 1433 "missing-hb-allowed": { 1434 "CurrentValue": 5, 1435 "MinValue": 3, 1436 "MaxValue" : 9, 1437 }, 1438 "max-retransmit": { 1439 "CurrentValue": 3, 1440 "MinValue": 2, 1441 "MaxValue" : 15, 1442 }, 1443 "ack-timeout": { 1444 "CurrentValue": 2, 1445 "MinValue": 1, 1446 "MaxValue" : 30, 1447 }, 1448 "ack-random-factor": { 1449 "CurrentValue": 1.5, 1450 "MinValue": 1.1, 1451 "MaxValue" : 4.0, 1452 } 1453 } 1455 Figure 15: configuration response body 1457 5.4.2. Convey DOTS Signal Channel Session Configuration 1459 A PUT request is used to convey the configuration parameters for the 1460 signaling channel (e.g., heartbeat interval, maximum 1461 retransmissions). Message transmission parameters for CoAP are 1462 defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of 1463 transmission parameter values are ack_timeout (2 seconds), max- 1464 retransmit (3), ack-random-factor (1.5). In addition to those 1465 parameters, the RECOMMENDED specific DOTS transmission parameter 1466 values are heartbeat-interval (30 seconds) and missing-hb-allowed 1467 (5). 1469 Note: heartbeat-interval should be tweaked to also assist DOTS 1470 messages for NAT traversal (SIG-010 of 1471 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 1472 messages must not be sent more frequently than once every 15 1473 seconds and should use longer intervals when possible. 1475 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 1476 minutes or longer, but experience shows that sending packets every 1477 15 to 30 seconds is necessary to prevent the majority of 1478 middleboxes from losing state for UDP flows. From that 1479 standpoint, this specification recommends a minimum heartbeat- 1480 interval of 15 seconds and a maximum heartbeat-interval of 240 1481 seconds. The recommended value of 30 seconds is selected to 1482 anticipate the expiry of NAT state. 1484 A heartbeat-interval of 30 second may be seen as too chatty in 1485 some deployments. For such deployments, DOTS agents may negotiate 1486 longer heartbeat-interval values to avoid overloading the network 1487 with too frequent keepalives. 1489 For the recommended transmission parameters, if the DOTS agent does 1490 not receive any response from the peer DOTS agent for five (missing- 1491 hb-allowed) consecutive "CoAP ping" confirmable messages, then it 1492 concludes that the DOTS signal channel session is disconnected, and a 1493 "CoAP ping" confirmable message is retransmitted three (max- 1494 retransmit) times using an initial timeout set to a random duration 1495 between 2 (ack_timeout) and 3 seconds (ack-timeout*ack-random-factor) 1496 and exponential back-off between retransmissions. 1498 If the DOTS agent wishes to change the default values of message 1499 transmission parameters, then it should follow the guidance given in 1500 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 1501 values for message transmission parameters and default values for 1502 non-negotiated message transmission parameters. 1504 The signaling channel session configuration is applicable to a single 1505 DOTS signal channel session between the DOTS agents. 1507 Header: PUT (Code=0.03) 1508 Uri-Host: "host" 1509 Uri-Path: "version" 1510 Uri-Path: "dots-signal" 1511 Uri-Path: "config" 1512 Content-Format: "application/cbor" 1513 { 1514 "signal-config": { 1515 "session-id": integer, 1516 "heartbeat-interval": integer, 1517 "missing-hb-allowed": integer, 1518 "max-retransmit": integer, 1519 "ack-timeout": integer, 1520 "ack-random-factor": number 1521 "trigger-mitigation": boolean 1522 } 1523 } 1525 Figure 16: PUT to convey the DOTS signal channel session 1526 configuration data. 1528 The parameters are described below: 1530 session-id: Identifier for the DOTS signal channel session 1531 configuration data represented as an integer. This identifier 1532 MUST be generated by the DOTS client. This document does not make 1533 any assumption about how this identifier is generated. This is a 1534 mandatory attribute. 1536 heartbeat-interval: Time interval in seconds between two 1537 consecutive heartbeat messages. This is an optional attribute. 1539 missing-hb-allowed: Maximum number of consecutive heartbeat 1540 messages for which the DOTS agent did not receive a response 1541 before concluding that the session is disconnected. This is an 1542 optional attribute. 1544 max-retransmit: Maximum number of retransmissions for a message 1545 (referred to as MAX_RETRANSMIT parameter in CoAP). This is an 1546 optional attribute. 1548 ack-timeout: Timeout value in seconds used to calculate the initial 1549 retransmission timeout value (referred to as ACK_TIMEOUT parameter 1550 in CoAP). This is an optional attribute. 1552 ack-random-factor: Random factor used to influence the timing of 1553 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1554 CoAP). This is an optional attribute. 1556 trigger-mitigation: If the parameter value is set to 'false', then 1557 DDoS mitigation is triggered only when the DOTS signal channel 1558 session is lost. Automated mtigation on loss of signal is 1559 discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. If 1560 the DOTS client ceases to respond to heartbeat messages, then the 1561 DOTS server can detect that the DOTS session is lost. The default 1562 value of the parameter is 'true'. This is an optional attribute. 1564 In the PUT request at least one of the attributes heartbeat-interval, 1565 missing-hb-allowed, max-retransmit, ack-timeout, ack-random-factor, 1566 and trigger-mitigation MUST be present. The PUT request with higher 1567 numeric session-id value over-rides the DOTS signal channel session 1568 configuration data installed by a PUT request with a lower numeric 1569 session-id value. 1571 Figure 17 shows a PUT request example to convey the configuration 1572 parameters for the DOTS signal channel. 1574 Header: PUT (Code=0.03) 1575 Uri-Host: "www.example.com" 1576 Uri-Path: "v1" 1577 Uri-Path: "dots-signal" 1578 Uri-Path: "config" 1579 Content-Format: "application/cbor" 1580 { 1581 "signal-config": { 1582 "session-id": 1234534333242, 1583 "heartbeat-interval": 91, 1584 "missing-hb-allowed": 3, 1585 "max-retransmit": 7, 1586 "ack-timeout": 5, 1587 "ack-random-factor": 1.5, 1588 "trigger-mitigation": false 1589 } 1590 } 1592 Figure 17: PUT to convey the configuration parameters 1594 The DOTS server indicates the result of processing the PUT request 1595 using CoAP response codes: 1597 o If the DOTS server finds the 'session-id' parameter value conveyed 1598 in the PUT request in its configuration data and if the DOTS 1599 server has accepted the updated configuration parameters, then 1600 2.04 (Changed) code is returned in the response. 1602 o If the DOTS server does not find the 'session-id' parameter value 1603 conveyed in the PUT request in its configuration data and if the 1604 DOTS server has accepted the configuration parameters, then a 1605 response code 2.01 (Created) is returned in the response. 1607 o If the request is missing one or more mandatory attributes, then 1608 4.00 (Bad Request) is returned in the response. 1610 o If the request contains one or more invalid or unknown parameters, 1611 then 4.02 (Invalid query) code is returned in the response. 1613 o Response code 4.22 (Unprocessable Entity) is returned in the 1614 response, if any of the heartbeat-interval, missing-hb-allowed, 1615 max-retransmit, target-protocol, ack-timeout, and ack-random- 1616 factor attribute values are not acceptable to the DOTS server. 1617 Upon receipt of the 4.22 error response code, the DOTS client 1618 should request the maximum and minumum attribute values acceptable 1619 to the DOTS server (Section 5.4.1). The DOTS client may re-try 1620 and send the PUT request with updated attribute values acceptable 1621 to the DOTS server. 1623 5.4.3. Delete DOTS Signal Channel Session Configuration 1625 A DELETE request is used to delete the installed DOTS signal channel 1626 session configuration data (Figure 18). 1628 Header: DELETE (Code=0.04) 1629 Uri-Host: "host" 1630 Uri-Path: "version" 1631 Uri-Path: "dots-signal" 1632 Uri-Path: "config" 1633 Content-Format: "application/cbor" 1634 { 1635 "signal-config": { 1636 "session-id": integer 1637 } 1638 } 1640 Figure 18: DELETE configuration 1642 If the DOTS server does not find the session-id parameter value 1643 conveyed in the DELETE request in its configuration data, then it 1644 responds with a 4.04 (Not Found) error response code. The DOTS 1645 server successfully acknowledges a DOTS client's request to remove 1646 the DOTS signal channel session configuration using 2.02 (Deleted) 1647 response code. 1649 5.4.4. Retrieving DOTS Signal Channel Session Configuration 1651 A GET request is used to retrieve the installed DOTS signal channel 1652 session configuration data from a DOTS server. Figure 19 shows how 1653 to retrieve the DOTS signal channel session configuration data. 1655 Header: GET (Code=0.01) 1656 Uri-Host: "host" 1657 Uri-Path: "version" 1658 Uri-Path: "dots-signal" 1659 Uri-Path: "config" 1660 Content-Format: "application/cbor" 1661 { 1662 "signal-config": { 1663 "session-id": integer 1664 } 1665 } 1667 Figure 19: GET to retrieve configuration 1669 5.5. Redirected Signaling 1671 Redirected Signaling is discussed in detail in Section 3.2.2 of 1672 [I-D.ietf-dots-architecture]. If the DOTS server wants to redirect 1673 the DOTS client to an alternative DOTS server for a signaling session 1674 then the response code 3.00 (alternate server) will be returned in 1675 the response to the client. The DOTS server can return the error 1676 response code 3.00 in response to a PUT request from the DOTS client 1677 or convey the error response code 3.00 in a unidirectional 1678 notification response from the DOTS server. 1680 The DOTS server in the error response conveys the alternate DOTS 1681 server FQDN, and the alternate DOTS server IP addresses and time to 1682 live values in the CBOR body. 1684 { 1685 "alt-server": "string", 1686 "alt-server-record": [ 1687 { 1688 "addr": "string", 1689 "ttl" : integer, 1690 } 1691 ] 1692 } 1694 Figure 20: Error response body 1696 The parameters are described below: 1698 alt-server: FQDN of an alternate DOTS server. 1700 addr: IP address of an alternate DOTS server. 1702 ttl: Time to live (TTL) represented as an integer number of seconds. 1704 Figure 21 shows a 3.00 response example to convey the DOTS alternate 1705 server www.example-alt.com, its IP addresses 2001:db8:6401::1 and 1706 2001:db8:6401::2, and TTL values 3600 and 1800. 1708 { 1710 "alt-server": "www.example-alt.com", 1711 "alt-server-record": [ 1712 { 1713 "ttl" : 3600, 1714 "addr": "2001:db8:6401::1" 1715 }, 1716 { 1717 "ttl" : 1800, 1718 "addr": "2001:db8:6401::2" 1719 } 1720 ] 1721 } 1723 Figure 21: Example of error response body 1725 When the DOTS client receives 3.00 response, it considers the current 1726 request as having failed, but SHOULD try the request with the 1727 alternate DOTS server. During a DDOS attack, the DNS server may be 1728 subjected to DDOS attack, alternate DOTS server IP addresses conveyed 1729 in the 3.00 response help the DOTS client to skip DNS lookup of the 1730 alternate DOTS server and can try to establish UDP or TCP session 1731 with the alternate DOTS server IP addresses. The DOTS client SHOULD 1732 implement DNS64 function to handle the scenario where IPv6-only DOTS 1733 client communicates with IPv4-only alternate DOTS server. 1735 5.6. Heartbeat Mechanism 1737 To provide a metric of signal health and distinguish an 'idle' signal 1738 channel from a 'disconnected' or 'defunct' session, the DOTS agent 1739 sends a heartbeat over the signal channel to maintain its half of the 1740 channel. The DOTS agent similarly expects a heartbeat from its peer 1741 DOTS agent, and may consider a session terminated in the extended 1742 absence of a peer agent heartbeat. 1744 While the communication between the DOTS agents is quiescent, the 1745 DOTS client will probe the DOTS server to ensure it has maintained 1746 cryptographic state and vice versa. Such probes can also keep alive 1747 firewall and/or NAT bindings. This probing reduces the frequency of 1748 establishing a new handshake when a DOTS signal needs to be conveyed 1749 to the DOTS server. 1751 In DOTS over UDP, heartbeat messages may be exchanged between the 1752 DOTS agents using the "COAP ping" mechanism defined in Section 4.2 of 1753 [RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable 1754 message and the peer DOTS agent will respond by sending an Reset 1755 message. 1757 In DOTS over TCP, heartbeat messages can be exchanged between the 1758 DOTS agents using the Ping and Pong messages specified in Section 4.4 1759 of [I-D.ietf-core-coap-tcp-tls]. That is, the DOTS agent sends a 1760 Ping message and the peer DOTS agent would respond by sending a 1761 single Pong message. 1763 A DOTS client MUST NOT transmit a heartbeat message while a previous 1764 heartbeat message has not been responded by the remote DOTS server. 1766 6. Mapping parameters to CBOR 1768 All parameters in the payload in the DOTS signal channel MUST be 1769 mapped to CBOR types as follows and are given an integer key to save 1770 space. The recipient of the payload MAY reject the information if it 1771 is not suitably mapped. 1773 /--------------------+------------------------+--------------------------\ 1774 | Parameter name | CBOR key | CBOR major type of value | 1775 +--------------------+------------------------+--------------------------+ 1776 | mitigation-scope | 1 | 5 (map) | 1777 | scope | 2 | 5 (map) | 1778 | mitigation-id | 3 | 0 (unsigned) | 1779 | target-ip | 4 | 4 (array) | 1780 | target-port-range | 5 | 4 | 1781 | lower-port | 6 | 0 | 1782 | upper-port | 7 | 0 | 1783 | target-protocol | 8 | 4 | 1784 | fqdn | 9 | 4 | 1785 | uri | 10 | 4 | 1786 | alias-name | 11 | 4 | 1787 | lifetime | 12 | 0 | 1788 | attack-status | 13 | 0 | 1789 | signal-config | 14 | 5 | 1790 | heartbeat-interval | 15 | 0 | 1791 | max-retransmit | 16 | 0 | 1792 | ack-timeout | 17 | 0 | 1793 | ack-random-factor | 18 | 7 | 1794 | MinValue | 19 | 0 | 1795 | MaxValue | 20 | 0 | 1796 | status | 21 | 0 | 1797 | bytes-dropped | 22 | 0 | 1798 | bps-dropped | 23 | 0 | 1799 | pkts-dropped | 24 | 0 | 1800 | pps-dropped | 25 | 0 | 1801 | session-id | 26 | 0 | 1802 | trigger-mitigation | 27 | 7 (simple types) | 1803 | missing-hb-allowed | 28 | 0 | 1804 | CurrentValue | 29 | 0 | 1805 | mitigation-start | 30 | 7 (floating-point) | 1806 | target-prefix | 31 | 4 (array) | 1807 | client-identifier | 32 | 2 (byte string) | 1808 \--------------------+------------------------+--------------------------/ 1810 Figure 22: CBOR mappings used in DOTS signal channel message 1812 7. (D)TLS Protocol Profile and Performance considerations 1814 This section defines the (D)TLS protocol profile of DOTS signal 1815 channel over (D)TLS and DOTS data channel over TLS. 1817 There are known attacks on (D)TLS, such as machine-in-the-middle and 1818 protocol downgrade. These are general attacks on (D)TLS and not 1819 specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for 1820 discussion of these security issues. DOTS agents MUST adhere to the 1821 (D)TLS implementation recommendations and security considerations of 1822 [RFC7525] except with respect to (D)TLS version. Since encryption of 1823 DOTS using (D)TLS is virtually a green-field deployment DOTS agents 1824 MUST implement only (D)TLS 1.2 or later. 1826 Implementations compliant with this profile MUST implement all of the 1827 following items: 1829 o DOTS agents MUST support DTLS record replay detection (Section 3.3 1830 of [RFC6347]) to protect against replay attacks. 1832 o DOTS client can use (D)TLS session resumption without server-side 1833 state [RFC5077] to resume session and convey the DOTS signal. 1835 o Raw public keys [RFC7250] which reduce the size of the 1836 ServerHello, and can be used by servers that cannot obtain 1837 certificates (e.g., DOTS gateways on private networks). 1839 Implementations compliant with this profile SHOULD implement all of 1840 the following items to reduce the delay required to deliver a DOTS 1841 signal: 1843 o TLS False Start [RFC7918] which reduces round-trips by allowing 1844 the TLS second flight of messages (ChangeCipherSpec) to also 1845 contain the DOTS signal. 1847 o Cached Information Extension [RFC7924] which avoids transmitting 1848 the server's certificate and certificate chain if the client has 1849 cached that information from a previous TLS handshake. 1851 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 1852 convey DOTS signal. 1854 7.1. MTU and Fragmentation Issues 1856 To avoid DOTS signal message fragmentation and the consequently 1857 decreased probability of message delivery, DOTS agents MUST ensure 1858 that the DTLS record MUST fit within a single datagram. If the Path 1859 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 1860 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 1861 is used to convey the DOTS signal messages then the DOTS client must 1862 consider the amount of record expansion expected by the DTLS 1863 processing when calculating the size of CoAP message that fits within 1864 the path MTU. Path MTU MUST be greater than or equal to [CoAP 1865 message size + DTLS overhead of 13 octets + authentication overhead 1866 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 1867 of [RFC6347]]. If the request size exceeds the Path MTU then the 1868 DOTS client MUST split the DOTS signal into separate messages, for 1869 example the list of addresses in the 'target-ip' parameter could be 1870 split into multiple lists and each list conveyed in a new PUT 1871 request. 1873 Implementation Note: DOTS choice of message size parameters works 1874 well with IPv6 and with most of today's IPv4 paths. However, with 1875 IPv4, it is harder to absolutely ensure that there is no IP 1876 fragmentation. If IPv4 support on unusual networks is a 1877 consideration and path MTU is unknown, implementations may want to 1878 limit themselves to more conservative IPv4 datagram sizes such as 576 1879 bytes, as per [RFC0791] IP packets up to 576 bytes should never need 1880 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal 1881 over a UDP datagram will generally avoid IP fragmentation. 1883 8. (D)TLS 1.3 considerations 1885 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 1886 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 1887 [I-D.rescorla-tls-dtls13] is based on the TLS 1.3 protocol and 1888 provides equivalent security guarantees. (D)TLS 1.3 provides two 1889 basic handshake modes of interest to DOTS signal channel: 1891 o Absent packet loss, a full handshake in which the DOTS client is 1892 able to send the DOTS signal message after one round trip and the 1893 DOTS server immediately after receiving the first DOTS signal 1894 message from the client. 1896 o 0-RTT mode in which the DOTS client can authenticate itself and 1897 send DOTS signal message on its first flight, thus reducing 1898 handshake latency. 0-RTT only works if the DOTS client has 1899 previously communicated with that DOTS server, which is very 1900 likely with the DOTS signal channel. The DOTS client SHOULD 1901 establish a (D)TLS session with the DOTS server during peacetime 1902 and share a PSK. During DDOS attack, the DOTS client can use the 1903 (D)TLS session to convey the DOTS signal message and if there is 1904 no response from the server after multiple re-tries then the DOTS 1905 client can resume the (D)TLS session in 0-RTT mode using PSK. A 1906 simplified TLS 1.3 handshake with 0-RTT DOTS signal message 1907 exchange is shown in Figure 23. 1909 DOTS Client DOTS Server 1911 ClientHello 1912 (Finished) 1913 (0-RTT DOTS signal message) 1914 (end_of_early_data) --------> 1915 ServerHello 1916 {EncryptedExtensions} 1917 {ServerConfiguration} 1918 {Certificate} 1919 {CertificateVerify} 1920 {Finished} 1921 <-------- [DOTS signal message] 1922 {Finished} --------> 1924 [DOTS signal message] <-------> [DOTS signal message] 1926 Figure 23: TLS 1.3 handshake with 0-RTT 1928 9. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 1930 (D)TLS based on client certificate can be used for mutual 1931 authentication between DOTS agents. If a DOTS gateway is involved, 1932 DOTS clients and DOTS gateway MUST perform mutual authentication; 1933 only authorized DOTS clients are allowed to send DOTS signals to a 1934 DOTS gateway. DOTS gateway and DOTS server MUST perform mutual 1935 authentication; DOTS server only allows DOTS signals from authorized 1936 DOTS gateway, creating a two-link chain of transitive authentication 1937 between the DOTS client and the DOTS server. 1939 +-------------------------------------------------+ 1940 | example.com domain +---------+ | 1941 | | AAA | | 1942 | +---------------+ | Server | | 1943 | | Application | +------+--+ | 1944 | | server + ^ 1945 | | (DOTS client) |<-----------------+ | | 1946 | +---------------+ + | | example.net domain 1947 | V V | 1948 | +-------------+ | +---------------+ 1949 | +--------------+ | | | | | 1950 | | Guest +<-----x----->+ +<---------------->+ DOTS | 1951 | | (DOTS client)| | DOTS | | | Server | 1952 | +--------------+ | Gateway | | | | 1953 | +----+--------+ | +---------------+ 1954 | ^ | 1955 | | | 1956 | +----------------+ | | 1957 | | DDOS detector | | | 1958 | | (DOTS client) +<--------------+ | 1959 | +----------------+ | 1960 | | 1961 +-------------------------------------------------+ 1963 Figure 24: Example of Authentication and Authorization of DOTS Agents 1965 In the example depicted in Figure 24, the DOTS gateway and DOTS 1966 clients within the 'example.com' domain mutually authenticate with 1967 each other. After the DOTS gateway validates the identity of a DOTS 1968 client, it communicates with the AAA server in the 'example.com' 1969 domain to determine if the DOTS client is authorized to request DDOS 1970 mitigation. If the DOTS client is not authorized, a 4.01 1971 (Unauthorized) is returned in the response to the DOTS client. In 1972 this example, the DOTS gateway only allows the application server and 1973 DDOS detector to request DDOS mitigation, but does not permit the 1974 user of type 'guest' to request DDOS mitigation. 1976 Also, DOTS gateway and DOTS server located in different domains MUST 1977 perform mutual authentication (e.g., using certificates). A DOTS 1978 server will only allow a DOTS gateway with a certificate for a 1979 particular domain to request mitigation for that domain. In 1980 reference to Figure 24, the DOTS server only allows the DOTS gateway 1981 to request mitigation for 'example.com' domain and not for other 1982 domains. 1984 10. IANA Considerations 1986 This specification registers new CoAP response code, new parameters 1987 for DOTS signal channel and establishes registries for mappings to 1988 CBOR. 1990 10.1. CoAP Response Code 1992 The following entry is added to the "CoAP Response Codes" sub- 1993 registry: 1995 +------+------------------------------+-----------+ 1996 | Code | Description | Reference | 1997 +------+------------------------------+-----------+ 1998 | 3.00 | Alternate server | [RFCXXXX] | 1999 +------+------------------------------+-----------+ 2001 Figure 25: CoAP Response Code 2003 [Note to RFC Editor: Please replace XXXX with the RFC number of this 2004 specification.] 2006 10.2. DOTS signal channel CBOR Mappings Registry 2008 A new registry will be requested from IANA, entitled "DOTS signal 2009 channel CBOR Mappings Registry". The registry is to be created as 2010 Expert Review Required. 2012 10.2.1. Registration Template 2014 Parameter name: 2015 Parameter names (e.g., "target_ip") in the DOTS signal channel. 2017 CBOR Key Value: 2018 Key value for the parameter. The key value MUST be an integer in 2019 the range of 1 to 65536. The key values in the range of 32768 to 2020 65536 are assigned for Vendor-Specific parameters. 2022 CBOR Major Type: 2023 CBOR Major type and optional tag for the claim. 2025 Change Controller: 2026 For Standards Track RFCs, list the "IESG". For others, give the 2027 name of the responsible party. Other details (e.g., postal 2028 address, email address, home page URI) may also be included. 2030 Specification Document(s): 2032 Reference to the document or documents that specify the parameter, 2033 preferably including URIs that can be used to retrieve copies of 2034 the documents. An indication of the relevant sections may also be 2035 included but is not required. 2037 10.2.2. Initial Registry Contents 2039 o Parameter Name: "mitigation-scope" 2040 o CBOR Key Value: 1 2041 o CBOR Major Type: 5 2042 o Change Controller: IESG 2043 o Specification Document(s): this document 2045 o Parameter Name: "scope" 2046 o CBOR Key Value: 2 2047 o CBOR Major Type: 5 2048 o Change Controller: IESG 2049 o Specification Document(s): this document 2051 o Parameter Name: "mitigation-id" 2052 o CBOR Key Value: 3 2053 o CBOR Major Type: 0 2054 o Change Controller: IESG 2055 o Specification Document(s): this document 2057 o Parameter Name:target-ip 2058 o CBOR Key Value: 4 2059 o CBOR Major Type: 4 2060 o Change Controller: IESG 2061 o Specification Document(s): this document 2063 o Parameter Name: target-port-range 2064 o CBOR Key Value: 5 2065 o CBOR Major Type: 4 2066 o Change Controller: IESG 2067 o Specification Document(s): this document 2069 o Parameter Name: "lower-port" 2070 o CBOR Key Value: 6 2071 o CBOR Major Type: 0 2072 o Change Controller: IESG 2073 o Specification Document(s): this document 2075 o Parameter Name: "upper-port" 2076 o CBOR Key Value: 7 2077 o CBOR Major Type: 0 2078 o Change Controller: IESG 2079 o Specification Document(s): this document 2080 o Parameter Name: target-protocol 2081 o CBOR Key Value: 8 2082 o CBOR Major Type: 4 2083 o Change Controller: IESG 2084 o Specification Document(s): this document 2086 o Parameter Name: "fqdn" 2087 o CBOR Key Value: 9 2088 o CBOR Major Type: 4 2089 o Change Controller: IESG 2090 o Specification Document(s): this document 2092 o Parameter Name: "uri" 2093 o CBOR Key Value: 10 2094 o CBOR Major Type: 4 2095 o Change Controller: IESG 2096 o Specification Document(s): this document 2098 o Parameter Name: alias-name 2099 o CBOR Key Value: 11 2100 o CBOR Major Type: 4 2101 o Change Controller: IESG 2102 o Specification Document(s): this document 2104 o Parameter Name: "lifetime" 2105 o CBOR Key Value: 12 2106 o CBOR Major Type: 0 2107 o Change Controller: IESG 2108 o Specification Document(s): this document 2110 o Parameter Name: attack-status 2111 o CBOR Key Value: 13 2112 o CBOR Major Type: 0 2113 o Change Controller: IESG 2114 o Specification Document(s): this document 2116 o Parameter Name: signal-config 2117 o CBOR Key Value: 14 2118 o CBOR Major Type: 5 2119 o Change Controller: IESG 2120 o Specification Document(s): this document 2122 o Parameter Name: heartbeat-interval 2123 o CBOR Key Value: 15 2124 o CBOR Major Type: 0 2125 o Change Controller: IESG 2126 o Specification Document(s): this document 2127 o Parameter Name: max-retransmit 2128 o CBOR Key Value: 16 2129 o CBOR Major Type: 0 2130 o Change Controller: IESG 2131 o Specification Document(s): this document 2133 o Parameter Name: ack-timeout 2134 o CBOR Key Value: 17 2135 o CBOR Major Type: 0 2136 o Change Controller: IESG 2137 o Specification Document(s): this document 2139 o Parameter Name: ack-random-factor 2140 o CBOR Key Value: 18 2141 o CBOR Major Type: 7 2142 o Change Controller: IESG 2143 o Specification Document(s): this document 2145 o Parameter Name: MinValue 2146 o CBOR Key Value: 19 2147 o CBOR Major Type: 0 2148 o Change Controller: IESG 2149 o Specification Document(s): this document 2151 o Parameter Name: MaxValue 2152 o CBOR Key Value: 20 2153 o CBOR Major Type: 0 2154 o Change Controller: IESG 2155 o Specification Document(s): this document 2157 o Parameter Name: status 2158 o CBOR Key Value: 21 2159 o CBOR Major Type: 0 2160 o Change Controller: IESG 2161 o Specification Document(s): this document 2163 o Parameter Name: bytes-dropped 2164 o CBOR Key Value: 22 2165 o CBOR Major Type: 0 2166 o Change Controller: IESG 2167 o Specification Document(s): this document 2169 o Parameter Name: bps-dropped 2170 o CBOR Key Value: 23 2171 o CBOR Major Type: 0 2172 o Change Controller: IESG 2173 o Specification Document(s): this document 2174 o Parameter Name: pkts-dropped 2175 o CBOR Key Value: 24 2176 o CBOR Major Type: 0 2177 o Change Controller: IESG 2178 o Specification Document(s): this document 2180 o Parameter Name: pps-dropped 2181 o CBOR Key Value: 25 2182 o CBOR Major Type: 0 2183 o Change Controller: IESG 2184 o Specification Document(s): this document 2186 o Parameter Name: session-id 2187 o CBOR Key Value: 26 2188 o CBOR Major Type: 0 2189 o Change Controller: IESG 2190 o Specification Document(s): this document 2192 o Parameter Name: trigger-mitigation 2193 o CBOR Key Value: 27 2194 o CBOR Major Type: 7 2195 o Change Controller: IESG 2196 o Specification Document(s): this document 2198 o Parameter Name: missing-hb-allowed 2199 o CBOR Key Value: 28 2200 o CBOR Major Type: 0 2201 o Change Controller: IESG 2202 o Specification Document(s): this document 2204 o Parameter Name: CurrentValue 2205 o CBOR Key Value: 29 2206 o CBOR Major Type: 0 2207 o Change Controller: IESG 2208 o Specification Document(s): this document 2210 o Parameter Name:mitigation-start 2211 o CBOR Key Value: 30 2212 o CBOR Major Type: 7 2213 o Change Controller: IESG 2214 o Specification Document(s): this document 2216 o Parameter Name:target-prefix 2217 o CBOR Key Value: 31 2218 o CBOR Major Type: 4 2219 o Change Controller: IESG 2220 o Specification Document(s): this document 2221 o Parameter Name:client-identifier 2222 o CBOR Key Value: 32 2223 o CBOR Major Type: 2 2224 o Change Controller: IESG 2225 o Specification Document(s): this document 2227 11. Implementation Status 2229 [Note to RFC Editor: Please remove this section and reference to 2230 [RFC7942] prior to publication.] 2232 This section records the status of known implementations of the 2233 protocol defined by this specification at the time of posting of this 2234 Internet-Draft, and is based on a proposal described in [RFC7942]. 2235 The description of implementations in this section is intended to 2236 assist the IETF in its decision processes in progressing drafts to 2237 RFCs. Please note that the listing of any individual implementation 2238 here does not imply endorsement by the IETF. Furthermore, no effort 2239 has been spent to verify the information presented here that was 2240 supplied by IETF contributors. This is not intended as, and must not 2241 be construed to be, a catalog of available implementations or their 2242 features. Readers are advised to note that other implementations may 2243 exist. 2245 According to [RFC7942], "this will allow reviewers and working groups 2246 to assign due consideration to documents that have the benefit of 2247 running code, which may serve as evidence of valuable experimentation 2248 and feedback that have made the implemented protocols more mature. 2249 It is up to the individual working groups to use this information as 2250 they see fit". 2252 11.1. nttdots 2254 Organization: NTT Communication is developing a DOTS client and 2255 DOTS server software based on DOTS signal channel specified in 2256 this draft. It will be open-sourced. 2257 Description: Early implementation of DOTS protocol. It is aimed to 2258 implement a full DOTS protocol spec in accordance with maturing of 2259 DOTS protocol itself. 2260 Implementation: https://github.com/nttdots/go-dots 2261 Level of maturity: It is a early implementation of DOTS protocol. 2262 Messaging between DOTS clients and DOTS servers has been tested. 2263 Level of maturity will increase in accordance with maturing of 2264 DOTS protocol itself. 2265 Coverage: Capability of DOTS client: sending DOTS messages to the 2266 DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS 2267 server: receiving dots-signal, validating received dots-signal, 2268 starting mitigation by handing over the dots-signal to DDOS 2269 mitigator. 2270 Licensing: It will be open-sourced with BSD 3-clause license. 2271 Implementation experience: It is implemented in Go-lang. Core 2272 specification of signaling is mature to be implemented, however, 2273 finding good libraries(like DTLS, CoAP) is rather difficult. 2274 Contact: Kaname Nishizuka 2276 12. Security Considerations 2278 Authenticated encryption MUST be used for data confidentiality and 2279 message integrity. (D)TLS based on client certificate MUST be used 2280 for mutual authentication. The interaction between the DOTS agents 2281 requires Datagram Transport Layer Security (DTLS) and Transport Layer 2282 Security (TLS) with a cipher suite offering confidentiality 2283 protection and the guidance given in [RFC7525] MUST be followed to 2284 avoid attacks on (D)TLS. 2286 A single DOTS signal channel between DOTS agents can be used to 2287 exchange multiple DOTS signal messages. To reduce DOTS client and 2288 DOTS server workload, DOTS client SHOULD re-use the (D)TLS session. 2290 If TCP is used between DOTS agents, an attacker may be able to inject 2291 RST packets, bogus application segments, etc., regardless of whether 2292 TLS authentication is used. Because the application data is TLS 2293 protected, this will not result in the application receiving bogus 2294 data, but it will constitute a DoS on the connection. This attack 2295 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 2296 any bogus packets injected by an attacker will be rejected by the 2297 TCP-AO integrity check and therefore will never reach the TLS layer. 2299 In order to prevent leaking internal information outside a client- 2300 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 2301 the identity of internal DOTS clients (client-identifier) unless 2302 explicitly configured to do so. 2304 Special care should be taken in order to ensure that the activation 2305 of the proposed mechanism won't have an impact on the stability of 2306 the network (including connectivity and services delivered over that 2307 network). 2309 Involved functional elements in the cooperation system must establish 2310 exchange instructions and notification over a secure and 2311 authenticated channel. Adequate filters can be enforced to avoid 2312 that nodes outside a trusted domain can inject request such as 2313 deleting filtering rules. Nevertheless, attacks can be initiated 2314 from within the trusted domain if an entity has been corrupted. 2315 Adequate means to monitor trusted nodes should also be enabled. 2317 13. Contributors 2319 The following individuals have contributed to this document: 2321 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 2322 mgeller@cisco.com 2324 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 2325 Email: rgm@htt-consult.com 2327 Dan Wing Email: dwing-ietf@fuggles.com 2329 14. Acknowledgements 2331 Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, 2332 Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang 2333 Xia, Jon Shallow, and Gilbert Clark for the discussion and comments. 2335 15. References 2337 15.1. Normative References 2339 [I-D.ietf-core-coap-tcp-tls] 2340 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 2341 Silverajan, B., and B. Raymor, "CoAP (Constrained 2342 Application Protocol) over TCP, TLS, and WebSockets", 2343 draft-ietf-core-coap-tcp-tls-09 (work in progress), May 2344 2017. 2346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2347 Requirement Levels", BCP 14, RFC 2119, 2348 DOI 10.17487/RFC2119, March 1997, 2349 . 2351 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2352 (TLS) Protocol Version 1.2", RFC 5246, 2353 DOI 10.17487/RFC5246, August 2008, 2354 . 2356 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2357 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 2358 June 2010, . 2360 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2361 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2362 DOI 10.17487/RFC6234, May 2011, 2363 . 2365 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2366 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2367 January 2012, . 2369 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 2370 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 2371 Transport Layer Security (TLS) and Datagram Transport 2372 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 2373 June 2014, . 2375 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2376 Application Protocol (CoAP)", RFC 7252, 2377 DOI 10.17487/RFC7252, June 2014, 2378 . 2380 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2381 "Recommendations for Secure Use of Transport Layer 2382 Security (TLS) and Datagram Transport Layer Security 2383 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2384 2015, . 2386 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2387 Application Protocol (CoAP)", RFC 7641, 2388 DOI 10.17487/RFC7641, September 2015, 2389 . 2391 15.2. Informative References 2393 [I-D.ietf-core-comi] 2394 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 2395 Management Interface", draft-ietf-core-comi-01 (work in 2396 progress), July 2017. 2398 [I-D.ietf-core-yang-cbor] 2399 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 2400 Minaburo, "CBOR Encoding of Data Modeled with YANG", 2401 draft-ietf-core-yang-cbor-05 (work in progress), August 2402 2017. 2404 [I-D.ietf-dots-architecture] 2405 Mortensen, A., Andreasen, F., Reddy, T., 2406 christopher_gray3@cable.comcast.com, c., Compton, R., and 2407 N. Teague, "Distributed-Denial-of-Service Open Threat 2408 Signaling (DOTS) Architecture", draft-ietf-dots- 2409 architecture-04 (work in progress), July 2017. 2411 [I-D.ietf-dots-data-channel] 2412 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 2413 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 2414 Service Open Threat Signaling (DOTS) Data Channel", draft- 2415 ietf-dots-data-channel-04 (work in progress), October 2416 2017. 2418 [I-D.ietf-dots-requirements] 2419 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 2420 Denial of Service (DDoS) Open Threat Signaling 2421 Requirements", draft-ietf-dots-requirements-06 (work in 2422 progress), July 2017. 2424 [I-D.ietf-dots-use-cases] 2425 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 2426 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 2427 Open Threat Signaling", draft-ietf-dots-use-cases-07 (work 2428 in progress), July 2017. 2430 [I-D.ietf-tls-tls13] 2431 Rescorla, E., "The Transport Layer Security (TLS) Protocol 2432 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 2433 July 2017. 2435 [I-D.rescorla-tls-dtls13] 2436 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2437 Datagram Transport Layer Security (DTLS) Protocol Version 2438 1.3", draft-rescorla-tls-dtls13-01 (work in progress), 2439 March 2017. 2441 [proto_numbers] 2442 "IANA, "Protocol Numbers"", 2011, 2443 . 2445 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2446 DOI 10.17487/RFC0791, September 1981, 2447 . 2449 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2450 (CIDR): The Internet Address Assignment and Aggregation 2451 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2452 2006, . 2454 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 2455 Denial-of-Service Considerations", RFC 4732, 2456 DOI 10.17487/RFC4732, December 2006, 2457 . 2459 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 2460 Translation (NAT) Behavioral Requirements for Unicast 2461 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2462 2007, . 2464 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 2465 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 2466 . 2468 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2469 "Transport Layer Security (TLS) Session Resumption without 2470 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 2471 January 2008, . 2473 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2474 the Network Configuration Protocol (NETCONF)", RFC 6020, 2475 DOI 10.17487/RFC6020, October 2010, 2476 . 2478 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 2479 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2480 2012, . 2482 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 2483 "Default Address Selection for Internet Protocol Version 6 2484 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 2485 . 2487 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2488 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2489 October 2013, . 2491 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2492 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2493 . 2495 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 2496 NETCONF Protocol over Transport Layer Security (TLS) with 2497 Mutual X.509 Authentication", RFC 7589, 2498 DOI 10.17487/RFC7589, June 2015, 2499 . 2501 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 2502 Layer Security (TLS) False Start", RFC 7918, 2503 DOI 10.17487/RFC7918, August 2016, 2504 . 2506 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 2507 (TLS) Cached Information Extension", RFC 7924, 2508 DOI 10.17487/RFC7924, July 2016, 2509 . 2511 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2512 Code: The Implementation Status Section", BCP 205, 2513 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2514 . 2516 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2517 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2518 March 2017, . 2520 Authors' Addresses 2522 Tirumaleswar Reddy 2523 McAfee, Inc. 2524 Embassy Golf Link Business Park 2525 Bangalore, Karnataka 560071 2526 India 2528 Email: kondtir@gmail.com 2530 Mohamed Boucadair 2531 Orange 2532 Rennes 35000 2533 France 2535 Email: mohamed.boucadair@orange.com 2537 Prashanth Patil 2538 Cisco Systems, Inc. 2540 Email: praspati@cisco.com 2542 Andrew Mortensen 2543 Arbor Networks, Inc. 2544 2727 S. State St 2545 Ann Arbor, MI 48104 2546 United States 2548 Email: amortensen@arbor.net 2549 Nik Teague 2550 Verisign, Inc. 2551 United States 2553 Email: nteague@verisign.com