idnits 2.17.1 draft-ietf-dots-signal-channel-03.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 80 instances of too long lines in the document, the longest one being 14 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 354 has weird spacing: '...er-port ine...' == Line 355 has weird spacing: '...er-port ine...' -- The document date (August 16, 2017) is 2444 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1690, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-09 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-01 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-05 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-04 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-02 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-06 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-07 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 -- 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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair 5 Expires: February 17, 2018 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 August 16, 2017 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel 16 draft-ietf-dots-signal-channel-03 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 http://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 February 17, 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 (http://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 Model . . . . . . . . . . . . . . . . . 8 68 5.2.1. Mitigation Request Model structure . . . . . . . . . 8 69 5.2.2. Mitigation Request Model . . . . . . . . . . . . . . 8 70 5.2.3. Session Configuration Model structure . . . . . . . . 10 71 5.2.4. Session Configuration Model . . . . . . . . . . . . . 10 72 5.3. Mitigation Request . . . . . . . . . . . . . . . . . . . 12 73 5.3.1. Requesting mitigation . . . . . . . . . . . . . . . . 12 74 5.3.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 17 75 5.3.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 18 76 5.3.4. Efficacy Update from DOTS Client . . . . . . . . . . 23 77 5.4. DOTS Signal Channel Session Configuration . . . . . . . . 25 78 5.4.1. Discover Acceptable Configuration Parameters . . . . 26 79 5.4.2. Convey DOTS Signal Channel Session Configuration . . 27 80 5.4.3. Delete DOTS Signal Channel Session Configuration . . 30 81 5.4.4. Retrieving DOTS Signal Channel Session Configuration 30 82 5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 31 83 5.6. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 32 84 6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 33 85 7. (D)TLS Protocol Profile and Performance considerations . . . 34 86 7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 34 87 8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 35 88 9. Mutual Authentication of DOTS Agents & Authorization of DOTS 89 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 91 10.1. CoAP Response Code . . . . . . . . . . . . . . . . . . . 38 92 10.2. DOTS signal channel CBOR Mappings Registry . . . . . . . 38 93 10.2.1. Registration Template . . . . . . . . . . . . . . . 38 94 10.2.2. Initial Registry Contents . . . . . . . . . . . . . 39 95 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 42 96 11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 43 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 43 99 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 44 100 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 102 15.1. Normative References . . . . . . . . . . . . . . . . . . 44 103 15.2. Informative References . . . . . . . . . . . . . . . . . 45 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 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 +--------------+ 304 | DOTS | 305 +--------------+ 306 | CoAP | 307 +--------------+ 308 | TLS | DTLS | 309 +--------------+ 310 | TCP | UDP | 311 +--------------+ 312 | IP | 313 +--------------+ 315 Figure 4: Abstract Layering of DOTS signal channel over CoAP over 316 (D)TLS 318 The signal channel is initiated by the DOTS client. Once the signal 319 channel is established, the DOTS agents periodically send heartbeats 320 to keep the channel active. At any time, the DOTS client may send a 321 mitigation request message to the DOTS server over the active 322 channel. While mitigation is active, the DOTS server periodically 323 sends status messages to the client, including basic mitigation 324 feedback details. Mitigation remains active until the DOTS client 325 explicitly terminates mitigation, or the mitigation lifetime expires. 327 Messages exchanged between DOTS client and server are serialized 328 using Concise Binary Object Representation (CBOR) [RFC7049], CBOR is 329 a binary encoding designed for small code and message size. CBOR 330 encoded payloads are used to convey signal channel specific payload 331 messages that convey request parameters and response information such 332 as errors. This specification uses the encoding rules defined in 333 [I-D.ietf-core-yang-cbor] for representing mitigation scope and DOTS 334 signal channel session configuration data defined using YANG 335 (Section 5.2) as CBOR data. 337 5.2. DOTS Signal YANG Model 339 This document defines a YANG [RFC6020] data model for mitigation 340 scope and DOTS signal channel session configuration data. 342 5.2.1. Mitigation Request Model structure 344 This document defines the YANG module "ietf-dots-signal", which has 345 the following structure: 347 module: ietf-dots-signal 348 +--rw mitigation-scope 349 +--rw scope* [mitigation-id] 350 +--rw mitigation-id int32 351 +--rw target-ip* inet:ip-address 352 +--rw target-prefix* inet:ip-prefix 353 +--rw target-port-range* [lower-port upper-port] 354 | +--rw lower-port inet:port-number 355 | +--rw upper-port inet:port-number 356 +--rw target-protocol* uint8 357 +--rw fqdn* inet:domain-name 358 +--rw uri* inet:uri 359 +--rw alias* string 360 +--rw lifetime? int32 362 5.2.2. Mitigation Request Model 364 file "ietf-dots-signal@2017-08-03.yang" 366 module ietf-dots-signal { 367 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; 368 prefix "signal"; 369 import ietf-inet-types { 370 prefix "inet"; 371 } 372 organization "McAfee, Inc."; 373 contact "Konda, Tirumaleswar Reddy "; 375 description 376 "This module contains YANG definition for DOTS 377 signal sent by the DOTS client to the DOTS server."; 379 revision 2017-08-03 { 380 reference 381 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 382 } 384 container mitigation-scope { 385 description 386 "Top level container for a mitigation request."; 388 list scope { 389 key mitigation-id; 390 description "Identifier for the mitigation request."; 391 leaf mitigation-id { 392 type int32; 393 description "Mitigation request identifier."; 394 } 395 leaf-list target-ip { 396 type inet:ip-address; 397 description 398 "IPv4 or IPv6 address identifyting the target."; 399 } 401 leaf-list target-prefix { 402 type inet:ip-prefix; 403 description 404 "IPv4 or IPv6 prefix identifyting the target."; 405 } 407 list target-port-range { 408 key "lower-port upper-port"; 409 description "Port range. When only lower-port is present, 410 it represents a single port."; 412 leaf lower-port { 413 type inet:port-number; 414 mandatory true; 415 description "Lower port number."; 416 } 418 leaf upper-port { 419 type inet:port-number; 420 must ". >= ../lower-port" { 421 error-message 422 "The upper port number must be greater than or 423 equal to lower port number."; 424 } 425 description "Upper port number."; 426 } 427 } 429 leaf-list target-protocol { 430 type uint8; 431 description "Identifies the target protocol number."; 432 } 433 leaf-list fqdn { 434 type inet:domain-name; 435 description "FQDN"; 436 } 438 leaf-list uri { 439 type inet:uri; 440 description "URI"; 441 } 443 leaf-list alias { 444 type string; 445 description "alias name"; 446 } 448 leaf lifetime { 449 type int32; 450 description 451 "Indicates the lifetime of the mitigation request."; 452 } 453 } 454 } 455 } 456 458 5.2.3. Session Configuration Model structure 460 This document defines the YANG module "ietf-dots-signal-config", 461 which has the following structure: 463 module: ietf-dots-signal-config 464 +--rw signal-config 465 +--rw session-id? int32 466 +--rw heartbeat-timeout? int16 467 +--rw max-retransmit? int16 468 +--rw ack-timeout? int16 469 +--rw ack-random-factor? decimal64 470 +--rw trigger-mitigation? boolean 472 5.2.4. Session Configuration Model 474 file "ietf-dots-signal-config@2016-11-28.yang" 476 module ietf-dots-signal-config { 477 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config"; 478 prefix "config"; 480 organization "McAfee, Inc."; 481 contact "Konda, Tirumaleswar Reddy "; 483 description 484 "This module contains YANG definition for DOTS 485 signal channel session configuration."; 487 revision 2016-11-28 { 488 reference 489 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 490 } 492 container signal-config { 493 description "Top level container for DOTS signal channel session 494 configuration."; 496 leaf session-id { 497 type int32; 498 description "An identifier for the DOTS signal channel 499 session configuration data."; 500 } 502 leaf heartbeat-timeout { 503 type int16; 504 description 505 "DOTS agents regularly send heartbeats to each other 506 after mutual authentication in order to keep 507 the DOTS signal channel open."; 508 } 510 leaf max-retransmit { 511 type int16; 512 description 513 "Maximum retransmissions of a Confirmable message."; 514 } 516 leaf ack-timeout { 517 type int16; 518 description 519 "Initial retransmission timeout value."; 520 } 522 leaf ack-random-factor { 523 type decimal64 { 524 fraction-digits 2; 525 } 526 description 527 "Random factor used to influence the timing of 528 retransmissions"; 530 } 531 leaf trigger-mitigation { 532 type boolean; 533 default true; 534 description 535 "If false, then mitigation is triggered 536 only when the DOTS server channel session is lost"; 537 } 538 } 539 } 541 543 5.3. Mitigation Request 545 The following methods are used to request or withdraw mitigation 546 requests: 548 PUT: DOTS clients use the PUT method to request mitigation 549 (Section 5.3.1). During active mitigation, DOTS clients may use 550 PUT requests to convey mitigation efficacy updates to the DOTS 551 server (Section 5.3.4). 553 DELETE: DOTS clients use the DELETE method to withdraw a request for 554 mitigation from the DOTS server (Section 5.3.2). 556 GET: DOTS clients may use the GET method to subscribe to DOTS server 557 status messages, or to retrieve the list of existing mitigations 558 (Section 5.3.3). 560 Mitigation request and response messages are marked as Non- 561 confirmable messages. DOTS agents should follow the data 562 transmission guidelines discussed in Section 3.1.3 of [RFC8085] and 563 control transmission behavior by not sending on average more than one 564 UDP datagram per RTT to the peer DOTS agent. Requests marked by the 565 DOTS client as Non-confirmable messages are sent at regular intervals 566 until a response is received from the DOTS server and if the DOTS 567 client cannot maintain a RTT estimate then it SHOULD NOT send more 568 than one Non-confirmable request every 3 seconds, and SHOULD use an 569 even less aggressive rate when possible (case 2 in Section 3.1.3 of 570 [RFC8085]). 572 5.3.1. Requesting mitigation 574 When a DOTS client requires mitigation for any reason, the DOTS 575 client uses CoAP PUT method to send a mitigation request to the DOTS 576 server (Figure 5, illustrated in JSON diagnostic notation). The DOTS 577 server can enable mitigation on behalf of the DOTS client by 578 communicating the DOTS client's request to the mitigator and relaying 579 selected mitigator feedback to the requesting DOTS client. 581 Header: PUT (Code=0.03) 582 Uri-Host: "host" 583 Uri-Path: "version" 584 Uri-Path: "dots-signal" 585 Uri-Path: "signal" 586 Content-Type: "application/cbor" 587 { 588 "mitigation-scope": { 589 "scope": [ 590 { 591 "mitigation-id": integer, 592 "target-ip": [ 593 "string" 594 ], 595 "target-prefix": [ 596 "string" 597 ], 598 "target-port-range": [ 599 { 600 "lower-port": integer, 601 "upper-port": integer 602 } 603 ], 604 "target-protocol": [ 605 integer 606 ], 607 "fqdn": [ 608 "string" 609 ], 610 "uri": [ 611 "string" 612 ], 613 "alias": [ 614 "string" 615 ], 616 "lifetime": integer 617 } 618 ] 619 } 620 } 622 Figure 5: PUT to convey DOTS signals 624 The parameters are described below. 626 mitigation-id: Identifier for the mitigation request represented 627 using an integer. This identifier MUST be unique for each 628 mitigation request bound to the DOTS client, i.e., the mitigation- 629 id parameter value in the mitigation request needs to be unique 630 relative to the mitigation-id parameter values of active 631 mitigation requests conveyed from the DOTS client to the DOTS 632 server. This identifier MUST be generated by the DOTS client. 633 This document does not make any assumption about how this 634 identifier is generated. This is a mandatory attribute. 636 target-ip: A list of IP addresses under attack. This is an optional 637 attribute. 639 target-prefix: A list of prefixes under attack. Prefixes are 640 represented using CIDR notation [RFC4632]. This is an optional 641 attribute. 643 target-port-range: A list of ports under attack. The port range, 644 lower-port for lower port number and upper-port for upper port 645 number. When only lower-port is present, it represents a single 646 port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g., 647 1024-65535). This is an optional attribute. 649 target-protocol: A list of protocols under attack. Values are taken 650 from the IANA protocol registry [proto_numbers]. The value 0 has 651 a special meaning for 'all protocols'. This is an optional 652 attribute. 654 fqdn: A list of Fully Qualified Domain Names. Fully Qualified 655 Domain Name (FQDN) is the full name of a system, rather than just 656 its hostname. For example, "venera" is a hostname, and 657 "venera.isi.edu" is an FQDN. This is an optional attribute. 659 uri: A list of Uniform Resource Identifiers (URI). This is an 660 optional attribute. 662 alias: A list of aliases. Aliases can be created using the DOTS 663 data channel (Section 3.1.1 in [I-D.ietf-dots-data-channel]) or 664 direct configuration, or other means and then used in subsequent 665 signal channel exchanges to refer more efficiently to the 666 resources under attack. This is an optional attribute. 668 lifetime: Lifetime of the mitigation request in seconds. Upon the 669 expiry of this lifetime, and if the request is not refreshed, the 670 mitigation request is removed. The request can be refreshed by 671 sending the same request again. The default lifetime of the 672 mitigation request is 3600 seconds (60 minutes) -- this value was 673 chosen to be long enough so that refreshing is not typically a 674 burden on the DOTS client, while expiring the request where the 675 client has unexpectedly quit in a timely manner. A lifetime of 676 negative one (-1) indicates indefinite lifetime for the mitigation 677 request. The server MUST always indicate the actual lifetime in 678 the response and the remaining lifetime in status messages sent to 679 the client. This is an optional attribute in the request. 681 The CBOR key values for the parameters are defined in Section 6. The 682 IANA Considerations section defines how the CBOR key values can be 683 allocated to standards bodies and vendors. FQDN and URI mitigation 684 scopes may be thought of as a form of scope alias, in which the 685 addresses to which the domain name or URI resolve represent the full 686 scope of the mitigation. In the PUT request at least one of the 687 attributes target-ip or target-prefix or fqdn or uri or alias MUST be 688 present. DOTS agents can safely ignore Vendor-Specific parameters 689 they don't understand. The relative order of two mitigation requests 690 from a DOTS client is determined by comparing their respective 691 mitigation-id values. If two mitigation requests have overlapping 692 mitigation scopes the mitigation request with higher numeric 693 mitigation-id value will override the mitigation request with a lower 694 numeric mitigation-id value. The Uri-Path option carries a major and 695 minor version nomenclature to manage versioning and DOTS signal 696 channel in this specification uses v1 major version. 698 In both DOTS signal and data channel sessions, the DOTS client MUST 699 authenticate itself to the DOTS server (Section 9). The DOTS server 700 can use the algorithm discussed in Section 7 of [RFC7589] to derive 701 the DOTS client identity or username from the client certificate. 702 The DOTS server couples the DOTS signal and data channel sessions 703 using the DOTS client identity, so the DOTS server can validate 704 whether the aliases conveyed in the mitigation request were indeed 705 created by the same DOTS client using the DOTS data channel session. 706 If the aliases were not created by the DOTS client then the DOTS 707 server returns 4.00 (Bad Request) in the response. The DOTS server 708 couples the DOTS signal channel sessions using the DOTS client 709 identity, and the DOTS server uses mitigation-id parameter value to 710 detect duplicate mitigation requests. If the mitigation request 711 contains both alias and other parameters identifying the target 712 resource (such as, target-ip, target-prefix, target-port-range, fqdn, 713 or uri) then the DOTS server appends the parameter values in alias 714 with the corresponding parameter values in target-ip, target-prefix, 715 target-port-range, fqdn, or uri. 717 Figure 6 shows a PUT request example to signal that ports 80, 8080, 718 and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are 719 being attacked (illustrated in JSON diagnostic notation). 721 Header: PUT (Code=0.03) 722 Uri-Host: "www.example.com" 723 Uri-Path: "v1" 724 Uri-Path: "dots-signal" 725 Uri-Path: "signal" 726 Content-Format: "application/cbor" 727 { 728 "mitigation-scope": { 729 "scope": [ 730 { 731 "mitigation-id": 12332, 732 "target-ip": [ 733 "2001:db8:6401::1", 734 "2001:db8:6401::2" 735 ], 736 "target-port-range": [ 737 { 738 "lower-port": 80 739 }, 740 { 741 "lower-port": 443 742 }, 743 { 744 "lower-port": 8080 745 } 746 ], 747 "target-protocol": [ 748 6 749 ] 750 } 751 ] 752 } 753 } 755 The CBOR encoding format is shown below: 757 a1 # map(1) 758 01 # unsigned(1) 759 a1 # map(1) 760 02 # unsigned(2) 761 81 # array(1) 762 a4 # map(4) 763 03 # unsigned(3) 764 19 302c # unsigned(12332) 765 04 # unsigned(4) 766 82 # array(2) 767 70 # text(16) 768 323030313A6462383A363430313A3A31 # "2001:db8:6401::1" 769 70 # text(16) 770 323030313A6462383A363430313A3A32 # "2001:db8:6401::2" 771 05 # unsigned(5) 772 83 # array(3) 773 a1 # map(1) 774 06 # unsigned(6) 775 18 50 # unsigned(80) 776 a1 # map(1) 777 06 # unsigned(6) 778 19 01bb # unsigned(443) 779 a1 # map(1) 780 06 # unsigned(6) 781 19 1f90 # unsigned(8080) 782 08 # unsigned(8) 783 81 # array(1) 784 06 # unsigned(6) 786 Figure 6: PUT for DOTS signal 788 The DOTS server indicates the result of processing the PUT request 789 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 790 codes are some sort of invalid requests. COAP 5.xx codes are 791 returned if the DOTS server has erred or is currently unavailable to 792 provide mitigation in response to the mitigation request from the 793 DOTS client. If the DOTS server does not find the mitigation-id 794 parameter value conveyed in the PUT request in its configuration data 795 then the server MAY accept the mitigation request, and a 2.01 796 (Created) response is returned to the DOTS client, and the DOTS 797 server will try to mitigate the attack. If the DOTS server finds the 798 mitigation-id parameter value conveyed in the PUT request in its 799 configuration data then the server MAY update the mitigation request, 800 and a 2.04 (Changed) response is returned to indicate a successful 801 update of the mitigation request. If the request is missing one or 802 more mandatory attributes, then 4.00 (Bad Request) will be returned 803 in the response or if the request contains invalid or unknown 804 parameters then 4.02 (Invalid query) will be returned in the 805 response. For responses indicating a client or server error, the 806 payload explains the error situation of the result of the requested 807 action (Section 5.5 in [RFC7252]). 809 5.3.2. Withdraw a DOTS Signal 811 A DELETE request is used to withdraw a DOTS signal from a DOTS server 812 (Figure 7). 814 Header: DELETE (Code=0.04) 815 Uri-Host: "host" 816 Uri-Path: "version" 817 Uri-Path: "dots-signal" 818 Uri-Path: "signal" 819 Content-Format: "application/cbor" 820 { 821 "mitigation-scope": { 822 "scope": [ 823 { 824 "mitigation-id": integer 825 } 826 ] 827 } 828 } 830 Figure 7: Withdraw DOTS signal 832 The DOTS server immediately acknowledges a DOTS client's request to 833 withdraw the DOTS signal using 2.02 (Deleted) response code. A 2.02 834 (Deleted) Response Code is returned even if the mitigation-id 835 parameter value conveyed in the DELETE request does not exist in its 836 configuration data before the request. If the DOTS server finds the 837 mitigation-id parameter value conveyed in the DELETE request in its 838 configuration data, then to protect against route or DNS flapping 839 caused by a client rapidly toggling mitigation, and to dampen the 840 effect of oscillating attacks, DOTS servers MAY allow mitigation to 841 continue for a limited period after acknowledging a DOTS client's 842 withdrawal of a mitigation request. During this period, DOTS server 843 status messages SHOULD indicate that mitigation is active but 844 terminating. The active-but-terminating period is initially 30 845 seconds. If the client requests mitigation again before that 30 846 second window elapses, the DOTS server MAY exponentially increase the 847 active- but-terminating period up to a maximum of 240 seconds (4 848 minutes). After the active-but-terminating period elapses, the DOTS 849 server MUST treat the mitigation as terminated, as the DOTS client is 850 no longer responsible for the mitigation. For example, if there is a 851 financial relationship between the DOTS client and server domains, 852 the DOTS client ceases incurring cost at this point. 854 5.3.3. Retrieving a DOTS Signal 856 A GET request is used to retrieve information and status of a DOTS 857 signal from a DOTS server (Figure 8). If the DOTS server does not 858 find the mitigation-id parameter value conveyed in the GET request in 859 its configuration data, then it responds with a 4.04 (Not Found) 860 error response code. The 'c' (content) parameter and its permitted 861 values defined in [I-D.ietf-core-comi] can be used to retrieve non- 862 configuration data or configuration data or both. 864 1) To retrieve all DOTS signals signaled by the DOTS client. 866 Header: GET (Code=0.01) 867 Uri-Host: "host" 868 Uri-Path: "version" 869 Uri-Path: "dots-signal" 870 Uri-Path: "signal" 871 Observe : 0 873 2) To retrieve a specific DOTS signal signaled by the DOTS client. 874 The configuration data in the response will be formatted in the 875 same order it was processed at the DOTS server. 877 Header: GET (Code=0.01) 878 Uri-Host: "host" 879 Uri-Path: "version" 880 Uri-Path: "dots-signal" 881 Uri-Path: "signal" 882 Observe : 0 883 Content-Format: "application/cbor" 884 { 885 "mitigation-scope": { 886 "scope": [ 887 { 888 "mitigation-id": integer 889 } 890 ] 891 } 892 } 894 Figure 8: GET to retrieve the rules 896 Figure 9 shows a response example of all the active mitigation 897 requests associated with the DOTS client on the DOTS server and the 898 mitigation status of each mitigation request. 900 { 901 "mitigation-scope":[ 902 { 903 "scope": [ 904 { 905 "mitigation-id": 12332, 906 "target-protocol": [ 907 17 908 ], 909 "lifetime":1800, 910 "status":2, 911 "bytes-dropped": 134334555, 912 "bps-dropped": 43344, 913 "pkts-dropped": 333334444, 914 "pps-dropped": 432432 915 } 916 ] 917 }, 918 { 919 "scope": [ 920 { 921 "mitigation-id": 12333, 922 "target-protocol": [ 923 6 924 ], 925 "lifetime":1800, 926 "status":3 927 "bytes-dropped": 0, 928 "bps-dropped": 0, 929 "pkts-dropped": 0, 930 "pps-dropped": 0 931 } 932 ] 933 } 934 ] 935 } 937 Figure 9: Response body 939 The mitigation status parameters are described below. 941 bytes-dropped: The total dropped byte count for the mitigation 942 request. This is a optional attribute. 944 bps-dropped: The average dropped bytes per second for the mitigation 945 request. This is a optional attribute. 947 pkts-dropped: The total dropped packet count for the mitigation 948 request. This is a optional attribute. 950 pps-dropped: The average dropped packets per second for the 951 mitigation request. This is a optional attribute. 953 status: Status of attack mitigation. The 'status' parameter is a 954 mandatory attribute. 956 The various possible values of 'status' parameter are explained 957 below: 959 /--------------------+---------------------------------------------------\ 960 | Parameter value | Description | 961 |--------------------+---------------------------------------------------| 962 | 1 | Attack mitigation is in progress | 963 | | (e.g., changing the network path to re-route the | 964 | | inbound traffic to DOTS mitigator). | 965 +------------------------------------------------------------------------+ 966 | 2 | Attack is successfully mitigated | 967 | | (e.g., traffic is redirected to a DDOS mitigator | 968 | | and attack traffic is dropped). | 969 +------------------------------------------------------------------------+ 970 | 3 | Attack has stopped and the DOTS client | 971 | | can withdraw the mitigation request. | 972 +------------------------------------------------------------------------+ 973 | 4 | Attack has exceeded the mitigation provider | 974 | | capability. | 975 +------------------------------------------------------------------------+ 976 | 5 | DOTS client has withdrawn the mitigation request | 977 and the mitigation is active but terminating. | 978 | | | 979 \--------------------+---------------------------------------------------/ 981 The observe option defined in [RFC7641] extends the CoAP core 982 protocol with a mechanism for a CoAP client to "observe" a resource 983 on a CoAP server: the client retrieves a representation of the 984 resource and requests this representation be updated by the server as 985 long as the client is interested in the resource. A DOTS client 986 conveys the observe option set to 0 in the GET request to receive 987 unsolicited notifications of attack mitigation status from the DOTS 988 server. Unidirectional notifications within the bidirectional signal 989 channel allows unsolicited message delivery, enabling asynchronous 990 notifications between the agents. A DOTS client that is no longer 991 interested in receiving notifications from the DOTS server can simply 992 "forget" the observation. When the DOTS server then sends the next 993 notification, the DOTS client will not recognize the token in the 994 message and thus will return a Reset message. This causes the DOTS 995 server to remove the associated entry. Alternatively, the DOTS 996 client can explicitly deregister by issuing a GET request that has 997 the Token field set to the token of the observation to be cancelled 998 and includes an Observe Option with the value set to 1 (deregister). 1000 DOTS Client DOTS Server 1001 | | 1002 | GET / | 1003 | Token: 0x4a | Registration 1004 | Observe: 0 | 1005 +------------------------------>| 1006 | | 1007 | 2.05 Content | 1008 | Token: 0x4a | Notification of 1009 | Observe: 12 | the current state 1010 | status: "mitigation | 1011 | in progress" | 1012 |<------------------------------+ 1013 | 2.05 Content | 1014 | Token: 0x4a | Notification upon 1015 | Observe: 44 | a state change 1016 | status: "mitigation | 1017 | complete" | 1018 |<------------------------------+ 1019 | 2.05 Content | 1020 | Token: 0x4a | Notification upon 1021 | Observe: 60 | a state change 1022 | status: "attack stopped" | 1023 |<------------------------------+ 1024 | | 1026 Figure 10: Notifications of attack mitigation status 1028 5.3.3.1. Mitigation Status 1030 A DOTS client retrieves the information about a DOTS signal at 1031 frequent intervals to determine the status of an attack. If the DOTS 1032 server has been able to mitigate the attack and the attack has 1033 stopped, the DOTS server indicates as such in the status, and the 1034 DOTS client recalls the mitigation request. 1036 A DOTS client should react to the status of the attack from the DOTS 1037 server and not the fact that it has recognized, using its own means, 1038 that the attack has been mitigated. This ensures that the DOTS 1039 client does not recall a mitigation request in a premature fashion 1040 because it is possible that the DOTS client does not sense the DDOS 1041 attack on its resources but the DOTS server could be actively 1042 mitigating the attack and the attack is not completely averted. 1044 5.3.4. Efficacy Update from DOTS Client 1046 While DDoS mitigation is active, a DOTS client MAY frequently 1047 transmit DOTS mitigation efficacy updates to the relevant DOTS 1048 server. An PUT request (Figure 11) is used to convey the mitigation 1049 efficacy update to the DOTS server. The PUT request MUST include all 1050 the parameters used in the PUT request to convey the DOTS signal 1051 (Section 5.3.1). The If-Match Option (Section 5.10.8.1 of [RFC7252]) 1052 with an empty value is used to make the PUT request conditional on 1053 the current existence of the mitigation request. If UDP is used as 1054 transport, CoAP requests may arrive out-of-order. For example, the 1055 DOTS client may send a PUT request to convey efficacy update to the 1056 DOTS server followed by a DELETE request to withdraw the mitigation 1057 request, but DELETE request arrives at the DOTS server before the PUT 1058 request. To handle out-of-order delivery of requests, if an If-Match 1059 option is present in the PUT request and the mitigation-id in the 1060 request matches a mitigation request from the DOTS client then the 1061 request is processed, and if no match is found then the PUT request 1062 is silently ignored. 1064 Header: PUT (Code=0.03) 1065 Uri-Host: "host" 1066 Uri-Path: "version" 1067 Uri-Path: "dots-signal" 1068 Uri-Path: "signal" 1069 Content-Format: "application/cbor" 1070 { 1071 "mitigation-scope": { 1072 "scope": [ 1073 { 1074 "mitigation-id": integer, 1075 "target-ip": [ 1076 "string" 1077 ], 1078 "target-port-range": [ 1079 { 1080 "lower-port": integer, 1081 "upper-port": integer 1082 } 1083 ], 1084 "target-protocol": [ 1085 integer 1086 ], 1087 "fqdn": [ 1088 "string" 1089 ], 1090 "uri": [ 1091 "string" 1092 ], 1093 "alias": [ 1094 "string" 1095 ], 1096 "lifetime": integer, 1097 "attack-status": integer 1098 } 1099 ] 1100 } 1101 } 1103 Figure 11: Efficacy Update 1105 The 'attack-status' parameter is a mandatory attribute. The various 1106 possible values contained in the 'attack-status' parameter are 1107 explained below: 1109 /--------------------+------------------------------------------------------\ 1110 | Parameter value | Description | 1111 |--------------------+------------------------------------------------------| 1112 | 1 | DOTS client determines that it is still under attack.| 1113 +---------------------------------------------------------------------------+ 1114 | 2 | DOTS client determines that the attack is | 1115 | | successfully mitigated | 1116 | | (e.g., attack traffic is not seen). | 1117 \--------------------+------------------------------------------------------/ 1119 The DOTS server indicates the result of processing the PUT request 1120 using CoAP response codes. The response code 2.04 (Changed) will be 1121 returned in the response if the DOTS server has accepted the 1122 mitigation efficacy update. The 5.xx response codes are returned if 1123 the DOTS server has erred or is incapable of performing the 1124 mitigation. 1126 5.4. DOTS Signal Channel Session Configuration 1128 The DOTS client can negotiate, configure and retrieve the DOTS signal 1129 channel session behavior. The DOTS signal channel can be used, for 1130 example, to configure the following: 1132 a. Heartbeat timeout: DOTS agents regularly send heartbeats (Ping/ 1133 Pong) to each other after mutual authentication in order to keep 1134 the DOTS signal channel open, heartbeat timeout is the time to 1135 wait for a Pong in milliseconds. 1137 b. Acceptable signal loss ratio: Maximum retransmissions, 1138 retransmission timeout value and other message transmission 1139 parameters for the DOTS signal channel. 1141 Reliability is provided to requests and responses by marking them as 1142 Confirmable (CON) messages. DOTS signal channel session 1143 configuration requests and responses are marked as Confirmable (CON) 1144 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1145 message is retransmitted using a default timeout and exponential 1146 back-off between retransmissions, until the DOTS server sends an 1147 Acknowledgement message (ACK) with the same Message ID conveyed from 1148 the DOTS client. Message transmission parameters are defined in 1149 Section 4.8 of [RFC7252]. Reliability is provided to the responses 1150 by marking them as Confirmable (CON) messages. The DOTS server can 1151 either piggyback the response in the acknowledgement message or if 1152 the DOTS server is not able to respond immediately to a request 1153 carried in a Confirmable message, it simply responds with an Empty 1154 Acknowledgement message so that the DOTS client can stop 1155 retransmitting the request. Empty Acknowledgement message is 1156 explained in Section 2.2 of [RFC7252]. When the response is ready, 1157 the server sends it in a new Confirmable message which then in turn 1158 needs to be acknowledged by the DOTS client (see Sections 5.2.1 and 1159 Sections 5.2.2 in [RFC7252]). Requests and responses exchanged 1160 between DOTS agents during peacetime are marked as Confirmable 1161 messages. 1163 Implementation Note: A DOTS client that receives a response in a CON 1164 message may want to clean up the message state right after sending 1165 the ACK. If that ACK is lost and the DOTS server retransmits the 1166 CON, the DOTS client may no longer have any state to which to 1167 correlate this response, making the retransmission an unexpected 1168 message; the DOTS client will send a Reset message so it does not 1169 receive any more retransmissions. This behavior is normal and not an 1170 indication of an error (see Section 5.3.2 in [RFC7252] for more 1171 details). 1173 5.4.1. Discover Acceptable Configuration Parameters 1175 A GET request is used to obtain acceptable configuration parameters 1176 on the DOTS server for DOTS signal channel session configuration. 1177 Figure 12 shows how to obtain acceptable configuration parameters for 1178 the server. 1180 Header: GET (Code=0.01) 1181 Uri-Host: "host" 1182 Uri-Path: "version" 1183 Uri-Path: "dots-signal" 1184 Uri-Path: "config" 1186 Figure 12: GET to retrieve configuration 1188 The DOTS server in the 2.05 (Content) response conveys the minimum 1189 and maximum attribute values acceptable by the DOTS server. 1191 Content-Format: "application/cbor" 1192 { 1193 "heartbeat-timeout": {"MinValue": integer, "MaxValue" : integer}, 1194 "max-retransmit": {"MinValue": integer, "MaxValue" : integer}, 1195 "ack-timeout": {"MinValue": integer, "MaxValue" : integer}, 1196 "ack-random-factor": {"MinValue": number, "MaxValue" : number} 1197 } 1199 Figure 13: GET response body 1201 5.4.2. Convey DOTS Signal Channel Session Configuration 1203 A PUT request is used to convey the configuration parameters for the 1204 signaling channel (e.g., heartbeat timeout, maximum retransmissions 1205 etc). Message transmission parameters for CoAP are defined in 1206 Section 4.8 of [RFC7252]. The RECOMMENDED values of transmission 1207 parameter values are ack_timeout (2 seconds), max-retransmit (7), 1208 ack-random-factor (1.5) and heartbeat-timeout (371 seconds). The 1209 heartbeat-timeout value is equal to the MAX_TRANSMIT_WAIT counter 1210 (Section 4.8.2 in [RFC7252]) whose value is derived from transmission 1211 parameters. If the DOTS agent wishes to change the default values of 1212 message transmission parameters then it should follow the guidance 1213 given in Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the 1214 negotiated values for message transmission parameters and default 1215 values for non-negotiated message transmission parameters. The 1216 signaling channel session configuration is applicable to a single 1217 DOTS signal channel session between the DOTS agents. 1219 Header: PUT (Code=0.03) 1220 Uri-Host: "host" 1221 Uri-Path: "version" 1222 Uri-Path: "dots-signal" 1223 Uri-Path: "config" 1224 Content-Format: "application/cbor" 1225 { 1226 "signal-config": { 1227 "session-id": integer, 1228 "heartbeat-timeout": integer, 1229 "max-retransmit": integer, 1230 "ack-timeout": integer, 1231 "ack-random-factor": number 1232 "trigger-mitigation": boolean 1233 } 1234 } 1236 Figure 14: PUT to convey the DOTS signal channel session 1237 configuration data. 1239 The parameters are described below: 1241 session-id: Identifier for the DOTS signal channel session 1242 configuration data represented as an integer. This identifier 1243 MUST be generated by the DOTS client. This document does not make 1244 any assumption about how this identifier is generated. This is a 1245 mandatory attribute. 1247 heartbeat-timeout: Heartbeat timeout is the time to wait for a 1248 response in milliseconds to check the DOTS peer health. This is 1249 an optional attribute. 1251 max-retransmit: Maximum number of retransmissions for a message 1252 (referred to as MAX_RETRANSMIT parameter in CoAP). This is an 1253 optional attribute. 1255 ack-timeout: Timeout value in seconds used to calculate the initial 1256 retransmission timeout value (referred to as ACK_TIMEOUT parameter 1257 in CoAP). This is an optional attribute. 1259 ack-random-factor: Random factor used to influence the timing of 1260 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1261 CoAP). This is an optional attribute. 1263 trigger-mitigation: If the parameter value is set to 'false', then 1264 DDoS mitigation is triggered only when the DOTS signal channel 1265 session is lost. Automated mtigation on loss of signal is 1266 discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. If 1267 the DOTS client ceases to respond to heartbeat messages, then the 1268 DOTS server can detect that the DOTS session is lost. The default 1269 value of the parameter is 'true'. This is an optional attribute. 1271 In the PUT request at least one of the attributes heartbeat-timeout, 1272 max-retransmit, ack-timeout, ack-random-factor, and trigger- 1273 mitigation MUST be present. The PUT request with higher numeric 1274 session-id value over-rides the DOTS signal channel session 1275 configuration data installed by a PUT request with a lower numeric 1276 session-id value. 1278 Figure 15 shows a PUT request example to convey the configuration 1279 parameters for the DOTS signal channel. 1281 Header: PUT (Code=0.03) 1282 Uri-Host: "www.example.com" 1283 Uri-Path: "v1" 1284 Uri-Path: "dots-signal" 1285 Uri-Path: "config" 1286 Content-Format: "application/cbor" 1287 { 1288 "signal-config": { 1289 "session-id": 1234534333242, 1290 "heartbeat-timeout": 30, 1291 "max-retransmit": 7, 1292 "ack-timeout": 5, 1293 "ack-random-factor": 1.5, 1294 "trigger-mitigation": false 1295 } 1296 } 1298 Figure 15: PUT to convey the configuration parameters 1300 The DOTS server indicates the result of processing the PUT request 1301 using CoAP response codes. The CoAP response will include the CBOR 1302 body received in the request. If the DOTS server finds the session- 1303 id parameter value conveyed in the PUT request in its configuration 1304 data and if the DOTS server has accepted the updated configuration 1305 parameters then the a 2.04 (Changed) response will be returned in the 1306 response. If the DOTS server does not find the session-id parameter 1307 value conveyed in the PUT request in its configuration data and if 1308 the DOTS server has accepted the configuration parameters then a 1309 response code 2.01 (Created) will be returned in the response. If 1310 the request is missing one or more mandatory attributes then 4.00 1311 (Bad Request) will be returned in the response or if the request 1312 contains invalid or unknown parameters then 4.02 (Invalid query) will 1313 be returned in the response. Response code 4.22 (Unprocessable 1314 Entity) will be returned in the response if any of the heartbeat- 1315 timeout, max-retransmit, target-protocol, ack-timeout and ack-random- 1316 factor attribute values is not acceptable to the DOTS server. The 1317 DOTS server in the error response conveys the minimum and maximum 1318 attribute values acceptable by the DOTS server. The DOTS client can 1319 re-try and send the PUT request with updated attribute values 1320 acceptable to the DOTS server. 1322 Content-Format: "application/cbor" 1323 { 1324 "heartbeat-timeout": {"MinValue": 15, "MaxValue" : 60}, 1325 "max-retransmit": {"MinValue": 3, "MaxValue" : 15}, 1326 "ack-timeout": {"MinValue": 1, "MaxValue" : 30}, 1327 "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0} 1328 } 1330 Figure 16: Error response body 1332 5.4.3. Delete DOTS Signal Channel Session Configuration 1334 A DELETE request is used to delete the installed DOTS signal channel 1335 session configuration data (Figure 17). 1337 Header: DELETE (Code=0.04) 1338 Uri-Host: "host" 1339 Uri-Path: "version" 1340 Uri-Path: "dots-signal" 1341 Uri-Path: "config" 1342 Content-Format: "application/cbor" 1343 { 1344 "signal-config": { 1345 "session-id": integer 1346 } 1347 } 1349 Figure 17: DELETE configuration 1351 If the DOTS server does not find the session-id parameter value 1352 conveyed in the DELETE request in its configuration data, then it 1353 responds with a 4.04 (Not Found) error response code. The DOTS 1354 server successfully acknowledges a DOTS client's request to remove 1355 the DOTS signal channel session configuration using 2.02 (Deleted) 1356 response code. 1358 5.4.4. Retrieving DOTS Signal Channel Session Configuration 1360 A GET request is used to retrieve the installed DOTS signal channel 1361 session configuration data from a DOTS server. Figure 18 shows how 1362 to retrieve the DOTS signal channel session configuration data. 1364 Header: GET (Code=0.01) 1365 Uri-Host: "host" 1366 Uri-Path: "version" 1367 Uri-Path: "dots-signal" 1368 Uri-Path: "config" 1369 Content-Format: "application/cbor" 1370 { 1371 "signal-config": { 1372 "session-id": integer 1373 } 1374 } 1376 Figure 18: GET to retrieve configuration 1378 5.5. Redirected Signaling 1380 Redirected Signaling is discussed in detail in Section 3.2.2 of 1381 [I-D.ietf-dots-architecture]. If the DOTS server wants to redirect 1382 the DOTS client to an alternative DOTS server for a signaling session 1383 then the response code 3.00 (alternate server) will be returned in 1384 the response to the client. The DOTS server can return the error 1385 response code 3.00 in response to a PUT request from the DOTS client 1386 or convey the error response code 3.00 in a unidirectional 1387 notification response from the DOTS server. 1389 The DOTS server in the error response conveys the alternate DOTS 1390 server FQDN, and the alternate DOTS server IP addresses and time to 1391 live values in the CBOR body. 1393 { 1394 "alt-server": "string", 1395 "alt-server-record": [ 1396 { 1397 "addr": "string", 1398 "ttl" : integer, 1399 } 1400 ] 1401 } 1403 Figure 19: Error response body 1405 The parameters are described below: 1407 alt-server: FQDN of an alternate DOTS server. 1409 addr: IP address of an alternate DOTS server. 1411 ttl: Time to live (TTL) represented as an integer number of seconds. 1413 Figure 20 shows a 3.00 response example to convey the DOTS alternate 1414 server www.example-alt.com, its IP addresses 2001:db8:6401::1 and 1415 2001:db8:6401::2, and TTL values 3600 and 1800. 1417 { 1419 "alt-server": "www.example-alt.com", 1420 "alt-server-record": [ 1421 { 1422 "ttl" : 3600, 1423 "addr": "2001:db8:6401::1" 1424 }, 1425 { 1426 "ttl" : 1800, 1427 "addr": "2001:db8:6401::2" 1428 } 1429 ] 1430 } 1432 Figure 20: Example of error response body 1434 When the DOTS client receives 3.00 response, it considers the current 1435 request as having failed, but SHOULD try the request with the 1436 alternate DOTS server. During a DDOS attack, the DNS server may be 1437 subjected to DDOS attack, alternate DOTS server IP addresses conveyed 1438 in the 3.00 response help the DOTS client to skip DNS lookup of the 1439 alternate DOTS server and can try to establish UDP or TCP session 1440 with the alternate DOTS server IP addresses. The DOTS client SHOULD 1441 implement DNS64 function to handle the scenario where IPv6-only DOTS 1442 client communicates with IPv4-only alternate DOTS server. 1444 5.6. Heartbeat Mechanism 1446 To provide a metric of signal health and distinguish an 'idle' signal 1447 channel from a 'disconnected' or 'defunct' session, the DOTS agent 1448 sends a heartbeat over the signal channel to maintain its half of the 1449 channel. The DOTS agent similarly expects a heartbeat from its peer 1450 agent, and may consider a session terminated in the extended absence 1451 of a peer agent heartbeat. While the communication between the DOTS 1452 agents is quiescent, the DOTS client will probe the DOTS server to 1453 ensure it has maintained cryptographic state and vice versa. Such 1454 probes can also keep alive firewall and/or NAT bindings. This 1455 probing reduces the frequency of establishing a new handshake when a 1456 DOTS signal needs to be conveyed to the DOTS server. In DOTS over 1457 UDP, heartbeat messages can be exchanged between the DOTS agents 1458 using the "COAP ping" mechanism (Section 4.2 in [RFC7252]). The DOTS 1459 agent sends an Empty Confirmable message and the peer DOTS agent will 1460 respond by sending an Reset message. In DOTS over TCP, heartbeat 1461 messages can be exchanged between the DOTS agents using the Ping and 1462 Pong messages (Section 4.4 in [I-D.ietf-core-coap-tcp-tls]). The 1463 DOTS agent sends a Ping message and the peer DOTS agent would respond 1464 by sending a single Pong message. 1466 6. Mapping parameters to CBOR 1468 All parameters in DOTS signal channel are mapped to CBOR types as 1469 follows and are given an integer key value to save space. 1471 /--------------------+------------------------+--------------------------\ 1472 | Parameter name | CBOR key | CBOR major type of value | 1473 |--------------------+------------------------+--------------------------| 1474 | mitigation-scope | 1 | 5 (map) | 1475 | scope | 2 | 5 (map) | 1476 | mitigation-id | 3 | 0 (unsigned) | 1477 | target-ip | 4 | 4 (array) | 1478 | target-port-range | 5 | 4 | 1479 | lower-port | 6 | 0 | 1480 | upper-port | 7 | 0 | 1481 | target-protocol | 8 | 4 | 1482 | fqdn | 9 | 4 | 1483 | uri | 10 | 4 | 1484 | alias | 11 | 4 | 1485 | lifetime | 12 | 0 | 1486 | attack-status | 13 | 0 | 1487 | signal-config | 14 | 5 | 1488 | heartbeat-timeout | 15 | 0 | 1489 | max-retransmit | 16 | 0 | 1490 | ack-timeout | 17 | 0 | 1491 | ack-random-factor | 18 | 7 | 1492 | MinValue | 19 | 0 | 1493 | MaxValue | 20 | 0 | 1494 | status | 21 | 0 | 1495 | bytes-dropped | 22 | 0 | 1496 | bps-dropped | 23 | 0 | 1497 | pkts-dropped | 24 | 0 | 1498 | pps-dropped | 25 | 0 | 1499 | session-id | 26 | 0 | 1500 | trigger-mitigation | 27 | 7 (simple types) | 1501 \--------------------+------------------------+--------------------------/ 1503 Figure 21: CBOR mappings used in DOTS signal channel message 1505 7. (D)TLS Protocol Profile and Performance considerations 1507 This section defines the (D)TLS protocol profile of DOTS signal 1508 channel over (D)TLS and DOTS data channel over TLS. 1510 There are known attacks on (D)TLS, such as machine-in-the-middle and 1511 protocol downgrade. These are general attacks on (D)TLS and not 1512 specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for 1513 discussion of these security issues. DOTS agents MUST adhere to the 1514 (D)TLS implementation recommendations and security considerations of 1515 [RFC7525] except with respect to (D)TLS version. Since encryption of 1516 DOTS using (D)TLS is virtually a green-field deployment DOTS agents 1517 MUST implement only (D)TLS 1.2 or later. 1519 Implementations compliant with this profile MUST implement all of the 1520 following items: 1522 o DOTS agents MUST support DTLS record replay detection (Section 3.3 1523 in [RFC6347]) to protect against replay attacks. 1525 o DOTS client can use (D)TLS session resumption without server-side 1526 state [RFC5077] to resume session and convey the DOTS signal. 1528 o Raw public keys [RFC7250] which reduce the size of the 1529 ServerHello, and can be used by servers that cannot obtain 1530 certificates (e.g., DOTS gateways on private networks). 1532 Implementations compliant with this profile SHOULD implement all of 1533 the following items to reduce the delay required to deliver a DOTS 1534 signal: 1536 o TLS False Start [RFC7918] which reduces round-trips by allowing 1537 the TLS second flight of messages (ChangeCipherSpec) to also 1538 contain the DOTS signal. 1540 o Cached Information Extension [RFC7924] which avoids transmitting 1541 the server's certificate and certificate chain if the client has 1542 cached that information from a previous TLS handshake. 1544 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 1545 convey DOTS signal. 1547 7.1. MTU and Fragmentation Issues 1549 To avoid DOTS signal message fragmentation and the consequently 1550 decreased probability of message delivery, DOTS agents MUST ensure 1551 that the DTLS record MUST fit within a single datagram. If the Path 1552 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 1553 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 1554 is used to convey the DOTS signal messages then the DOTS client must 1555 consider the amount of record expansion expected by the DTLS 1556 processing when calculating the size of CoAP message that fits within 1557 the path MTU. Path MTU MUST be greater than or equal to [CoAP 1558 message size + DTLS overhead of 13 octets + authentication overhead 1559 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 1560 of [RFC6347]]. If the request size exceeds the Path MTU then the 1561 DOTS client MUST split the DOTS signal into separate messages, for 1562 example the list of addresses in the 'target-ip' parameter could be 1563 split into multiple lists and each list conveyed in a new PUT 1564 request. 1566 Implementation Note: DOTS choice of message size parameters works 1567 well with IPv6 and with most of today's IPv4 paths. However, with 1568 IPv4, it is harder to absolutely ensure that there is no IP 1569 fragmentation. If IPv4 support on unusual networks is a 1570 consideration and path MTU is unknown, implementations may want to 1571 limit themselves to more conservative IPv4 datagram sizes such as 576 1572 bytes, as per [RFC0791] IP packets up to 576 bytes should never need 1573 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal 1574 over a UDP datagram will generally avoid IP fragmentation. 1576 8. (D)TLS 1.3 considerations 1578 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 1579 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 1580 [I-D.rescorla-tls-dtls13] is based on the TLS 1.3 protocol and 1581 provides equivalent security guarantees. (D)TLS 1.3 provides two 1582 basic handshake modes of interest to DOTS signal channel: 1584 o Absent packet loss, a full handshake in which the DOTS client is 1585 able to send the DOTS signal message after one round trip and the 1586 DOTS server immediately after receiving the first DOTS signal 1587 message from the client. 1589 o 0-RTT mode in which the DOTS client can authenticate itself and 1590 send DOTS signal message on its first flight, thus reducing 1591 handshake latency. 0-RTT only works if the DOTS client has 1592 previously communicated with that DOTS server, which is very 1593 likely with the DOTS signal channel. The DOTS client SHOULD 1594 establish a (D)TLS session with the DOTS server during peacetime 1595 and share a PSK. During DDOS attack, the DOTS client can use the 1596 (D)TLS session to convey the DOTS signal message and if there is 1597 no response from the server after multiple re-tries then the DOTS 1598 client can resume the (D)TLS session in 0-RTT mode using PSK. A 1599 simplified TLS 1.3 handshake with 0-RTT DOTS signal message 1600 exchange is shown in Figure 22. 1602 DOTS Client DOTS Server 1604 ClientHello 1605 (Finished) 1606 (0-RTT DOTS signal message) 1607 (end_of_early_data) --------> 1608 ServerHello 1609 {EncryptedExtensions} 1610 {ServerConfiguration} 1611 {Certificate} 1612 {CertificateVerify} 1613 {Finished} 1614 <-------- [DOTS signal message] 1615 {Finished} --------> 1617 [DOTS signal message] <-------> [DOTS signal message] 1619 Figure 22: TLS 1.3 handshake with 0-RTT 1621 9. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 1623 (D)TLS based on client certificate can be used for mutual 1624 authentication between DOTS agents. If a DOTS gateway is involved, 1625 DOTS clients and DOTS gateway MUST perform mutual authentication; 1626 only authorized DOTS clients are allowed to send DOTS signals to a 1627 DOTS gateway. DOTS gateway and DOTS server MUST perform mutual 1628 authentication; DOTS server only allows DOTS signals from authorized 1629 DOTS gateway, creating a two-link chain of transitive authentication 1630 between the DOTS client and the DOTS server. 1632 +-------------------------------------------------+ 1633 | example.com domain +---------+ | 1634 | | AAA | | 1635 | +---------------+ | Server | | 1636 | | Application | +------+--+ | 1637 | | server + ^ 1638 | | (DOTS client) |<-----------------+ | | 1639 | +---------------+ + | | example.net domain 1640 | V V | 1641 | +-------------+ | +---------------+ 1642 | +--------------+ | | | | | 1643 | | Guest +<-----x----->+ +<---------------->+ DOTS | 1644 | | (DOTS client)| | DOTS | | | Server | 1645 | +--------------+ | Gateway | | | | 1646 | +----+--------+ | +---------------+ 1647 | ^ | 1648 | | | 1649 | +----------------+ | | 1650 | | DDOS detector | | | 1651 | | (DOTS client) +<--------------+ | 1652 | +----------------+ | 1653 | | 1654 +-------------------------------------------------+ 1656 Figure 23: Example of Authentication and Authorization of DOTS Agents 1658 In the example depicted in Figure 23, the DOTS gateway and DOTS 1659 clients within the 'example.com' domain mutually authenticate with 1660 each other. After the DOTS gateway validates the identity of a DOTS 1661 client, it communicates with the AAA server in the 'example.com' 1662 domain to determine if the DOTS client is authorized to request DDOS 1663 mitigation. If the DOTS client is not authorized, a 4.01 1664 (Unauthorized) is returned in the response to the DOTS client. In 1665 this example, the DOTS gateway only allows the application server and 1666 DDOS detector to request DDOS mitigation, but does not permit the 1667 user of type 'guest' to request DDOS mitigation. 1669 Also, DOTS gateway and DOTS server MUST perform mutual authentication 1670 using certificates. A DOTS server will only allow a DOTS gateway 1671 with a certificate for a particular domain to request mitigation for 1672 that domain. In reference to Figure 23, the DOTS server only allows 1673 the DOTS gateway to request mitigation for 'example.com' domain and 1674 not for other domains. 1676 10. IANA Considerations 1678 This specification registers new CoAP response code, new parameters 1679 for DOTS signal channel and establishes registries for mappings to 1680 CBOR. 1682 10.1. CoAP Response Code 1684 The following entry is added to the "CoAP Response Codes" sub- 1685 registry: 1687 +------+------------------------------+-----------+ 1688 | Code | Description | Reference | 1689 +------+------------------------------+-----------+ 1690 | 3.00 | Alternate server | [RFCXXXX] | 1691 +------+------------------------------+-----------+ 1693 Figure 24: CoAP Response Code 1695 [Note to RFC Editor: Please replace XXXX with the RFC number of this 1696 specification.] 1698 10.2. DOTS signal channel CBOR Mappings Registry 1700 A new registry will be requested from IANA, entitled "DOTS signal 1701 channel CBOR Mappings Registry". The registry is to be created as 1702 Expert Review Required. 1704 10.2.1. Registration Template 1706 Parameter name: 1707 Parameter names (e.g., "target_ip") in the DOTS signal channel. 1709 CBOR Key Value: 1710 Key value for the parameter. The key value MUST be an integer in 1711 the range of 1 to 65536. The key values in the range of 32768 to 1712 65536 are assigned for Vendor-Specific parameters. 1714 CBOR Major Type: 1715 CBOR Major type and optional tag for the claim. 1717 Change Controller: 1718 For Standards Track RFCs, list the "IESG". For others, give the 1719 name of the responsible party. Other details (e.g., postal 1720 address, email address, home page URI) may also be included. 1722 Specification Document(s): 1724 Reference to the document or documents that specify the parameter, 1725 preferably including URIs that can be used to retrieve copies of 1726 the documents. An indication of the relevant sections may also be 1727 included but is not required. 1729 10.2.2. Initial Registry Contents 1731 o Parameter Name: "mitigation-scope" 1732 o CBOR Key Value: 1 1733 o CBOR Major Type: 5 1734 o Change Controller: IESG 1735 o Specification Document(s): this document 1737 o Parameter Name: "scope" 1738 o CBOR Key Value: 2 1739 o CBOR Major Type: 5 1740 o Change Controller: IESG 1741 o Specification Document(s): this document 1743 o Parameter Name: "mitigation-id" 1744 o CBOR Key Value: 3 1745 o CBOR Major Type: 0 1746 o Change Controller: IESG 1747 o Specification Document(s): this document 1749 o Parameter Name:target-ip 1750 o CBOR Key Value: 4 1751 o CBOR Major Type: 4 1752 o Change Controller: IESG 1753 o Specification Document(s): this document 1755 o Parameter Name: target-port-range 1756 o CBOR Key Value: 5 1757 o CBOR Major Type: 4 1758 o Change Controller: IESG 1759 o Specification Document(s): this document 1761 o Parameter Name: "lower-port" 1762 o CBOR Key Value: 6 1763 o CBOR Major Type: 0 1764 o Change Controller: IESG 1765 o Specification Document(s): this document 1767 o Parameter Name: "upper-port" 1768 o CBOR Key Value: 7 1769 o CBOR Major Type: 0 1770 o Change Controller: IESG 1771 o Specification Document(s): this document 1772 o Parameter Name: target-protocol 1773 o CBOR Key Value: 8 1774 o CBOR Major Type: 4 1775 o Change Controller: IESG 1776 o Specification Document(s): this document 1778 o Parameter Name: "FQDN" 1779 o CBOR Key Value: 9 1780 o CBOR Major Type: 4 1781 o Change Controller: IESG 1782 o Specification Document(s): this document 1784 o Parameter Name: "URI" 1785 o CBOR Key Value: 10 1786 o CBOR Major Type: 4 1787 o Change Controller: IESG 1788 o Specification Document(s): this document 1790 o Parameter Name: alias 1791 o CBOR Key Value: 11 1792 o CBOR Major Type: 4 1793 o Change Controller: IESG 1794 o Specification Document(s): this document 1796 o Parameter Name: "lifetime" 1797 o CBOR Key Value: 12 1798 o CBOR Major Type: 0 1799 o Change Controller: IESG 1800 o Specification Document(s): this document 1802 o Parameter Name: attack-status 1803 o CBOR Key Value: 13 1804 o CBOR Major Type: 0 1805 o Change Controller: IESG 1806 o Specification Document(s): this document 1808 o Parameter Name: signal-config 1809 o CBOR Key Value: 14 1810 o CBOR Major Type: 5 1811 o Change Controller: IESG 1812 o Specification Document(s): this document 1814 o Parameter Name: heartbeat-timeout 1815 o CBOR Key Value: 15 1816 o CBOR Major Type: 0 1817 o Change Controller: IESG 1818 o Specification Document(s): this document 1819 o Parameter Name: max-retransmit 1820 o CBOR Key Value: 16 1821 o CBOR Major Type: 0 1822 o Change Controller: IESG 1823 o Specification Document(s): this document 1825 o Parameter Name: ack-timeout 1826 o CBOR Key Value: 17 1827 o CBOR Major Type: 0 1828 o Change Controller: IESG 1829 o Specification Document(s): this document 1831 o Parameter Name: ack-random-factor 1832 o CBOR Key Value: 18 1833 o CBOR Major Type: 7 1834 o Change Controller: IESG 1835 o Specification Document(s): this document 1837 o Parameter Name: MinValue 1838 o CBOR Key Value: 19 1839 o CBOR Major Type: 0 1840 o Change Controller: IESG 1841 o Specification Document(s): this document 1843 o Parameter Name: MaxValue 1844 o CBOR Key Value: 20 1845 o CBOR Major Type: 0 1846 o Change Controller: IESG 1847 o Specification Document(s): this document 1849 o Parameter Name: status 1850 o CBOR Key Value: 21 1851 o CBOR Major Type: 0 1852 o Change Controller: IESG 1853 o Specification Document(s): this document 1855 o Parameter Name: bytes-dropped 1856 o CBOR Key Value: 22 1857 o CBOR Major Type: 0 1858 o Change Controller: IESG 1859 o Specification Document(s): this document 1861 o Parameter Name: bps-dropped 1862 o CBOR Key Value: 23 1863 o CBOR Major Type: 0 1864 o Change Controller: IESG 1865 o Specification Document(s): this document 1866 o Parameter Name: pkts-dropped 1867 o CBOR Key Value: 24 1868 o CBOR Major Type: 0 1869 o Change Controller: IESG 1870 o Specification Document(s): this document 1872 o Parameter Name: pps-dropped 1873 o CBOR Key Value: 25 1874 o CBOR Major Type: 0 1875 o Change Controller: IESG 1876 o Specification Document(s): this document 1878 o Parameter Name: session-id 1879 o CBOR Key Value: 26 1880 o CBOR Major Type: 0 1881 o Change Controller: IESG 1882 o Specification Document(s): this document 1884 o Parameter Name: trigger-mitigation 1885 o CBOR Key Value: 27 1886 o CBOR Major Type: 7 1887 o Change Controller: IESG 1888 o Specification Document(s): this document 1890 11. Implementation Status 1892 [Note to RFC Editor: Please remove this section and reference to 1893 [RFC7942] prior to publication.] 1895 This section records the status of known implementations of the 1896 protocol defined by this specification at the time of posting of this 1897 Internet-Draft, and is based on a proposal described in [RFC7942]. 1898 The description of implementations in this section is intended to 1899 assist the IETF in its decision processes in progressing drafts to 1900 RFCs. Please note that the listing of any individual implementation 1901 here does not imply endorsement by the IETF. Furthermore, no effort 1902 has been spent to verify the information presented here that was 1903 supplied by IETF contributors. This is not intended as, and must not 1904 be construed to be, a catalog of available implementations or their 1905 features. Readers are advised to note that other implementations may 1906 exist. 1908 According to [RFC7942], "this will allow reviewers and working groups 1909 to assign due consideration to documents that have the benefit of 1910 running code, which may serve as evidence of valuable experimentation 1911 and feedback that have made the implemented protocols more mature. 1912 It is up to the individual working groups to use this information as 1913 they see fit". 1915 11.1. nttdots 1917 Organization: NTT Communication is developing a DOTS client and 1918 DOTS server software based on DOTS signal channel specified in 1919 this draft. It will be open-sourced. 1920 Description: Early implementation of DOTS protocol. It is aimed to 1921 implement a full DOTS protocol spec in accordance with maturing of 1922 DOTS protocol itself. 1923 Implementation: To be open-sourced. 1924 Level of maturity: It is a early implementation of DOTS protocol. 1925 Messaging between DOTS clients and DOTS servers has been tested. 1926 Level of maturity will increase in accordance with maturing of 1927 DOTS protocol itself. 1928 Coverage: Capability of DOTS client: sending DOTS messages to the 1929 DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS 1930 server: receiving dots-signal, validating received dots-signal, 1931 starting mitigation by handing over the dots-signal to DDOS 1932 mitigator. 1933 Licensing: It will be open-sourced with BSD 3-clause license. 1934 Implementation experience: It is implemented in Go-lang. Core 1935 specification of signaling is mature to be implemented, however, 1936 finding good libraries(like DTLS, CoAP) is rather difficult. 1937 Contact: Kaname Nishizuka 1939 12. Security Considerations 1941 Authenticated encryption MUST be used for data confidentiality and 1942 message integrity. (D)TLS based on client certificate MUST be used 1943 for mutual authentication. The interaction between the DOTS agents 1944 requires Datagram Transport Layer Security (DTLS) and Transport Layer 1945 Security (TLS) with a cipher suite offering confidentiality 1946 protection and the guidance given in [RFC7525] MUST be followed to 1947 avoid attacks on (D)TLS. 1949 A single DOTS signal channel between DOTS agents can be used to 1950 exchange multiple DOTS signal messages. To reduce DOTS client and 1951 DOTS server workload, DOTS client SHOULD re-use the (D)TLS session. 1953 If TCP is used between DOTS agents, an attacker may be able to inject 1954 RST packets, bogus application segments, etc., regardless of whether 1955 TLS authentication is used. Because the application data is TLS 1956 protected, this will not result in the application receiving bogus 1957 data, but it will constitute a DoS on the connection. This attack 1958 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 1959 any bogus packets injected by an attacker will be rejected by the 1960 TCP-AO integrity check and therefore will never reach the TLS layer. 1962 Special care should be taken in order to ensure that the activation 1963 of the proposed mechanism won't have an impact on the stability of 1964 the network (including connectivity and services delivered over that 1965 network). 1967 Involved functional elements in the cooperation system must establish 1968 exchange instructions and notification over a secure and 1969 authenticated channel. Adequate filters can be enforced to avoid 1970 that nodes outside a trusted domain can inject request such as 1971 deleting filtering rules. Nevertheless, attacks can be initiated 1972 from within the trusted domain if an entity has been corrupted. 1973 Adequate means to monitor trusted nodes should also be enabled. 1975 13. Contributors 1977 The following individuals have contributed to this document: 1979 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 1980 mgeller@cisco.com 1982 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 1983 Email: rgm@htt-consult.com 1985 Dan Wing Email: dwing-ietf@fuggles.com 1987 14. Acknowledgements 1989 Thanks to Christian Jacquenet, Roland Dobbins, Andrew Mortensen, 1990 Roman D. Danyliw, Michael Richardson, Ehud Doron, Kaname Nishizuka, 1991 Dave Dolson, Liang Xia, Jon Shallow and Gilbert Clark for the 1992 discussion and comments. 1994 15. References 1996 15.1. Normative References 1998 [I-D.ietf-core-coap-tcp-tls] 1999 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 2000 Silverajan, B., and B. Raymor, "CoAP (Constrained 2001 Application Protocol) over TCP, TLS, and WebSockets", 2002 draft-ietf-core-coap-tcp-tls-09 (work in progress), May 2003 2017. 2005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2006 Requirement Levels", BCP 14, RFC 2119, 2007 DOI 10.17487/RFC2119, March 1997, 2008 . 2010 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2011 (TLS) Protocol Version 1.2", RFC 5246, 2012 DOI 10.17487/RFC5246, August 2008, 2013 . 2015 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2016 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 2017 June 2010, . 2019 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2020 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2021 January 2012, . 2023 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 2024 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 2025 Transport Layer Security (TLS) and Datagram Transport 2026 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 2027 June 2014, . 2029 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2030 Application Protocol (CoAP)", RFC 7252, 2031 DOI 10.17487/RFC7252, June 2014, 2032 . 2034 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2035 "Recommendations for Secure Use of Transport Layer 2036 Security (TLS) and Datagram Transport Layer Security 2037 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2038 2015, . 2040 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2041 Application Protocol (CoAP)", RFC 7641, 2042 DOI 10.17487/RFC7641, September 2015, 2043 . 2045 15.2. Informative References 2047 [I-D.ietf-core-comi] 2048 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 2049 Management Interface", draft-ietf-core-comi-01 (work in 2050 progress), July 2017. 2052 [I-D.ietf-core-yang-cbor] 2053 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 2054 Minaburo, "CBOR Encoding of Data Modeled with YANG", 2055 draft-ietf-core-yang-cbor-05 (work in progress), August 2056 2017. 2058 [I-D.ietf-dots-architecture] 2059 Mortensen, A., Andreasen, F., Reddy, T., 2060 christopher_gray3@cable.comcast.com, c., Compton, R., and 2061 N. Teague, "Distributed-Denial-of-Service Open Threat 2062 Signaling (DOTS) Architecture", draft-ietf-dots- 2063 architecture-04 (work in progress), July 2017. 2065 [I-D.ietf-dots-data-channel] 2066 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 2067 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 2068 Service Open Threat Signaling (DOTS) Data Channel", draft- 2069 ietf-dots-data-channel-02 (work in progress), June 2017. 2071 [I-D.ietf-dots-requirements] 2072 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 2073 Denial of Service (DDoS) Open Threat Signaling 2074 Requirements", draft-ietf-dots-requirements-06 (work in 2075 progress), July 2017. 2077 [I-D.ietf-dots-use-cases] 2078 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 2079 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 2080 Open Threat Signaling", draft-ietf-dots-use-cases-07 (work 2081 in progress), July 2017. 2083 [I-D.ietf-tls-tls13] 2084 Rescorla, E., "The Transport Layer Security (TLS) Protocol 2085 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 2086 July 2017. 2088 [I-D.rescorla-tls-dtls13] 2089 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2090 Datagram Transport Layer Security (DTLS) Protocol Version 2091 1.3", draft-rescorla-tls-dtls13-01 (work in progress), 2092 March 2017. 2094 [proto_numbers] 2095 "IANA, "Protocol Numbers"", 2011, 2096 . 2098 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2099 DOI 10.17487/RFC0791, September 1981, 2100 . 2102 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2103 (CIDR): The Internet Address Assignment and Aggregation 2104 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2105 2006, . 2107 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 2108 Denial-of-Service Considerations", RFC 4732, 2109 DOI 10.17487/RFC4732, December 2006, 2110 . 2112 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 2113 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 2114 . 2116 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2117 "Transport Layer Security (TLS) Session Resumption without 2118 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 2119 January 2008, . 2121 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2122 the Network Configuration Protocol (NETCONF)", RFC 6020, 2123 DOI 10.17487/RFC6020, October 2010, 2124 . 2126 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 2127 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2128 2012, . 2130 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 2131 "Default Address Selection for Internet Protocol Version 6 2132 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 2133 . 2135 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2136 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2137 October 2013, . 2139 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2140 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2141 . 2143 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 2144 NETCONF Protocol over Transport Layer Security (TLS) with 2145 Mutual X.509 Authentication", RFC 7589, 2146 DOI 10.17487/RFC7589, June 2015, 2147 . 2149 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 2150 Layer Security (TLS) False Start", RFC 7918, 2151 DOI 10.17487/RFC7918, August 2016, 2152 . 2154 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 2155 (TLS) Cached Information Extension", RFC 7924, 2156 DOI 10.17487/RFC7924, July 2016, 2157 . 2159 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2160 Code: The Implementation Status Section", BCP 205, 2161 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2162 . 2164 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2165 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2166 March 2017, . 2168 Authors' Addresses 2170 Tirumaleswar Reddy 2171 McAfee, Inc. 2172 Embassy Golf Link Business Park 2173 Bangalore, Karnataka 560071 2174 India 2176 Email: kondtir@gmail.com 2178 Mohamed Boucadair 2179 Orange 2180 Rennes 35000 2181 France 2183 Email: mohamed.boucadair@orange.com 2185 Prashanth Patil 2186 Cisco Systems, Inc. 2188 Email: praspati@cisco.com 2190 Andrew Mortensen 2191 Arbor Networks, Inc. 2192 2727 S. State St 2193 Ann Arbor, MI 48104 2194 United States 2196 Email: amortensen@arbor.net 2197 Nik Teague 2198 Verisign, Inc. 2199 United States 2201 Email: nteague@verisign.com