idnits 2.17.00 (12 Aug 2021) /tmp/idnits30487/draft-ietf-dots-signal-channel-11.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 is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFCXXXX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1816 has weird spacing: '...er-port ine...' == Line 1817 has weird spacing: '...er-port ine...' == Line 1833 has weird spacing: '...er-port ine...' == Line 1834 has weird spacing: '...er-port ine...' -- The document date (December 5, 2017) is 1627 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 2579, but not defined == Outdated reference: draft-ietf-core-coap-tcp-tls has been published as RFC 8323 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-11) exists of draft-ietf-core-comi-01 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-05 == Outdated reference: draft-ietf-dots-architecture has been published as RFC 8811 == Outdated reference: draft-ietf-dots-data-channel has been published as RFC 8783 == Outdated reference: draft-ietf-dots-requirements has been published as RFC 8612 == Outdated reference: draft-ietf-dots-use-cases has been published as RFC 8903 == Outdated reference: draft-ietf-netmod-yang-tree-diagrams has been published as RFC 8340 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 6 errors (**), 0 flaws (~~), 16 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: June 8, 2018 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 December 5, 2017 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel 16 draft-ietf-dots-signal-channel-11 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. 25 A companion document defines the DOTS data channel, a separate 26 reliable communication layer for DOTS management and configuration. 28 Editorial Note (To be removed by RFC Editor) 30 Please update these statements with the RFC number to be assigned to 31 this document: 33 o "This version of this YANG module is part of RFC XXXX;" 35 o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling 36 (DOTS) Signal Channel"; 38 o "| 3.00 | Alternate server | [RFCXXXX] |" 40 o reference: RFC XXXX 42 o This RFC 44 Please update TBD statements with the port number to be assigned to 45 DOTS Signal Channel Protocol. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on June 8, 2018. 64 Copyright Notice 66 Copyright (c) 2017 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (https://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. Notational Conventions and Terminology . . . . . . . . . . . 5 83 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 84 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8 85 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8 86 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8 87 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 8 88 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10 89 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 10 90 4.4.2. Retrieve Information Related to a Mitigation . . . . 19 91 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 27 92 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 29 93 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 31 94 4.5.1. Discover Configuration Parameters . . . . . . . . . . 32 95 4.5.2. Convey DOTS Signal Channel Session Configuration . . 34 96 4.5.3. Delete DOTS Signal Channel Session Configuration . . 39 97 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 39 98 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 41 99 5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 42 100 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 42 101 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 44 102 6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 53 103 7. (D)TLS Protocol Profile and Performance Considerations . . . 55 104 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 55 105 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 56 106 7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 57 107 8. Mutual Authentication of DOTS Agents & Authorization of DOTS 108 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 110 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 59 111 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 59 112 9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 59 113 9.4. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 60 114 9.4.1. Registration Template . . . . . . . . . . . . . . . . 60 115 9.4.2. Initial Registry Contents . . . . . . . . . . . . . . 60 116 9.5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 66 117 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 66 118 10.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 66 119 11. Security Considerations . . . . . . . . . . . . . . . . . . . 67 120 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 68 121 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 122 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 123 14.1. Normative References . . . . . . . . . . . . . . . . . . 68 124 14.2. Informative References . . . . . . . . . . . . . . . . . 70 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 127 1. Introduction 129 A distributed denial-of-service (DDoS) attack is an attempt to make 130 machines or network resources unavailable to their intended users. 131 In most cases, sufficient scale can be achieved by compromising 132 enough end-hosts and using those infected hosts to perpetrate and 133 amplify the attack. The victim in this attack can be an application 134 server, a host, a router, a firewall, or an entire network. 136 Network applications have finite resources like CPU cycles, number of 137 processes or threads they can create and use, maximum number of 138 simultaneous connections it can handle, limited resources of the 139 control plane, etc. When processing network traffic, such 140 applications are supposed to use these resources to offer the 141 intended task in the most efficient fashion. However, a DDoS 142 attacker may be able to prevent an application from performing its 143 intended task by causing the application to exhaust the finite supply 144 of a specific resource. 146 TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the 147 victim and ACK-flood is a CPU exhaustion attack on the victim 148 [RFC4987]. Attacks on the link are carried out by sending enough 149 traffic such that the link becomes excessively congested, and 150 legitimate traffic suffers high packet loss. Stateful firewalls can 151 also be attacked by sending traffic that causes the firewall to hold 152 excessive state. The firewall then runs out of memory, and can no 153 longer instantiate the state required to pass legitimate flows. 154 Other possible DDoS attacks are discussed in [RFC4732]. 156 In many cases, it may not be possible for network administrators to 157 determine the causes of an attack, but instead just realize that 158 certain resources seem to be under attack. This document defines a 159 lightweight protocol permitting a DOTS client to request mitigation 160 from one or more DOTS servers for protection against detected, 161 suspected, or anticipated attacks. This protocol enables cooperation 162 between DOTS agents to permit a highly-automated network defense that 163 is robust, reliable, and secure. 165 An example of network diagram showing a deployment of DOTS agents is 166 shown in Figure 1. In this example, the DOTS server is operating on 167 the access network. The DOTS client is located on the LAN (Local 168 Area Network), while a DOTS gateway is embedded in the CPE (Customer 169 Premises Equipment). 171 Network 172 Resource CPE router Access network __________ 173 +-----------+ +--------------+ +-------------+ / \ 174 | |____| |_______| |___ | Internet | 175 |DOTS client| | DOTS gateway | | DOTS server | | | 176 | | | | | | | | 177 +-----------+ +--------------+ +-------------+ \__________/ 179 Figure 1: Sample DOTS Deployment (1) 181 The DOTS server can also be reachable over the Internet, as depicted 182 in Figure 2. 184 Network DDoS mitigation 185 Resource CPE router __________ service 186 +-----------+ +-------------+ / \ +-------------+ 187 | |____| |_______| |___ | | 188 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 189 | | | | | | | | 190 +-----------+ +-------------+ \__________/ +-------------+ 192 Figure 2: Sample DOTS Deployment (2) 194 In typical deployments, the DOTS client belongs to a different 195 administrative domain than the DOTS server. For example, the DOTS 196 client is embedded in a firewall protecting services owned and 197 operated by a domain, while the DOTS server is owned and operated by 198 a different domain providing DDoS mitigation services. That domain 199 providing DDoS mitigation service might, or might not, provide 200 connectivity service to the network hosting the DOTS client. 202 The DOTS server may (not) be co-located with the DOTS mitigator. In 203 typical deployments, the DOTS server belongs to the same 204 administrative domain as the mitigator. The DOTS client can 205 communicate directly with a DOTS server or indirectly via a DOTS 206 gateway. 208 The document adheres to the DOTS architecture 209 [I-D.ietf-dots-architecture]. The requirements for DOTS signal 210 channel protocol are obtained from [I-D.ietf-dots-requirements]. 211 This document satisfies all the use cases discussed in 212 [I-D.ietf-dots-use-cases]. 214 This document focuses on the DOTS signal channel. This is a 215 companion document to the DOTS data channel specification 216 [I-D.ietf-dots-data-channel] that defines a configuration and bulk 217 data exchange mechanism supporting the DOTS signal channel. 219 2. Notational Conventions and Terminology 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 223 "OPTIONAL" in this document are to be interpreted as described in 224 [RFC2119]. 226 (D)TLS is used for statements that apply to both Transport Layer 227 Security [RFC5246] and Datagram Transport Layer Security [RFC6347]. 228 Specific terms will be used for any statement that applies to either 229 protocol alone. 231 The reader should be familiar with the terms defined in 232 [I-D.ietf-dots-architecture]. 234 The meaning of the symbols in YANG tree diagrams is defined in 235 [I-D.ietf-netmod-yang-tree-diagrams]. 237 3. Design Overview 239 The DOTS signal channel is built on top of the Constrained 240 Application Protocol (CoAP) [RFC7252], a lightweight protocol 241 originally designed for constrained devices and networks. CoAP's 242 expectation of packet loss, support for asynchronous non-confirmable 243 messaging, congestion control, small message overhead limiting the 244 need for fragmentation, use of minimal resources, and support for 245 (D)TLS make it a good foundation on which to build the DOTS signaling 246 mechanism. 248 The DOTS signal channel is layered on existing standards (Figure 3). 250 +--------------+ 251 | DOTS | 252 +--------------+ 253 | CoAP | 254 +--------------+ 255 | TLS | DTLS | 256 +--------------+ 257 | TCP | UDP | 258 +--------------+ 259 | IP | 260 +--------------+ 262 Figure 3: Abstract Layering of DOTS signal channel over CoAP over 263 (D)TLS 265 By default, DOTS signal channel MUST run over port number TBD as 266 defined in Section 9.1, for both UDP and TCP, unless the DOTS server 267 has mutual agreement with its DOTS clients to use a port number other 268 than TBD for DOTS signal channel, or DOTS clients supports means to 269 dynamically discover the ports used by their DOTS servers. In order 270 to use a distinct port number (vs. TBD), DOTS clients and servers 271 should support a configurable parameter to supply the port number to 272 use. The rationale for not using the default port number 5684 273 ((D)TLS CoAP) is to allow for differentiated behaviors in deployment 274 contexts where both a DOTS gateway and an IoT gateway (e.g., Figure 3 275 of [RFC7452]) are present. 277 The signal channel is initiated by the DOTS client (Section 4.4). 278 Once the signal channel is established, the DOTS agents periodically 279 send heartbeats to keep the channel active (Section 4.7). At any 280 time, the DOTS client may send a mitigation request message to a DOTS 281 server over the active channel. While mitigation is active, due to 282 the higher likelihood of packet loss during a DDoS attack, the DOTS 283 server periodically sends status messages to the client, including 284 basic mitigation feedback details. Mitigation remains active until 285 the DOTS client explicitly terminates mitigation, or the mitigation 286 lifetime expires. 288 DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS 289 [RFC5246] over TCP. Likewise, DOTS requests may be sent using IPv4 290 or IPv6 transfer capabilities. A Happy Eyeballs procedure for DOTS 291 signal channel is specified in Section 4.3. 293 Messages exchanged between DOTS agents are serialized using Concise 294 Binary Object Representation (CBOR) [RFC7049], CBOR is a binary 295 encoding designed for small code and message size. CBOR encoded 296 payloads are used to convey signal channel specific payload messages 297 that convey request parameters and response information such as 298 errors. This specification uses the encoding rules defined in 299 [I-D.ietf-core-yang-cbor] for representing mitigation scope and DOTS 300 signal channel session configuration data defined using YANG 301 (Section 5) as CBOR data. 303 In order to prevent fragmentation, DOTS agents must follow the 304 recommendations in Section 4.6 of [RFC7252]. Refer to Section 7.3 305 for more details. 307 DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The 308 payload included in CoAP responses with 2.xx and 3.xx Response Codes 309 MUST be of content type "application/cbor" (Section 5.5.1 of 310 [RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes 311 MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The 312 Diagnostic Payload may contain additional information to aid 313 troubleshooting. 315 In deployments where multiple DOTS clients are enabled in a network 316 (owned by the same entity), the DOTS server may detect conflicting 317 mitigation requests from these clients. This document does not aim 318 to specify a comprehensive list of conditions under which a DOTS 319 server will characterize two mitigation requests from distinct DOTS 320 clients as conflicting, nor recommend a DOTS server behavior for 321 processing conflicting mitigation requests. Those considerations are 322 implementation- and deployment-specific. Nevertheless, the document 323 specifies the mechanisms to notify DOTS clients when conflicts occur, 324 including the conflict cause (Section 4.4). 326 4. DOTS Signal Channel: Messages & Behaviors 328 4.1. DOTS Server(s) Discovery 330 This document assumes that DOTS clients are provisioned with the 331 reachability information of their DOTS server(s) using a variety of 332 means (e.g., local configuration, or dynamic means such as DHCP). 333 These means are out of scope of this document. 335 Likewise, it is out of scope of this document to specify the behavior 336 to follow by a DOTS client to place its requests (e.g., contact all 337 servers, select one server among the list) when multiple DOTS servers 338 are provisioned. 340 4.2. CoAP URIs 342 The DOTS server MUST support the use of the path-prefix of "/.well- 343 known/" as defined in [RFC5785] and the registered name of "dots". 344 Each DOTS operation is indicated by a path-suffix that indicates the 345 intended operation. The operation path (Table 1) is appended to the 346 path-prefix to form the URI used with a CoAP request to perform the 347 desired DOTS operation. 349 +-----------------------+----------------+-------------+ 350 | Operation | Operation path | Details | 351 +-----------------------+----------------+-------------+ 352 | Mitigation | /v1/mitigate | Section 4.4 | 353 +-----------------------+----------------+-------------+ 354 | Session configuration | /v1/config | Section 4.5 | 355 +-----------------------+----------------+-------------+ 357 Table 1: Operations and their corresponding URIs 359 4.3. Happy Eyeballs for DOTS Signal Channel 361 DOTS signaling can happen with DTLS over UDP and TLS over TCP. A 362 DOTS client can use DNS to determine the IP address(es) of a DOTS 363 server or a DOTS client may be provided with the list of DOTS server 364 IP addresses. The DOTS client MUST know a DOTS server's domain name; 365 hard-coding the domain name of the DOTS server into software is NOT 366 RECOMMENDED in case the domain name is not valid or needs to change 367 for legal or other reasons. The DOTS client performs A and/or AAAA 368 record lookup of the domain name and the result will be a list of IP 369 addresses, each of which can be used to contact the DOTS server using 370 UDP and TCP. 372 If an IPv4 path to reach a DOTS server is found, but the DOTS 373 server's IPv6 path is not working, a dual-stack DOTS client can 374 experience a significant connection delay compared to an IPv4-only 375 DOTS client. The other problem is that if a middlebox between the 376 DOTS client and DOTS server is configured to block UDP, the DOTS 377 client will fail to establish a DTLS session with the DOTS server and 378 will, then, have to fall back to TLS over TCP incurring significant 379 connection delays. [I-D.ietf-dots-requirements] discusses that DOTS 380 agents will have to support both connectionless and connection- 381 oriented protocols. 383 To overcome these connection setup problems, the DOTS client can try 384 connecting to the DOTS server using both IPv6 and IPv4, and try both 385 DTLS over UDP and TLS over TCP in a fashion similar to the Happy 386 Eyeballs mechanism [RFC6555]. These connection attempts are 387 performed by the DOTS client when its initializes, and the client 388 uses that information for its subsequent alert to the DOTS server. 389 In order of preference (most preferred first), it is UDP over IPv6, 390 UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which 391 adheres to address preference order [RFC6724] and the DOTS preference 392 that UDP be used over TCP (to avoid TCP's head of line blocking). 394 DOTS client DOTS server 395 | | 396 |--DTLS ClientHello, IPv6 ---->X | 397 |--TCP SYN, IPv6-------------->X | 398 |--DTLS ClientHello, IPv4 ---->X | 399 |--TCP SYN, IPv4----------------------------------------->| 400 |--DTLS ClientHello, IPv6 ---->X | 401 |--TCP SYN, IPv6-------------->X | 402 |<-TCP SYNACK---------------------------------------------| 403 |--DTLS ClientHello, IPv4 ---->X | 404 |--TCP ACK----------------------------------------------->| 405 |<------------Establish TLS Session---------------------->| 406 |----------------DOTS signal----------------------------->| 407 | | 409 Figure 4: DOTS Happy Eyeballs 411 In reference to Figure 4, the DOTS client sends two TCP SYNs and two 412 DTLS ClientHello messages at the same time over IPv6 and IPv4. In 413 this example, it is assumed that the IPv6 path is broken and UDP is 414 dropped by a middlebox but has little impact to the DOTS client 415 because there is no long delay before using IPv4 and TCP. The DOTS 416 client repeats the mechanism to discover if DOTS signaling with DTLS 417 over UDP becomes available from the DOTS server, so the DOTS client 418 can migrate the DOTS signal channel from TCP to UDP, but such probing 419 SHOULD NOT be done more frequently than every 24 hours and MUST NOT 420 be done more frequently than every 5 minutes. 422 4.4. DOTS Mitigation Methods 424 The following methods are used by a DOTS client to request, withdraw, 425 or retrieve the status of mitigation requests: 427 PUT: DOTS clients use the PUT method to request mitigation from a 428 DOTS server (Section 4.4.1). During active mitigation, DOTS 429 clients may use PUT requests to convey mitigation efficacy 430 updates to the DOTS server (Section 4.4.3). 432 GET: DOTS clients may use the GET method to subscribe to DOTS 433 server status messages, or to retrieve the list of its 434 mitigations maintained by a DOTS server (Section 4.4.2). 436 DELETE: DOTS clients use the DELETE method to withdraw a request for 437 mitigation from a DOTS server (Section 4.4.4). 439 Mitigation request and response messages are marked as Non- 440 confirmable messages (Section 2.2 of [RFC7252]). 442 DOTS agents SHOULD follow the data transmission guidelines discussed 443 in Section 3.1.3 of [RFC8085] and control transmission behavior by 444 not sending on average more than one UDP datagram per RTT to the peer 445 DOTS agent. 447 Requests marked by the DOTS client as Non-confirmable messages are 448 sent at regular intervals until a response is received from the DOTS 449 server. If the DOTS client cannot maintain an RTT estimate, it 450 SHOULD NOT send more than one Non-confirmable request every 3 451 seconds, and SHOULD use an even less aggressive rate when possible 452 (case 2 in Section 3.1.3 of [RFC8085]). 454 4.4.1. Request Mitigation 456 When a DOTS client requires mitigation for any reason, the DOTS 457 client uses CoAP PUT method to send a mitigation request to its DOTS 458 server(s) (Figure 5, illustrated in JSON diagnostic notation). If 459 this DOTS client is entitled to solicit the DOTS service, the DOTS 460 server can enable mitigation on behalf of the DOTS client by 461 communicating the DOTS client's request to the mitigator and relaying 462 selected mitigator feedback to the requesting DOTS client. 464 Header: PUT (Code=0.03) 465 Uri-Host: "host" 466 Uri-Path: ".well-known" 467 Uri-Path: "dots" 468 Uri-Path: "version" 469 Uri-Path: "mitigate" 470 Content-Type: "application/cbor" 471 { 472 "mitigation-scope": { 473 "client-identifier": [ 474 "string" 475 ], 476 "scope": [ 477 { 478 "mitigation-id": integer, 479 "target-ip": [ 480 "string" 481 ], 482 "target-prefix": [ 483 "string" 484 ], 485 "target-port-range": [ 486 { 487 "lower-port": integer, 488 "upper-port": integer 489 } 490 ], 491 "target-protocol": [ 492 integer 493 ], 494 "target-fqdn": [ 495 "string" 496 ], 497 "target-uri": [ 498 "string" 499 ], 500 "alias-name": [ 501 "string" 502 ], 503 "lifetime": integer 504 } 505 ] 506 } 507 } 509 Figure 5: PUT to convey DOTS signals 511 The parameters are described below: 513 client-identifier: The client identifier MAY be conveyed by the DOTS 514 gateway to propagate the DOTS client identity from the gateway's 515 client-side to the gateway's server-side, and from the gateway's 516 server-side to the DOTS server. This allows the final DOTS server 517 to accept mitigation requests with scopes which the DOTS client is 518 authorized to manage. 520 The 'client-identifier' value MUST be assigned by the DOTS gateway 521 in a manner that ensures that there is no probability that the 522 same value will be assigned to a different DOTS client. The DOTS 523 gateway MUST obscure potentially sensitive DOTS client identity 524 information. The client-identifier attribute SHOULD NOT to be 525 generated and included by the DOTS client. 527 This is an optional attribute. 529 mitigation-id: Identifier for the mitigation request represented 530 using an integer. This identifier MUST be unique for each 531 mitigation request bound to the DOTS client, i.e., the mitigation- 532 id parameter value in the mitigation request needs to be unique 533 relative to the mitigation-id parameter values of active 534 mitigation requests conveyed from the DOTS client to the DOTS 535 server. This identifier MUST be generated by the DOTS client. 536 This document does not make any assumption about how this 537 identifier is generated. 539 This is a mandatory attribute. 541 target-ip: A list of IP addresses identifying resources under 542 attack. This is an optional attribute. 544 target-prefix: A list of prefixes identifying resources under 545 attack. Prefixes are represented using Classless Inter-domain 546 Routing (CIDR) notation [RFC4632]. 548 This is an optional attribute. 550 target-port-range: A list of port numbers bound to resources under 551 attack. 553 The port range is defined by two bounds, a lower port number 554 (lower-port) and an upper port number (upper-port). When only 555 'lower-port' is present, it represents a single port number. For 556 TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], 557 or Datagram Congestion Control Protocol (DCCP) [RFC4340], the 558 range of ports can be, for example, 1024-65535. 560 This is an optional attribute. 562 target-protocol: A list of protocols involved in an attack. Values 563 are taken from the IANA protocol registry [proto_numbers]. 565 The value 0 has a special meaning for 'all protocols'. 567 This is an optional attribute. 569 target-fqdn: A list of Fully Qualified Domain Names (FQDNs) 570 identifying resources under attack. An FQDN is the full name of a 571 resource, rather than just its hostname. For example, "venera" is 572 a hostname, and "venera.isi.edu" is an FQDN. 574 This is an optional attribute. 576 target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986] 577 identifying resources under attack. 579 This is an optional attribute. 581 alias-name: A list of aliases of resources for which the mitigation 582 is requested. Aliases can be created using the DOTS data channel 583 (Section 6.1 of [I-D.ietf-dots-data-channel]), direct 584 configuration, or other means. An alias is used in subsequent 585 signal channel exchanges to refer more efficiently to the 586 resources under attack. 588 This is an optional attribute. 590 lifetime: Lifetime of the mitigation request in seconds. The 591 RECOMMENDED lifetime of a mitigation request is 3600 seconds (60 592 minutes) -- this value was chosen to be long enough so that 593 refreshing is not typically a burden on the DOTS client, while 594 expiring the request where the client has unexpectedly quit in a 595 timely manner. DOTS clients MUST include this parameter in their 596 mitigation requests. Upon the expiry of this lifetime, and if the 597 request is not refreshed, the mitigation request is removed. The 598 request can be refreshed by sending the same request again. 600 A lifetime of 0 in a mitigation request is an invalid value. 602 A lifetime of negative one (-1) indicates indefinite lifetime for 603 the mitigation request. The DOTS server MAY refuse indefinite 604 lifetime, for policy reasons; the granted lifetime value is 605 returned in the response. DOTS clients MUST be prepared to not be 606 granted mitigations with indefinite lifetimes. 608 The DOTS server MUST always indicate the actual lifetime in the 609 response and the remaining lifetime in status messages sent to the 610 DOTS client. 612 This is a mandatory attribute. 614 Because of the complexity to handle partial failure cases, this 615 specification does not allow for including multiple mitigation 616 requests in the same PUT request. Concretely, a DOTS client MUST NOT 617 include multiple 'scope' parameters in the same PUT request. 619 The CBOR key values for the parameters are defined in Section 6. 620 Section 9 defines how the CBOR key values can be allocated to 621 standards bodies and vendors. 623 FQDN and URI mitigation scopes may be thought of as a form of scope 624 alias, in which the addresses to which the domain name or URI resolve 625 represent the full scope of the mitigation. 627 In the PUT request at least one of the attributes 'target-ip' or 628 'target-prefix' or 'target-fqdn' or 'target-uri 'or 'alias-name' MUST 629 be present. If the attribute value is empty, then the attribute MUST 630 NOT be present in the request. 632 The relative order of two mitigation requests from a DOTS client is 633 determined by comparing their respective 'mitigation-id' values. If 634 two mitigation requests have overlapping mitigation scopes, the 635 mitigation request with higher numeric 'mitigation-id' value will 636 override the mitigation request with a lower numeric 'mitigation-id' 637 value. Two mitigation-ids from a DOTS client are overlapping if 638 there is a common IP address, IP prefix, FQDN, URI, or alias-name. 639 To avoid maintaining a long list of overlapping mitigation requests 640 from a DOTS client and avoid error-prone provisioning of mitigation 641 requests from a DOTS client, the overlapped lower numeric 642 'mitigation-id' MUST be automatically deleted and no longer available 643 at the DOTS server. 645 The Uri-Path option carries a major and minor version nomenclature to 646 manage versioning and DOTS signal channel in this specification uses 647 v1 major version. 649 Figure 6 shows a PUT request example to signal that ports 80, 8080, 650 and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are 651 being attacked (illustrated in JSON diagnostic notation). 653 Header: PUT (Code=0.03) 654 Uri-Host: "www.example.com" 655 Uri-Path: ".well-known" 656 Uri-Path: "dots" 657 Uri-Path: "v1" 658 Uri-Path: "mitigate" 659 Content-Format: "application/cbor" 660 { 661 "mitigation-scope": { 662 "client-identifier": [ 663 "dz6pHjaADkaFTbjr0JGBpw" 664 ], 665 "scope": [ 666 { 667 "mitigation-id": 12332, 668 "target-ip": [ 669 "2001:db8:6401::1", 670 "2001:db8:6401::2" 671 ], 672 "target-port-range": [ 673 { 674 "lower-port": 80 675 }, 676 { 677 "lower-port": 443 678 }, 679 { 680 "lower-port": 8080 681 } 682 ], 683 "target-protocol": [ 684 6 685 ] 686 } 687 ] 688 } 689 } 691 Figure 6: PUT for DOTS signal 693 The corresponding CBOR encoding format is shown in Figure 7. 695 A1 # map(1) 696 01 # unsigned(1) 697 A2 # map(2) 698 18 20 # unsigned(32) 699 81 # array(1) 700 76 # text(22) 701 647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw" 702 02 # unsigned(2) 703 81 # array(1) 704 A4 # map(4) 705 03 # unsigned(3) 706 19 302C # unsigned(12332) 707 04 # unsigned(4) 708 82 # array(2) 709 70 # text(16) 710 323030313A6462383A363430313A3A31 # "2001:db8:6401::1" 711 70 # text(16) 712 323030313A6462383A363430313A3A32 # "2001:db8:6401::2" 713 05 # unsigned(5) 714 83 # array(3) 715 A1 # map(1) 716 06 # unsigned(6) 717 18 50 # unsigned(80) 718 A1 # map(1) 719 06 # unsigned(6) 720 19 01BB # unsigned(443) 721 A1 # map(1) 722 06 # unsigned(6) 723 19 1F90 # unsigned(8080) 724 08 # unsigned(8) 725 81 # array(1) 726 06 # unsigned(6) 728 Figure 7: PUT for DOTS signal (CBOR) 730 If the DOTS client is using the certificate provisioned by the 731 Enrollment over Secure Transport (EST) server [RFC7030] in the DOTS 732 gateway-domain to authenticate itself to the DOTS gateway, then the 733 'client-identifier' value can be the output of a cryptographic hash 734 algorithm whose input is the DER-encoded ASN.1 representation of the 735 Subject Public Key Info (SPKI) of an X.509 certificate. In this 736 version of the specification, the cryptographic hash algorithm used 737 is SHA-256 [RFC6234]. The output of the cryptographic hash algorithm 738 is truncated to 16 bytes; truncation is done by stripping off the 739 final 16 bytes. The truncated output is base64url encoded. If the 740 'client-identifier' value is already present in the mitigation 741 request received from the DOTS client, the DOTS gateway MAY compute 742 the 'client-identifier' value, as discussed above, and add the 743 computed 'client-identifier' value to the end of the 'client- 744 identifier' list. The DOTS server MUST NOT use the 'client- 745 identifier' for the DOTS client authentication process. 747 In both DOTS signal and data channel sessions, the DOTS client MUST 748 authenticate itself to the DOTS server (Section 8). The DOTS server 749 may use the algorithm in Section 7 of [RFC7589] to derive the DOTS 750 client identity or username from the client certificate. The DOTS 751 client identity allows the DOTS server to accept mitigation requests 752 with scopes which the DOTS client is authorized to manage. The DOTS 753 server couples the DOTS signal and data channel sessions using the 754 DOTS client identity and the 'client-identifier' parameter value, so 755 the DOTS server can validate whether the aliases conveyed in the 756 mitigation request were indeed created by the same DOTS client using 757 the DOTS data channel session. If the aliases were not created by 758 the DOTS client, the DOTS server returns 4.00 (Bad Request) in the 759 response. 761 The DOTS server uses 'mitigation-id' parameter value to detect 762 duplicate mitigation requests. If the mitigation request contains 763 both alias-name and other parameters identifying the target resources 764 (such as, 'target-ip', 'target-prefix', 'target-port-range', 'target- 765 fqdn', or 'target-uri'), then the DOTS server appends the parameter 766 values in 'alias-name' with the corresponding parameter values in 767 'target-ip', 'target-prefix', 'target-port-range', 'target-fqdn', or 768 'target-uri'. 770 The DOTS server indicates the result of processing the PUT request 771 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 772 codes are some sort of invalid requests (client errors). COAP 5.xx 773 codes are returned if the DOTS server has erred or is currently 774 unavailable to provide mitigation in response to the mitigation 775 request from the DOTS client. 777 Figure 8 shows an example of a PUT request that is successfully 778 processed (i.e., CoAP 2.xx response codes). 780 { 781 "mitigation-scope": { 782 "client-identifier": [ 783 "string" 784 ], 785 "scope": [ 786 { 787 "mitigation-id": integer, 788 "lifetime": integer 789 } 790 ] 791 } 792 } 794 Figure 8: 2.xx response body 796 If the request is missing one or more mandatory attributes, includes 797 multiple 'scope' parameters, or contains invalid or unknown 798 parameters, the DOTS server replies with 4.00 (Bad Request). DOTS 799 agents can safely ignore Vendor-Specific parameters they don't 800 understand. 802 A DOTS server that receives a mitigation request with a lifetime set 803 to 0 MUST reply with a 4.00 (Bad Request). 805 If the DOTS server does not find the 'mitigation-id' parameter value 806 conveyed in the PUT request in its configuration data, it MAY accept 807 the mitigation request by sending back a 2.01 (Created) response to 808 the DOTS client; the DOTS server will consequently try to mitigate 809 the attack. 811 If the DOTS server finds the 'mitigation-id' parameter value conveyed 812 in the PUT request in its configuration data, it MAY update the 813 mitigation request, and a 2.04 (Changed) response is returned to 814 indicate a successful update of the mitigation request. 816 If the request is conflicting with an existing mitigation request 817 from a different DOTS client, and the DOTS server decides to maintain 818 the conflicting mitigation request, the DOTS server returns 4.09 819 (Conflict) [RFC8132] to the requesting DOTS client. The response 820 includes enough information for a DOTS client to recognize the source 821 of the conflict (refer to 'conflict-information' specified in 822 Section 4.4.2). 824 For a mitigation request to continue beyond the initial negotiated 825 lifetime, the DOTS client has to refresh the current mitigation 826 request by sending a new PUT request. This PUT request MUST use the 827 same 'mitigation-id' value, and MUST repeat all the other parameters 828 as sent in the original mitigation request apart from a possible 829 change to the lifetime parameter value. 831 A DOTS gateway MUST update the 'client-identifier' list in the 832 response to remove the 'client-identifier' value it had added in the 833 corresponding request before forwarding the response to the DOTS 834 client. 836 4.4.2. Retrieve Information Related to a Mitigation 838 A GET request is used to retrieve information (including status) of a 839 DOTS mitigation from a DOTS server. If the DOTS server does not find 840 the 'mitigation-id' parameter value conveyed in the GET request in 841 its configuration data, it responds with a 4.04 (Not Found) error 842 response code. 844 The 'c' (content) parameter and its permitted values defined in 845 [I-D.ietf-core-comi] can be used to retrieve non-configuration data 846 (attack mitigation status) or configuration data or both. The DOTS 847 server SHOULD support this optional filtering capability but can 848 safely ignore it if not supported. 850 The following examples illustrate how a DOTS client retrieves active 851 mitigation requests from a DOTS server. In particular: 853 o Figure 9 shows the example of a GET request to retrieve all DOTS 854 mitigation requests signaled by a DOTS client. 856 o Figure 10 shows the example of a GET request to retrieve a 857 specific DOTS mitigation request signaled by a DOTS client. The 858 configuration data to be reported in the response is formatted in 859 the same order it was processed at the DOTS server. 861 These two examples assume the default of "c=a"; that is the DOTS 862 client asks for all data to be reported by the DOTS server. 864 Header: GET (Code=0.01) 865 Uri-Host: "host" 866 Uri-Path: ".well-known" 867 Uri-Path: "dots" 868 Uri-Path: "version" 869 Uri-Path: "mitigate" 870 Observe : 0 871 { 872 "mitigation-scope": { 873 "client-identifier": [ 874 "string" 875 ] 876 } 877 } 879 Figure 9: GET to retrieve all DOTS mitigation requests 881 Header: GET (Code=0.01) 882 Uri-Host: "host" 883 Uri-Path: ".well-known" 884 Uri-Path: "dots" 885 Uri-Path: "version" 886 Uri-Path: "mitigate" 887 Observe : 0 888 Content-Format: "application/cbor" 889 { 890 "mitigation-scope": { 891 "client-identifier": [ 892 "string" 893 ], 894 "scope": [ 895 { 896 "mitigation-id": integer 897 } 898 ] 899 } 900 } 902 Figure 10: GET to retrieve a specific DOTS mitigation request 904 Figure 11 shows a response example of all active mitigation requests 905 associated with the DOTS client on the DOTS server and the mitigation 906 status of each mitigation request. 908 { 909 "mitigation-scope": { 910 "scope": [ 911 { 912 "mitigation-id": 12332, 913 "mitigation-start": 1507818434.00, 914 "target-protocol": [ 915 17 916 ], 917 "lifetime":1800, 918 "status":2, 919 "bytes-dropped": 134334555, 920 "bps-dropped": 43344, 921 "pkts-dropped": 333334444, 922 "pps-dropped": 432432 923 }, 924 { 925 "mitigation-id": 12333, 926 "mitigation-start": 1507818393.00, 927 "target-protocol": [ 928 6 929 ], 930 "lifetime":1800, 931 "status":3 932 "bytes-dropped": 0, 933 "bps-dropped": 0, 934 "pkts-dropped": 0, 935 "pps-dropped": 0 936 } 937 ] 938 } 939 } 941 Figure 11: Response body 943 The mitigation status parameters are described below: 945 mitigation-start: Mitigation start time is represented in seconds 946 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 947 [RFC7049]). The encoding is modified so that the leading tag 1 948 (epoch-based date/time) MUST be omitted. 950 lifetime: The remaining lifetime of the mitigation request, in 951 seconds. 953 status: Status of attack mitigation. The 'status' parameter is a 954 mandatory attribute. The various possible values of 'status' 955 parameter are explained in Table 2. 957 conflict-information: Indicates that a mitigation request is 958 conflicting with another mitigation request(s) from other DOTS 959 client(s). This optional attribute has the following structure: 961 conflict-status: Indicates the status of a conflicting mitigation 962 request. The following values are defined: 964 1: DOTS server has detected conflicting mitigation requests 965 from different DOTS clients. This mitigation request is 966 currently inactive until the conflicts are resolved. 967 Another mitigation request is active. 969 2: DOTS server has detected conflicting mitigation requests 970 from different DOTS clients. This mitigation request is 971 currently active. 973 3: DOTS server has detected conflicting mitigation requests 974 from different DOTS clients. All conflicting mitigation 975 requests are inactive. 977 conflict-cause: Indicates the cause of the conflict. The 978 following values are defined: 980 1: Overlapping targets. 'conflict-scope' provides more details 981 about the conflicting target clauses. 983 2: Conflicts with an existing white list. This code is 984 returned when the DDoS mitigation detects source addresses/ 985 prefixes in the white-listed ACLs are attacking the target. 987 conflict-scope Indicates the conflict scope. It may include a 988 list of IP addresses, a list of prefixes, a list of port 989 numbers, a list of target protocols, a list of FQDNs, a list of 990 URIs, or a list of alias-names. 992 retry-timer Indicates, in seconds, the time upon which the DOTS 993 client may re-issue the same request. The DOTS server returns 994 'retry-timer' only to DOTS client(s) for which a mitigation 995 request is deactivated. Any retransmission of the same 996 mitigation request before the expiry of this timer is likely to 997 be rejected by the DOTS server for the same reasons. 999 The retry-timer SHOULD be equal to the lifetime of the active 1000 mitigation request resulting in the deactivation of the 1001 conflicting mitigation request. The lifetime of the 1002 deactivated mitigation request will be updated to (retry-timer 1003 + 45 seconds), so the DOTS client can refresh the deactivated 1004 mitigation request after retry-timer seconds before expiry of 1005 lifetime and check if the conflict is resolved. 1007 bytes-dropped: The total dropped byte count for the mitigation 1008 request since the attack mitigation is triggered. The count wraps 1009 around when it reaches the maximum value of unsigned integer. 1010 This is an optional attribute. 1012 bps-dropped: The average dropped bytes per second for the mitigation 1013 request since the attack mitigation is triggered. This SHOULD be 1014 a five-minute average. This is an optional attribute. 1016 pkts-dropped: The total dropped packet count for the mitigation 1017 request since the attack mitigation is triggered. This is an 1018 optional attribute. 1020 pps-dropped: The average dropped packets per second for the 1021 mitigation request since the attack mitigation is triggered. This 1022 SHOULD be a five-minute average. This is an optional attribute. 1024 +-----------+-------------------------------------------------------+ 1025 | Parameter | Description | 1026 | value | | 1027 +-----------+-------------------------------------------------------+ 1028 | 1 | Attack mitigation is in progress (e.g., changing the | 1029 | | network path to re-route the inbound traffic to DOTS | 1030 | | mitigator). | 1031 +-----------+-------------------------------------------------------+ 1032 | 2 | Attack is successfully mitigated (e.g., traffic is | 1033 | | redirected to a DDOS mitigator and attack traffic is | 1034 | | dropped). | 1035 +-----------+-------------------------------------------------------+ 1036 | 3 | Attack has stopped and the DOTS client can withdraw | 1037 | | the mitigation request. | 1038 +-----------+-------------------------------------------------------+ 1039 | 4 | Attack has exceeded the mitigation provider | 1040 | | capability. | 1041 +-----------+-------------------------------------------------------+ 1042 | 5 | DOTS client has withdrawn the mitigation request and | 1043 | | the mitigation is active but terminating. | 1044 +-----------+-------------------------------------------------------+ 1045 | 6 | Attack mitigation is now terminated. | 1046 +-----------+-------------------------------------------------------+ 1047 | 7 | Attack mitigation is withdrawn. | 1048 +-----------+-------------------------------------------------------+ 1049 | 8 | Attack mitigation is rejected. | 1050 +-----------+-------------------------------------------------------+ 1052 Table 2: Values of 'status' parameter 1054 The observe option defined in [RFC7641] extends the CoAP core 1055 protocol with a mechanism for a CoAP client to "observe" a resource 1056 on a CoAP server: the client retrieves a representation of the 1057 resource and requests this representation be updated by the server as 1058 long as the client is interested in the resource. A DOTS client 1059 conveys the observe option set to '0' in the GET request to receive 1060 unsolicited notifications of attack mitigation status from the DOTS 1061 server. Unidirectional notifications within the bidirectional signal 1062 channel allows unsolicited message delivery, enabling asynchronous 1063 notifications between the agents. Due to the higher likelihood of 1064 packet loss during a DDoS attack, DOTS server periodically sends 1065 attack mitigation status to the DOTS client and also notifies the 1066 DOTS client whenever the status of the attack mitigation changes. If 1067 the DOTS server cannot maintain a RTT estimate, it SHOULD NOT send 1068 more than one unsolicited notification every 3 seconds, and SHOULD 1069 use an even less aggressive rate when possible (case 2 in 1070 Section 3.1.3 of [RFC8085]). 1072 When conflicting requests are detected, the DOTS server enforces the 1073 corresponding policy (e.g. accept all requests, reject all requests, 1074 accept only one request but reject all the others, ...). It is 1075 assumed that this policy is supplied by the DOTS server administrator 1076 or it is a default behavior of the DOTS server implementation. Then, 1077 the DOTS server sends notification message(s) to the DOTS client(s) 1078 at the origin of the conflict. A conflict notification message 1079 includes information about the conflict cause, scope, and the status 1080 of the mitigation request(s). For example, 1082 o A notification message with status code set to '8 (Attack 1083 mitigation is rejected)' and 'conflict-status' set to '1' is sent 1084 to a DOTS client to indicate that this mitigation request is 1085 rejected because a conflict is detected. 1087 o A notification message with status code set to '7 (Attack 1088 mitigation is withdrawn)' and 'conflict-status' set to '1' is sent 1089 to a DOTS client to indicate that an active mitigation request is 1090 deactivated because a conflict is detected. 1092 o A notification message with status code set to '1 (Attack 1093 mitigation is in progress)' and 'conflict-status' set to 2 is sent 1094 to a DOTS client to indicate that this mitigation request is in 1095 progress, but a conflict is detected. 1097 Upon receipt of a conflict notification message indicating that a 1098 mitigation request is deactivated because of a conflict, a DOTS 1099 client MUST NOT resend the same mitigation request before the expiry 1100 of 'retry-timer'. It is also recommended that DOTS clients support 1101 means to alert administrators about mitigation conflicts. 1103 A DOTS client that is no longer interested in receiving notifications 1104 from the DOTS server can simply "forget" the observation. When the 1105 DOTS server then sends the next notification, the DOTS client will 1106 not recognize the token in the message and thus will return a Reset 1107 message. This causes the DOTS server to remove the associated entry. 1108 Alternatively, the DOTS client can explicitly deregister by issuing a 1109 GET request that has the Token field set to the token of the 1110 observation to be cancelled and includes an Observe Option with the 1111 value set to '1' (deregister). 1113 Figure 12 shows an example of a DOTS client requesting a DOTS server 1114 to send notifications related a given mitigation request. 1116 DOTS Client DOTS Server 1117 | | 1118 | GET / | 1119 | Token: 0x4a | Registration 1120 | Observe: 0 | 1121 +------------------------------>| 1122 | | 1123 | 2.05 Content | 1124 | Token: 0x4a | Notification of 1125 | Observe: 12 | the current state 1126 | status: "mitigation | 1127 | in progress" | 1128 |<------------------------------+ 1129 | 2.05 Content | 1130 | Token: 0x4a | Notification upon 1131 | Observe: 44 | a state change 1132 | status: "mitigation | 1133 | complete" | 1134 |<------------------------------+ 1135 | 2.05 Content | 1136 | Token: 0x4a | Notification upon 1137 | Observe: 60 | a state change 1138 | status: "attack stopped" | 1139 |<------------------------------+ 1140 | | 1142 Figure 12: Notifications of attack mitigation status 1144 4.4.2.1. Mitigation Status 1146 The DOTS client can send the GET request at frequent intervals 1147 without the Observe option to retrieve the configuration data of the 1148 mitigation request and non-configuration data (i.e., the attack 1149 status). The frequency of polling the DOTS server to get the 1150 mitigation status should follow the transmission guidelines given in 1151 Section 3.1.3 of [RFC8085]. If the DOTS server has been able to 1152 mitigate the attack and the attack has stopped, the DOTS server 1153 indicates as such in the status, and the DOTS client recalls the 1154 mitigation request by issuing a DELETE request for the mitigation-id. 1156 A DOTS client SHOULD react to the status of the attack from the DOTS 1157 server and not the fact that it has recognized, using its own means, 1158 that the attack has been mitigated. This ensures that the DOTS 1159 client does not recall a mitigation request in a premature fashion 1160 because it is possible that the DOTS client does not sense the DDOS 1161 attack on its resources but the DOTS server could be actively 1162 mitigating the attack and the attack is not completely averted. 1164 4.4.3. Efficacy Update from DOTS Clients 1166 While DDoS mitigation is active, due to the likelihood of packet 1167 loss, a DOTS client MAY periodically transmit DOTS mitigation 1168 efficacy updates to the relevant DOTS server. A PUT request is used 1169 to convey the mitigation efficacy update to the DOTS server. 1171 The PUT request MUST include all the parameters used in the PUT 1172 request to convey the DOTS signal (Section 4.4.1) unchanged apart 1173 from the lifetime parameter value. If this is not the case, the DOTS 1174 server MUST reject the request with a 4.00 (Bad Request). 1176 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1177 value is used to make the PUT request conditional on the current 1178 existence of the mitigation request. If UDP is used as transport, 1179 CoAP requests may arrive out-of-order. For example, the DOTS client 1180 may send a PUT request to convey an efficacy update to the DOTS 1181 server followed by a DELETE request to withdraw the mitigation 1182 request, but the DELETE request arrives at the DOTS server before the 1183 PUT request. To handle out-of-order delivery of requests, if an If- 1184 Match option is present in the PUT request and the 'mitigation-id' in 1185 the request matches a mitigation request from that DOTS client, then 1186 the request is processed. If no match is found, the PUT request is 1187 silently ignored. 1189 An example of an efficacy update message, which includes an If-Match 1190 option with an empty value, is depicted in Figure 13. 1192 Header: PUT (Code=0.03) 1193 Uri-Host: "host" 1194 Uri-Path: ".well-known" 1195 Uri-Path: "dots" 1196 Uri-Path: "version" 1197 Uri-Path: "mitigate" 1198 Content-Format: "application/cbor" 1199 If-Match: 1200 { 1201 "mitigation-scope": { 1202 "client-identifier": [ 1203 "string" 1204 ], 1205 "scope": [ 1206 { 1207 "mitigation-id": integer, 1208 "target-ip": [ 1209 "string" 1210 ], 1211 "target-port-range": [ 1212 { 1213 "lower-port": integer, 1214 "upper-port": integer 1215 } 1216 ], 1217 "target-protocol": [ 1218 integer 1219 ], 1220 "target-fqdn": [ 1221 "string" 1222 ], 1223 "target-uri": [ 1224 "string" 1225 ], 1226 "alias-name": [ 1227 "string" 1228 ], 1229 "lifetime": integer, 1230 "attack-status": integer 1231 } 1232 ] 1233 } 1234 } 1236 Figure 13: Efficacy Update 1238 The 'attack-status' parameter is a mandatory attribute when doing an 1239 efficacy update. The various possible values contained in the 1240 'attack-status' parameter are described in Table 3. 1242 +-----------+-------------------------------------------------------+ 1243 | Parameter | Description | 1244 | value | | 1245 +-----------+-------------------------------------------------------+ 1246 | 1 | The DOTS client determines that it is still under | 1247 | | attack. | 1248 +-----------+-------------------------------------------------------+ 1249 | 2 | The DOTS client determines that the attack is | 1250 | | successfully mitigated (e.g., attack traffic is not | 1251 | | seen). | 1252 +-----------+-------------------------------------------------------+ 1254 Table 3: Values of 'attack-status' parameter 1256 The DOTS server indicates the result of processing a PUT request 1257 using CoAP response codes. The response code 2.04 (Changed) is 1258 returned if the DOTS server has accepted the mitigation efficacy 1259 update. The error response code 5.03 (Service Unavailable) is 1260 returned if the DOTS server has erred or is incapable of performing 1261 the mitigation. 1263 4.4.4. Withdraw a Mitigation 1265 A DELETE request is used to withdraw a DOTS mitigation request from a 1266 DOTS server (Figure 14). 1268 Header: DELETE (Code=0.04) 1269 Uri-Host: "host" 1270 Uri-Path: ".well-known" 1271 Uri-Path: "dots" 1272 Uri-Path: "version" 1273 Uri-Path: "mitigate" 1274 Content-Format: "application/cbor" 1275 { 1276 "mitigation-scope": { 1277 "client-identifier": [ 1278 "string" 1279 ], 1280 "scope": [ 1281 { 1282 "mitigation-id": integer 1283 } 1284 ] 1285 } 1286 } 1288 Figure 14: Withdraw DOTS signal 1290 If the request does not include a 'mitigation-id', the DOTS server 1291 MUST reply with a 4.00 (Bad Request). 1293 Once the request is validated, the DOTS server immediately 1294 acknowledges a DOTS client's request to withdraw the DOTS signal 1295 using 2.02 (Deleted) response code with no response payload. A 2.02 1296 (Deleted) Response Code is returned even if the 'mitigation-id' 1297 parameter value conveyed in the DELETE request does not exist in its 1298 configuration data before the request. 1300 If the DOTS server finds the 'mitigation-id' parameter value conveyed 1301 in the DELETE request in its configuration data, then to protect 1302 against route or DNS flapping caused by a DOTS client rapidly 1303 toggling mitigation, and to dampen the effect of oscillating attacks, 1304 the DOTS server MAY allow mitigation to continue for a limited period 1305 after acknowledging a DOTS client's withdrawal of a mitigation 1306 request. During this period, the DOTS server status messages SHOULD 1307 indicate that mitigation is active but terminating (Section 4.4.2). 1309 The initial active-but-terminating period SHOULD be sufficiently long 1310 to absorb latency incurred by route propagation. The active-but- 1311 terminating period SHOULD be set by default to 120 seconds. If the 1312 client requests mitigation again before the initial active-but- 1313 terminating period elapses, the DOTS server MAY exponentially 1314 increase the active-but- terminating period up to a maximum of 300 1315 seconds (5 minutes). 1317 After the active-but-terminating period elapses, the DOTS server MUST 1318 treat the mitigation as terminated, as the DOTS client is no longer 1319 responsible for the mitigation. For example, if there is a financial 1320 relationship between the DOTS client and server domains, the DOTS 1321 client ceases incurring cost at this point. 1323 4.5. DOTS Signal Channel Session Configuration 1325 The DOTS client can negotiate, configure, and retrieve the DOTS 1326 signal channel session behavior. The DOTS signal channel can be 1327 used, for example, to configure the following: 1329 a. Heartbeat interval: DOTS agents regularly send heartbeats (CoAP 1330 Ping/Pong) to each other after mutual authentication in order to 1331 keep the DOTS signal channel open, heartbeat messages are 1332 exchanged between the DOTS agents every heartbeat-interval 1333 seconds to detect the current status of the DOTS signal channel 1334 session. 1336 b. Missing heartbeats allowed: This variable indicates the maximum 1337 number of consecutive heartbeat messages for which a DOTS agent 1338 did not receive a response before concluding that the session is 1339 disconnected or defunct. 1341 c. Acceptable signal loss ratio: Maximum retransmissions, 1342 retransmission timeout value and other message transmission 1343 parameters for the DOTS signal channel. 1345 Reliability is provided to requests and responses by marking them as 1346 Confirmable (CON) messages. DOTS signal channel session 1347 configuration requests and responses are marked as Confirmable 1348 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1349 message is retransmitted using a default timeout and exponential 1350 back-off between retransmissions, until the DOTS server sends an 1351 Acknowledgement message (ACK) with the same Message ID conveyed from 1352 the DOTS client. Message transmission parameters are defined in 1353 Section 4.8 of [RFC7252]. The DOTS server can either piggyback the 1354 response in the acknowledgement message or if the DOTS server is not 1355 able to respond immediately to a request carried in a Confirmable 1356 message, it simply responds with an Empty Acknowledgement message so 1357 that the DOTS client can stop retransmitting the request. Empty 1358 Acknowledgement message is explained in Section 2.2 of [RFC7252]. 1359 When the response is ready, the server sends it in a new Confirmable 1360 message which then in turn needs to be acknowledged by the DOTS 1361 client (see Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and 1362 responses exchanged between DOTS agents during peacetime are marked 1363 as Confirmable messages. 1365 Implementation Note: A DOTS client that receives a response in a 1366 CON message may want to clean up the message state right after 1367 sending the ACK. If that ACK is lost and the DOTS server 1368 retransmits the CON, the DOTS client may no longer have any state 1369 to which to correlate this response, making the retransmission an 1370 unexpected message; the DOTS client will send a Reset message so 1371 it does not receive any more retransmissions. This behavior is 1372 normal and not an indication of an error (see Section 5.3.2 of 1373 [RFC7252] for more details). 1375 4.5.1. Discover Configuration Parameters 1377 A GET request is used to obtain acceptable and current configuration 1378 parameters on the DOTS server for DOTS signal channel session 1379 configuration. Figure 15 shows how to obtain acceptable 1380 configuration parameters for the DOTS server. 1382 Header: GET (Code=0.01) 1383 Uri-Host: "host" 1384 Uri-Path: ".well-known" 1385 Uri-Path: "dots" 1386 Uri-Path: "version" 1387 Uri-Path: "config" 1389 Figure 15: GET to retrieve configuration 1391 The DOTS server in the 2.05 (Content) response conveys the current, 1392 minimum and maximum attribute values acceptable by the DOTS server. 1394 Content-Format: "application/cbor" 1395 { 1396 "heartbeat-interval": { 1397 "CurrentValue": integer, 1398 "MinValue": integer, 1399 "MaxValue" : integer, 1400 }, 1401 "missing-hb-allowed": { 1402 "CurrentValue": integer, 1403 "MinValue": integer, 1404 "MaxValue" : integer, 1405 }, 1406 "max-retransmit": { 1407 "CurrentValue": integer, 1408 "MinValue": integer, 1409 "MaxValue" : integer, 1410 }, 1411 "ack-timeout": { 1412 "CurrentValue": integer, 1413 "MinValue": integer, 1414 "MaxValue" : integer, 1415 }, 1416 "ack-random-factor": { 1417 "CurrentValue": number, 1418 "MinValue": number, 1419 "MaxValue" : number, 1420 }, 1421 "trigger-mitigation": { 1422 "CurrentValue": boolean, 1423 } 1424 } 1426 Figure 16: GET response body 1428 Figure 17 shows an example of acceptable and current configuration 1429 parameters on the DOTS server for DOTS signal channel session 1430 configuration. 1432 Content-Format: "application/cbor" 1433 { 1434 "heartbeat-interval": { 1435 "CurrentValue": 30, 1436 "MinValue": 15, 1437 "MaxValue" : 240, 1438 }, 1439 "missing-hb-allowed": { 1440 "CurrentValue": 5, 1441 "MinValue": 3, 1442 "MaxValue" : 9, 1443 }, 1444 "max-retransmit": { 1445 "CurrentValue": 3, 1446 "MinValue": 2, 1447 "MaxValue" : 15, 1448 }, 1449 "ack-timeout": { 1450 "CurrentValue": 2, 1451 "MinValue": 1, 1452 "MaxValue" : 30, 1453 }, 1454 "ack-random-factor": { 1455 "CurrentValue": 1.5, 1456 "MinValue": 1.1, 1457 "MaxValue" : 4.0, 1458 }, 1459 "trigger-mitigation": { 1460 "CurrentValue": true, 1461 } 1462 } 1464 Figure 17: Configuration response body 1466 4.5.2. Convey DOTS Signal Channel Session Configuration 1468 A PUT request is used to convey the configuration parameters for the 1469 signal channel (e.g., heartbeat interval, maximum retransmissions). 1470 Message transmission parameters for CoAP are defined in Section 4.8 1471 of [RFC7252]. The RECOMMENDED values of transmission parameter 1472 values are ack_timeout (2 seconds), max-retransmit (3), ack-random- 1473 factor (1.5). In addition to those parameters, the RECOMMENDED 1474 specific DOTS transmission parameter values are heartbeat-interval 1475 (30 seconds) and missing-hb-allowed (5). 1477 Note: heartbeat-interval should be tweaked to also assist DOTS 1478 messages for NAT traversal (SIG-010 of 1479 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 1480 messages must not be sent more frequently than once every 15 1481 seconds and should use longer intervals when possible. 1482 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 1483 minutes or longer, but experience shows that sending packets every 1484 15 to 30 seconds is necessary to prevent the majority of 1485 middleboxes from losing state for UDP flows. From that 1486 standpoint, this specification recommends a minimum heartbeat- 1487 interval of 15 seconds and a maximum heartbeat-interval of 240 1488 seconds. The recommended value of 30 seconds is selected to 1489 anticipate the expiry of NAT state. 1491 A heartbeat-interval of 30 second may be seen as too chatty in 1492 some deployments. For such deployments, DOTS agents may negotiate 1493 longer heartbeat-interval values to avoid overloading the network 1494 with too frequent keepalives. 1496 When a confirmable "CoAP Ping" is sent, and if there is no response, 1497 the "CoAP Ping" is retransmitted max-retransmit number of times by 1498 the CoAP layer using an initial timeout set to a random duration 1499 between ack_timeout and (ack-timeout*ack-random-factor) and 1500 exponential back-off between retransmissions. By choosing the 1501 recommended transmission parameters, the "CoAP Ping" will timeout 1502 after 45 seconds. If the DOTS agent does not receive any response 1503 from the peer DOTS agent for missing-hb-allowed number of consecutive 1504 "CoAP Ping" confirmable messages, it concludes that the DOTS signal 1505 channel session is disconnected. A DOTS client MUST NOT transmit a 1506 "CoAP Ping" while waiting for the previous "CoAP Ping" response from 1507 the same DOTS server. 1509 If the DOTS agent wishes to change the default values of message 1510 transmission parameters, then it should follow the guidance given in 1511 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 1512 values for message transmission parameters and default values for 1513 non-negotiated message transmission parameters. 1515 The signal channel session configuration is applicable to a single 1516 DOTS signal channel session between the DOTS agents. 1518 Header: PUT (Code=0.03) 1519 Uri-Host: "host" 1520 Uri-Path: ".well-known" 1521 Uri-Path: "dots" 1522 Uri-Path: "version" 1523 Uri-Path: "config" 1524 Content-Format: "application/cbor" 1525 { 1526 "signal-config": { 1527 "session-id": integer, 1528 "heartbeat-interval": integer, 1529 "missing-hb-allowed": integer, 1530 "max-retransmit": integer, 1531 "ack-timeout": integer, 1532 "ack-random-factor": number 1533 "trigger-mitigation": boolean 1534 } 1535 } 1537 Figure 18: PUT to convey the DOTS signal channel session 1538 configuration data. 1540 The parameters are described below: 1542 session-id: Identifier for the DOTS signal channel session 1543 configuration data represented as an integer. This identifier 1544 MUST be generated by the DOTS client. This document does not make 1545 any assumption about how this identifier is generated. 1547 This is a mandatory attribute. 1549 heartbeat-interval: Time interval in seconds between two 1550 consecutive heartbeat messages. 1552 This is an optional attribute. 1554 missing-hb-allowed: Maximum number of consecutive heartbeat 1555 messages for which the DOTS agent did not receive a response 1556 before concluding that the session is disconnected. 1558 This is an optional attribute. 1560 max-retransmit: Maximum number of retransmissions for a message 1561 (referred to as MAX_RETRANSMIT parameter in CoAP). 1563 This is an optional attribute. 1565 ack-timeout: Timeout value in seconds used to calculate the initial 1566 retransmission timeout value (referred to as ACK_TIMEOUT parameter 1567 in CoAP). 1569 This is an optional attribute. 1571 ack-random-factor: Random factor used to influence the timing of 1572 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1573 CoAP). 1575 This is an optional attribute. 1577 trigger-mitigation: If the parameter value is set to 'false', then 1578 DDoS mitigation is triggered only when the DOTS signal channel 1579 session is lost. Automated mitigation on loss of signal is 1580 discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. 1582 If the DOTS client ceases to respond to heartbeat messages, the 1583 DOTS server can detect that the DOTS session is lost. 1585 The default value of the parameter is 'true'. 1587 This is an optional attribute. 1589 In the PUT request at least one of the attributes 'heartbeat- 1590 interval', 'missing-hb-allowed', 'max-retransmit', 'ack-timeout', 1591 'ack-random-factor', and 'trigger-mitigation' MUST be present. The 1592 PUT request with higher numeric 'session-id' value over-rides the 1593 DOTS signal channel session configuration data installed by a PUT 1594 request with a lower numeric 'session-id' value. 1596 Figure 19 shows a PUT request example to convey the configuration 1597 parameters for the DOTS signal channel. 1599 Header: PUT (Code=0.03) 1600 Uri-Host: "www.example.com" 1601 Uri-Path: ".well-known" 1602 Uri-Path: "dots" 1603 Uri-Path: "v1" 1604 Uri-Path: "config" 1605 Content-Format: "application/cbor" 1606 { 1607 "signal-config": { 1608 "session-id": 1234534333242, 1609 "heartbeat-interval": 91, 1610 "missing-hb-allowed": 3, 1611 "max-retransmit": 7, 1612 "ack-timeout": 5, 1613 "ack-random-factor": 1.5, 1614 "trigger-mitigation": false 1615 } 1616 } 1618 Figure 19: PUT to convey the configuration parameters 1620 The DOTS server indicates the result of processing the PUT request 1621 using CoAP response codes: 1623 o If the DOTS server finds the 'session-id' parameter value conveyed 1624 in the PUT request in its configuration data and if the DOTS 1625 server has accepted the updated configuration parameters, then 1626 2.04 (Changed) code is returned in the response. 1628 o If the DOTS server does not find the 'session-id' parameter value 1629 conveyed in the PUT request in its configuration data and if the 1630 DOTS server has accepted the configuration parameters, then a 1631 response code 2.01 (Created) is returned in the response. 1633 o If the request is missing one or more mandatory attributes or it 1634 contains one or more invalid or unknown parameters, then 4.00 (Bad 1635 Request) is returned in the response. 1637 o Response code 4.22 (Unprocessable Entity) is returned in the 1638 response, if any of the heartbeat-interval, missing-hb-allowed, 1639 max-retransmit, target-protocol, ack-timeout, and ack-random- 1640 factor attribute values are not acceptable to the DOTS server. 1641 Upon receipt of the 4.22 error response code, the DOTS client 1642 should request the maximum and minimum attribute values acceptable 1643 to the DOTS server (Section 4.5.1). The DOTS client may re-try 1644 and send the PUT request with updated attribute values acceptable 1645 to the DOTS server. 1647 4.5.3. Delete DOTS Signal Channel Session Configuration 1649 A DELETE request is used to delete the installed DOTS signal channel 1650 session configuration data (Figure 20). 1652 Header: DELETE (Code=0.04) 1653 Uri-Host: "host" 1654 Uri-Path: ".well-known" 1655 Uri-Path: "dots" 1656 Uri-Path: "version" 1657 Uri-Path: "config" 1658 Content-Format: "application/cbor" 1660 Figure 20: DELETE configuration 1662 The DOTS server resets the DOTS signal channel session configuration 1663 back to the default values and acknowledges a DOTS client's request 1664 to remove the DOTS signal channel session configuration using 2.02 1665 (Deleted) response code. 1667 4.6. Redirected Signaling 1669 Redirected DOTS signaling is discussed in detail in Section 3.2.2 of 1670 [I-D.ietf-dots-architecture]. 1672 If a DOTS server wants to redirect a DOTS client to an alternative 1673 DOTS server for a signal session, then the response code 3.00 1674 (alternate server) will be returned in the response to the client. 1676 The DOTS server can return the error response code 3.00 in response 1677 to a PUT request from the DOTS client or convey the error response 1678 code 3.00 in a unidirectional notification response from the DOTS 1679 server. 1681 The DOTS server in the error response conveys the alternate DOTS 1682 server's FQDN, and the alternate DOTS server IP address(es) and time 1683 to live values in the CBOR body. 1685 { 1686 "alt-server": "string", 1687 "alt-server-record": [ 1688 { 1689 "addr": "string", 1690 "ttl" : integer, 1691 } 1692 ] 1693 } 1695 Figure 21: Error response body 1697 The parameters are described below: 1699 alt-server: FQDN of an alternate DOTS server. 1701 addr: IP address of an alternate DOTS server. 1703 ttl: Time to live (TTL) represented as an integer number of seconds. 1705 Figure 22 shows a 3.00 response example to convey the DOTS alternate 1706 server 'alt-server.example', its IP addresses 2001:db8:6401::1 and 1707 2001:db8:6401::2, and TTL values 3600 and 1800. 1709 { 1710 "alt-server": "alt-server.example", 1711 "alt-server-record": [ 1712 { 1713 "ttl" : 3600, 1714 "addr": "2001:db8:6401::1" 1715 }, 1716 { 1717 "ttl" : 1800, 1718 "addr": "2001:db8:6401::2" 1719 } 1720 ] 1721 } 1723 Figure 22: Example of error response body 1725 When the DOTS client receives 3.00 response, it considers the current 1726 request as having failed, but SHOULD try the request with the 1727 alternate DOTS server. During a DDOS attack, the DNS server may be 1728 subjected to DDOS attack, alternate DOTS server IP addresses conveyed 1729 in the 3.00 response help the DOTS client to skip DNS lookup of the 1730 alternate DOTS server and can try to establish UDP or TCP session 1731 with the alternate DOTS server IP addresses. The DOTS client SHOULD 1732 implement DNS64 function to handle the scenario where IPv6-only DOTS 1733 client communicates with IPv4-only alternate DOTS server. 1735 4.7. Heartbeat Mechanism 1737 To provide a metric of signal health and distinguish an 'idle' signal 1738 channel from a 'disconnected' or 'defunct' session, the DOTS agent 1739 sends a heartbeat over the signal channel to maintain its half of the 1740 channel. The DOTS agent similarly expects a heartbeat from its peer 1741 DOTS agent, and may consider a session terminated in the extended 1742 absence of a peer agent heartbeat. 1744 While the communication between the DOTS agents is quiescent, the 1745 DOTS client will probe the DOTS server to ensure it has maintained 1746 cryptographic state and vice versa. Such probes can also keep alive 1747 firewall and/or NAT bindings. This probing reduces the frequency of 1748 establishing a new handshake when a DOTS signal needs to be conveyed 1749 to the DOTS server. 1751 In case of a volumetric DDoS attack saturating the incoming link to 1752 the DOTS client, all traffic from the DOTS server to the DOTS client 1753 will likely be dropped, although the DOTS server receives heartbeat 1754 requests and DOTS messages from the DOTS client. In this scenario, 1755 the DOTS agents MUST behave differently to handle message 1756 transmission and DOTS session liveliness during link saturation: 1758 o The DOTS client MUST NOT consider the DOTS session terminated even 1759 after maximum 'missing-hb-allowed' threshold is reached. The DOTS 1760 client SHOULD continue to use the current DOTS session, and send 1761 heartbeat requests over the current DOTS session, so the DOTS 1762 server knows the DOTS client has not disconnected the DOTS 1763 session. 1765 After the maximum 'missing-hb-allowed' threshold is reached, the 1766 DOTS client SHOULD try (D)TLS session resumption. The DOTS client 1767 SHOULD send mitigation requests over the current DOTS session, and 1768 in parallel, try (D)TLS session resumption or 0-RTT mode in DTLS 1769 1.3 to piggyback the mitigation request in the ClientHello 1770 message. 1772 Once the link is no longer saturated, if traffic from the DOTS 1773 server reaches the DOTS client over the current DOTS session, the 1774 DOTS client can stop (D)TLS session resumption or if (D)TLS 1775 session resumption is successful then disconnect the current DOTS 1776 session. 1778 o If the DOTS server does not receive any traffic from the peer DOTS 1779 client, then the DOTS server sends heartbeat requests to the DOTS 1780 client and after maximum 'missing-hb-allowed' threshold is 1781 reached, the DOTS server concludes the session is disconnected. 1783 In DOTS over UDP, heartbeat messages may be exchanged between the 1784 DOTS agents using the "COAP Ping" mechanism defined in Section 4.2 of 1785 [RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable 1786 message and the peer DOTS agent will respond by sending an Reset 1787 message. 1789 In DOTS over TCP, heartbeat messages can be exchanged between the 1790 DOTS agents using the Ping and Pong messages specified in Section 4.4 1791 of [I-D.ietf-core-coap-tcp-tls]. That is, the DOTS agent sends a 1792 Ping message and the peer DOTS agent would respond by sending a 1793 single Pong message. 1795 5. DOTS Signal Channel YANG Module 1797 This document defines a YANG [RFC7950] module for mitigation scope 1798 and DOTS signal channel session configuration data. 1800 5.1. Tree Structure 1802 This document defines the YANG module "ietf-dots-signal" 1803 (Section 5.2), which has the following tree structure. A DOTS signal 1804 message can either be a mitigation or a configuration message. 1806 module: ietf-dots-signal 1807 +--rw dots-signal 1808 +--rw (message-type)? 1809 +--:(mitigation-scope) 1810 | +--rw client-identifier* binary 1811 | +--rw scope* [mitigation-id] 1812 | +--rw mitigation-id int32 1813 | +--rw target-ip* inet:ip-address 1814 | +--rw target-prefix* inet:ip-prefix 1815 | +--rw target-port-range* [lower-port upper-port] 1816 | | +--rw lower-port inet:port-number 1817 | | +--rw upper-port inet:port-number 1818 | +--rw target-protocol* uint8 1819 | +--rw target-fqdn* inet:domain-name 1820 | +--rw target-uri* inet:uri 1821 | +--rw alias-name* string 1822 | +--rw lifetime? int32 1823 | +--rw mitigation-start? int64 1824 | +--ro status? enumeration 1825 | +--ro conflict-information 1826 | | +--ro conflict-status? enumeration 1827 | | +--ro conflict-cause? enumeration 1828 | | +--ro retry-timer? int32 1829 | | +--ro conflict-scope 1830 | | +--ro target-ip* inet:ip-address 1831 | | +--ro target-prefix* inet:ip-prefix 1832 | | +--ro target-port-range* [lower-port upper-port] 1833 | | | +--ro lower-port inet:port-number 1834 | | | +--ro upper-port inet:port-number 1835 | | +--ro target-protocol* uint8 1836 | | +--ro target-fqdn* inet:domain-name 1837 | | +--ro target-uri* inet:uri 1838 | | +--ro alias-name* string 1839 | +--ro pkts-dropped? yang:zero-based-counter64 1840 | +--ro bps-dropped? yang:zero-based-counter64 1841 | +--ro bytes-dropped? yang:zero-based-counter64 1842 | +--ro pps-dropped? yang:zero-based-counter64 1843 +--:(configuration) 1844 +--rw session-id int32 1845 +--rw heartbeat-interval? int16 1846 +--rw missing-hb-allowed? int16 1847 +--rw max-retransmit? int16 1848 +--rw ack-timeout? int16 1849 +--rw ack-random-factor? decimal64 1850 +--rw trigger-mitigation? boolean 1852 5.2. YANG Module 1854 file "ietf-dots-signal@2017-12-05.yang" 1856 module ietf-dots-signal { 1857 yang-version 1.1; 1858 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; 1859 prefix "signal"; 1861 import ietf-inet-types {prefix "inet";} 1862 import ietf-yang-types {prefix yang; } 1864 organization "IETF DOTS Working Group"; 1866 contact 1867 "Konda, Tirumaleswar Reddy 1868 Mohamed Boucadair 1869 Prashanth Patil 1870 Andrew Mortensen 1871 Nik Teague "; 1873 description 1874 "This module contains YANG definition for the signaling 1875 messages exchanegd between the DOTS client to the DOTS server. 1877 Copyright (c) 2017 IETF Trust and the persons identified as 1878 authors of the code. All rights reserved. 1880 Redistribution and use in source and binary forms, with or 1881 without modification, is permitted pursuant to, and subject 1882 to the license terms contained in, the Simplified BSD License 1883 set forth in Section 4.c of the IETF Trust's Legal Provisions 1884 Relating to IETF Documents 1885 (http://trustee.ietf.org/license-info). 1887 This version of this YANG module is part of RFC XXXX; see 1888 the RFC itself for full legal notices."; 1890 revision 2017-12-05 { 1891 description 1892 "Initial revision."; 1893 reference 1894 "RFC XXXX: Distributed Denial-of-Service Open Threat 1895 Signaling (DOTS) Signal Channel"; 1896 } 1898 grouping target { 1899 description 1900 "Specifies the scope of the mitigation request."; 1902 leaf-list target-ip { 1903 type inet:ip-address; 1904 description 1905 "IPv4 or IPv6 address identifying the target."; 1906 } 1908 leaf-list target-prefix { 1909 type inet:ip-prefix; 1910 description 1911 "IPv4 or IPv6 prefix identifying the target."; 1912 } 1914 list target-port-range { 1915 key "lower-port upper-port"; 1917 description 1918 "Port range. When only lower-port is 1919 present, it represents a single port."; 1921 leaf lower-port { 1922 type inet:port-number; 1923 mandatory true; 1924 description "Lower port number."; 1925 } 1927 leaf upper-port { 1928 type inet:port-number; 1929 must ". >= ../lower-port" { 1930 error-message 1931 "The upper port number must be greater than 1932 or equal to lower port number."; 1933 } 1934 description "Upper port number."; 1935 } 1936 } 1938 leaf-list target-protocol { 1939 type uint8; 1940 description 1941 "Identifies the target protocol number. 1943 The value '0' means 'all protocols'. 1945 Values are taken from the IANA protocol registry: 1946 https://www.iana.org/assignments/protocol-numbers/ 1947 protocol-numbers.xhtml 1948 For example, 6 for a TCP or 17 for UDP."; 1949 } 1951 leaf-list target-fqdn { 1952 type inet:domain-name; 1953 description "FQDN identifying the target."; 1954 } 1956 leaf-list target-uri { 1957 type inet:uri; 1958 description "URI identifying the target."; 1959 } 1961 leaf-list alias-name { 1962 type string; 1963 description "alias name"; 1964 } 1965 } 1967 grouping mitigation-scope { 1968 description 1969 "Specifies the scope of the mitigation request."; 1971 leaf-list client-identifier { 1972 type binary; 1973 description 1974 "The client identifier may be conveyed by 1975 the DOTS gateway to propagate the DOTS client 1976 identity from the gateway's client-side to the 1977 gateway's server-side, and from the gateway's 1978 server-side to the DOTS server. 1980 It allows the final DOTS server to accept 1981 mitigation requests with scopes which the DOTS 1982 client is authorized to manage."; 1983 } 1985 list scope { 1986 key mitigation-id; 1987 description 1988 "The scope of the request."; 1990 leaf mitigation-id { 1991 type int32; 1992 description 1993 "Mitigation request identifier. 1995 This identifier must be unique for each mitigation 1996 request bound to the DOTS client."; 1997 } 1999 uses target; 2001 leaf lifetime { 2002 type int32; 2003 units "seconds"; 2004 default 3600; 2005 description 2006 "Indicates the lifetime of the mitigation request."; 2007 reference 2008 "RFC XXXX: Distributed Denial-of-Service Open Threat 2009 Signaling (DOTS) Signal Channel"; 2010 } 2012 leaf mitigation-start { 2013 type int64; 2014 units "seconds"; 2015 description 2016 "Mitigation start time is represented in seconds 2017 relative to 1970-01-01T00:00Z in UTC time."; 2018 } 2020 leaf status { 2021 type enumeration { 2022 enum "1" { 2023 description 2024 "Attack mitigation is in progress (e.g., changing 2025 the network path to re-route the inbound traffic 2026 to DOTS mitigator)."; 2027 } 2029 enum "2" { 2030 description 2031 "Attack is successfully mitigated (e.g., traffic 2032 is redirected to a DDOS mitigator and attack 2033 traffic is dropped)."; 2034 } 2036 enum "3" { 2037 description 2038 "Attack has stopped and the DOTS client can 2039 withdraw the mitigation request."; 2040 } 2042 enum "4" { 2043 description 2044 "Attack has exceeded the mitigation provider 2045 capability."; 2046 } 2048 enum "5" { 2049 description 2050 "DOTS client has withdrawn the mitigation 2051 request and the mitigation is active but 2052 terminating."; 2053 } 2055 enum "6" { 2056 description 2057 "Attack mitigation is now terminated."; 2058 } 2060 enum "7" { 2061 description 2062 "Attack mitigation is withdrawn."; 2063 } 2065 enum "8" { 2066 description 2067 "Attack mitigation is rejected."; 2068 } 2069 } 2070 config false; 2071 description 2072 "Indicates the status of a mitigation request. 2073 It must be included in responses, only."; 2074 } 2076 container conflict-information { 2077 config false; 2078 description 2079 "Indicates that a conflict is detected. 2080 Must only be used for responses."; 2082 leaf conflict-status { 2083 type enumeration { 2084 enum "1" { 2085 description 2086 "DOTS Server has detected conflicting mitigation 2087 requests from different DOTS clients. 2088 This mitigation request is currently inactive 2089 until the conflicts are resolved. Another 2090 mitigation request is active."; 2092 } 2094 enum "2" { 2095 description 2096 "DOTS Server has detected conflicting mitigation 2097 requests from different DOTS clients. 2098 This mitigation request is currently active."; 2099 } 2101 enum "3" { 2102 description 2103 "DOTS Server has detected conflicting mitigation 2104 requests from different DOTS clients. All 2105 conflicting mitigation requests are inactive."; 2106 } 2107 } 2108 description 2109 "Indicates the conflict status. 2110 It must be included in responses, only."; 2111 } 2113 leaf conflict-cause { 2114 type enumeration { 2115 enum "1" { 2116 description 2117 "Overlapping targets. conflict-scope provides 2118 more details about the exact conflict."; 2119 } 2121 enum "2" { 2122 description 2123 "Conflicts with an existing white list. 2125 This code is returned when the DDoS mitigation 2126 detects source addresses/prefixes in the 2127 white-listed ACLs are attacking the target."; 2128 } 2129 } 2130 description 2131 "Indicates the cause of the conflict. 2132 It must be included in responses, only."; 2133 } 2135 leaf retry-timer { 2136 type int32; 2137 units "seconds"; 2138 description 2139 "The DOTS client must not re-send the 2140 same request before the expiry of this timer. 2141 It must be included in responses, only."; 2142 } 2144 container conflict-scope { 2145 description 2146 "Provides more information about the conflict scope."; 2147 uses target; 2148 } 2149 } 2151 leaf pkts-dropped { 2152 type yang:zero-based-counter64; 2153 config false; 2154 description 2155 "Number of dropped packets"; 2156 } 2158 leaf bps-dropped { 2159 type yang:zero-based-counter64; 2160 config false; 2161 description 2162 "The average dropped bytes per second for 2163 the mitigation request since the attack 2164 mitigation is triggered."; 2165 } 2167 leaf bytes-dropped { 2168 type yang:zero-based-counter64; 2169 units 'bytes'; 2170 config false; 2171 description 2172 "Counter for dropped pacckets; in bytes."; 2173 } 2175 leaf pps-dropped { 2176 type yang:zero-based-counter64; 2177 config false; 2178 description 2179 "The average dropped packets per second 2180 for the mitigation request since the attack 2181 mitigation is triggered."; 2182 } 2183 } 2184 } 2186 grouping signal-config { 2187 description 2188 "DOTS signal channel session configuration."; 2190 leaf session-id { 2191 type int32; 2192 mandatory true; 2193 description 2194 "An identifier for the DOTS signal channel 2195 session configuration data."; 2196 } 2198 leaf heartbeat-interval { 2199 type int16; 2200 units "seconds"; 2201 default 30; 2202 description 2203 "DOTS agents regularly send heartbeats to each other 2204 after mutual authentication in order to keep 2205 the DOTS signal channel open."; 2206 reference 2207 "RFC XXXX: Distributed Denial-of-Service Open Threat 2208 Signaling (DOTS) Signal Channel"; 2209 } 2211 leaf missing-hb-allowed { 2212 type int16; 2213 default 5; 2214 description 2215 "Maximum number of missing heartbeats allowed."; 2216 reference 2217 "RFC XXXX: Distributed Denial-of-Service Open Threat 2218 Signaling (DOTS) Signal Channel"; 2219 } 2221 leaf max-retransmit { 2222 type int16; 2223 default 3; 2224 description 2225 "Maximum number of retransmissions of a 2226 Confirmable message."; 2227 reference 2228 "RFC XXXX: Distributed Denial-of-Service Open Threat 2229 Signaling (DOTS) Signal Channel"; 2230 } 2232 leaf ack-timeout { 2233 type int16; 2234 units "seconds"; 2235 default 2; 2236 description 2237 "Initial retransmission timeout value."; 2238 reference 2239 "Section 4.8 of RFC 7552."; 2240 } 2242 leaf ack-random-factor { 2243 type decimal64 { 2244 fraction-digits 2; 2245 } 2246 default 1.5; 2247 description 2248 "Random factor used to influence the timing of 2249 retransmissions."; 2250 reference 2251 "Section 4.8 of RFC 7552."; 2252 } 2254 leaf trigger-mitigation { 2255 type boolean; 2256 default true; 2257 description 2258 "If false, then mitigation is triggered 2259 only when the DOTS server channel session is lost"; 2260 reference 2261 "RFC XXXX: Distributed Denial-of-Service Open Threat 2262 Signaling (DOTS) Signal Channel"; 2263 } 2264 } 2266 container dots-signal { 2267 description 2268 "Main contaner for DOTS signal message. 2269 A DOTS signal message can be a mitigation messages or 2270 a configuration message."; 2272 choice message-type { 2273 description 2274 "Either a mitigation or a configuration message."; 2276 case mitigation-scope { 2277 description 2278 "Mitigation scope of a mitigation message."; 2279 uses mitigation-scope; 2280 } 2282 case configuration { 2283 description 2284 "Configuration message."; 2285 uses signal-config; 2286 } 2287 } 2288 } 2289 } 2290 2292 6. Mapping Parameters to CBOR 2294 All parameters in the payload in the DOTS signal channel MUST be 2295 mapped to CBOR types as shown in Table 4 and are given an integer key 2296 to save space. The recipient of the payload MAY reject the 2297 information if it is not suitably mapped. 2299 /----------------------+----------------+--------------------------\ 2300 | Parameter name | CBOR key | CBOR major type of value | 2301 +----------------------+----------------+--------------------------+ 2302 | mitigation-scope | 1 | 5 (map) | 2303 | scope | 2 | 5 (map) | 2304 | mitigation-id | 3 | 0 (unsigned) | 2305 | target-ip | 4 | 4 (array) | 2306 | target-port-range | 5 | 4 | 2307 | lower-port | 6 | 0 | 2308 | upper-port | 7 | 0 | 2309 | target-protocol | 8 | 4 | 2310 | target-fqdn | 9 | 4 | 2311 | target-uri | 10 | 4 | 2312 | alias-name | 11 | 4 | 2313 | lifetime | 12 | 0 | 2314 | attack-status | 13 | 0 | 2315 | signal-config | 14 | 5 | 2316 | heartbeat-interval | 15 | 0 | 2317 | max-retransmit | 16 | 0 | 2318 | ack-timeout | 17 | 0 | 2319 | ack-random-factor | 18 | 7 | 2320 | MinValue | 19 | 0 | 2321 | MaxValue | 20 | 0 | 2322 | status | 21 | 0 | 2323 | conflict-information | 22 | 5 (map) | 2324 | conflict-status | 23 | 0 | 2325 | conflict-cause | 24 | 0 | 2326 | retry-timer | 25 | 0 | 2327 | bytes-dropped | 26 | 0 | 2328 | bps-dropped | 27 | 0 | 2329 | pkts-dropped | 28 | 0 | 2330 | pps-dropped | 29 | 0 | 2331 | session-id | 30 | 0 | 2332 | trigger-mitigation | 31 | 7 (simple types) | 2333 | missing-hb-allowed | 32 | 0 | 2334 | CurrentValue | 33 | 0 | 2335 | mitigation-start | 34 | 7 (floating-point) | 2336 | target-prefix | 35 | 4 (array) | 2337 | client-identifier | 36 | 2 (byte string) | 2338 | alt-server | 37 | 2 | 2339 | alt-server-record | 38 | 4 | 2340 | addr | 39 | 2 | 2341 | ttl | 40 | 0 | 2342 \----------------------+----------------+--------------------------/ 2343 Table 4: CBOR mappings used in DOTS signal channel message 2345 7. (D)TLS Protocol Profile and Performance Considerations 2347 7.1. (D)TLS Protocol Profile 2349 This section defines the (D)TLS protocol profile of DOTS signal 2350 channel over (D)TLS and DOTS data channel over TLS. 2352 There are known attacks on (D)TLS, such as machine-in-the-middle and 2353 protocol downgrade. These are general attacks on (D)TLS and not 2354 specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for 2355 discussion of these security issues. DOTS agents MUST adhere to the 2356 (D)TLS implementation recommendations and security considerations of 2357 [RFC7525] except with respect to (D)TLS version. Since encryption of 2358 DOTS using (D)TLS is virtually a green-field deployment DOTS agents 2359 MUST implement only (D)TLS 1.2 or later. 2361 When a DOTS client is configured with a domain name of the DOTS 2362 server, and connects to its configured DOTS server, the server may 2363 present it with a PKIX certificate. In order to ensure proper 2364 authentication, DOTS client MUST verify the entire certification path 2365 per [RFC5280]. The DOTS client additionaly uses [RFC6125] validation 2366 techniques to compare the domain name to the certificate provided. 2368 A key challenge to deploying DOTS is provisioning DOTS clients, 2369 including the distribution of keying material to DOTS clients to make 2370 possible the required mutual authentication of DOTS agents. EST 2371 defines a method of certificate enrollment by which domains operating 2372 DOTS servers may provision DOTS clients with all necessary 2373 cryptographic keying material, including a private key and 2374 certificate with which to authenticate itself. One deployment option 2375 is DOTS clients to behave as EST clients for certificate enrollment 2376 from an EST server provisioned by the mitigation provider. This 2377 document does not specify which EST mechanism the DOTS client uses to 2378 achieve initial enrollment. 2380 Implementations compliant with this profile MUST implement all of the 2381 following items: 2383 o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect 2384 against replay attacks. 2386 o (D)TLS session resumption without server-side state [RFC5077] to 2387 resume session and convey the DOTS signal. 2389 o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduce 2390 the size of the ServerHello, and can be used by DOTS agents that 2391 cannot obtain certificates (e.g., DOTS clients and DOTS gateways 2392 on private networks). 2394 Implementations compliant with this profile SHOULD implement all of 2395 the following items to reduce the delay required to deliver a DOTS 2396 signal: 2398 o TLS False Start [RFC7918] which reduces round-trips by allowing 2399 the TLS second flight of messages (ChangeCipherSpec) to also 2400 contain the DOTS signal. 2402 o Cached Information Extension [RFC7924] which avoids transmitting 2403 the server's certificate and certificate chain if the client has 2404 cached that information from a previous TLS handshake. 2406 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 2407 convey DOTS signal. 2409 7.2. (D)TLS 1.3 Considerations 2411 TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements 2412 for connection establishment over TLS 1.2. The DTLS 1.3 protocol 2413 [I-D.ietf-tls-dtls13] is based on the TLS 1.3 protocol and provides 2414 equivalent security guarantees. (D)TLS 1.3 provides two basic 2415 handshake modes of interest to DOTS signal channel: 2417 o Absent packet loss, a full handshake in which the DOTS client is 2418 able to send the DOTS signal message after one round trip and the 2419 DOTS server immediately after receiving the first DOTS signal 2420 message from the client. 2422 o 0-RTT mode in which the DOTS client can authenticate itself and 2423 send DOTS signal message on its first flight, thus reducing 2424 handshake latency. 0-RTT only works if the DOTS client has 2425 previously communicated with that DOTS server, which is very 2426 likely with the DOTS signal channel. The DOTS client SHOULD 2427 establish a (D)TLS session with the DOTS server during peacetime 2428 and share a PSK. During DDOS attack, the DOTS client can use the 2429 (D)TLS session to convey the DOTS signal message and if there is 2430 no response from the server after multiple re-tries then the DOTS 2431 client can resume the (D)TLS session in 0-RTT mode using PSK. A 2432 simplified TLS 1.3 handshake with 0-RTT DOTS signal message 2433 exchange is shown in Figure 23. 2435 DOTS Client DOTS Server 2437 ClientHello 2438 (Finished) 2439 (0-RTT DOTS signal message) 2440 (end_of_early_data) --------> 2441 ServerHello 2442 {EncryptedExtensions} 2443 {ServerConfiguration} 2444 {Certificate} 2445 {CertificateVerify} 2446 {Finished} 2447 <-------- [DOTS signal message] 2448 {Finished} --------> 2450 [DOTS signal message] <-------> [DOTS signal message] 2452 Figure 23: TLS 1.3 handshake with 0-RTT 2454 7.3. MTU and Fragmentation 2456 To avoid DOTS signal message fragmentation and the consequently 2457 decreased probability of message delivery, DOTS agents MUST ensure 2458 that the DTLS record MUST fit within a single datagram. If the path 2459 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 2460 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 2461 is used to convey the DOTS signal messages then the DOTS client must 2462 consider the amount of record expansion expected by the DTLS 2463 processing when calculating the size of CoAP message that fits within 2464 the path MTU. Path MTU MUST be greater than or equal to [CoAP 2465 message size + DTLS overhead of 13 octets + authentication overhead 2466 of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 2467 of [RFC6347]). If the request size exceeds the path MTU then the 2468 DOTS client MUST split the DOTS signal into separate messages, for 2469 example the list of addresses in the 'target-ip' parameter could be 2470 split into multiple lists and each list conveyed in a new PUT 2471 request. 2473 Implementation Note: DOTS choice of message size parameters works 2474 well with IPv6 and with most of today's IPv4 paths. However, with 2475 IPv4, it is harder to absolutely ensure that there is no IP 2476 fragmentation. If IPv4 support on unusual networks is a 2477 consideration and path MTU is unknown, implementations may want to 2478 limit themselves to more conservative IPv4 datagram sizes such as 576 2479 bytes, as per [RFC0791] IP packets up to 576 bytes should never need 2480 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal 2481 over a UDP datagram will generally avoid IP fragmentation. 2483 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 2485 (D)TLS based on client certificate can be used for mutual 2486 authentication between DOTS agents. If a DOTS gateway is involved, 2487 DOTS clients and DOTS gateway MUST perform mutual authentication; 2488 only authorized DOTS clients are allowed to send DOTS signals to a 2489 DOTS gateway. DOTS gateway and DOTS server MUST perform mutual 2490 authentication; DOTS server only allows DOTS signals from authorized 2491 DOTS gateway, creating a two-link chain of transitive authentication 2492 between the DOTS client and the DOTS server. 2494 +-----------------------------------------------+ 2495 | example.com domain +---------+ | 2496 | | AAA | | 2497 | +---------------+ | Server | | 2498 | | Application | +------+--+ | 2499 | | server +<-----------------+ ^ | 2500 | | (DOTS client) | | | | 2501 | +---------------+ | | | 2502 | V V | example.net domain 2503 | +-----+----+--+ | +---------------+ 2504 | +--------------+ | | | | | 2505 | | Guest +<-----x----->+ DOTS +<------>+ DOTS | 2506 | | (DOTS client)| | Gateway | | | Server | 2507 | +--------------+ | | | | | 2508 | +----+--------+ | +---------------+ 2509 | ^ | 2510 | | | 2511 | +----------------+ | | 2512 | | DDOS detector | | | 2513 | | (DOTS client) +<---------------+ | 2514 | +----------------+ | 2515 +-----------------------------------------------+ 2517 Figure 24: Example of Authentication and Authorization of DOTS Agents 2519 In the example depicted in Figure 24, the DOTS gateway and DOTS 2520 clients within the 'example.com' domain mutually authenticate with 2521 each other. After the DOTS gateway validates the identity of a DOTS 2522 client, it communicates with the AAA server in the 'example.com' 2523 domain to determine if the DOTS client is authorized to request DDOS 2524 mitigation. If the DOTS client is not authorized, a 4.01 2525 (Unauthorized) is returned in the response to the DOTS client. In 2526 this example, the DOTS gateway only allows the application server and 2527 DDOS detector to request DDOS mitigation, but does not permit the 2528 user of type 'guest' to request DDOS mitigation. 2530 Also, DOTS gateway and DOTS server located in different domains MUST 2531 perform mutual authentication (e.g., using certificates). A DOTS 2532 server will only allow a DOTS gateway with a certificate for a 2533 particular domain to request mitigation for that domain. In 2534 reference to Figure 24, the DOTS server only allows the DOTS gateway 2535 to request mitigation for 'example.com' domain and not for other 2536 domains. 2538 9. IANA Considerations 2540 This specification registers a service port (Section 9.1), an URI 2541 suffix in the Well-Known URIs registry (Section 9.2), a CoAP response 2542 code (Section 9.3), a YANG module (Section 9.5). It also creates a 2543 registry for mappings to CBOR (Section 9.4). 2545 9.1. DOTS Signal Channel UDP and TCP Port Number 2547 IANA is requested to assign the port number TBD to the DOTS signal 2548 channel protocol for both UDP and TCP from the "Service Name and 2549 Transport Protocol Port Number Registry" available at 2550 https://www.iana.org/assignments/service-names-port-numbers/service- 2551 names-port-numbers.xhtml. 2553 It is strongly suggested that the port number 4646 is to be assigned. 2554 4646 is the ASCII decimal value for ".." (DOTS). 2556 9.2. Well-Known 'dots' URI 2558 This document requests IANA to register the 'dots' well-known URI in 2559 the Well-Known URIs registry (https://www.iana.org/assignments/well- 2560 known-uris/well-known-uris.xhtml) as defined by [RFC5785]. 2562 URI suffix: dots 2564 Change controller: IETF 2566 Specification document(s): This RFC 2568 Related information: None 2570 9.3. CoAP Response Code 2572 IANA is requested to add the following entry to the "CoAP Response 2573 Codes" sub-registry available at https://www.iana.org/assignments/ 2574 core-parameters/core-parameters.xhtml#response-codes: 2576 +------+------------------+-----------+ 2577 | Code | Description | Reference | 2578 +------+------------------+-----------+ 2579 | 3.00 | Alternate server | [RFCXXXX] | 2580 +------+------------------+-----------+ 2582 Table 4: CoAP Response Code 2584 9.4. DOTS Signal Channel CBOR Mappings Registry 2586 The document requests IANA to create a new registry, entitled "DOTS 2587 Signal Channel CBOR Mappings Registry". The structrue of this 2588 registry is provided in Section 9.4.1. 2590 The registry is initially populated with the values in Section 9.4.2. 2592 Values from that registry MUST be assigned via Expert Review 2593 [RFC8126]. 2595 9.4.1. Registration Template 2597 Parameter name: 2598 Parameter names (e.g., "target_ip") in the DOTS signal channel. 2600 CBOR Key Value: 2601 Key value for the parameter. The key value MUST be an integer in 2602 the range of 1 to 65536. The key values in the range of 32768 to 2603 65536 are assigned for Vendor-Specific parameters. 2605 CBOR Major Type: 2606 CBOR Major type and optional tag for the claim. 2608 Change Controller: 2609 For Standards Track RFCs, list the "IESG". For others, give the 2610 name of the responsible party. Other details (e.g., postal 2611 address, email address, home page URI) may also be included. 2613 Specification Document(s): 2614 Reference to the document or documents that specify the parameter, 2615 preferably including URIs that can be used to retrieve copies of 2616 the documents. An indication of the relevant sections may also be 2617 included but is not required. 2619 9.4.2. Initial Registry Contents 2621 o Parameter Name: "mitigation-scope" 2622 o CBOR Key Value: 1 2623 o CBOR Major Type: 5 2624 o Change Controller: IESG 2625 o Specification Document(s): this document 2627 o Parameter Name: "scope" 2628 o CBOR Key Value: 2 2629 o CBOR Major Type: 5 2630 o Change Controller: IESG 2631 o Specification Document(s): this document 2633 o Parameter Name: "mitigation-id" 2634 o CBOR Key Value: 3 2635 o CBOR Major Type: 0 2636 o Change Controller: IESG 2637 o Specification Document(s): this document 2639 o Parameter Name:target-ip 2640 o CBOR Key Value: 4 2641 o CBOR Major Type: 4 2642 o Change Controller: IESG 2643 o Specification Document(s): this document 2645 o Parameter Name: target-port-range 2646 o CBOR Key Value: 5 2647 o CBOR Major Type: 4 2648 o Change Controller: IESG 2649 o Specification Document(s): this document 2651 o Parameter Name: "lower-port" 2652 o CBOR Key Value: 6 2653 o CBOR Major Type: 0 2654 o Change Controller: IESG 2655 o Specification Document(s): this document 2657 o Parameter Name: "upper-port" 2658 o CBOR Key Value: 7 2659 o CBOR Major Type: 0 2660 o Change Controller: IESG 2661 o Specification Document(s): this document 2663 o Parameter Name: target-protocol 2664 o CBOR Key Value: 8 2665 o CBOR Major Type: 4 2666 o Change Controller: IESG 2667 o Specification Document(s): this document 2669 o Parameter Name: "target-fqdn" 2670 o CBOR Key Value: 9 2671 o CBOR Major Type: 4 2672 o Change Controller: IESG 2673 o Specification Document(s): this document 2675 o Parameter Name: "target-uri" 2676 o CBOR Key Value: 10 2677 o CBOR Major Type: 4 2678 o Change Controller: IESG 2679 o Specification Document(s): this document 2681 o Parameter Name: alias-name 2682 o CBOR Key Value: 11 2683 o CBOR Major Type: 4 2684 o Change Controller: IESG 2685 o Specification Document(s): this document 2687 o Parameter Name: "lifetime" 2688 o CBOR Key Value: 12 2689 o CBOR Major Type: 0 2690 o Change Controller: IESG 2691 o Specification Document(s): this document 2693 o Parameter Name: attack-status 2694 o CBOR Key Value: 13 2695 o CBOR Major Type: 0 2696 o Change Controller: IESG 2697 o Specification Document(s): this document 2699 o Parameter Name: signal-config 2700 o CBOR Key Value: 14 2701 o CBOR Major Type: 5 2702 o Change Controller: IESG 2703 o Specification Document(s): this document 2705 o Parameter Name: heartbeat-interval 2706 o CBOR Key Value: 15 2707 o CBOR Major Type: 0 2708 o Change Controller: IESG 2709 o Specification Document(s): this document 2711 o Parameter Name: max-retransmit 2712 o CBOR Key Value: 16 2713 o CBOR Major Type: 0 2714 o Change Controller: IESG 2715 o Specification Document(s): this document 2717 o Parameter Name: ack-timeout 2718 o CBOR Key Value: 17 2719 o CBOR Major Type: 0 2720 o Change Controller: IESG 2721 o Specification Document(s): this document 2723 o Parameter Name: ack-random-factor 2724 o CBOR Key Value: 18 2725 o CBOR Major Type: 7 2726 o Change Controller: IESG 2727 o Specification Document(s): this document 2729 o Parameter Name: MinValue 2730 o CBOR Key Value: 19 2731 o CBOR Major Type: 0 2732 o Change Controller: IESG 2733 o Specification Document(s): this document 2735 o Parameter Name: MaxValue 2736 o CBOR Key Value: 20 2737 o CBOR Major Type: 0 2738 o Change Controller: IESG 2739 o Specification Document(s): this document 2741 o Parameter Name: status 2742 o CBOR Key Value: 21 2743 o CBOR Major Type: 0 2744 o Change Controller: IESG 2745 o Specification Document(s): this document 2747 o Parameter Name: conflict-information 2748 o CBOR Key Value: 22 2749 o CBOR Major Type: 5 2750 o Change Controller: IESG 2751 o Specification Document(s): this document 2753 o Parameter Name: conflict-status 2754 o CBOR Key Value: 23 2755 o CBOR Major Type: 0 2756 o Change Controller: IESG 2757 o Specification Document(s): this document 2759 o Parameter Name: conflict-cause 2760 o CBOR Key Value: 24 2761 o CBOR Major Type: 0 2762 o Change Controller: IESG 2763 o Specification Document(s): this document 2765 o Parameter Name: retry-timer 2766 o CBOR Key Value: 25 2767 o CBOR Major Type: 0 2768 o Change Controller: IESG 2769 o Specification Document(s): this document 2771 o Parameter Name: bytes-dropped 2772 o CBOR Key Value: 26 2773 o CBOR Major Type: 0 2774 o Change Controller: IESG 2775 o Specification Document(s): this document 2777 o Parameter Name: bps-dropped 2778 o CBOR Key Value: 27 2779 o CBOR Major Type: 0 2780 o Change Controller: IESG 2781 o Specification Document(s): this document 2783 o Parameter Name: pkts-dropped 2784 o CBOR Key Value: 28 2785 o CBOR Major Type: 0 2786 o Change Controller: IESG 2787 o Specification Document(s): this document 2789 o Parameter Name: pps-dropped 2790 o CBOR Key Value: 29 2791 o CBOR Major Type: 0 2792 o Change Controller: IESG 2793 o Specification Document(s): this document 2795 o Parameter Name: session-id 2796 o CBOR Key Value: 30 2797 o CBOR Major Type: 0 2798 o Change Controller: IESG 2799 o Specification Document(s): this document 2801 o Parameter Name: trigger-mitigation 2802 o CBOR Key Value: 31 2803 o CBOR Major Type: 7 2804 o Change Controller: IESG 2805 o Specification Document(s): this document 2807 o Parameter Name: missing-hb-allowed 2808 o CBOR Key Value: 32 2809 o CBOR Major Type: 0 2810 o Change Controller: IESG 2811 o Specification Document(s): this document 2813 o Parameter Name: CurrentValue 2814 o CBOR Key Value: 33 2815 o CBOR Major Type: 0 2816 o Change Controller: IESG 2817 o Specification Document(s): this document 2819 o Parameter Name:mitigation-start 2820 o CBOR Key Value: 34 2821 o CBOR Major Type: 7 2822 o Change Controller: IESG 2823 o Specification Document(s): this document 2825 o Parameter Name:target-prefix 2826 o CBOR Key Value: 35 2827 o CBOR Major Type: 4 2828 o Change Controller: IESG 2829 o Specification Document(s): this document 2831 o Parameter Name:client-identifier 2832 o CBOR Key Value: 36 2833 o CBOR Major Type: 2 2834 o Change Controller: IESG 2835 o Specification Document(s): this document 2837 o Parameter Name:alt-server 2838 o CBOR Key Value: 37 2839 o CBOR Major Type: 2 2840 o Change Controller: IESG 2841 o Specification Document(s): this document 2843 o Parameter Name:alt-server-record 2844 o CBOR Key Value: 38 2845 o CBOR Major Type: 4 2846 o Change Controller: IESG 2847 o Specification Document(s): this document 2849 o Parameter Name:addr 2850 o CBOR Key Value: 39 2851 o CBOR Major Type: 2 2852 o Change Controller: IESG 2853 o Specification Document(s): this document 2855 o Parameter Name:ttl 2856 o CBOR Key Value: 40 2857 o CBOR Major Type: 0 2858 o Change Controller: IESG 2859 o Specification Document(s): this document 2861 9.5. DOTS Signal Channel YANG Module 2863 This document requests IANA to register the following URI in the 2864 "IETF XML Registry" [RFC3688]: 2866 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal 2867 Registrant Contact: The IESG. 2868 XML: N/A; the requested URI is an XML namespace. 2870 This document requests IANA to register the following YANG module in 2871 the "YANG Module Names" registry [RFC7950]. 2873 name: ietf-signal 2874 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal 2875 prefix: signal 2876 reference: RFC XXXX 2878 10. Implementation Status 2880 [Note to RFC Editor: Please remove this section and reference to 2881 [RFC7942] prior to publication.] 2883 This section records the status of known implementations of the 2884 protocol defined by this specification at the time of posting of this 2885 Internet-Draft, and is based on a proposal described in [RFC7942]. 2886 The description of implementations in this section is intended to 2887 assist the IETF in its decision processes in progressing drafts to 2888 RFCs. Please note that the listing of any individual implementation 2889 here does not imply endorsement by the IETF. Furthermore, no effort 2890 has been spent to verify the information presented here that was 2891 supplied by IETF contributors. This is not intended as, and must not 2892 be construed to be, a catalog of available implementations or their 2893 features. Readers are advised to note that other implementations may 2894 exist. 2896 According to [RFC7942], "this will allow reviewers and working groups 2897 to assign due consideration to documents that have the benefit of 2898 running code, which may serve as evidence of valuable experimentation 2899 and feedback that have made the implemented protocols more mature. 2900 It is up to the individual working groups to use this information as 2901 they see fit". 2903 10.1. nttdots 2905 Organization: NTT Communication is developing a DOTS client and 2906 DOTS server software based on DOTS signal channel specified in 2907 this draft. It will be open-sourced. 2909 Description: Early implementation of DOTS protocol. It is aimed to 2910 implement a full DOTS protocol spec in accordance with maturing of 2911 DOTS protocol itself. 2912 Implementation: https://github.com/nttdots/go-dots 2913 Level of maturity: It is a early implementation of DOTS protocol. 2914 Messaging between DOTS clients and DOTS servers has been tested. 2915 Level of maturity will increase in accordance with maturing of 2916 DOTS protocol itself. 2917 Coverage: Capability of DOTS client: sending DOTS messages to the 2918 DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS 2919 server: receiving dots-signal, validating received dots-signal, 2920 starting mitigation by handing over the dots-signal to DDOS 2921 mitigator. 2922 Licensing: It will be open-sourced with BSD 3-clause license. 2923 Implementation experience: It is implemented in Go-lang. Core 2924 specification of signaling is mature to be implemented, however, 2925 finding good libraries(like DTLS, CoAP) is rather difficult. 2926 Contact: Kaname Nishizuka 2928 11. Security Considerations 2930 Authenticated encryption MUST be used for data confidentiality and 2931 message integrity. The interaction between the DOTS agents requires 2932 Datagram Transport Layer Security (DTLS) and Transport Layer Security 2933 (TLS) with a cipher suite offering confidentiality protection and the 2934 guidance given in [RFC7525] MUST be followed to avoid attacks on 2935 (D)TLS. 2937 A single DOTS signal channel between DOTS agents can be used to 2938 exchange multiple DOTS signal messages. To reduce DOTS client and 2939 DOTS server workload, DOTS client SHOULD re-use the (D)TLS session. 2941 If TCP is used between DOTS agents, an attacker may be able to inject 2942 RST packets, bogus application segments, etc., regardless of whether 2943 TLS authentication is used. Because the application data is TLS 2944 protected, this will not result in the application receiving bogus 2945 data, but it will constitute a DoS on the connection. This attack 2946 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 2947 any bogus packets injected by an attacker will be rejected by the 2948 TCP-AO integrity check and therefore will never reach the TLS layer. 2950 In order to prevent leaking internal information outside a client- 2951 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 2952 the identity of internal DOTS clients (client-identifier) unless 2953 explicitly configured to do so. 2955 Special care should be taken in order to ensure that the activation 2956 of the proposed mechanism won't have an impact on the stability of 2957 the network (including connectivity and services delivered over that 2958 network). 2960 Involved functional elements in the cooperation system must establish 2961 exchange instructions and notification over a secure and 2962 authenticated channel. Adequate filters can be enforced to avoid 2963 that nodes outside a trusted domain can inject request such as 2964 deleting filtering rules. Nevertheless, attacks can be initiated 2965 from within the trusted domain if an entity has been corrupted. 2966 Adequate means to monitor trusted nodes should also be enabled. 2968 12. Contributors 2970 The following individuals have contributed to this document: 2972 Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: 2973 mgeller@cisco.com 2975 Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States 2976 Email: rgm@htt-consult.com 2978 Dan Wing Email: dwing-ietf@fuggles.com 2980 13. Acknowledgements 2982 Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, 2983 Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang 2984 Xia, Jon Shallow, Gilbert Clark, and Nesredien Suleiman for the 2985 discussion and comments. 2987 14. References 2989 14.1. Normative References 2991 [I-D.ietf-core-coap-tcp-tls] 2992 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 2993 Silverajan, B., and B. Raymor, "CoAP (Constrained 2994 Application Protocol) over TCP, TLS, and WebSockets", 2995 draft-ietf-core-coap-tcp-tls-10 (work in progress), 2996 October 2017. 2998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2999 Requirement Levels", BCP 14, RFC 2119, 3000 DOI 10.17487/RFC2119, March 1997, 3001 . 3003 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3004 DOI 10.17487/RFC3688, January 2004, 3005 . 3007 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 3008 Ciphersuites for Transport Layer Security (TLS)", 3009 RFC 4279, DOI 10.17487/RFC4279, December 2005, 3010 . 3012 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3013 (TLS) Protocol Version 1.2", RFC 5246, 3014 DOI 10.17487/RFC5246, August 2008, 3015 . 3017 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3018 Housley, R., and W. Polk, "Internet X.509 Public Key 3019 Infrastructure Certificate and Certificate Revocation List 3020 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3021 . 3023 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3024 Uniform Resource Identifiers (URIs)", RFC 5785, 3025 DOI 10.17487/RFC5785, April 2010, 3026 . 3028 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 3029 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 3030 June 2010, . 3032 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3033 Verification of Domain-Based Application Service Identity 3034 within Internet Public Key Infrastructure Using X.509 3035 (PKIX) Certificates in the Context of Transport Layer 3036 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3037 2011, . 3039 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 3040 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 3041 DOI 10.17487/RFC6234, May 2011, 3042 . 3044 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3045 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3046 January 2012, . 3048 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 3049 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 3050 Transport Layer Security (TLS) and Datagram Transport 3051 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 3052 June 2014, . 3054 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3055 Application Protocol (CoAP)", RFC 7252, 3056 DOI 10.17487/RFC7252, June 2014, 3057 . 3059 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3060 "Recommendations for Secure Use of Transport Layer 3061 Security (TLS) and Datagram Transport Layer Security 3062 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3063 2015, . 3065 [RFC7641] Hartke, K., "Observing Resources in the Constrained 3066 Application Protocol (CoAP)", RFC 7641, 3067 DOI 10.17487/RFC7641, September 2015, 3068 . 3070 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3071 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3072 . 3074 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3075 Writing an IANA Considerations Section in RFCs", BCP 26, 3076 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3077 . 3079 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 3080 FETCH Methods for the Constrained Application Protocol 3081 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 3082 . 3084 14.2. Informative References 3086 [I-D.ietf-core-comi] 3087 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 3088 Management Interface", draft-ietf-core-comi-01 (work in 3089 progress), July 2017. 3091 [I-D.ietf-core-yang-cbor] 3092 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 3093 Minaburo, "CBOR Encoding of Data Modeled with YANG", 3094 draft-ietf-core-yang-cbor-05 (work in progress), August 3095 2017. 3097 [I-D.ietf-dots-architecture] 3098 Mortensen, A., Andreasen, F., Reddy, T., 3099 christopher_gray3@cable.comcast.com, c., Compton, R., and 3100 N. Teague, "Distributed-Denial-of-Service Open Threat 3101 Signaling (DOTS) Architecture", draft-ietf-dots- 3102 architecture-05 (work in progress), October 2017. 3104 [I-D.ietf-dots-data-channel] 3105 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 3106 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 3107 Service Open Threat Signaling (DOTS) Data Channel", draft- 3108 ietf-dots-data-channel-08 (work in progress), November 3109 2017. 3111 [I-D.ietf-dots-requirements] 3112 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 3113 Denial of Service (DDoS) Open Threat Signaling 3114 Requirements", draft-ietf-dots-requirements-07 (work in 3115 progress), October 2017. 3117 [I-D.ietf-dots-use-cases] 3118 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 3119 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 3120 Open Threat Signaling", draft-ietf-dots-use-cases-09 (work 3121 in progress), November 2017. 3123 [I-D.ietf-netmod-yang-tree-diagrams] 3124 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 3125 ietf-netmod-yang-tree-diagrams-02 (work in progress), 3126 October 2017. 3128 [I-D.ietf-tls-dtls13] 3129 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 3130 Datagram Transport Layer Security (DTLS) Protocol Version 3131 1.3", draft-ietf-tls-dtls13-22 (work in progress), 3132 November 2017. 3134 [I-D.ietf-tls-tls13] 3135 Rescorla, E., "The Transport Layer Security (TLS) Protocol 3136 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 3137 July 2017. 3139 [proto_numbers] 3140 "IANA, "Protocol Numbers"", 2011, 3141 . 3143 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3144 DOI 10.17487/RFC0791, September 1981, 3145 . 3147 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3148 Resource Identifier (URI): Generic Syntax", STD 66, 3149 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3150 . 3152 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3153 Congestion Control Protocol (DCCP)", RFC 4340, 3154 DOI 10.17487/RFC4340, March 2006, 3155 . 3157 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3158 (CIDR): The Internet Address Assignment and Aggregation 3159 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 3160 2006, . 3162 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 3163 Denial-of-Service Considerations", RFC 4732, 3164 DOI 10.17487/RFC4732, December 2006, 3165 . 3167 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 3168 Translation (NAT) Behavioral Requirements for Unicast 3169 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 3170 2007, . 3172 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3173 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3174 . 3176 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3177 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 3178 . 3180 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 3181 "Transport Layer Security (TLS) Session Resumption without 3182 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 3183 January 2008, . 3185 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 3186 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 3187 2012, . 3189 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 3190 "Default Address Selection for Internet Protocol Version 6 3191 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 3192 . 3194 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 3195 "Enrollment over Secure Transport", RFC 7030, 3196 DOI 10.17487/RFC7030, October 2013, 3197 . 3199 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 3200 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 3201 October 2013, . 3203 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 3204 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 3205 . 3207 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 3208 "Architectural Considerations in Smart Object Networking", 3209 RFC 7452, DOI 10.17487/RFC7452, March 2015, 3210 . 3212 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 3213 NETCONF Protocol over Transport Layer Security (TLS) with 3214 Mutual X.509 Authentication", RFC 7589, 3215 DOI 10.17487/RFC7589, June 2015, 3216 . 3218 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 3219 Layer Security (TLS) False Start", RFC 7918, 3220 DOI 10.17487/RFC7918, August 2016, 3221 . 3223 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 3224 (TLS) Cached Information Extension", RFC 7924, 3225 DOI 10.17487/RFC7924, July 2016, 3226 . 3228 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 3229 Code: The Implementation Status Section", BCP 205, 3230 RFC 7942, DOI 10.17487/RFC7942, July 2016, 3231 . 3233 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 3234 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 3235 March 2017, . 3237 Authors' Addresses 3239 Tirumaleswar Reddy 3240 McAfee, Inc. 3241 Embassy Golf Link Business Park 3242 Bangalore, Karnataka 560071 3243 India 3245 Email: kondtir@gmail.com 3247 Mohamed Boucadair 3248 Orange 3249 Rennes 35000 3250 France 3252 Email: mohamed.boucadair@orange.com 3254 Prashanth Patil 3255 Cisco Systems, Inc. 3257 Email: praspati@cisco.com 3259 Andrew Mortensen 3260 Arbor Networks, Inc. 3261 2727 S. State St 3262 Ann Arbor, MI 48104 3263 United States 3265 Email: amortensen@arbor.net 3267 Nik Teague 3268 Verisign, Inc. 3269 United States 3271 Email: nteague@verisign.com