idnits 2.17.1 draft-ietf-dots-signal-channel-02.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 78 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 352 has weird spacing: '...er-port ine...' == Line 353 has weird spacing: '...er-port ine...' -- The document date (June 21, 2017) is 2494 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) == 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-00 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-04 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-03 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-01 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-05 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-05 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 -- 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 (~~), 12 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: December 23, 2017 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 June 21, 2017 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel 16 draft-ietf-dots-signal-channel-02 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 December 23, 2017. 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 . . . . . . . . . . . . . . . . . . . 11 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 . . 29 81 5.4.4. Retrieving DOTS Signal Channel Session Configuration 29 82 5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 30 83 5.6. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 31 84 6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 32 85 7. (D)TLS Protocol Profile and Performance considerations . . . 32 86 7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 33 87 8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 34 88 9. Mutual Authentication of DOTS Agents & Authorization of DOTS 89 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 91 10.1. DOTS signal channel CBOR Mappings Registry . . . . . . . 37 92 10.1.1. Registration Template . . . . . . . . . . . . . . . 37 93 10.1.2. Initial Registry Contents . . . . . . . . . . . . . 37 94 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 41 95 11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 41 96 12. Security Considerations . . . . . . . . . . . . . . . . . . . 42 97 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 98 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 99 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 100 15.1. Normative References . . . . . . . . . . . . . . . . . . 43 101 15.2. Informative References . . . . . . . . . . . . . . . . . 44 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 104 1. Introduction 106 A distributed denial-of-service (DDoS) attack is an attempt to make 107 machines or network resources unavailable to their intended users. 108 In most cases, sufficient scale can be achieved by compromising 109 enough end-hosts and using those infected hosts to perpetrate and 110 amplify the attack. The victim in this attack can be an application 111 server, a host, a router, a firewall, or an entire network. 113 In many cases, it may not be possible for an network administrators 114 to determine the causes of an attack, but instead just realize that 115 certain resources seem to be under attack. This document defines a 116 lightweight protocol permitting a DOTS client to request mitigation 117 from one or more DOTS servers for protection against detected, 118 suspected, or anticipated attacks . This protocol enables cooperation 119 between DOTS agents to permit a highly-automated network defense that 120 is robust, reliable and secure. 122 The requirements for DOTS signal channel protocol are obtained from 123 [I-D.ietf-dots-requirements]. 125 This document satisfies all the use cases discussed in 126 [I-D.ietf-dots-use-cases] except the Third-party DOTS notifications 127 use case in Section 3.2.3 of [I-D.ietf-dots-use-cases] which is an 128 optional feature and not a core use case. Third-party DOTS 129 notifications are not part of the DOTS requirements document. 130 Moreover, the DOTS architecture does not assess whether that use case 131 may have an impact on the architecture itself and/or the DOTS trust 132 model. 134 This is a companion document to the DOTS data channel specification 135 [I-D.ietf-dots-data-channel] that defines a configuration and bulk 136 data exchange mechanism supporting the DOTS signal channel. 138 2. Notational Conventions and Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in 143 [RFC2119]. 145 (D)TLS: For brevity this term is used for statements that apply to 146 both Transport Layer Security [RFC5246] and Datagram Transport Layer 147 Security [RFC6347]. Specific terms will be used for any statement 148 that applies to either protocol alone. 150 The reader should be familiar with the terms defined in 151 [I-D.ietf-dots-architecture]. 153 3. Solution Overview 155 Network applications have finite resources like CPU cycles, number of 156 processes or threads they can create and use, maximum number of 157 simultaneous connections it can handle, limited resources of the 158 control plane, etc. When processing network traffic, such 159 applications are supposed to use these resources to offer the 160 intended task in the most efficient fashion. However, an attacker 161 may be able to prevent an application from performing its intended 162 task by causing the application to exhaust the finite supply of a 163 specific resource. 165 TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the 166 victim and ACK-flood is a CPU exhaustion attack on the victim 167 ([RFC4987]). Attacks on the link are carried out by sending enough 168 traffic such that the link becomes excessively congested, and 169 legitimate traffic suffers high packet loss. Stateful firewalls can 170 also be attacked by sending traffic that causes the firewall to hold 171 excessive state. The firewall then runs out of memory, and can no 172 longer instantiate the state required to pass legitimate flows. 173 Other possible DDoS attacks are discussed in [RFC4732]. 175 In each of the cases described above, the possible arrangements 176 between the DOTS client and DOTS server to mitigate the attack are 177 discussed in [I-D.ietf-dots-use-cases]. An example of network 178 diagram showing a deployment of these elements is shown in Figure 1. 179 Architectural relationships between involved DOTS agents is explained 180 in [I-D.ietf-dots-architecture]. In this example, the DOTS server is 181 operating on the access network. 183 Network 184 Resource CPE router Access network __________ 185 +-----------+ +--------------+ +-------------+ / \ 186 | |____| |_______| |___ | Internet | 187 |DOTS client| | DOTS gateway | | DOTS server | | | 188 | | | | | | | | 189 +-----------+ +--------------+ +-------------+ \__________/ 191 Figure 1: Sample DOTS Deployment (1) 193 The DOTS server can also be running on the Internet, as depicted in 194 Figure 2. 196 Network DDoS mitigation 197 Resource CPE router __________ service 198 +-----------+ +-------------+ / \ +-------------+ 199 | |____| |_______| |___ | | 200 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 201 | | | | | | | | | 202 +-----------+ +-------------+ \__________/ +-------------+ 204 Figure 2: Sample DOTS Deployment (2) 206 In typical deployments, the DOTS client belongs to a different 207 administrative domain than the DOTS server. For example, the DOTS 208 client is a firewall protecting services owned and operated by an 209 domain, while the DOTS server is owned and operated by a different 210 domain providing DDoS mitigation services. That domain providing 211 DDoS mitigation service might, or might not, also provide Internet 212 access service to the website operator. 214 The DOTS server may (not) be co-located with the DOTS mitigator. In 215 typical deployments, the DOTS server belongs to the same 216 administrative domain as the mitigator. 218 The DOTS client can communicate directly with the DOTS server or 219 indirectly via a DOTS gateway. 221 This document focuses on the DOTS signal channel. 223 4. Happy Eyeballs for DOTS Signal Channel 225 DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS 226 [RFC5246] over TCP. A DOTS client can use DNS to determine the IP 227 address(es) of a DOTS server or a DOTS client may be provided with 228 the list of DOTS server IP addresses. The DOTS client MUST know a 229 DOTS server's domain name; hard-coding the domain name of the DOTS 230 server into software is NOT RECOMMENDED in case the domain name is 231 not valid or needs to change for legal or other reasons. The DOTS 232 client performs A and/or AAAA record lookup of the domain name and 233 the result will be a list of IP addresses, each of which can be used 234 to contact the DOTS server using UDP and TCP. 236 If an IPv4 path to reach a DOTS server is found, but the DOTS 237 server's IPv6 path is not working, a dual-stack DOTS client can 238 experience a significant connection delay compared to an IPv4-only 239 DOTS client. The other problem is that if a middlebox between the 240 DOTS client and DOTS server is configured to block UDP, the DOTS 241 client will fail to establish a DTLS session with the DOTS server and 242 will, then, have to fall back to TLS over TCP incurring significant 243 connection delays. [I-D.ietf-dots-requirements] discusses that DOTS 244 client and server will have to support both connectionless and 245 connection-oriented protocols. 247 To overcome these connection setup problems, the DOTS client can try 248 connecting to the DOTS server using both IPv6 and IPv4, and try both 249 DTLS over UDP and TLS over TCP in a fashion similar to the Happy 250 Eyeballs mechanism [RFC6555]. These connection attempts are 251 performed by the DOTS client when its initializes, and the client 252 uses that information for its subsequent alert to the DOTS server. 253 In order of preference (most preferred first), it is UDP over IPv6, 254 UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which 255 adheres to address preference order [RFC6724] and the DOTS preference 256 that UDP be used over TCP (to avoid TCP's head of line blocking). 258 DOTS client DOTS server 259 | | 260 |--DTLS ClientHello, IPv6 ---->X | 261 |--TCP SYN, IPv6-------------->X | 262 |--DTLS ClientHello, IPv4 ---->X | 263 |--TCP SYN, IPv4----------------------------------------->| 264 |--DTLS ClientHello, IPv6 ---->X | 265 |--TCP SYN, IPv6-------------->X | 266 |<-TCP SYNACK---------------------------------------------| 267 |--DTLS ClientHello, IPv4 ---->X | 268 |--TCP ACK----------------------------------------------->| 269 |<------------Establish TLS Session---------------------->| 270 |----------------DOTS signal----------------------------->| 271 | | 273 Figure 3: Happy Eyeballs 275 In reference to Figure 3, the DOTS client sends two TCP SYNs and two 276 DTLS ClientHello messages at the same time over IPv6 and IPv4. In 277 this example, it is assumed that the IPv6 path is broken and UDP is 278 dropped by a middle box but has little impact to the DOTS client 279 because there is no long delay before using IPv4 and TCP. The DOTS 280 client repeats the mechanism to discover if DOTS signaling with DTLS 281 over UDP becomes available from the DOTS server, so the DOTS client 282 can migrate the DOTS signal channel from TCP to UDP, but such probing 283 SHOULD NOT be done more frequently than every 24 hours and MUST NOT 284 be done more frequently than every 5 minutes. 286 5. DOTS Signal Channel 288 5.1. Overview 290 The DOTS signal channel is built on top of the Constrained 291 Application Protocol (CoAP) [RFC7252], a lightweight protocol 292 originally designed for constrained devices and networks. CoAP's 293 expectation of packet loss, support for asynchronous non-confirmable 294 messaging, congestion control, small message overhead limiting the 295 need for fragmentation, use of minimal resources, and support for 296 (D)TLS make it a good foundation on which to build the DOTS signaling 297 mechanism. 299 The DOTS signal channel is layered on existing standards (Figure 4). 301 +--------------+ 302 | DOTS | 303 +--------------+ 304 | CoAP | 305 +--------------+ 306 | TLS | DTLS | 307 +--------------+ 308 | TCP | UDP | 309 +--------------+ 310 | IP | 311 +--------------+ 313 Figure 4: Abstract Layering of DOTS signal channel over CoAP over 314 (D)TLS 316 The signal channel is initiated by the DOTS client. Once the signal 317 channel is established, the DOTS agents periodically send heartbeats 318 to keep the channel active. At any time, the DOTS client may send a 319 mitigation request message to the DOTS server over the active 320 channel. While mitigation is active, the DOTS server periodically 321 sends status messages to the client, including basic mitigation 322 feedback details. Mitigation remains active until the DOTS client 323 explicitly terminates mitigation, or the mitigation lifetime expires. 325 Messages exchanged between DOTS client and server are serialized 326 using Concise Binary Object Representation (CBOR) [RFC7049], CBOR is 327 a binary encoding designed for small code and message size. CBOR 328 encoded payloads are used to convey signal channel specific payload 329 messages that convey request parameters and response information such 330 as errors. This specification uses the encoding rules defined in 331 [I-D.ietf-core-yang-cbor] for representing mitigation scope and DOTS 332 signal channel session configuration data defined using YANG 333 (Section 5.2) as CBOR data. 335 5.2. DOTS Signal YANG Model 337 This document defines a YANG [RFC6020] data model for mitigation 338 scope and DOTS signal channel session configuration data. 340 5.2.1. Mitigation Request Model structure 342 This document defines the YANG module "ietf-dots-signal", which has 343 the following structure: 345 module: ietf-dots-signal 346 +--rw mitigation-scope 347 +--rw scope* [mitigation-id] 348 +--rw mitigation-id int32 349 +--rw target-ip* inet:ip-address 350 +--rw target-prefix* inet:ip-prefix 351 +--rw target-port-range* [lower-port upper-port] 352 | +--rw lower-port inet:port-number 353 | +--rw upper-port inet:port-number 354 +--rw target-protocol* uint8 355 +--rw fqdn* inet:domain-name 356 +--rw uri* inet:uri 357 +--rw alias* string 358 +--rw lifetime? int32 360 5.2.2. Mitigation Request Model 362 file "ietf-dots-signal@2016-11-28.yang" 364 module ietf-dots-signal { 365 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; 366 prefix "signal"; 367 import ietf-inet-types { 368 prefix "inet"; 369 } 370 organization "McAfee, Inc."; 371 contact "Konda, Tirumaleswar Reddy "; 373 description 374 "This module contains YANG definition for DOTS 375 signal sent by the DOTS client to the DOTS server"; 377 revision 2016-11-28 { 378 reference 379 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 380 } 382 container mitigation-scope { 383 description "top level container for mitigation request"; 384 list scope { 385 key mitigation-id; 386 description "Identifier for the mitigation request"; 387 leaf mitigation-id { 388 type int32; 389 description "mitigation request identifier"; 390 } 391 leaf-list target-ip { 392 type inet:ip-address; 393 description "IP address"; 394 } 395 leaf-list target-prefix { 396 type inet:ip-prefix; 397 description "prefix"; 398 } 399 list target-port-range { 400 key "lower-port upper-port"; 401 description "Port range. When only lower-port is present, 402 it represents a single port."; 403 leaf lower-port { 404 type inet:port-number; 405 mandatory true; 406 description "lower port"; 407 } 408 leaf upper-port { 409 type inet:port-number; 410 must ". >= ../lower-port" { 411 error-message 412 "The upper-port must be greater than or 413 equal to lower-port"; 414 } 415 description "upper port"; 416 } 417 } 418 leaf-list target-protocol { 419 type uint8; 420 description "Internet Protocol number"; 421 } 422 leaf-list fqdn { 423 type inet:domain-name; 424 description "FQDN"; 425 } 426 leaf-list uri { 427 type inet:uri; 428 description "URI"; 429 } 430 leaf-list alias { 431 type string; 432 description "alias name"; 433 } 434 leaf lifetime { 435 type int32; 436 description "lifetime"; 437 } 438 } 439 } 440 } 441 443 5.2.3. Session Configuration Model structure 445 This document defines the YANG module "ietf-dots-signal-config", 446 which has the following structure: 448 module: ietf-dots-signal-config 449 +--rw signal-config 450 +--rw session-id? int32 451 +--rw heartbeat-timeout? int16 452 +--rw max-retransmit? int16 453 +--rw ack-timeout? int16 454 +--rw ack-random-factor? decimal64 456 5.2.4. Session Configuration Model 458 file "ietf-dots-signal-config@2016-11-28.yang" 460 module ietf-dots-signal-config { 461 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config"; 462 prefix "config"; 464 organization "McAfee, Inc."; 465 contact "Konda, Tirumaleswar Reddy "; 467 description 468 "This module contains YANG definition for DOTS 469 signal channel session configuration"; 471 revision 2016-11-28 { 472 reference 473 "https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; 474 } 476 container signal-config { 477 description "top level container for DOTS signal channel session 478 configuration"; 480 leaf session-id { 481 type int32; 482 description "Identifier for the DOTS signal channel 483 session configuration data"; 484 } 485 leaf heartbeat-timeout { 486 type int16; 487 description "heartbeat timeout"; 488 } 489 leaf max-retransmit { 490 type int16; 491 description "Maximum number of retransmissions"; 492 } 493 leaf ack-timeout { 494 type int16; 495 description "Initial retransmission timeout value"; 496 } 497 leaf ack-random-factor { 498 type decimal64 { 499 fraction-digits 2; 500 } 501 description "Random factor used to influence the timing of 502 retransmissions"; 503 } 504 } 505 } 507 509 5.3. Mitigation Request 511 The following methods are used to request or withdraw mitigation 512 requests: 514 PUT: DOTS clients use the PUT method to request mitigation 515 (Section 5.3.1). During active mitigation, DOTS clients may use 516 PUT requests to convey mitigation efficacy updates to the DOTS 517 server (Section 5.3.4). 519 DELETE: DOTS clients use the DELETE method to withdraw a request for 520 mitigation from the DOTS server (Section 5.3.2). 522 GET: DOTS clients may use the GET method to subscribe to DOTS server 523 status messages, or to retrieve the list of existing mitigations 524 (Section 5.3.3). 526 Mitigation request and response messages are marked as Non- 527 confirmable messages. DOTS agents should follow the data 528 transmission guidelines discussed in Section 3.1.3 of [RFC8085] and 529 control transmission behavior by not sending on average more than one 530 UDP datagram per RTT to the peer DOTS agent. Requests marked by the 531 DOTS client as Non-confirmable messages are sent at regular intervals 532 until a response is received from the DOTS server and if the DOTS 533 client cannot maintain a RTT estimate then it SHOULD NOT send more 534 than one Non-confirmable request every 3 seconds, and SHOULD use an 535 even less aggressive rate when possible (case 2 in Section 3.1.3 of 536 [RFC8085]). 538 5.3.1. Requesting mitigation 540 When a DOTS client requires mitigation for any reason, the DOTS 541 client uses CoAP PUT method to send a mitigation request to the DOTS 542 server (Figure 5, illustrated in JSON diagnostic notation). The DOTS 543 server can enable mitigation on behalf of the DOTS client by 544 communicating the DOTS client's request to the mitigator and relaying 545 selected mitigator feedback to the requesting DOTS client. 547 Header: PUT (Code=0.03) 548 Uri-Host: "host" 549 Uri-Path: "version" 550 Uri-Path: "dots-signal" 551 Uri-Path: "signal" 552 Content-Type: "application/cbor" 553 { 554 "mitigation-scope": { 555 "scope": [ 556 { 557 "mitigation-id": integer, 558 "target-ip": [ 559 "string" 560 ], 561 "target-prefix": [ 562 "string" 563 ], 564 "target-port-range": [ 565 { 566 "lower-port": integer, 567 "upper-port": integer 568 } 569 ], 570 "target-protocol": [ 571 integer 572 ], 573 "fqdn": [ 574 "string" 575 ], 576 "uri": [ 577 "string" 578 ], 579 "alias": [ 580 "string" 581 ], 582 "lifetime": integer 583 } 584 ] 585 } 586 } 588 Figure 5: PUT to convey DOTS signals 590 The parameters are described below. 592 mitigation-id: Identifier for the mitigation request represented 593 using an integer. This identifier MUST be unique for each 594 mitigation request bound to the DOTS client, i.e., the mitigation- 595 id parameter value in the mitigation request needs to be unique 596 relative to the mitigation-id parameter values of active 597 mitigation requests conveyed from the DOTS client to the DOTS 598 server. This identifier MUST be generated by the DOTS client. 599 This document does not make any assumption about how this 600 identifier is generated. This is a mandatory attribute. 602 target-ip: A list of IP addresses under attack. This is an optional 603 attribute. 605 target-prefix: A list of prefixes under attack. Prefixes are 606 represented using CIDR notation [RFC4632]. This is an optional 607 attribute. 609 target-port-range: A list of ports under attack. The port range, 610 lower-port for lower port number and upper-port for upper port 611 number. When only lower-port is present, it represents a single 612 port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g., 613 1024-65535). This is an optional attribute. 615 target-protocol: A list of protocols under attack. Internet 616 Protocol numbers. This is an optional attribute. 618 fqdn: A list of Fully Qualified Domain Names. Fully Qualified 619 Domain Name (FQDN) is the full name of a system, rather than just 620 its hostname. For example, "venera" is a hostname, and 621 "venera.isi.edu" is an FQDN. This is an optional attribute. 623 uri: A list of Uniform Resource Identifiers (URI). This is an 624 optional attribute. 626 alias: A list of aliases. Aliases can be created using the DOTS 627 data channel (Section 3.1.1 in [I-D.ietf-dots-data-channel]) or 628 direct configuration , or other means and then used in subsequent 629 signal channel exchanges to refer more efficiently to the 630 resources under attack. This is an optional attribute. 632 lifetime: Lifetime of the mitigation request in seconds. Upon the 633 expiry of this lifetime, and if the request is not refreshed, the 634 mitigation request is removed. The request can be refreshed by 635 sending the same request again. The default lifetime of the 636 mitigation request is 3600 seconds (60 minutes) -- this value was 637 chosen to be long enough so that refreshing is not typically a 638 burden on the DOTS client, while expiring the request where the 639 client has unexpectedly quit in a timely manner. A lifetime of 640 zero indicates indefinite lifetime for the mitigation request. 641 The server MUST always indicate the actual lifetime in the 642 response and the remaining lifetime in status messages sent to the 643 client. This is an optional attribute in the request. 645 The CBOR key values for the parameters are defined in Section 6. The 646 IANA Considerations section defines how the CBOR key values can be 647 allocated to standards bodies and vendors. In the PUT request at 648 least one of the attributes target-ip or target-prefix or fqdn or uri 649 or alias MUST be present. DOTS agents can safely ignore Vendor- 650 Specific parameters they don't understand. The relative order of two 651 mitigation requests from a DOTS client is determined by comparing 652 their respective mitigation-id values. If two mitigation requests 653 have overlapping mitigation scopes the mitigation request with higher 654 numeric mitigation-id value will override the mitigation request with 655 a lower numeric mitigation-id value. The Uri-Path option carries a 656 major and minor version nomenclature to manage versioning and DOTS 657 signal channel in this specification uses v1 major version. 659 In both DOTS signal and data channel sessions, the DOTS client MUST 660 authenticate itself to the DOTS server (Section 9). The DOTS server 661 can use the algorithm discussed in Section 7 of [RFC7589] to derive 662 the DOTS client identity or username from the client certificate. 663 The DOTS server couples the DOTS signal and data channel sessions 664 using the DOTS client identity, so the DOTS server can validate 665 whether the aliases conveyed in the mitigation request were indeed 666 created by the same DOTS client using the DOTS data channel session. 667 If the aliases were not created by the DOTS client then the DOTS 668 server returns 4.00 (Bad Request) in the response. The DOTS server 669 couples the DOTS signal channel sessions using the DOTS client 670 identity, and the DOTS server uses mitigation-id parameter value to 671 detect duplicate mitigation requests. 673 Figure 6 shows a PUT request example to signal that ports 80, 8080, 674 and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are 675 being attacked (illustrated in JSON diagnostic notation). 677 Header: PUT (Code=0.03) 678 Uri-Host: "www.example.com" 679 Uri-Path: "v1" 680 Uri-Path: "dots-signal" 681 Uri-Path: "signal" 682 Content-Format: "application/cbor" 683 { 684 "mitigation-scope": { 685 "scope": [ 686 { 687 "mitigation-id": 12332, 688 "target-ip": [ 689 "2001:db8:6401::1", 690 "2001:db8:6401::2" 691 ], 692 "target-port-range": [ 693 { 694 "lower-port": 80 695 }, 696 { 697 "lower-port": 443 698 }, 699 { 700 "lower-port": 8080 701 } 702 ], 703 "target-protocol": [ 704 6 705 ] 706 } 707 ] 708 } 709 } 711 The CBOR encoding format is shown below: 713 a1 # map(1) 714 01 # unsigned(1) 715 a1 # map(1) 716 02 # unsigned(2) 717 81 # array(1) 718 a4 # map(4) 719 03 # unsigned(3) 720 19 302c # unsigned(12332) 721 04 # unsigned(4) 722 82 # array(2) 723 70 # text(16) 724 323030313A6462383A363430313A3A31 # "2001:db8:6401::1" 725 70 # text(16) 726 323030313A6462383A363430313A3A32 # "2001:db8:6401::2" 727 05 # unsigned(5) 728 83 # array(3) 729 a1 # map(1) 730 06 # unsigned(6) 731 18 50 # unsigned(80) 732 a1 # map(1) 733 06 # unsigned(6) 734 19 01bb # unsigned(443) 735 a1 # map(1) 736 06 # unsigned(6) 737 19 1f90 # unsigned(8080) 739 08 # unsigned(8) 740 81 # array(1) 741 06 # unsigned(6) 743 Figure 6: POST for DOTS signal 745 The DOTS server indicates the result of processing the PUT request 746 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 747 codes are some sort of invalid requests. COAP 5.xx codes are 748 returned if the DOTS server has erred or is currently unavailable to 749 provide mitigation in response to the mitigation request from the 750 DOTS client. If the DOTS server does not find the mitigation-id 751 parameter value conveyed in the PUT request in its configuration data 752 then the server MAY accept the mitigation request, and a 2.01 753 (Created) response is returned to the DOTS client, and the DOTS 754 server will try to mitigate the attack. If the DOTS server finds the 755 mitigation-id parameter value conveyed in the PUT request in its 756 configuration data then the server MAY update the mitigation request, 757 and a 2.04 (Changed) response is returned to indicate a successful 758 update of the mitigation request. If the request is missing one or 759 more mandatory attributes, then 4.00 (Bad Request) will be returned 760 in the response or if the request contains invalid or unknown 761 parameters then 4.02 (Invalid query) will be returned in the 762 response. For responses indicating a client or server error, the 763 payload explains the error situation of the result of the requested 764 action (Section 5.5 in [RFC7252]). 766 5.3.2. Withdraw a DOTS Signal 768 A DELETE request is used to withdraw a DOTS signal from a DOTS server 769 (Figure 7). 771 Header: DELETE (Code=0.04) 772 Uri-Host: "host" 773 Uri-Path: "version" 774 Uri-Path: "dots-signal" 775 Uri-Path: "signal" 776 Content-Format: "application/cbor" 777 { 778 "mitigation-scope": { 779 "scope": [ 780 { 781 "mitigation-id": integer 782 } 783 ] 784 } 785 } 787 Figure 7: Withdraw DOTS signal 789 If the DOTS server does not find the mitigation-id parameter value 790 conveyed in the DELETE request in its configuration data, then it 791 responds with a 4.04 (Not Found) error response code. The DOTS 792 server successfully acknowledges a DOTS client's request to withdraw 793 the DOTS signal using 2.02 (Deleted) response code, and ceases 794 mitigation activity as quickly as possible. 796 To protect against route or DNS flapping caused by a client rapidly 797 toggling mitigation, and to dampen the effect of oscillating attacks, 798 DOTS servers MAY continue mitigation for a period of up to five 799 minutes after acknowledging a DOTS client's withdrawal of a 800 mitigation request. During this period, DOTS server status messages 801 SHOULD indicate that mitigation is active but terminating. After the 802 five-minute period elapses, the DOTS server MUST treat the mitigation 803 as terminated, as the DOTS client is no longer responsible for the 804 mitigation. For example, if there is a financial relationship 805 between the DOTS client and server domains, the DOTS client ceases 806 incurring cost at this point. 808 5.3.3. Retrieving a DOTS Signal 810 A GET request is used to retrieve information and status of a DOTS 811 signal from a DOTS server (Figure 8). If the DOTS server does not 812 find the mitigation-id parameter value conveyed in the GET request in 813 its configuration data, then it responds with a 4.04 (Not Found) 814 error response code. The 'c' (content) parameter and its permitted 815 values defined in [I-D.ietf-core-comi] can be used to retrieve non- 816 configuration data or configuration data or both. 818 1) To retrieve all DOTS signals signaled by the DOTS client. 820 Header: GET (Code=0.01) 821 Uri-Host: "host" 822 Uri-Path: "version" 823 Uri-Path: "dots-signal" 824 Uri-Path: "signal" 825 Observe : 0 827 2) To retrieve a specific DOTS signal signaled by the DOTS client. 828 The configuration data in the response will be formatted in the 829 same order it was processed at the DOTS server. 831 Header: GET (Code=0.01) 832 Uri-Host: "host" 833 Uri-Path: "version" 834 Uri-Path: "dots-signal" 835 Uri-Path: "signal" 836 Observe : 0 837 Content-Format: "application/cbor" 838 { 839 "mitigation-scope": { 840 "scope": [ 841 { 842 "mitigation-id": integer 843 } 844 ] 845 } 846 } 848 Figure 8: GET to retrieve the rules 850 Figure 9 shows a response example of all the active mitigation 851 requests associated with the DOTS client on the DOTS server and the 852 mitigation status of each mitigation request. 854 { 855 "mitigation-scope":[ 856 { 857 "scope": [ 858 { 859 "mitigation-id": 12332, 860 "target-protocol": [ 861 17 862 ], 863 "lifetime":1800, 864 "status":2, 865 "bytes-dropped": 134334555, 866 "bps-dropped": 43344, 867 "pkts-dropped": 333334444, 868 "pps-dropped": 432432 869 } 870 ] 871 }, 872 { 873 "scope": [ 874 { 875 "mitigation-id": 12333, 876 "target-protocol": [ 877 6 878 ], 879 "lifetime":1800, 880 "status":3 881 "bytes-dropped": 0, 882 "bps-dropped": 0, 883 "pkts-dropped": 0, 884 "pps-dropped": 0 885 } 886 ] 887 } 888 ] 889 } 891 Figure 9: Response body 893 The mitigation status parameters are described below. 895 bytes-dropped: The total dropped byte count for the mitigation 896 request. This is a optional attribute. 898 bps-dropped: The average dropped bytes per second for the mitigation 899 request. This is a optional attribute. 901 pkts-dropped: The total dropped packet count for the mitigation 902 request. This is a optional attribute. 904 pps-dropped: The average dropped packets per second for the 905 mitigation request. This is a optional attribute. 907 status: Status of attack mitigation. The 'status' parameter is a 908 mandatory attribute. 910 The various possible values of 'status' parameter are explained 911 below: 913 /--------------------+---------------------------------------------------\ 914 | Parameter value | Description | 915 |--------------------+---------------------------------------------------| 916 | 1 | Attack mitigation is in progress | 917 | | (e.g., changing the network path to re-route the | 918 | | inbound traffic to DOTS mitigator). | 919 +------------------------------------------------------------------------+ 920 | 2 | Attack is successfully mitigated | 921 | | (e.g., traffic is redirected to a DDOS mitigator | 922 | | and attack traffic is dropped). | 923 +------------------------------------------------------------------------+ 924 | 3 | Attack has stopped and the DOTS client | 925 | | can withdraw the mitigation request. | 926 +------------------------------------------------------------------------+ 927 | 4 | Attack has exceeded the mitigation provider | 928 | | capability. | 929 +------------------------------------------------------------------------+ 930 | 5 | DOTS client has withdrawn the mitigation request | 931 and the mitigation is active but terminating. | 932 | | | 933 \--------------------+---------------------------------------------------/ 935 The observe option defined in [RFC7641] extends the CoAP core 936 protocol with a mechanism for a CoAP client to "observe" a resource 937 on a CoAP server: the client retrieves a representation of the 938 resource and requests this representation be updated by the server as 939 long as the client is interested in the resource. A DOTS client 940 conveys the observe option set to 0 in the GET request to receive 941 unsolicited notifications of attack mitigation status from the DOTS 942 server. Unidirectional notifications within the bidirectional signal 943 channel allows unsolicited message delivery, enabling asynchronous 944 notifications between the agents. A DOTS client that is no longer 945 interested in receiving notifications from the DOTS server can simply 946 "forget" the observation. When the DOTS server then sends the next 947 notification, the DOTS client will not recognize the token in the 948 message and thus will return a Reset message. This causes the DOTS 949 server to remove the associated entry. 951 DOTS Client DOTS Server 952 | | 953 | GET / | 954 | Token: 0x4a | Registration 955 | Observe: 0 | 956 +------------------------------>| 957 | | 958 | 2.05 Content | 959 | Token: 0x4a | Notification of 960 | Observe: 12 | the current state 961 | status: "mitigation | 962 | in progress" | 963 |<------------------------------+ 964 | 2.05 Content | 965 | Token: 0x4a | Notification upon 966 | Observe: 44 | a state change 967 | status: "mitigation | 968 | complete" | 969 |<------------------------------+ 970 | 2.05 Content | 971 | Token: 0x4a | Notification upon 972 | Observe: 60 | a state change 973 | status: "attack stopped" | 974 |<------------------------------+ 975 | | 977 Figure 10: Notifications of attack mitigation status 979 5.3.3.1. Mitigation Status 981 A DOTS client retrieves the information about a DOTS signal at 982 frequent intervals to determine the status of an attack. If the DOTS 983 server has been able to mitigate the attack and the attack has 984 stopped, the DOTS server indicates as such in the status, and the 985 DOTS client recalls the mitigation request. 987 A DOTS client should react to the status of the attack from the DOTS 988 server and not the fact that it has recognized, using its own means, 989 that the attack has been mitigated. This ensures that the DOTS 990 client does not recall a mitigation request in a premature fashion 991 because it is possible that the DOTS client does not sense the DDOS 992 attack on its resources but the DOTS server could be actively 993 mitigating the attack and the attack is not completely averted. 995 5.3.4. Efficacy Update from DOTS Client 997 While DDoS mitigation is active, a DOTS client MAY frequently 998 transmit DOTS mitigation efficacy updates to the relevant DOTS 999 server. An PUT request (Figure 11) is used to convey the mitigation 1000 efficacy update to the DOTS server. The PUT request MUST include all 1001 the parameters used in the PUT request to convey the DOTS signal 1002 (Section 5.3.1). 1004 Header: PUT (Code=0.03) 1005 Uri-Host: "host" 1006 Uri-Path: "version" 1007 Uri-Path: "dots-signal" 1008 Uri-Path: "signal" 1009 Content-Format: "application/cbor" 1010 { 1011 "mitigation-scope": { 1012 "scope": [ 1013 { 1014 "mitigation-id": integer, 1015 "target-ip": [ 1016 "string" 1017 ], 1018 "target-port-range": [ 1019 { 1020 "lower-port": integer, 1021 "upper-port": integer 1022 } 1023 ], 1024 "target-protocol": [ 1025 integer 1026 ], 1027 "fqdn": [ 1028 "string" 1029 ], 1030 "uri": [ 1031 "string" 1032 ], 1033 "alias": [ 1034 "string" 1035 ], 1036 "lifetime": integer, 1037 "attack-status": integer 1038 } 1039 ] 1040 } 1041 } 1043 Figure 11: Efficacy Update 1045 The 'attack-status' parameter is a mandatory attribute. The various 1046 possible values contained in the 'attack-status' parameter are 1047 explained below: 1049 /--------------------+------------------------------------------------------\ 1050 | Parameter value | Description | 1051 |--------------------+------------------------------------------------------| 1052 | 1 | DOTS client determines that it is still under attack.| 1053 +---------------------------------------------------------------------------+ 1054 | 2 | DOTS client determines that the attack is | 1055 | | successfully mitigated | 1056 | | (e.g., attack traffic is not seen). | 1057 \--------------------+------------------------------------------------------/ 1059 The DOTS server indicates the result of processing the PUT request 1060 using CoAP response codes. The response code 2.04 (Changed) will be 1061 returned in the response if the DOTS server has accepted the 1062 mitigation efficacy update. If the DOTS server does not find the 1063 mitigation-id parameter value conveyed in the PUT request in its 1064 configuration data then the server MAY accept the mitigation request 1065 and will try to mitigate the attack, resulting in a 2.01 (Created) 1066 Response Code. The 5.xx response codes are returned if the DOTS 1067 server has erred or is incapable of performing the mitigation. 1069 5.4. DOTS Signal Channel Session Configuration 1071 The DOTS client can negotiate, configure and retrieve the DOTS signal 1072 channel session behavior. The DOTS signal channel can be used, for 1073 example, to configure the following: 1075 a. Heartbeat timeout: DOTS agents regularly send heartbeats (Ping/ 1076 Pong) to each other after mutual authentication in order to keep 1077 the DOTS signal channel open, heartbeat timeout is the time to 1078 wait for a Pong in milliseconds. 1080 b. Acceptable signal loss ratio: Maximum retransmissions, 1081 retransmission timeout value and other message transmission 1082 parameters for the DOTS signal channel. 1084 Reliability is provided to requests and responses by marking them as 1085 Confirmable (CON) messages. DOTS signal channel session 1086 configuration requests and responses are marked as Confirmable (CON) 1087 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1088 message is retransmitted using a default timeout and exponential 1089 back-off between retransmissions, until the DOTS server sends an 1090 Acknowledgement message (ACK) with the same Message ID conveyed from 1091 the DOTS client. Message transmission parameters are defined in 1092 Section 4.8 of [RFC7252]. Reliability is provided to the responses 1093 by marking them as Confirmable (CON) messages. The DOTS server can 1094 either piggyback the response in the acknowledgement message or if 1095 the DOTS server is not able to respond immediately to a request 1096 carried in a Confirmable message, it simply responds with an Empty 1097 Acknowledgement message so that the DOTS client can stop 1098 retransmitting the request. Empty Acknowledgement message is 1099 explained in Section 2.2 of [RFC7252]. When the response is ready, 1100 the server sends it in a new Confirmable message which then in turn 1101 needs to be acknowledged by the DOTS client (see Sections 5.2.1 and 1102 Sections 5.2.2 in [RFC7252]). Requests and responses exchanged 1103 between DOTS agents during peacetime are marked as Confirmable 1104 messages. 1106 Implementation Note: A DOTS client that receives a response in a CON 1107 message may want to clean up the message state right after sending 1108 the ACK. If that ACK is lost and the DOTS server retransmits the 1109 CON, the DOTS client may no longer have any state to which to 1110 correlate this response, making the retransmission an unexpected 1111 message; the DOTS client will send a Reset message so it does not 1112 receive any more retransmissions. This behavior is normal and not an 1113 indication of an error (see Section 5.3.2 in [RFC7252] for more 1114 details). 1116 5.4.1. Discover Acceptable Configuration Parameters 1118 A GET request is used to obtain acceptable configuration parameters 1119 on the DOTS server for DOTS signal channel session configuration. 1120 Figure 12 shows how to obtain acceptable configuration parameters for 1121 the server. 1123 Header: GET (Code=0.01) 1124 Uri-Host: "host" 1125 Uri-Path: "version" 1126 Uri-Path: "dots-signal" 1127 Uri-Path: "config" 1129 Figure 12: GET to retrieve configuration 1131 The DOTS server in the 2.05 (Content) response conveys the minimum 1132 and maximum attribute values acceptable by the DOTS server. 1134 Content-Format: "application/cbor" 1135 { 1136 "heartbeat-timeout": {"MinValue": integer, "MaxValue" : integer}, 1137 "max-retransmit": {"MinValue": integer, "MaxValue" : integer}, 1138 "ack-timeout": {"MinValue": integer, "MaxValue" : integer}, 1139 "ack-random-factor": {"MinValue": number, "MaxValue" : number} 1140 } 1142 Figure 13: GET response body 1144 5.4.2. Convey DOTS Signal Channel Session Configuration 1146 A POST request is used to convey the configuration parameters for the 1147 signaling channel (e.g., heartbeat timeout, maximum retransmissions 1148 etc). Message transmission parameters for CoAP are defined in 1149 Section 4.8 of [RFC7252]. If the DOTS agent wishes to change the 1150 default values of message transmission parameters then it should 1151 follow the guidance given in Section 4.8.1 of [RFC7252]. The DOTS 1152 agents MUST use the negotiated values for message transmission 1153 parameters and default values for non-negotiated message transmission 1154 parameters. The signaling channel session configuration is 1155 applicable to a single DOTS signal channel session between the DOTS 1156 agents. 1158 Header: POST (Code=0.02) 1159 Uri-Host: "host" 1160 Uri-Path: "version" 1161 Uri-Path: "dots-signal" 1162 Uri-Path: "config" 1163 Content-Format: "application/cbor" 1164 { 1165 "signal-config": { 1166 "session-id": integer, 1167 "heartbeat-timeout": integer, 1168 "max-retransmit": integer, 1169 "ack-timeout": integer, 1170 "ack-random-factor": number 1171 } 1172 } 1174 Figure 14: POST to convey the DOTS signal channel session 1175 configuration data. 1177 The parameters are described below: 1179 session-id: Identifier for the DOTS signal channel session 1180 configuration data represented as an integer. This identifier 1181 MUST be generated by the DOTS client. This document does not make 1182 any assumption about how this identifier is generated. This is a 1183 mandatory attribute. 1185 heartbeat-timeout: Heartbeat timeout is the time to wait for a 1186 response in milliseconds to check the DOTS peer health. This is 1187 an optional attribute. 1189 max-retransmit: Maximum number of retransmissions for a message 1190 (referred to as MAX_RETRANSMIT parameter in CoAP). This is an 1191 optional attribute. 1193 ack-timeout: Timeout value in seconds used to calculate the initial 1194 retransmission timeout value (referred to as ACK_TIMEOUT parameter 1195 in CoAP). This is an optional attribute. 1197 ack-random-factor: Random factor used to influence the timing of 1198 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1199 CoAP). This is an optional attribute. 1201 In the POST request at least one of the attributes heartbeat-timeout 1202 or max-retransmit or ack-timeout or ack-random-factor MUST be 1203 present. The POST request with higher numeric session-id value over- 1204 rides the DOTS signal channel session configuration data installed by 1205 a POST request with a lower numeric session-id value. 1207 Figure 15 shows a POST request example to convey the configuration 1208 parameters for the DOTS signal channel. 1210 Header: POST (Code=0.02) 1211 Uri-Host: "www.example.com" 1212 Uri-Path: "v1" 1213 Uri-Path: "dots-signal" 1214 Uri-Path: "config" 1215 Content-Format: "application/cbor" 1216 { 1217 "signal-config": { 1218 "session-id": 1234534333242, 1219 "heartbeat-timeout": 30, 1220 "max-retransmit": 7, 1221 "ack-timeout": 5, 1222 "ack-random-factor": 1.5 1223 } 1224 } 1226 Figure 15: POST to convey the configuration parameters 1228 The DOTS server indicates the result of processing the POST request 1229 using CoAP response codes. The CoAP response will include the CBOR 1230 body received in the request. Response code 2.01 (Created) will be 1231 returned in the response if the DOTS server has accepted the 1232 configuration parameters. If the request is missing one or more 1233 mandatory attributes then 4.00 (Bad Request) will be returned in the 1234 response or if the request contains invalid or unknown parameters 1235 then 4.02 (Invalid query) will be returned in the response. Response 1236 code 4.22 (Unprocessable Entity) will be returned in the response if 1237 any of the heartbeat-timeout, max-retransmit, target-protocol, ack- 1238 timeout and ack-random-factor attribute values is not acceptable to 1239 the DOTS server. The DOTS server in the error response conveys the 1240 minimum and maximum attribute values acceptable by the DOTS server. 1242 The DOTS client can re-try and send the POST request with updated 1243 attribute values acceptable to the DOTS server. 1245 Content-Format: "application/cbor" 1246 { 1247 "heartbeat-timeout": {"MinValue": 15, "MaxValue" : 60}, 1248 "max-retransmit": {"MinValue": 3, "MaxValue" : 15}, 1249 "ack-timeout": {"MinValue": 1, "MaxValue" : 30}, 1250 "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0} 1251 } 1253 Figure 16: Error response body 1255 5.4.3. Delete DOTS Signal Channel Session Configuration 1257 A DELETE request is used to delete the installed DOTS signal channel 1258 session configuration data (Figure 17). 1260 Header: DELETE (Code=0.04) 1261 Uri-Host: "host" 1262 Uri-Path: "version" 1263 Uri-Path: "dots-signal" 1264 Uri-Path: "config" 1265 Content-Format: "application/cbor" 1266 { 1267 "signal-config": { 1268 "session-id": integer 1269 } 1270 } 1272 Figure 17: DELETE configuration 1274 If the DOTS server does not find the session-id parameter value 1275 conveyed in the DELETE request in its configuration data, then it 1276 responds with a 4.04 (Not Found) error response code. The DOTS 1277 server successfully acknowledges a DOTS client's request to remove 1278 the DOTS signal channel session configuration using 2.02 (Deleted) 1279 response code. 1281 5.4.4. Retrieving DOTS Signal Channel Session Configuration 1283 A GET request is used to retrieve the installed DOTS signal channel 1284 session configuration data from a DOTS server. Figure 18 shows how 1285 to retrieve the DOTS signal channel session configuration data. 1287 Header: GET (Code=0.01) 1288 Uri-Host: "host" 1289 Uri-Path: "version" 1290 Uri-Path: "dots-signal" 1291 Uri-Path: "config" 1292 Content-Format: "application/cbor" 1293 { 1294 "signal-config": { 1295 "session-id": integer 1296 } 1297 } 1299 Figure 18: GET to retrieve configuration 1301 5.5. Redirected Signaling 1303 Redirected Signaling is discussed in detail in Section 3.2.2 of 1304 [I-D.ietf-dots-architecture]. If the DOTS server wants to redirect 1305 the DOTS client to an alternative DOTS server for a signaling session 1306 then the response code 3.00 (alternate server) will be returned in 1307 the response to the client. The DOTS server can return the error 1308 response code 3.00 in response to a POST or PUT request from the DOTS 1309 client or convey the error response code 3.00 in a unidirectional 1310 notification response from the DOTS server. 1312 The DOTS server in the error response conveys the alternate DOTS 1313 server FQDN, and the alternate DOTS server IP addresses and time to 1314 live values in the CBOR body. 1316 { 1317 "alt-server": "string", 1318 "alt-server-record": [ 1319 { 1320 "addr": "string", 1321 "ttl" : integer, 1322 } 1323 ] 1324 } 1326 Figure 19: Error response body 1328 The parameters are described below: 1330 alt-server: FQDN of alternate DOTS server. 1332 addr: IP address of alternate DOTS server. 1334 ttl: Time to live (TTL) represented as an integer number of seconds. 1336 Figure 20 shows a 3.00 response example to convey the DOTS alternate 1337 server www.example-alt.com, its IP addresses 2001:db8:6401::1 and 1338 2001:db8:6401::2, and TTL values 3600 and 1800. 1340 { 1342 "alt-server": "www.example-alt.com", 1343 "alt-server-record": [ 1344 { 1345 "ttl" : 3600, 1346 "addr": "2001:db8:6401::1" 1347 }, 1348 { 1349 "ttl" : 1800, 1350 "addr": "2001:db8:6401::2" 1351 } 1352 ] 1353 } 1355 Figure 20: Example of error response body 1357 When the DOTS client receives 3.00 response, it considers the current 1358 request as having failed, but SHOULD try the request with the 1359 alternate DOTS server. During a DDOS attack, the DNS server may be 1360 subjected to DDOS attack, alternate DOTS server IP addresses conveyed 1361 in the 3.00 response help the DOTS client to skip DNS lookup of the 1362 alternate DOTS server and can try to establish UDP or TCP session 1363 with the alternate DOTS server IP addresses. The DOTS client SHOULD 1364 implement DNS64 function to handle the scenario where IPv6-only DOTS 1365 client communicates with IPv4-only alternate DOTS server. 1367 5.6. Heartbeat Mechanism 1369 While the communication between the DOTS agents is quiescent, the 1370 DOTS client will probe the DOTS server to ensure it has maintained 1371 cryptographic state and vice versa. Such probes can also keep alive 1372 firewall or NAT bindings. This probing reduces the frequency of 1373 needing a new handshake when a DOTS signal needs to be conveyed to 1374 the DOTS server. In DOTS over UDP, heartbeat messages can be 1375 exchanged between the DOTS agents using the "COAP ping" mechanism 1376 (Section 4.2 in [RFC7252]). The DOTS agent sends an Empty 1377 Confirmable message and the peer DOTS agent will respond by sending 1378 an Reset message. In DOTS over TCP, heartbeat messages can be 1379 exchanged between the DOTS agents using the Ping and Pong messages 1380 (Section 4.4 in [I-D.ietf-core-coap-tcp-tls]). The DOTS agent sends 1381 an Ping message and the peer DOTS agent will respond by sending an 1382 single Pong message. 1384 6. Mapping parameters to CBOR 1386 All parameters in DOTS signal channel are mapped to CBOR types as 1387 follows and are given an integer key value to save space. 1389 /--------------------+------------------------+--------------------------\ 1390 | Parameter name | CBOR key | CBOR major type of value | 1391 |--------------------+------------------------+--------------------------| 1392 | mitigation-scope | 1 | 5 (map) | 1393 | scope | 2 | 5 (map) | 1394 | mitigation-id | 3 | 0 (unsigned) | 1395 | target-ip | 4 | 4 (array) | 1396 | target-port-range | 5 | 4 | 1397 | lower-port | 6 | 0 | 1398 | upper-port | 7 | 0 | 1399 | target-protocol | 8 | 4 | 1400 | fqdn | 9 | 4 | 1401 | uri | 10 | 4 | 1402 | alias | 11 | 4 | 1403 | lifetime | 12 | 0 | 1404 | attack-status | 13 | 0 | 1405 | signal-config | 14 | 5 | 1406 | heartbeat-timeout | 15 | 0 | 1407 | max-retransmit | 16 | 0 | 1408 | ack-timeout | 17 | 0 | 1409 | ack-random-factor | 18 | 7 | 1410 | MinValue | 19 | 0 | 1411 | MaxValue | 20 | 0 | 1412 | status | 21 | 0 | 1413 | bytes-dropped | 22 | 0 | 1414 | bps-dropped | 23 | 0 | 1415 | pkts-dropped | 24 | 0 | 1416 | pps-dropped | 25 | 0 | 1417 | session-id | 26 | 0 | 1418 \--------------------+------------------------+--------------------------/ 1420 Figure 21: CBOR mappings used in DOTS signal channel message 1422 7. (D)TLS Protocol Profile and Performance considerations 1424 This section defines the (D)TLS protocol profile of DOTS signal 1425 channel over (D)TLS and DOTS data channel over TLS. 1427 There are known attacks on (D)TLS, such as machine-in-the-middle and 1428 protocol downgrade. These are general attacks on (D)TLS and not 1429 specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for 1430 discussion of these security issues. DOTS agents MUST adhere to the 1431 (D)TLS implementation recommendations and security considerations of 1433 [RFC7525] except with respect to (D)TLS version. Since encryption of 1434 DOTS using (D)TLS is virtually a green-field deployment DOTS agents 1435 MUST implement only (D)TLS 1.2 or later. 1437 Implementations compliant with this profile MUST implement all of the 1438 following items: 1440 o DOTS agents MUST support DTLS record replay detection (Section 3.3 1441 in [RFC6347]) to protect against replay attacks. 1443 o DOTS client can use (D)TLS session resumption without server-side 1444 state [RFC5077] to resume session and convey the DOTS signal. 1446 o Raw public keys [RFC7250] which reduce the size of the 1447 ServerHello, and can be used by servers that cannot obtain 1448 certificates (e.g., DOTS gateways on private networks). 1450 Implementations compliant with this profile SHOULD implement all of 1451 the following items to reduce the delay required to deliver a DOTS 1452 signal: 1454 o TLS False Start [RFC7918] which reduces round-trips by allowing 1455 the TLS second flight of messages (ChangeCipherSpec) to also 1456 contain the DOTS signal. 1458 o Cached Information Extension [RFC7924] which avoids transmitting 1459 the server's certificate and certificate chain if the client has 1460 cached that information from a previous TLS handshake. 1462 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 1463 convey DOTS signal. 1465 7.1. MTU and Fragmentation Issues 1467 To avoid DOTS signal message fragmentation and the consequently 1468 decreased probability of message delivery, DOTS agents MUST ensure 1469 that the DTLS record MUST fit within a single datagram. If the Path 1470 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 1471 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 1472 is used to convey the DOTS signal messages then the DOTS client must 1473 consider the amount of record expansion expected by the DTLS 1474 processing when calculating the size of CoAP message that fits within 1475 the path MTU. Path MTU MUST be greater than or equal to [CoAP 1476 message size + DTLS overhead of 13 octets + authentication overhead 1477 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 1478 of [RFC6347]]. If the request size exceeds the Path MTU then the 1479 DOTS client MUST split the DOTS signal into separate messages, for 1480 example the list of addresses in the 'target-ip' parameter could be 1481 split into multiple lists and each list conveyed in a new POST 1482 request. 1484 Implementation Note: DOTS choice of message size parameters works 1485 well with IPv6 and with most of today's IPv4 paths. However, with 1486 IPv4, it is harder to absolutely ensure that there is no IP 1487 fragmentation. If IPv4 support on unusual networks is a 1488 consideration and path MTU is unknown, implementations may want to 1489 limit themselves to more conservative IPv4 datagram sizes such as 576 1490 bytes, as per [RFC0791] IP packets up to 576 bytes should never need 1491 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal 1492 over a UDP datagram will generally avoid IP fragmentation. 1494 8. (D)TLS 1.3 considerations 1496 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 1497 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 1498 [I-D.rescorla-tls-dtls13] is based on the TLS 1.3 protocol and 1499 provides equivalent security guarantees. (D)TLS 1.3 provides two 1500 basic handshake modes of interest to DOTS signal channel: 1502 o Absent packet loss, a full handshake in which the DOTS client is 1503 able to send the DOTS signal message after one round trip and the 1504 DOTS server immediately after receiving the first DOTS signal 1505 message from the client. 1507 o 0-RTT mode in which the DOTS client can authenticate itself and 1508 send DOTS signal message on its first flight, thus reducing 1509 handshake latency. 0-RTT only works if the DOTS client has 1510 previously communicated with that DOTS server, which is very 1511 likely with the DOTS signal channel. The DOTS client SHOULD 1512 establish a (D)TLS session with the DOTS server during peacetime 1513 and share a PSK. During DDOS attack, the DOTS client can use the 1514 (D)TLS session to convey the DOTS signal message and if there is 1515 no response from the server after multiple re-tries then the DOTS 1516 client can resume the (D)TLS session in 0-RTT mode using PSK. A 1517 simplified TLS 1.3 handshake with 0-RTT DOTS signal message 1518 exchange is shown in Figure 22. 1520 DOTS Client DOTS Server 1522 ClientHello 1523 (Finished) 1524 (0-RTT DOTS signal message) 1525 (end_of_early_data) --------> 1526 ServerHello 1527 {EncryptedExtensions} 1528 {ServerConfiguration} 1529 {Certificate} 1530 {CertificateVerify} 1531 {Finished} 1532 <-------- [DOTS signal message] 1533 {Finished} --------> 1535 [DOTS signal message] <-------> [DOTS signal message] 1537 Figure 22: TLS 1.3 handshake with 0-RTT 1539 9. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 1541 (D)TLS based on client certificate can be used for mutual 1542 authentication between DOTS agents. If a DOTS gateway is involved, 1543 DOTS clients and DOTS gateway MUST perform mutual authentication; 1544 only authorized DOTS clients are allowed to send DOTS signals to a 1545 DOTS gateway. DOTS gateway and DOTS server MUST perform mutual 1546 authentication; DOTS server only allows DOTS signals from authorized 1547 DOTS gateway, creating a two-link chain of transitive authentication 1548 between the DOTS client and the DOTS server. 1550 +-------------------------------------------------+ 1551 | example.com domain +---------+ | 1552 | | AAA | | 1553 | +---------------+ | Server | | 1554 | | Application | +------+--+ | 1555 | | server + ^ 1556 | | (DOTS client) |<-----------------+ | | 1557 | +---------------+ + | | example.net domain 1558 | V V | 1559 | +-------------+ | +---------------+ 1560 | +--------------+ | | | | | 1561 | | Guest +<-----x----->+ +<---------------->+ DOTS | 1562 | | (DOTS client)| | DOTS | | | Server | 1563 | +--------------+ | Gateway | | | | 1564 | +----+--------+ | +---------------+ 1565 | ^ | 1566 | | | 1567 | +----------------+ | | 1568 | | DDOS detector | | | 1569 | | (DOTS client) +<--------------+ | 1570 | +----------------+ | 1571 | | 1572 +-------------------------------------------------+ 1574 Figure 23: Example of Authentication and Authorization of DOTS Agents 1576 In the example depicted in Figure 23, the DOTS gateway and DOTS 1577 clients within the 'example.com' domain mutually authenticate with 1578 each other. After the DOTS gateway validates the identity of a DOTS 1579 client, it communicates with the AAA server in the 'example.com' 1580 domain to determine if the DOTS client is authorized to request DDOS 1581 mitigation. If the DOTS client is not authorized, a 4.01 1582 (Unauthorized) is returned in the response to the DOTS client. In 1583 this example, the DOTS gateway only allows the application server and 1584 DDOS detector to request DDOS mitigation, but does not permit the 1585 user of type 'guest' to request DDOS mitigation. 1587 Also, DOTS gateway and DOTS server MUST perform mutual authentication 1588 using certificates. A DOTS server will only allow a DOTS gateway 1589 with a certificate for a particular domain to request mitigation for 1590 that domain. In reference to Figure 23, the DOTS server only allows 1591 the DOTS gateway to request mitigation for 'example.com' domain and 1592 not for other domains. 1594 10. IANA Considerations 1596 This specification registers new parameters for DOTS signal channel 1597 and establishes registries for mappings to CBOR. 1599 10.1. DOTS signal channel CBOR Mappings Registry 1601 A new registry will be requested from IANA, entitled "DOTS signal 1602 channel CBOR Mappings Registry". The registry is to be created as 1603 Expert Review Required. 1605 10.1.1. Registration Template 1607 Parameter name: 1608 Parameter names (e.g., "target_ip") in the DOTS signal channel. 1610 CBOR Key Value: 1611 Key value for the parameter. The key value MUST be an integer in 1612 the range of 1 to 65536. The key values in the range of 32768 to 1613 65536 are assigned for Vendor-Specific parameters. 1615 CBOR Major Type: 1616 CBOR Major type and optional tag for the claim. 1618 Change Controller: 1619 For Standards Track RFCs, list the "IESG". For others, give the 1620 name of the responsible party. Other details (e.g., postal 1621 address, email address, home page URI) may also be included. 1623 Specification Document(s): 1624 Reference to the document or documents that specify the parameter, 1625 preferably including URIs that can be used to retrieve copies of 1626 the documents. An indication of the relevant sections may also be 1627 included but is not required. 1629 10.1.2. Initial Registry Contents 1631 o Parameter Name: "mitigation-scope" 1632 o CBOR Key Value: 1 1633 o CBOR Major Type: 5 1634 o Change Controller: IESG 1635 o Specification Document(s): this document 1637 o Parameter Name: "scope" 1638 o CBOR Key Value: 2 1639 o CBOR Major Type: 5 1640 o Change Controller: IESG 1641 o Specification Document(s): this document 1642 o Parameter Name: "mitigation-id" 1643 o CBOR Key Value: 3 1644 o CBOR Major Type: 0 1645 o Change Controller: IESG 1646 o Specification Document(s): this document 1648 o Parameter Name:target-ip 1649 o CBOR Key Value: 4 1650 o CBOR Major Type: 4 1651 o Change Controller: IESG 1652 o Specification Document(s): this document 1654 o Parameter Name: target-port-range 1655 o CBOR Key Value: 5 1656 o CBOR Major Type: 4 1657 o Change Controller: IESG 1658 o Specification Document(s): this document 1660 o Parameter Name: "lower-port" 1661 o CBOR Key Value: 6 1662 o CBOR Major Type: 0 1663 o Change Controller: IESG 1664 o Specification Document(s): this document 1666 o Parameter Name: "upper-port" 1667 o CBOR Key Value: 7 1668 o CBOR Major Type: 0 1669 o Change Controller: IESG 1670 o Specification Document(s): this document 1672 o Parameter Name: target-protocol 1673 o CBOR Key Value: 8 1674 o CBOR Major Type: 4 1675 o Change Controller: IESG 1676 o Specification Document(s): this document 1678 o Parameter Name: "FQDN" 1679 o CBOR Key Value: 9 1680 o CBOR Major Type: 4 1681 o Change Controller: IESG 1682 o Specification Document(s): this document 1684 o Parameter Name: "URI" 1685 o CBOR Key Value: 10 1686 o CBOR Major Type: 4 1687 o Change Controller: IESG 1688 o Specification Document(s): this document 1689 o Parameter Name: alias 1690 o CBOR Key Value: 11 1691 o CBOR Major Type: 4 1692 o Change Controller: IESG 1693 o Specification Document(s): this document 1695 o Parameter Name: "lifetime" 1696 o CBOR Key Value: 12 1697 o CBOR Major Type: 0 1698 o Change Controller: IESG 1699 o Specification Document(s): this document 1701 o Parameter Name: attack-status 1702 o CBOR Key Value: 13 1703 o CBOR Major Type: 0 1704 o Change Controller: IESG 1705 o Specification Document(s): this document 1707 o Parameter Name: signal-config 1708 o CBOR Key Value: 14 1709 o CBOR Major Type: 5 1710 o Change Controller: IESG 1711 o Specification Document(s): this document 1713 o Parameter Name: heartbeat-timeout 1714 o CBOR Key Value: 15 1715 o CBOR Major Type: 0 1716 o Change Controller: IESG 1717 o Specification Document(s): this document 1719 o Parameter Name: max-retransmit 1720 o CBOR Key Value: 16 1721 o CBOR Major Type: 0 1722 o Change Controller: IESG 1723 o Specification Document(s): this document 1725 o Parameter Name: ack-timeout 1726 o CBOR Key Value: 17 1727 o CBOR Major Type: 0 1728 o Change Controller: IESG 1729 o Specification Document(s): this document 1731 o Parameter Name: ack-random-factor 1732 o CBOR Key Value: 18 1733 o CBOR Major Type: 7 1734 o Change Controller: IESG 1735 o Specification Document(s): this document 1736 o Parameter Name: MinValue 1737 o CBOR Key Value: 19 1738 o CBOR Major Type: 0 1739 o Change Controller: IESG 1740 o Specification Document(s): this document 1742 o Parameter Name: MaxValue 1743 o CBOR Key Value: 20 1744 o CBOR Major Type: 0 1745 o Change Controller: IESG 1746 o Specification Document(s): this document 1748 o Parameter Name: status 1749 o CBOR Key Value: 21 1750 o CBOR Major Type: 0 1751 o Change Controller: IESG 1752 o Specification Document(s): this document 1754 o Parameter Name: bytes-dropped 1755 o CBOR Key Value: 22 1756 o CBOR Major Type: 0 1757 o Change Controller: IESG 1758 o Specification Document(s): this document 1760 o Parameter Name: bps-dropped 1761 o CBOR Key Value: 23 1762 o CBOR Major Type: 0 1763 o Change Controller: IESG 1764 o Specification Document(s): this document 1766 o Parameter Name: pkts-dropped 1767 o CBOR Key Value: 24 1768 o CBOR Major Type: 0 1769 o Change Controller: IESG 1770 o Specification Document(s): this document 1772 o Parameter Name: pps-dropped 1773 o CBOR Key Value: 25 1774 o CBOR Major Type: 0 1775 o Change Controller: IESG 1776 o Specification Document(s): this document 1778 o Parameter Name: session-id 1779 o CBOR Key Value: 26 1780 o CBOR Major Type: 0 1781 o Change Controller: IESG 1782 o Specification Document(s): this document 1784 11. Implementation Status 1786 [Note to RFC Editor: Please remove this section and reference to 1787 [RFC7942] prior to publication.] 1789 This section records the status of known implementations of the 1790 protocol defined by this specification at the time of posting of this 1791 Internet-Draft, and is based on a proposal described in [RFC7942]. 1792 The description of implementations in this section is intended to 1793 assist the IETF in its decision processes in progressing drafts to 1794 RFCs. Please note that the listing of any individual implementation 1795 here does not imply endorsement by the IETF. Furthermore, no effort 1796 has been spent to verify the information presented here that was 1797 supplied by IETF contributors. This is not intended as, and must not 1798 be construed to be, a catalog of available implementations or their 1799 features. Readers are advised to note that other implementations may 1800 exist. 1802 According to [RFC7942], "this will allow reviewers and working groups 1803 to assign due consideration to documents that have the benefit of 1804 running code, which may serve as evidence of valuable experimentation 1805 and feedback that have made the implemented protocols more mature. 1806 It is up to the individual working groups to use this information as 1807 they see fit". 1809 11.1. nttdots 1811 Organization: NTT Communication is developing a DOTS client and 1812 DOTS server software based on DOTS signal channel specified in 1813 this draft. It will be open-sourced. 1814 Description: Early implementation of DOTS protocol. It is aimed to 1815 implement a full DOTS protocol spec in accordance with maturing of 1816 DOTS protocol itself. 1817 Implementation: To be open-sourced. 1818 Level of maturity: It is a early implementation of DOTS protocol. 1819 Messaging between DOTS clients and DOTS servers has been tested. 1820 Level of maturity will increase in accordance with maturing of 1821 DOTS protocol itself. 1822 Coverage: Capability of DOTS client: sending DOTS messages to the 1823 DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS 1824 server: receiving dots-signal, validating received dots-signal, 1825 starting mitigation by handing over the dots-signal to DDOS 1826 mitigator. 1827 Licensing: It will be open-sourced with BSD 3-clause license. 1828 Implementation experience: It is implemented in Go-lang. Core 1829 specification of signaling is mature to be implemented, however, 1830 finding good libraries(like DTLS, CoAP) is rather difficult. 1831 Contact: Kaname Nishizuka 1833 12. Security Considerations 1835 Authenticated encryption MUST be used for data confidentiality and 1836 message integrity. (D)TLS based on client certificate MUST be used 1837 for mutual authentication. The interaction between the DOTS agents 1838 requires Datagram Transport Layer Security (DTLS) and Transport Layer 1839 Security (TLS) with a cipher suite offering confidentiality 1840 protection and the guidance given in [RFC7525] MUST be followed to 1841 avoid attacks on (D)TLS. 1843 A single DOTS signal channel between DOTS agents can be used to 1844 exchange multiple DOTS signal messages. To reduce DOTS client and 1845 DOTS server workload, DOTS client SHOULD re-use the (D)TLS session. 1847 If TCP is used between DOTS agents, an attacker may be able to inject 1848 RST packets, bogus application segments, etc., regardless of whether 1849 TLS authentication is used. Because the application data is TLS 1850 protected, this will not result in the application receiving bogus 1851 data, but it will constitute a DoS on the connection. This attack 1852 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 1853 any bogus packets injected by an attacker will be rejected by the 1854 TCP-AO integrity check and therefore will never reach the TLS layer. 1856 Special care should be taken in order to ensure that the activation 1857 of the proposed mechanism won't have an impact on the stability of 1858 the network (including connectivity and services delivered over that 1859 network). 1861 Involved functional elements in the cooperation system must establish 1862 exchange instructions and notification over a secure and 1863 authenticated channel. Adequate filters can be enforced to avoid 1864 that nodes outside a trusted domain can inject request such as 1865 deleting filtering rules. Nevertheless, attacks can be initiated 1866 from within the trusted domain if an entity has been corrupted. 1867 Adequate means to monitor trusted nodes should also be enabled. 1869 13. Contributors 1871 The following individuals have contributed to this document: 1873 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 1874 mgeller@cisco.com 1876 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 1877 Email: rgm@htt-consult.com 1879 Dan Wing Email: dwing-ietf@fuggles.com 1881 14. Acknowledgements 1883 Thanks to Christian Jacquenet, Roland Dobbins, Andrew Mortensen, 1884 Roman D. Danyliw, Michael Richardson, Ehud Doron, Kaname Nishizuka, 1885 Dave Dolson, Liang Xia and Gilbert Clark for the discussion and 1886 comments. 1888 15. References 1890 15.1. Normative References 1892 [I-D.ietf-core-coap-tcp-tls] 1893 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1894 Silverajan, B., and B. Raymor, "CoAP (Constrained 1895 Application Protocol) over TCP, TLS, and WebSockets", 1896 draft-ietf-core-coap-tcp-tls-09 (work in progress), May 1897 2017. 1899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1900 Requirement Levels", BCP 14, RFC 2119, 1901 DOI 10.17487/RFC2119, March 1997, 1902 . 1904 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1905 (TLS) Protocol Version 1.2", RFC 5246, 1906 DOI 10.17487/RFC5246, August 2008, 1907 . 1909 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1910 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1911 June 2010, . 1913 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1914 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1915 January 2012, . 1917 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1918 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1919 Transport Layer Security (TLS) and Datagram Transport 1920 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1921 June 2014, . 1923 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1924 Application Protocol (CoAP)", RFC 7252, 1925 DOI 10.17487/RFC7252, June 2014, 1926 . 1928 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1929 "Recommendations for Secure Use of Transport Layer 1930 Security (TLS) and Datagram Transport Layer Security 1931 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1932 2015, . 1934 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1935 Application Protocol (CoAP)", RFC 7641, 1936 DOI 10.17487/RFC7641, September 2015, 1937 . 1939 15.2. Informative References 1941 [I-D.ietf-core-comi] 1942 Stok, P., Bierman, A., Veillette, M., and A. Pelov, "CoAP 1943 Management Interface", draft-ietf-core-comi-00 (work in 1944 progress), January 2017. 1946 [I-D.ietf-core-yang-cbor] 1947 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 1948 Minaburo, "CBOR Encoding of Data Modeled with YANG", 1949 draft-ietf-core-yang-cbor-04 (work in progress), February 1950 2017. 1952 [I-D.ietf-dots-architecture] 1953 Mortensen, A., Andreasen, F., Reddy, T., 1954 christopher_gray3@cable.comcast.com, c., Compton, R., and 1955 N. Teague, "Distributed-Denial-of-Service Open Threat 1956 Signaling (DOTS) Architecture", draft-ietf-dots- 1957 architecture-03 (work in progress), June 2017. 1959 [I-D.ietf-dots-data-channel] 1960 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 1961 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 1962 Service Open Threat Signaling (DOTS) Data Channel", draft- 1963 ietf-dots-data-channel-01 (work in progress), June 2017. 1965 [I-D.ietf-dots-requirements] 1966 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1967 Denial of Service (DDoS) Open Threat Signaling 1968 Requirements", draft-ietf-dots-requirements-05 (work in 1969 progress), June 2017. 1971 [I-D.ietf-dots-use-cases] 1972 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 1973 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 1974 Open Threat Signaling (DDoS) Open Threat Signaling", 1975 draft-ietf-dots-use-cases-05 (work in progress), May 2017. 1977 [I-D.ietf-tls-tls13] 1978 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1979 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 1980 April 2017. 1982 [I-D.rescorla-tls-dtls13] 1983 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1984 Datagram Transport Layer Security (DTLS) Protocol Version 1985 1.3", draft-rescorla-tls-dtls13-01 (work in progress), 1986 March 2017. 1988 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1989 DOI 10.17487/RFC0791, September 1981, 1990 . 1992 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1993 (CIDR): The Internet Address Assignment and Aggregation 1994 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1995 2006, . 1997 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1998 Denial-of-Service Considerations", RFC 4732, 1999 DOI 10.17487/RFC4732, December 2006, 2000 . 2002 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 2003 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 2004 . 2006 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2007 "Transport Layer Security (TLS) Session Resumption without 2008 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 2009 January 2008, . 2011 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2012 the Network Configuration Protocol (NETCONF)", RFC 6020, 2013 DOI 10.17487/RFC6020, October 2010, 2014 . 2016 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 2017 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2018 2012, . 2020 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 2021 "Default Address Selection for Internet Protocol Version 6 2022 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 2023 . 2025 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2026 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2027 October 2013, . 2029 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2030 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2031 . 2033 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 2034 NETCONF Protocol over Transport Layer Security (TLS) with 2035 Mutual X.509 Authentication", RFC 7589, 2036 DOI 10.17487/RFC7589, June 2015, 2037 . 2039 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 2040 Layer Security (TLS) False Start", RFC 7918, 2041 DOI 10.17487/RFC7918, August 2016, 2042 . 2044 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 2045 (TLS) Cached Information Extension", RFC 7924, 2046 DOI 10.17487/RFC7924, July 2016, 2047 . 2049 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2050 Code: The Implementation Status Section", BCP 205, 2051 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2052 . 2054 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2055 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2056 March 2017, . 2058 Authors' Addresses 2060 Tirumaleswar Reddy 2061 McAfee, Inc. 2062 Embassy Golf Link Business Park 2063 Bangalore, Karnataka 560071 2064 India 2066 Email: kondtir@gmail.com 2067 Mohamed Boucadair 2068 Orange 2069 Rennes 35000 2070 France 2072 Email: mohamed.boucadair@orange.com 2074 Prashanth Patil 2075 Cisco Systems, Inc. 2077 Email: praspati@cisco.com 2079 Andrew Mortensen 2080 Arbor Networks, Inc. 2081 2727 S. State St 2082 Ann Arbor, MI 48104 2083 United States 2085 Email: amortensen@arbor.net 2087 Nik Teague 2088 Verisign, Inc. 2089 United States 2091 Email: nteague@verisign.com