idnits 2.17.1 draft-ietf-dots-signal-channel-32.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 : ---------------------------------------------------------------------------- ** 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 2548 has weird spacing: '...er-port ine...' -- The document date (May 9, 2019) is 1812 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 4181, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-core-hop-limit-03 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Downref: Normative reference to an Informational RFC: RFC 7918 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-04 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-10 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-13 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-28 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-01 == Outdated reference: A later version (-15) exists of draft-ietf-dots-server-discovery-02 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-31 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy, Ed. 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair, Ed. 5 Expires: November 10, 2019 Orange 6 P. Patil 7 Cisco 8 A. Mortensen 9 Arbor Networks, Inc. 10 N. Teague 11 Verisign, Inc. 12 May 9, 2019 14 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 15 Channel Specification 16 draft-ietf-dots-signal-channel-32 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 27 purposes. 29 Editorial Note (To be removed by RFC Editor) 31 Please update these statements within the document with the RFC 32 number to be assigned to this document: 34 o "This version of this YANG module is part of RFC XXXX;" 36 o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling 37 (DOTS) Signal Channel Specification"; 39 o "| [RFCXXXX] |" 41 o reference: RFC XXXX 43 Please update this statement with the RFC number to be assigned to 44 the following documents: 46 o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling 47 (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data- 48 channel) 50 Please update TBD/TBD1/TBD2 statements with the assignments made by 51 IANA to DOTS Signal Channel Protocol. 53 Also, please update the "revision" date of the YANG modules. 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at https://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on November 10, 2019. 72 Copyright Notice 74 Copyright (c) 2019 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (https://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 90 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 91 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 92 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 9 93 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 9 94 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 95 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 10 96 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 12 97 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 13 98 4.4.2. Retrieve Information Related to a Mitigation . . . . 29 99 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 34 100 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37 101 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38 102 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40 103 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41 104 4.5.1. Discover Configuration Parameters . . . . . . . . . . 43 105 4.5.2. Convey DOTS Signal Channel Session Configuration . . 47 106 4.5.3. Configuration Freshness and Notifications . . . . . . 52 107 4.5.4. Delete DOTS Signal Channel Session Configuration . . 53 108 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 54 109 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 56 110 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 57 111 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 57 112 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 59 113 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 63 114 6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 74 115 7. (D)TLS Protocol Profile and Performance Considerations . . . 76 116 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 76 117 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 77 118 7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 79 119 8. Mutual Authentication of DOTS Agents & Authorization of DOTS 120 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 121 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 122 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 82 123 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 82 124 9.3. Media Type Registration . . . . . . . . . . . . . . . . . 82 125 9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 83 126 9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 83 127 9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 84 128 9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 84 129 9.6.1.1. Registration Template . . . . . . . . . . . . . . 84 130 9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 85 131 9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 87 132 9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 88 133 9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 90 134 9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 90 135 9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 91 136 10. Security Considerations . . . . . . . . . . . . . . . . . . . 92 137 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 94 138 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 139 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 140 13.1. Normative References . . . . . . . . . . . . . . . . . . 95 141 13.2. Informative References . . . . . . . . . . . . . . . . . 98 142 Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 103 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 145 1. Introduction 147 A distributed denial-of-service (DDoS) attack is a distributed 148 attempt to make machines or network resources unavailable to their 149 intended users. In most cases, sufficient scale for an effective 150 attack can be achieved by compromising enough end-hosts and using 151 those infected hosts to perpetrate and amplify the attack. The 152 victim in this attack can be an application server, a host, a router, 153 a firewall, or an entire network. 155 Network applications have finite resources like CPU cycles, the 156 number of processes or threads they can create and use, the maximum 157 number of simultaneous connections they can handle, the limited 158 resources of the control plane, etc. When processing network 159 traffic, such applications are supposed to use these resources to 160 provide the intended functionality in the most efficient manner. 161 However, a DDoS attacker may be able to prevent an application from 162 performing its intended task by making the application exhaust its 163 finite resources. 165 A TCP DDoS SYN-flood [RFC4987], for example, is a memory-exhausting 166 attack while an ACK-flood is a CPU-exhausting attack. Attacks on the 167 link are carried out by sending enough traffic so that the link 168 becomes congested, thereby likely causing packet loss for legitimate 169 traffic. Stateful firewalls can also be attacked by sending traffic 170 that causes the firewall to maintain an excessive number of states 171 that may jeopardize the firewall's operation overall, besides likely 172 performance impacts. The firewall then runs out of memory, and can 173 no longer instantiate the states required to process legitimate 174 flows. Other possible DDoS attacks are discussed in [RFC4732]. 176 In many cases, it may not be possible for network administrators to 177 determine the cause(s) of an attack. They may instead just realize 178 that certain resources seem to be under attack. This document 179 defines a lightweight protocol that allows a DOTS client to request 180 mitigation from one or more DOTS servers for protection against 181 detected, suspected, or anticipated attacks. This protocol enables 182 cooperation between DOTS agents to permit a highly-automated network 183 defense that is robust, reliable, and secure. Note that "secure" 184 means the support of the features defined in Section 2.4 of 185 [I-D.ietf-dots-requirements]. 187 An example of a network diagram that illustrates a deployment of DOTS 188 agents is shown in Figure 1. In this example, a DOTS server is 189 operating on the access network. A DOTS client is located on the LAN 190 (Local Area Network), while a DOTS gateway is embedded in the CPE 191 (Customer Premises Equipment). 193 Network 194 Resource CPE router Access network __________ 195 +-----------+ +--------------+ +-------------+ / \ 196 | |___| |____| |___ | Internet | 197 |DOTS client| | DOTS gateway | | DOTS server | | | 198 | | | | | | | | 199 +-----------+ +--------------+ +-------------+ \__________/ 201 Figure 1: Sample DOTS Deployment (1) 203 DOTS servers can also be reachable over the Internet, as depicted in 204 Figure 2. 206 Network DDoS mitigation 207 Resource CPE router __________ service 208 +-----------+ +-------------+ / \ +-------------+ 209 | |___| |____| |___ | | 210 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 211 | | | | | | | | 212 +-----------+ +-------------+ \__________/ +-------------+ 214 Figure 2: Sample DOTS Deployment (2) 216 In typical deployments, the DOTS client belongs to a different 217 administrative domain than the DOTS server. For example, the DOTS 218 client is embedded in a firewall protecting services owned and 219 operated by a customer, while the DOTS server is owned and operated 220 by a different administrative entity (service provider, typically) 221 providing DDoS mitigation services. The latter might or might not 222 provide connectivity services to the network hosting the DOTS client. 224 The DOTS server may (not) be co-located with the DOTS mitigator. In 225 typical deployments, the DOTS server belongs to the same 226 administrative domain as the mitigator. The DOTS client can 227 communicate directly with a DOTS server or indirectly via a DOTS 228 gateway. 230 The document adheres to the DOTS architecture 231 [I-D.ietf-dots-architecture]. The requirements for DOTS signal 232 channel protocol are documented in [I-D.ietf-dots-requirements]. 233 This document satisfies all the use cases discussed in 234 [I-D.ietf-dots-use-cases]. 236 This document focuses on the DOTS signal channel. This is a 237 companion document of the DOTS data channel specification 238 [I-D.ietf-dots-data-channel] that defines a configuration and a bulk 239 data exchange mechanism supporting the DOTS signal channel. 241 2. Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 245 "OPTIONAL" in this document are to be interpreted as described in BCP 246 14 [RFC2119][RFC8174] when, and only when, they appear in all 247 capitals, as shown here. 249 (D)TLS is used for statements that apply to both Transport Layer 250 Security [RFC5246][RFC8446] and Datagram Transport Layer Security 251 [RFC6347]. Specific terms are used for any statement that applies to 252 either protocol alone. 254 The reader should be familiar with the terms defined in 255 [I-D.ietf-dots-requirements]. 257 The meaning of the symbols in YANG tree diagrams is defined in 258 [RFC8340]. 260 3. Design Overview 262 The DOTS signal channel is built on top of the Constrained 263 Application Protocol (CoAP) [RFC7252], a lightweight protocol 264 originally designed for constrained devices and networks. The many 265 features of CoAP (expectation of packet loss, support for 266 asynchronous Non-confirmable messaging, congestion control, small 267 message overhead limiting the need for fragmentation, use of minimal 268 resources, and support for (D)TLS) makes it a good candidate to build 269 the DOTS signaling mechanism from. 271 The DOTS signal channel is layered on existing standards (Figure 3). 273 +---------------------+ 274 | DOTS Signal Channel | 275 +---------------------+ 276 | CoAP | 277 +----------+----------+ 278 | TLS | DTLS | 279 +----------+----------+ 280 | TCP | UDP | 281 +----------+----------+ 282 | IP | 283 +---------------------+ 285 Figure 3: Abstract Layering of DOTS Signal Channel over CoAP over 286 (D)TLS 288 In some cases, a DOTS client and server may have mutual agreement to 289 use a specific port number, such as by explicit configuration or 290 dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such 291 mutual agreement, the DOTS signal channel MUST run over port number 292 TBD as defined in Section 9.1, for both UDP and TCP. In order to use 293 a distinct port number (as opposed to TBD), DOTS clients and servers 294 SHOULD support a configurable parameter to supply the port number to 295 use. The rationale for not using the default port number 5684 296 ((D)TLS CoAP) is to allow for differentiated behaviors in 297 environments where both a DOTS gateway and an IoT gateway (e.g., 298 Figure 3 of [RFC7452]) are present. 300 The signal channel uses the "coaps" URI scheme defined in Section 6 301 of [RFC7252] and the "coaps+tcp" URI scheme defined in Section 8.2 of 302 [RFC8323] to identify DOTS server resources accessible using CoAP 303 over UDP secured with DTLS and CoAP over TCP secured with TLS, 304 respectively. 306 The DOTS signal channel can be established between two DOTS agents 307 prior or during an attack. The DOTS signal channel is initiated by 308 the DOTS client. The DOTS client can then negotiate, configure, and 309 retrieve the DOTS signal channel session behavior with its DOTS peer 310 (Section 4.5). Once the signal channel is established, the DOTS 311 agents periodically send heartbeats to keep the channel active 312 (Section 4.7). At any time, the DOTS client may send a mitigation 313 request message (Section 4.4) to a DOTS server over the active signal 314 channel. While mitigation is active (because of the higher 315 likelihood of packet loss during a DDoS attack), the DOTS server 316 periodically sends status messages to the client, including basic 317 mitigation feedback details. Mitigation remains active until the 318 DOTS client explicitly terminates mitigation, or the mitigation 319 lifetime expires. Also, the DOTS server may rely on the signal 320 channel session loss to trigger mitigation for pre-configured 321 mitigation requests (if any). 323 DOTS signaling can happen with DTLS over UDP and TLS over TCP. 324 Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer 325 capabilities. A Happy Eyeballs procedure for DOTS signal channel is 326 specified in Section 4.3. 328 A DOTS client is entitled to access only to resources it creates. In 329 particular, a DOTS client can not retrieve data related to mitigation 330 requests created by other DOTS clients of the same DOTS client 331 domain. 333 Messages exchanged between DOTS agents are serialized using Concise 334 Binary Object Representation (CBOR) [RFC7049], a binary encoding 335 scheme designed for small code and message size. CBOR-encoded 336 payloads are used to carry signal channel-specific payload messages 337 which convey request parameters and response information such as 338 errors. In order to allow reusing data models across protocols, 339 [RFC7951] specifies the JavaScript Object Notation (JSON) encoding of 340 YANG-modeled data. A similar effort for CBOR is defined in 341 [I-D.ietf-core-yang-cbor]. 343 DOTS agents determine that a CBOR data structure is a DOTS signal 344 channel object from the application context, such as from the port 345 number assigned to the DOTS signal channel. The other method DOTS 346 agents use to indicate that a CBOR data structure is a DOTS signal 347 channel object is the use of the "application/dots+cbor" content type 348 (Section 9.3). 350 This document specifies a YANG module for representing DOTS 351 mitigation scopes, DOTS signal channel session configuration data, 352 and DOTS redirected signaling (Section 5). All parameters in the 353 payload of the DOTS signal channel are mapped to CBOR types as 354 specified in Table 4 (Section 6). 356 In order to prevent fragmentation, DOTS agents must follow the 357 recommendations documented in Section 4.6 of [RFC7252]. Refer to 358 Section 7.3 for more details. 360 DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The 361 payload included in CoAP responses with 2.xx Response Codes MUST be 362 of content type "application/dots+cbor". CoAP responses with 4.xx 363 and 5.xx error Response Codes MUST include a diagnostic payload 364 (Section 5.5.2 of [RFC7252]). The Diagnostic Payload may contain 365 additional information to aid troubleshooting. 367 In deployments where multiple DOTS clients are enabled in a network 368 (owned and operated by the same entity), the DOTS server may detect 369 conflicting mitigation requests from these clients. This document 370 does not aim to specify a comprehensive list of conditions under 371 which a DOTS server will characterize two mitigation requests from 372 distinct DOTS clients as conflicting, nor recommend a DOTS server 373 behavior for processing conflicting mitigation requests. Those 374 considerations are implementation- and deployment-specific. 375 Nevertheless, the document specifies the mechanisms to notify DOTS 376 clients when conflicts occur, including the conflict cause 377 (Section 4.4). 379 In deployments where one or more translators (e.g., Traditional NAT 380 [RFC3022], CGN [RFC6888], NAT64 [RFC6146], NPTv6 [RFC6296]) are 381 enabled between the client's network and the DOTS server, DOTS signal 382 channel messages forwarded to a DOTS server MUST NOT include internal 383 IP addresses/prefixes and/or port numbers; external addresses/ 384 prefixes and/or port numbers as assigned by the translator MUST be 385 used instead. This document does not make any recommendation about 386 possible translator discovery mechanisms. The following are some 387 (non-exhaustive) deployment examples that may be considered: 389 o Port Control Protocol (PCP) [RFC6887] or Session Traversal 390 Utilities for NAT (STUN) [RFC5389] may be used to retrieve the 391 external addresses/prefixes and/or port numbers. Information 392 retrieved by means of PCP or STUN will be used to feed the DOTS 393 signal channel messages that will be sent to a DOTS server. 395 o A DOTS gateway may be co-located with the translator. The DOTS 396 gateway will need to update the DOTS messages, based upon the 397 local translator's binding table. 399 4. DOTS Signal Channel: Messages & Behaviors 401 4.1. DOTS Server(s) Discovery 403 This document assumes that DOTS clients are provisioned with the 404 reachability information of their DOTS server(s) using any of a 405 variety of means (e.g., local configuration, or dynamic means such as 406 DHCP [I-D.ietf-dots-server-discovery]). The description of such 407 means is out of scope of this document. 409 Likewise, it is out of scope of this document to specify the behavior 410 to be followed by a DOTS client to send DOTS requests when multiple 411 DOTS servers are provisioned (e.g., contact all DOTS servers, select 412 one DOTS server among the list). Such behavior is specified in other 413 documents (e.g. [I-D.ietf-dots-multihoming]). 415 4.2. CoAP URIs 417 The DOTS server MUST support the use of the path-prefix of "/.well- 418 known/" as defined in [RFC5785] and the registered name of "dots". 419 Each DOTS operation is indicated by a path-suffix that indicates the 420 intended operation. The operation path (Table 1) is appended to the 421 path-prefix to form the URI used with a CoAP request to perform the 422 desired DOTS operation. 424 +-----------------------+----------------+-------------+ 425 | Operation | Operation Path | Details | 426 +-----------------------+----------------+-------------+ 427 | Mitigation | /mitigate | Section 4.4 | 428 +-----------------------+----------------+-------------+ 429 | Session configuration | /config | Section 4.5 | 430 +-----------------------+----------------+-------------+ 432 Table 1: Operations and their Corresponding URIs 434 4.3. Happy Eyeballs for DOTS Signal Channel 436 [I-D.ietf-dots-requirements] mentions that DOTS agents will have to 437 support both connectionless and connection-oriented protocols. As 438 such, the DOTS signal channel is designed to operate with DTLS over 439 UDP and TLS over TCP. Further, a DOTS client may acquire a list of 440 IPv4 and IPv6 addresses (Section 4.1), each of which can be used to 441 contact the DOTS server using UDP and TCP. The following specifies 442 the procedure to follow to select the address family and the 443 transport protocol for sending DOTS signal channel messages. 445 Such procedure is needed to avoid experiencing long connection 446 delays. For example, if an IPv4 path to reach a DOTS server is 447 functional, but the DOTS server's IPv6 path is non-functional, a 448 dual-stack DOTS client may experience a significant connection delay 449 compared to an IPv4-only DOTS client, in the same network conditions. 450 The other problem is that if a middlebox between the DOTS client and 451 DOTS server is configured to block UDP traffic, the DOTS client will 452 fail to establish a DTLS association with the DOTS server and, as a 453 consequence, will have to fall back to TLS over TCP, thereby 454 incurring significant connection delays. 456 To overcome these connection setup problems, the DOTS client attempts 457 to connect to its DOTS server(s) using both IPv6 and IPv4, and tries 458 both DTLS over UDP and TLS over TCP following a DOTS Happy Eyeballs 459 approach. To some extent, this approach is similar to the Happy 460 Eyeballs mechanism defined in [RFC8305]. The connection attempts are 461 performed by the DOTS client when it initializes, or in general when 462 it has to select an address family and transport to contact its DOTS 463 server. The results of the Happy Eyeballs procedure are used by the 464 DOTS client for sending its subsequent messages to the DOTS server. 465 The difference in behavior with respect to the Happy Eyeballs 466 mechanism [RFC8305] are listed below: 468 o The order of preference of the DOTS signal channel address family 469 and transport protocol (most preferred first) is: UDP over IPv6, 470 UDP over IPv4, TCP over IPv6, and finally TCP over IPv4. This 471 order adheres to the address preference order specified in 473 [RFC6724] and the DOTS signal channel preference which privileges 474 the use of UDP over TCP (to avoid TCP's head of line blocking). 476 o The DOTS client after successfully establishing a connection MUST 477 cache information regarding the outcome of each connection attempt 478 for a specific time period, and it uses that information to avoid 479 thrashing the network with subsequent attempts. The cached 480 information is flushed when its age exceeds a specific time period 481 on the order of few minutes (e.g., 10 mn). Typically, if the DOTS 482 client has to re-establish the connection with the same DOTS 483 server within few seconds after the Happy Eyeballs mechanism is 484 completed, caching avoids trashing the network especially in the 485 presence of DDoS attack traffic. 487 o If DOTS signal channel session is established with TLS (but DTLS 488 failed), the DOTS client periodically repeats the mechanism to 489 discover whether DOTS signal channel messages with DTLS over UDP 490 becomes available from the DOTS server, so the DOTS client can 491 migrate the DOTS signal channel from TCP to UDP. Such probing 492 SHOULD NOT be done more frequently than every 24 hours and MUST 493 NOT be done more frequently than every 5 minutes. 495 When connection attempts are made during an attack, the DOTS client 496 SHOULD use a "Connection Attempt Delay" [RFC8305] set to 100 ms. 498 In reference to Figure 4, the DOTS client proceeds with the 499 connection attempts following the rules in [RFC8305]. In this 500 example, it is assumed that the IPv6 path is broken and UDP traffic 501 is dropped by a middlebox but has little impact to the DOTS client 502 because there is no long delay before using IPv4 and TCP. 504 +-----------+ +-----------+ 505 |DOTS client| |DOTS server| 506 +-----------+ +-----------+ 507 | | 508 T0 |--DTLS ClientHello, IPv6 ---->X | 509 T1 |--DTLS ClientHello, IPv4 ---->X | 510 T2 |--TCP SYN, IPv6-------------->X | 511 T3 |--TCP SYN, IPv4--------------------------------------->| 512 |<-TCP SYNACK-------------------------------------------| 513 |--TCP ACK--------------------------------------------->| 514 |<------------Establish TLS Session-------------------->| 515 |----------------DOTS signal--------------------------->| 516 | | 518 Note: 519 * Retransmission messages are not shown. 520 * T1-T0=T2-T1=T3-T2= Connection Attempt Delay. 522 Figure 4: DOTS Happy Eyeballs (Sample Flow) 524 A single DOTS signal channel between DOTS agents can be used to 525 exchange multiple DOTS signal messages. To reduce DOTS client and 526 DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session. 528 4.4. DOTS Mitigation Methods 530 The following methods are used by a DOTS client to request, withdraw, 531 or retrieve the status of mitigation requests: 533 PUT: DOTS clients use the PUT method to request mitigation from a 534 DOTS server (Section 4.4.1). During active mitigation, DOTS 535 clients may use PUT requests to carry mitigation efficacy 536 updates to the DOTS server (Section 4.4.3). 538 GET: DOTS clients may use the GET method to subscribe to DOTS 539 server status messages, or to retrieve the list of its 540 mitigations maintained by a DOTS server (Section 4.4.2). 542 DELETE: DOTS clients use the DELETE method to withdraw a request for 543 mitigation from a DOTS server (Section 4.4.4). 545 Mitigation request and response messages are marked as Non- 546 confirmable messages (Section 2.2 of [RFC7252]). 548 DOTS agents MUST follow the data transmission guidelines discussed in 549 Section 3.1.3 of [RFC8085] and control transmission behavior by not 550 sending more than one UDP datagram per round-trip time (RTT) to the 551 peer DOTS agent on average. 553 Requests marked by the DOTS client as Non-confirmable messages are 554 sent at regular intervals until a response is received from the DOTS 555 server. If the DOTS client cannot maintain an RTT estimate, it MUST 556 NOT send more than one Non-confirmable request every 3 seconds, and 557 SHOULD use an even less aggressive rate whenever possible (case 2 in 558 Section 3.1.3 of [RFC8085]). 560 JSON encoding is used to illustrate the various methods defined in 561 the following sub-sections. Also, the examples use the Labels 562 defined in Sections 9.6.2, 9.6.3, 9.6.4, and 9.6.5. 564 4.4.1. Request Mitigation 566 When a DOTS client requires mitigation for some reason, the DOTS 567 client uses the CoAP PUT method to send a mitigation request to its 568 DOTS server(s) (Figures 5 and 6). 570 If a DOTS client is entitled to solicit the DOTS service, the DOTS 571 server enables mitigation on behalf of the DOTS client by 572 communicating the DOTS client's request to a mitigator (which may be 573 co-located with the DOTS server) and relaying the feedback of the 574 thus-selected mitigator to the requesting DOTS client. 576 Header: PUT (Code=0.03) 577 Uri-Path: ".well-known" 578 Uri-Path: "dots" 579 Uri-Path: "mitigate" 580 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 581 Uri-Path: "mid=123" 582 Content-Format: "application/dots+cbor" 584 { 585 ... 586 } 588 Figure 5: PUT to Convey DOTS Mitigation Requests 590 The order of the Uri-Path options is important as it defines the CoAP 591 resource. In particular, 'mid' MUST follow 'cuid'. 593 The additional Uri-Path parameters to those defined in Section 4.2 594 are as follows: 596 cuid: Stands for Client Unique Identifier. A globally unique 597 identifier that is meant to prevent collisions among DOTS clients, 598 especially those from the same domain. It MUST be generated by 599 DOTS clients. 601 For the reasons discussed in Appendix A, implementations SHOULD 602 set 'cuid' to the output of a cryptographic hash algorithm whose 603 input is the Distinguished Encoding Rules (DER)-encoded Abstract 604 Syntax Notation One (ASN.1) representation of the Subject Public 605 Key Info (SPKI) of the DOTS client X.509 certificate [RFC5280], 606 the DOTS client raw public key [RFC7250], or the "Pre-Shared Key 607 (PSK) identity" used by the DOTS client in the TLS 608 ClientKeyExchange message. In this version of the specification, 609 the cryptographic hash algorithm used is SHA-256 [RFC6234]. The 610 output of the cryptographic hash algorithm is truncated to 16 611 bytes; truncation is done by stripping off the final 16 bytes. 612 The truncated output is base64url encoded (Section 5 of [RFC4648]) 613 with the trailing "=" removed from the encoding. 615 The 'cuid' is intended to be stable when communicating with a 616 given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD 617 NOT change over time. Distinct 'cuid' values MAY be used by a 618 single DOTS client per DOTS server. 620 If a DOTS client has to change its 'cuid' for some reason, it MUST 621 NOT do so when mitigations are still active for the old 'cuid'. 622 The 'cuid' SHOULD be 22 characters to avoid DOTS signal message 623 fragmentation over UDP. Furthermore, if that DOTS client created 624 aliases and filtering entries at the DOTS server by means of the 625 DOTS data channel, it MUST delete all the entries bound to the old 626 'cuid' and re-install them using the new 'cuid'. 628 DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer 629 to notify that the 'cuid' is already in-use by another DOTS 630 client. Upon receipt of that error code, a new 'cuid' MUST be 631 generated by the DOTS peer (e.g., using [RFC4122]). 633 Client-domain DOTS gateways MUST handle 'cuid' collision directly 634 and it is RECOMMENDED that 'cuid' collision is handled directly by 635 server-domain DOTS gateways. 637 DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. 638 Triggers for such rewriting are out of scope. 640 This is a mandatory Uri-Path parameter. 642 mid: Identifier for the mitigation request represented with an 643 integer. This identifier MUST be unique for each mitigation 644 request bound to the DOTS client, i.e., the 'mid' parameter value 645 in the mitigation request needs to be unique (per 'cuid' and DOTS 646 server) relative to the 'mid' parameter values of active 647 mitigation requests conveyed from the DOTS client to the DOTS 648 server. 650 In order to handle out-of-order delivery of mitigation requests, 651 'mid' values MUST increase monotonically. 653 If the 'mid' value has reached 3/4 of (2**32 - 1) (i.e., 654 3221225471) and no attack is detected, the DOTS client MUST reset 655 'mid' to 0 to handle 'mid' rollover. If the DOTS client maintains 656 mitigation requests with pre-configured scopes, it MUST re-create 657 them with the 'mid' restarting at 0. 659 This identifier MUST be generated by the DOTS client. 661 This is a mandatory Uri-Path parameter. 663 'cuid' and 'mid' MUST NOT appear in the PUT request message body 664 (Figure 6). The schema in Figure 6 uses the types defined in 665 Section 6. Note that this figure (and other similar figures 666 depicting a schema) are non-normative sketches of the structure of 667 the message. 669 { 670 "ietf-dots-signal-channel:mitigation-scope": { 671 "scope": [ 672 { 673 "target-prefix": [ 674 "string" 675 ], 676 "target-port-range": [ 677 { 678 "lower-port": number, 679 "upper-port": number 680 } 681 ], 682 "target-protocol": [ 683 number 684 ], 685 "target-fqdn": [ 686 "string" 687 ], 688 "target-uri": [ 689 "string" 690 ], 691 "alias-name": [ 692 "string" 693 ], 694 "lifetime": number, 695 "trigger-mitigation": true|false 696 } 697 ] 698 } 699 } 701 Figure 6: PUT to Convey DOTS Mitigation Requests (Message Body 702 Schema) 704 The parameters in the CBOR body (Figure 6) of the PUT request are 705 described below: 707 target-prefix: A list of prefixes identifying resources under 708 attack. Prefixes are represented using Classless Inter-Domain 709 Routing (CIDR) notation [RFC4632]. 710 As a reminder, the prefix length must be less than or equal to 32 711 (or 128) for IPv4 (or IPv6). 713 The prefix list MUST NOT include broadcast, loopback, or multicast 714 addresses. These addresses are considered as invalid values. In 715 addition, the DOTS server MUST validate that target prefixes are 716 within the scope of the DOTS client domain. Other validation 717 checks may be supported by DOTS servers. 719 This is an optional attribute. 721 target-port-range: A list of port numbers bound to resources under 722 attack. 724 A port range is defined by two bounds, a lower port number (lower- 725 port) and an upper port number (upper-port). When only 'lower- 726 port' is present, it represents a single port number. 728 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 729 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 730 [RFC4340], a range of ports can be, for example, 0-1023, 731 1024-65535, or 1024-49151. 733 This is an optional attribute. 735 target-protocol: A list of protocols involved in an attack. Values 736 are taken from the IANA protocol registry [proto_numbers]. 738 If 'target-protocol' is not specified, then the request applies to 739 any protocol. 741 This is an optional attribute. 743 target-fqdn: A list of Fully Qualified Domain Names (FQDNs) 744 identifying resources under attack [RFC8499]. 746 How a name is passed to an underlying name resolution library is 747 implementation- and deployment-specific. Nevertheless, once the 748 name is resolved into one or multiple IP addresses, DOTS servers 749 MUST apply the same validation checks as those for 'target- 750 prefix'. 752 The use of FQDNs may be suboptimal because: 754 * It induces both an extra load and increased delays on the DOTS 755 server to handle and manage DNS resolution requests. 757 * It does not guarantee that the DOTS server will resolve a name 758 to the same IP addresses that the DOTS client does. 760 This is an optional attribute. 762 target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986] 763 identifying resources under attack. 765 The same validation checks used for 'target-fqdn' MUST be followed 766 by DOTS servers to validate a target URI. 768 This is an optional attribute. 770 alias-name: A list of aliases of resources for which the mitigation 771 is requested. Aliases can be created using the DOTS data channel 772 (Section 6.1 of [I-D.ietf-dots-data-channel]), direct 773 configuration, or other means. 775 An alias is used in subsequent signal channel exchanges to refer 776 more efficiently to the resources under attack. 778 This is an optional attribute. 780 lifetime: Lifetime of the mitigation request in seconds. The 781 RECOMMENDED lifetime of a mitigation request is 3600 seconds -- 782 this value was chosen to be long enough so that refreshing is not 783 typically a burden on the DOTS client, while still making the 784 request expire in a timely manner when the client has unexpectedly 785 quit. DOTS clients MUST include this parameter in their 786 mitigation requests. Upon the expiry of this lifetime, and if the 787 request is not refreshed, the mitigation request is removed. The 788 request can be refreshed by sending the same request again. 790 A lifetime of '0' in a mitigation request is an invalid value. 792 A lifetime of negative one (-1) indicates indefinite lifetime for 793 the mitigation request. The DOTS server MAY refuse indefinite 794 lifetime, for policy reasons; the granted lifetime value is 795 returned in the response. DOTS clients MUST be prepared to not be 796 granted mitigations with indefinite lifetimes. 798 The DOTS server MUST always indicate the actual lifetime in the 799 response and the remaining lifetime in status messages sent to the 800 DOTS client. 802 This is a mandatory attribute. 804 trigger-mitigation: If the parameter value is set to 'false', DDoS 805 mitigation will not be triggered for the mitigation request unless 806 the DOTS signal channel session is lost. 808 If the DOTS client ceases to respond to heartbeat messages, the 809 DOTS server can detect that the DOTS signal channel session is 810 lost. 812 The default value of the parameter is 'true' (that is, the 813 mitigation starts immediately). If 'trigger-mitigation' is not 814 present in a request, this is equivalent to receiving a request 815 with 'trigger-mitigation' set to 'true'. 817 This is an optional attribute. 819 In deployments where server-domain DOTS gateways are enabled, 820 identity information about the origin source client domain ('cdid') 821 SHOULD be propagated to the DOTS server. That information is meant 822 to assist the DOTS server to enforce some policies such as grouping 823 DOTS clients that belong to the same DOTS domain, limiting the number 824 of DOTS requests, and identifying the mitigation scope. These 825 policies can be enforced per-client, per-client domain, or both. 826 Also, the identity information may be used for auditing and debugging 827 purposes. 829 Figure 7 shows an example of a request relayed by a server-domain 830 DOTS gateway. 832 Header: PUT (Code=0.03) 833 Uri-Path: ".well-known" 834 Uri-Path: "dots" 835 Uri-Path: "mitigate" 836 Uri-Path: "cdid=7eeaf349529eb55ed50113" 837 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 838 Uri-Path: "mid=123" 839 Content-Format: "application/dots+cbor" 841 { 842 ... 843 } 845 Figure 7: PUT for DOTS Mitigation Request as Relayed by a DOTS 846 Gateway 848 A server-domain DOTS gateway SHOULD add the following Uri-Path 849 parameter: 851 cdid: Stands for Client Domain Identifier. The 'cdid' is conveyed 852 by a server-domain DOTS gateway to propagate the source domain 853 identity from the gateway's client-facing-side to the gateway's 854 server-facing-side, and from the gateway's server-facing-side to 855 the DOTS server. 'cdid' may be used by the final DOTS server for 856 policy enforcement purposes (e.g., enforce a quota on filtering 857 rules). These policies are deployment-specific. 859 Server-domain DOTS gateways SHOULD support a configuration option 860 to instruct whether 'cdid' parameter is to be inserted. 862 In order to accommodate deployments that require enforcing per- 863 client policies, per-client domain policies, or a combination 864 thereof, server-domain DOTS gateways instructed to insert the 865 'cdid' parameter MUST supply the SPKI hash of the DOTS client 866 X.509 certificate, the DOTS client raw public key, or the hash of 867 the "PSK identity" in the 'cdid', following the same rules for 868 generating the hash conveyed in 'cuid', which is then used by the 869 ultimate DOTS server to determine the corresponding client's 870 domain. The 'cdid' generated by a server-domain gateway is likely 871 to be the same as the 'cuid' except if the DOTS message was 872 relayed by a client-domain DOTS gateway or the 'cuid' was 873 generated from a rogue DOTS client. 875 If a DOTS client is provisioned, for example, with distinct 876 certificates as a function of the peer server-domain DOTS gateway, 877 distinct 'cdid' values may be supplied by a server-domain DOTS 878 gateway. The ultimate DOTS server MUST treat those 'cdid' values 879 as equivalent. 881 The 'cdid' attribute MUST NOT be generated and included by DOTS 882 clients. 884 DOTS servers MUST ignore 'cdid' attributes that are directly 885 supplied by source DOTS clients or client-domain DOTS gateways. 886 This implies that first server-domain DOTS gateways MUST strip 887 'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD 888 support a configuration parameter to identify DOTS gateways that 889 are trusted to supply 'cdid' attributes. 891 Only single-valued 'cdid' are defined in this document. That is, 892 only the first on-path server-domain DOTS gateway can insert a 893 'cdid' value. This specification does not allow multiple server- 894 domain DOTS gateways, whenever involved in the path, to insert a 895 'cdid' value for each server-domain gateway. 897 This is an optional Uri-Path. When present, 'cdid' MUST be 898 positioned before 'cuid'. 900 A DOTS gateway MAY add the CoAP Hop-Limit Option 901 [I-D.ietf-core-hop-limit]. 903 Because of the complexity to handle partial failure cases, this 904 specification does not allow for including multiple mitigation 905 requests in the same PUT request. Concretely, a DOTS client MUST NOT 906 include multiple entries in the 'scope' array of the same PUT 907 request. 909 FQDN and URI mitigation scopes may be thought of as a form of scope 910 alias, in which the addresses associated with the domain name or URI 911 (as resolved by the DOTS server) represent the scope of the 912 mitigation. Particularly, the IP addresses to which the host 913 subcomponent of authority component of an URI resolves represent the 914 'target-prefix', the URI scheme represents the 'target-protocol', the 915 port subcomponent of authority component of an URI represents the 916 'target-port-range'. If the optional port information is not present 917 in the authority component, the default port defined for the URI 918 scheme represents the 'target-port'. 920 In the PUT request at least one of the attributes 'target-prefix', 921 'target-fqdn','target-uri', or 'alias-name' MUST be present. 923 Attributes and Uri-Path parameters with empty values MUST NOT be 924 present in a request and render the entire request invalid. 926 Figure 8 shows a PUT request example to signal that TCP port numbers 927 80, 8080, and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 928 servers are under attack. The presence of 'cdid' indicates that a 929 server-domain DOTS gateway has modified the initial PUT request sent 930 by the DOTS client. Note that 'cdid' MUST NOT appear in the PUT 931 request message body. 933 Header: PUT (Code=0.03) 934 Uri-Path: ".well-known" 935 Uri-Path: "dots" 936 Uri-Path: "mitigate" 937 Uri-Path: "cdid=7eeaf349529eb55ed50113" 938 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 939 Uri-Path: "mid=123" 940 Content-Format: "application/dots+cbor" 942 { 943 "ietf-dots-signal-channel:mitigation-scope": { 944 "scope": [ 945 { 946 "target-prefix": [ 947 "2001:db8:6401::1/128", 948 "2001:db8:6401::2/128" 949 ], 950 "target-port-range": [ 951 { 952 "lower-port": 80 953 }, 954 { 955 "lower-port": 443 956 }, 957 { 958 "lower-port": 8080 959 } 960 ], 961 "target-protocol": [ 962 6 963 ], 964 "lifetime": 3600 965 } 966 ] 967 } 968 } 970 Figure 8: PUT for DOTS Mitigation Request (An Example) 972 The corresponding CBOR encoding format for the payload is shown in 973 Figure 9. 975 A1 # map(1) 976 01 # unsigned(1) 977 A1 # map(1) 978 02 # unsigned(2) 979 81 # array(1) 980 A3 # map(3) 981 06 # unsigned(6) 982 82 # array(2) 983 74 # text(20) 984 323030313A6462383A363430313A3A312F313238 985 74 # text(20) 986 323030313A6462383A363430313A3A322F313238 987 07 # unsigned(7) 988 83 # array(3) 989 A1 # map(1) 990 08 # unsigned(8) 991 18 50 # unsigned(80) 992 A1 # map(1) 993 08 # unsigned(8) 994 19 01BB # unsigned(443) 995 A1 # map(1) 996 08 # unsigned(8) 997 19 1F90 # unsigned(8080) 998 0A # unsigned(10) 999 81 # array(1) 1000 06 # unsigned(6) 1001 0E # unsigned(14) 1002 19 0E10 # unsigned(3600) 1004 Figure 9: PUT for DOTS Mitigation Request (CBOR) 1006 In both DOTS signal and data channel sessions, the DOTS client MUST 1007 authenticate itself to the DOTS server (Section 8). The DOTS server 1008 MAY use the algorithm presented in Section 7 of [RFC7589] to derive 1009 the DOTS client identity or username from the client certificate. 1010 The DOTS client identity allows the DOTS server to accept mitigation 1011 requests with scopes that the DOTS client is authorized to manage. 1013 The DOTS server couples the DOTS signal and data channel sessions 1014 using the DOTS client identity and optionally the 'cdid' parameter 1015 value, so the DOTS server can validate whether the aliases conveyed 1016 in the mitigation request were indeed created by the same DOTS client 1017 using the DOTS data channel session. If the aliases were not created 1018 by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in 1019 the response. 1021 The DOTS server couples the DOTS signal channel sessions using the 1022 DOTS client identity and optionally the 'cdid' parameter value, and 1023 the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to 1024 detect duplicate mitigation requests. If the mitigation request 1025 contains the 'alias-name' and other parameters identifying the target 1026 resources (such as 'target-prefix', 'target-port-range', 'target- 1027 fqdn', or 'target-uri'), the DOTS server appends the parameter values 1028 in 'alias-name' with the corresponding parameter values in 'target- 1029 prefix', 'target-port-range', 'target-fqdn', or 'target-uri'. 1031 The DOTS server indicates the result of processing the PUT request 1032 using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx 1033 codes are some sort of invalid requests (client errors). COAP 5.xx 1034 codes are returned if the DOTS server is in an error state or is 1035 currently unavailable to provide mitigation in response to the 1036 mitigation request from the DOTS client. 1038 Figure 10 shows an example response to a PUT request that is 1039 successfully processed by a DOTS server (i.e., CoAP 2.xx response 1040 codes). This version of the specification forbids 'cuid' and 'cdid' 1041 (if used) to be returned in a response message body. 1043 { 1044 "ietf-dots-signal-channel:mitigation-scope": { 1045 "scope": [ 1046 { 1047 "mid": 123, 1048 "lifetime": 3600 1049 } 1050 ] 1051 } 1052 } 1054 Figure 10: 2.xx Response Body 1056 If the request is missing a mandatory attribute, does not include 1057 'cuid' or 'mid' Uri-Path options, includes multiple 'scope' 1058 parameters, or contains invalid or unknown parameters, the DOTS 1059 server MUST reply with 4.00 (Bad Request). DOTS agents can safely 1060 ignore comprehension-optional parameters they don't understand 1061 (Section 9.6.1.1). 1063 A DOTS server that receives a mitigation request with a lifetime set 1064 to '0' MUST reply with a 4.00 (Bad Request). 1066 If the DOTS server does not find the 'mid' parameter value conveyed 1067 in the PUT request in its configuration data, it MAY accept the 1068 mitigation request by sending back a 2.01 (Created) response to the 1069 DOTS client; the DOTS server will consequently try to mitigate the 1070 attack. A DOTS server could reject mitigation requests when it is 1071 near capacity or needs to rate-limit a particular client, for 1072 example. 1074 The relative order of two mitigation requests, having the same 1075 'trigger-mitigation' type, from a DOTS client is determined by 1076 comparing their respective 'mid' values. If two mitigation requests 1077 with the same 'trigger-mitigation' type have overlapping mitigation 1078 scopes, the mitigation request with the highest numeric 'mid' value 1079 will override the other mitigation request. Two mitigation requests 1080 from a DOTS client have overlapping scopes if there is a common IP 1081 address, IP prefix, FQDN, URI, or alias-name. To avoid maintaining a 1082 long list of overlapping mitigation requests (i.e., requests with the 1083 same 'trigger-mitigation' type and overlapping scopes) from a DOTS 1084 client and avoid error-prone provisioning of mitigation requests from 1085 a DOTS client, the overlapped lower numeric 'mid' MUST be 1086 automatically deleted and no longer available at the DOTS server. 1087 For example, if the DOTS server receives a mitigation request which 1088 overlaps with an existing mitigation with a higher numeric 'mid', the 1089 DOTS server rejects the request by returning 4.09 (Conflict) to the 1090 DOTS client. The response includes enough information for a DOTS 1091 client to recognize the source of the conflict as described below in 1092 the 'conflict-information' subtree with only the relevant nodes 1093 listed: 1095 conflict-information: Indicates that a mitigation request is 1096 conflicting with another mitigation request. This optional 1097 attribute has the following structure: 1099 conflict-cause: Indicates the cause of the conflict. The 1100 following values are defined: 1102 1: Overlapping targets. 'conflict-scope' provides more details 1103 about the conflicting target clauses. 1105 conflict-scope: Characterizes the exact conflict scope. It may 1106 include a list of IP addresses, a list of prefixes, a list of 1107 port numbers, a list of target protocols, a list of FQDNs, a 1108 list of URIs, a list of alias-names, or a 'mid'. 1110 If the DOTS server receives a mitigation request which overlaps with 1111 an active mitigation request, but both having distinct 'trigger- 1112 mitigation' types, the DOTS server SHOULD deactivate (absent explicit 1113 policy/configuration otherwise) the mitigation request with 'trigger- 1114 mitigation' set to false. Particularly, if the mitigation request 1115 with 'trigger-mitigation' set to false is active, the DOTS server 1116 withdraws the mitigation request (i.e., status code is set to '7' as 1117 defined in Table 2) and transitions the status of the mitigation 1118 request to '8'. 1120 Upon DOTS signal channel session loss with a peer DOTS client, the 1121 DOTS server MUST withdraw (absent explicit policy/configuration 1122 otherwise) any active mitigation requests overlapping with mitigation 1123 requests having 'trigger-mitigation' set to false from that DOTS 1124 client, as the loss of the session implictily activates these 1125 preconfigured mitigation requests and they take precedence. Note 1126 that active-but-terminating period is not observed for mitigations 1127 withdrawn at the initiative of the DOTS server. 1129 DOTS clients may adopt various strategies for setting the scopes of 1130 immediate and pre-configured mitigation requests to avoid potential 1131 conflicts. For example, a DOTS client may tweak pre-configured 1132 scopes so that the scope of any overlapping immediate mitigation 1133 request will be a subset of the pre-configured scopes. Also, if an 1134 immediate mitigation request overlaps with any of the pre-configured 1135 scopes, the DOTS client sets the scope of the overlapping immediate 1136 mitigation request to be a subset of the pre-configured scopes, so as 1137 to get a broad mitigation when the DOTS signal channel collapses and 1138 maximize the chance of recovery. 1140 If the request is conflicting with an existing mitigation request 1141 from a different DOTS client, the DOTS server may return 2.01 1142 (Created) or 4.09 (Conflict) to the requesting DOTS client. If the 1143 DOTS server decides to maintain the new mitigation request, the DOTS 1144 server returns 2.01 (Created) to the requesting DOTS client. If the 1145 DOTS server decides to reject the new mitigation request, the DOTS 1146 server returns 4.09 (Conflict) to the requesting DOTS client. For 1147 both 2.01 (Created) and 4.09 (Conflict) responses, the response 1148 includes enough information for a DOTS client to recognize the source 1149 of the conflict as described below: 1151 conflict-information: Indicates that a mitigation request is 1152 conflicting with another mitigation request(s) from other DOTS 1153 client(s). This optional attribute has the following structure: 1155 conflict-status: Indicates the status of a conflicting mitigation 1156 request. The following values are defined: 1158 1: DOTS server has detected conflicting mitigation requests 1159 from different DOTS clients. This mitigation request is 1160 currently inactive until the conflicts are resolved. 1161 Another mitigation request is active. 1163 2: DOTS server has detected conflicting mitigation requests 1164 from different DOTS clients. This mitigation request is 1165 currently active. 1167 3: DOTS server has detected conflicting mitigation requests 1168 from different DOTS clients. All conflicting mitigation 1169 requests are inactive. 1171 conflict-cause: Indicates the cause of the conflict. The 1172 following values are defined: 1174 1: Overlapping targets. 'conflict-scope' provides more details 1175 about the conflicting target clauses. 1177 2: Conflicts with an existing accept-list. This code is 1178 returned when the DDoS mitigation detects source addresses/ 1179 prefixes in the accept-listed ACLs are attacking the 1180 target. 1182 3: CUID Collision. This code is returned when a DOTS client 1183 uses a 'cuid' that is already used by another DOTS client. 1184 This code is an indication that the request has been 1185 rejected and a new request with a new 'cuid' is to be re- 1186 sent by the DOTS client (see the example shown in 1187 Figure 11). Note that 'conflict-status', 'conflict-scope', 1188 and 'retry-timer' MUST NOT be returned in the error 1189 response. 1191 conflict-scope: Characterizes the exact conflict scope. It may 1192 include a list of IP addresses, a list of prefixes, a list of 1193 port numbers, a list of target protocols, a list of FQDNs, a 1194 list of URIs, a list of alias-names, or references to 1195 conflicting ACLs (by an 'acl-name', typically 1196 [I-D.ietf-dots-data-channel]). 1198 retry-timer: Indicates, in seconds, the time after which the DOTS 1199 client may re-issue the same request. The DOTS server returns 1200 'retry-timer' only to DOTS client(s) for which a mitigation 1201 request is deactivated. Any retransmission of the same 1202 mitigation request before the expiry of this timer is likely to 1203 be rejected by the DOTS server for the same reasons. 1205 The retry-timer SHOULD be equal to the lifetime of the active 1206 mitigation request resulting in the deactivation of the 1207 conflicting mitigation request. 1209 If the DOTS server decides to maintain a state for the 1210 deactivated mitigation request, the DOTS server updates the 1211 lifetime of the deactivated mitigation request to (retry-timer 1212 + 45 seconds), so that the DOTS client can refresh the 1213 deactivated mitigation request after 'retry-timer' seconds, but 1214 before the expiry of the lifetime, and check if the conflict is 1215 resolved. 1217 Header: PUT (Code=0.03) 1218 Uri-Path: ".well-known" 1219 Uri-Path: "dots" 1220 Uri-Path: "mitigate" 1221 Uri-Path: "cuid=7eeaf349529eb55ed50113" 1222 Uri-Path: "mid=12" 1224 (1) Request with a conflicting 'cuid' 1226 { 1227 "ietf-dots-signal-channel:mitigation-scope": { 1228 "scope": [ 1229 { 1230 "conflict-information": { 1231 "conflict-cause": "cuid-collision" 1232 } 1233 } 1234 ] 1235 } 1236 } 1238 (2) Message body of the 4.09 (Conflict) response 1239 from the DOTS server 1241 Header: PUT (Code=0.03) 1242 Uri-Path: ".well-known" 1243 Uri-Path: "dots" 1244 Uri-Path: "mitigate" 1245 Uri-Path: "cuid=f30d281ce6b64fc5a0b91e" 1246 Uri-Path: "mid=12" 1248 (3) Request with a new 'cuid' 1250 Figure 11: Example of Generating a New 'cuid' 1252 As an active attack evolves, DOTS clients can adjust the scope of 1253 requested mitigation as necessary, by refining the scope of resources 1254 requiring mitigation. This can be achieved by sending a PUT request 1255 with a new 'mid' value that will override the existing one with 1256 overlapping mitigation scopes. 1258 For a mitigation request to continue beyond the initial negotiated 1259 lifetime, the DOTS client has to refresh the current mitigation 1260 request by sending a new PUT request. This PUT request MUST use the 1261 same 'mid' value, and MUST repeat all the other parameters as sent in 1262 the original mitigation request apart from a possible change to the 1263 lifetime parameter value. In such case, the DOTS server MAY update 1264 the mitigation request, and a 2.04 (Changed) response is returned to 1265 indicate a successful update of the mitigation request. If this is 1266 not the case, the DOTS server MUST reject the request with a 4.00 1267 (Bad Request). 1269 4.4.2. Retrieve Information Related to a Mitigation 1271 A GET request is used by a DOTS client to retrieve information 1272 (including status) of DOTS mitigations from a DOTS server. 1274 'cuid' is a mandatory Uri-Path parameter for GET requests. 1276 Uri-Path parameters with empty values MUST NOT be present in a 1277 request. 1279 The same considerations for manipulating 'cdid' parameter by server- 1280 domain DOTS gateways specified in Section 4.4.1 MUST be followed for 1281 GET requests. 1283 The 'c' Uri-Query option is used to control selection of 1284 configuration and non-configuration data nodes. Concretely, the 'c' 1285 (content) parameter and its permitted values defined in the following 1286 table [I-D.ietf-core-comi] can be used to retrieve non-configuration 1287 data (attack mitigation status), configuration data, or both. The 1288 DOTS server MAY support this optional filtering capability. It can 1289 safely ignore it if not supported. If the DOTS client supports the 1290 optional filtering capability, it SHOULD use "c=n" query (to get back 1291 only the dynamically changing data) or "c=c" query (to get back the 1292 static configuration values) when the DDoS attack is active to limit 1293 the size of the response. 1295 +-------+-----------------------------------------------------+ 1296 | Value | Description | 1297 +-------+-----------------------------------------------------+ 1298 | c | Return only configuration descendant data nodes | 1299 | n | Return only non-configuration descendant data nodes | 1300 | a | Return all descendant data nodes | 1301 +-------+-----------------------------------------------------+ 1303 The DOTS client can use Block-wise transfer [RFC7959] to get the list 1304 of all its mitigations maintained by a DOTS server, it can send 1305 Block2 Option in a GET request with NUM = 0 to aid in limiting the 1306 size of the response. If the representation of all the active 1307 mitigation requests associated with the DOTS client does not fit 1308 within a single datagram, the DOTS server MUST use the Block2 Option 1309 with NUM = 0 in the GET response. The Size2 Option may be conveyed 1310 in the response to indicate the total size of the resource 1311 representation. The DOTS client retrieves the rest of the 1312 representation by sending additional GET requests with Block2 Options 1313 containing NUM values greater than zero. The DOTS client MUST adhere 1314 to the block size preferences indicated by the DOTS server in the 1315 response. If the DOTS server uses the Block2 Option in the GET 1316 response and the response is for a dynamically changing resource 1317 (e.g. "c=n" or "c=a" query), the DOTS server MUST include the ETag 1318 Option in the response. The DOTS client MUST include the same ETag 1319 value in subsequent GET requests to retrieve the rest of the 1320 representation. 1322 The following examples illustrate how a DOTS client retrieves active 1323 mitigation requests from a DOTS server. In particular: 1325 o Figure 12 shows the example of a GET request to retrieve all DOTS 1326 mitigation requests signaled by a DOTS client. 1328 o Figure 13 shows the example of a GET request to retrieve a 1329 specific DOTS mitigation request signaled by a DOTS client. The 1330 configuration data to be reported in the response is formatted in 1331 the same order as was processed by the DOTS server in the original 1332 mitigation request. 1334 These two examples assume the default of "c=a"; that is, the DOTS 1335 client asks for all data to be reported by the DOTS server. 1337 Header: GET (Code=0.01) 1338 Uri-Path: ".well-known" 1339 Uri-Path: "dots" 1340 Uri-Path: "mitigate" 1341 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1342 Observe: 0 1344 Figure 12: GET to Retrieve all DOTS Mitigation Requests 1346 Header: GET (Code=0.01) 1347 Uri-Path: ".well-known" 1348 Uri-Path: "dots" 1349 Uri-Path: "mitigate" 1350 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1351 Uri-Path: "mid=12332" 1352 Observe: 0 1354 Figure 13: GET to Retrieve a Specific DOTS Mitigation Request 1356 If the DOTS server does not find the 'mid' Uri-Path value conveyed in 1357 the GET request in its configuration data for the requesting DOTS 1358 client, it MUST respond with a 4.04 (Not Found) error response code. 1359 Likewise, the same error MUST be returned as a response to a request 1360 to retrieve all mitigation records (i.e., 'mid' Uri-Path is not 1361 defined) of a given DOTS client if the DOTS server does not find any 1362 mitigation record for that DOTS client. As a reminder, a DOTS client 1363 is identified by its identity (e.g., client certificate, 'cuid') and 1364 optionally the 'cdid'. 1366 Figure 14 shows a response example of all active mitigation requests 1367 associated with the DOTS client as maintained by the DOTS server. 1368 The response indicates the mitigation status of each mitigation 1369 request. 1371 { 1372 "ietf-dots-signal-channel:mitigation-scope": { 1373 "scope": [ 1374 { 1375 "mid": 12332, 1376 "mitigation-start": "1507818434", 1377 "target-prefix": [ 1378 "2001:db8:6401::1/128", 1379 "2001:db8:6401::2/128" 1380 ], 1381 "target-protocol": [ 1382 17 1383 ], 1384 "lifetime": 1756, 1385 "status": "attack-successfully-mitigated", 1386 "bytes-dropped": "134334555", 1387 "bps-dropped": "43344", 1388 "pkts-dropped": "333334444", 1389 "pps-dropped": "432432" 1390 }, 1391 { 1392 "mid": 12333, 1393 "mitigation-start": "1507818393", 1394 "target-prefix": [ 1395 "2001:db8:6401::1/128", 1396 "2001:db8:6401::2/128" 1397 ], 1398 "target-protocol": [ 1399 6 1400 ], 1401 "lifetime": 1755, 1402 "status": "attack-stopped", 1403 "bytes-dropped": "0", 1404 "bps-dropped": "0", 1405 "pkts-dropped": "0", 1406 "pps-dropped": "0" 1407 } 1408 ] 1409 } 1410 } 1412 Figure 14: Response Body to a GET Request 1414 The mitigation status parameters are described below: 1416 mitigation-start: Mitigation start time is expressed in seconds 1417 relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of 1419 [RFC7049]). The CBOR encoding is modified so that the leading tag 1420 1 (epoch-based date/time) MUST be omitted. 1422 This is a mandatory attribute when an attack mitigation is active. 1423 Particularly, 'mitigation-start' is not returned for a mitigation 1424 with 'status' code set to 8. 1426 lifetime: The remaining lifetime of the mitigation request, in 1427 seconds. 1429 This is a mandatory attribute. 1431 status: Status of attack mitigation. The various possible values of 1432 'status' parameter are explained in Table 2. 1434 This is a mandatory attribute. 1436 bytes-dropped: The total dropped byte count for the mitigation 1437 request since the attack mitigation is triggered. The count wraps 1438 around when it reaches the maximum value of unsigned integer64. 1440 This is an optional attribute. 1442 bps-dropped: The average number of dropped bytes per second for the 1443 mitigation request since the attack mitigation is triggered. This 1444 average SHOULD be over five-minute intervals (that is, measuring 1445 bytes into five-minute buckets and then averaging these buckets 1446 over the time since the mitigation was triggered). 1448 This is an optional attribute. 1450 pkts-dropped: The total number of dropped packet count for the 1451 mitigation request since the attack mitigation is triggered. The 1452 count wraps around when it reaches the maximum value of unsigned 1453 integer64. 1455 This is an optional attribute. 1457 pps-dropped: The average number of dropped packets per second for 1458 the mitigation request since the attack mitigation is triggered. 1459 This average SHOULD be over five-minute intervals (that is, 1460 measuring packets into five-minute buckets and then averaging 1461 these buckets over the time since the mitigation was triggered). 1463 This is an optional attribute. 1465 +-----------+-------------------------------------------------------+ 1466 | Parameter | Description | 1467 | Value | | 1468 +-----------+-------------------------------------------------------+ 1469 | 1 | Attack mitigation setup is in progress (e.g., | 1470 | | changing the network path to redirect the inbound | 1471 | | traffic to a DOTS mitigator). | 1472 +-----------+-------------------------------------------------------+ 1473 | 2 | Attack is being successfully mitigated (e.g., traffic | 1474 | | is redirected to a DDoS mitigator and attack traffic | 1475 | | is dropped). | 1476 +-----------+-------------------------------------------------------+ 1477 | 3 | Attack has stopped and the DOTS client can withdraw | 1478 | | the mitigation request. This status code will be | 1479 | | transmitted for immediate mitigation requests till | 1480 | | the mitigation is withdrawn or the lifetime expires. | 1481 | | For mitigation requests with pre-configured scopes | 1482 | | (i.e., 'trigger-mitigation' set to 'false'), this | 1483 | | status code will be transmitted 4 times and then | 1484 | | transition to "8". | 1485 +-----------+-------------------------------------------------------+ 1486 | 4 | Attack has exceeded the mitigation provider | 1487 | | capability. | 1488 +-----------+-------------------------------------------------------+ 1489 | 5 | DOTS client has withdrawn the mitigation request and | 1490 | | the mitigation is active but terminating. | 1491 +-----------+-------------------------------------------------------+ 1492 | 6 | Attack mitigation is now terminated. | 1493 +-----------+-------------------------------------------------------+ 1494 | 7 | Attack mitigation is withdrawn (by the DOTS server). | 1495 | | If a mitigation request with 'trigger-mitigation' set | 1496 | | to false is withdrawn because it overlaps with an | 1497 | | immediate mitigation request, this status code will | 1498 | | be transmitted 4 times and then transition to "8" for | 1499 | | the mitigation request with pre-configured scopes. | 1500 +-----------+-------------------------------------------------------+ 1501 | 8 | Attack mitigation will be triggered for the | 1502 | | mitigation request only when the DOTS signal channel | 1503 | | session is lost. | 1504 +-----------+-------------------------------------------------------+ 1506 Table 2: Values of 'status' Parameter 1508 4.4.2.1. DOTS Servers Sending Mitigation Status 1510 The Observe Option defined in [RFC7641] extends the CoAP core 1511 protocol with a mechanism for a CoAP client to "observe" a resource 1512 on a CoAP server: The client retrieves a representation of the 1513 resource and requests this representation be updated by the server as 1514 long as the client is interested in the resource. DOTS 1515 implementations MUST use the Observe Option for both 'mitigate' and 1516 'config' (Section 4.2). 1518 A DOTS client conveys the Observe Option set to '0' in the GET 1519 request to receive asynchronous notifications of attack mitigation 1520 status from the DOTS server. 1522 Unidirectional mitigation notifications within the bidirectional 1523 signal channel enables asynchronous notifications between the agents. 1524 [RFC7641] indicates that (1) a notification can be sent in a 1525 Confirmable or a Non-confirmable message, and (2) the message type 1526 used is typically application-dependent and may be determined by the 1527 server for each notification individually. For DOTS server 1528 application, the message type MUST always be set to Non-confirmable 1529 even if the underlying COAP library elects a notification to be sent 1530 in a Confirmable message. 1532 Due to the higher likelihood of packet loss during a DDoS attack, the 1533 DOTS server periodically sends attack mitigation status to the DOTS 1534 client and also notifies the DOTS client whenever the status of the 1535 attack mitigation changes. If the DOTS server cannot maintain an RTT 1536 estimate, it MUST NOT send more than one asynchronous notification 1537 every 3 seconds, and SHOULD use an even less aggressive rate whenever 1538 possible (case 2 in Section 3.1.3 of [RFC8085]). 1540 When conflicting requests are detected, the DOTS server enforces the 1541 corresponding policy (e.g., accept all requests, reject all requests, 1542 accept only one request but reject all the others, ...). It is 1543 assumed that this policy is supplied by the DOTS server administrator 1544 or it is a default behavior of the DOTS server implementation. Then, 1545 the DOTS server sends notification message(s) to the DOTS client(s) 1546 at the origin of the conflict (refer to the conflict parameters 1547 defined in Section 4.4.1). A conflict notification message includes 1548 information about the conflict cause, scope, and the status of the 1549 mitigation request(s). For example, 1551 o A notification message with 'status' code set to '7 (Attack 1552 mitigation is withdrawn)' and 'conflict-status' set to '1' is sent 1553 to a DOTS client to indicate that an active mitigation request is 1554 deactivated because a conflict is detected. 1556 o A notification message with 'status' code set to '1 (Attack 1557 mitigation is in progress)' and 'conflict-status' set to '2' is 1558 sent to a DOTS client to indicate that this mitigation request is 1559 in progress, but a conflict is detected. 1561 Upon receipt of a conflict notification message indicating that a 1562 mitigation request is deactivated because of a conflict, a DOTS 1563 client MUST NOT resend the same mitigation request before the expiry 1564 of 'retry-timer'. It is also recommended that DOTS clients support 1565 means to alert administrators about mitigation conflicts. 1567 A DOTS client that is no longer interested in receiving notifications 1568 from the DOTS server can simply "forget" the observation. When the 1569 DOTS server sends the next notification, the DOTS client will not 1570 recognize the token in the message and thus will return a Reset 1571 message. This causes the DOTS server to remove the associated entry. 1572 Alternatively, the DOTS client can explicitly deregister itself by 1573 issuing a GET request that has the Token field set to the token of 1574 the observation to be cancelled and includes an Observe Option with 1575 the value set to '1' (deregister). The latter is RECOMMENDED. 1577 Figure 15 shows an example of a DOTS client requesting a DOTS server 1578 to send notifications related to a mitigation request. Note that for 1579 mitigations with pre-configured scopes (i.e., 'trigger-mitigation' 1580 set to 'false'), the state will need to transition from 3 (attack- 1581 stopped) to 8 (attack-mitigation-signal-loss). 1583 +-----------+ +-----------+ 1584 |DOTS client| |DOTS server| 1585 +-----------+ +-----------+ 1586 | | 1587 | GET / | 1588 | Token: 0x4a | Registration 1589 | Observe: 0 | 1590 +----------------------------------------->| 1591 | | 1592 | 2.05 Content | 1593 | Token: 0x4a | Notification of 1594 | Observe: 12 | the current state 1595 | status: "attack-mitigation-in-progress" | 1596 | | 1597 |<-----------------------------------------+ 1598 | 2.05 Content | 1599 | Token: 0x4a | Notification upon 1600 | Observe: 44 | a state change 1601 | status: "attack-successfully-mitigated" | 1602 | | 1603 |<-----------------------------------------+ 1604 | 2.05 Content | 1605 | Token: 0x4a | Notification upon 1606 | Observe: 60 | a state change 1607 | status: "attack-stopped" | 1608 |<-----------------------------------------+ 1609 | | 1610 ... 1612 Figure 15: Notifications of Attack Mitigation Status 1614 4.4.2.2. DOTS Clients Polling for Mitigation Status 1616 The DOTS client can send the GET request at frequent intervals 1617 without the Observe Option to retrieve the configuration data of the 1618 mitigation request and non-configuration data (i.e., the attack 1619 status). DOTS clients MAY be configured with a policy indicating the 1620 frequency of polling DOTS servers to get the mitigation status. 1621 Absent such policy, the frequency of polling the DOTS server to get 1622 the mitigation status SHOULD follow the transmission guidelines in 1623 Section 3.1.3 of [RFC8085]. 1625 If the DOTS server has been able to mitigate the attack and the 1626 attack has stopped, the DOTS server indicates as such in the status. 1627 In such case, the DOTS client recalls the mitigation request by 1628 issuing a DELETE request for this mitigation request (Section 4.4.4). 1630 A DOTS client SHOULD react to the status of the attack as per the 1631 information sent by the DOTS server rather than performing its own 1632 detection that the attack has been mitigated. This ensures that the 1633 DOTS client does not recall a mitigation request prematurely because 1634 it is possible that the DOTS client does not sense the DDoS attack on 1635 its resources, but the DOTS server could be actively mitigating the 1636 attack because the attack is not completely averted. 1638 4.4.3. Efficacy Update from DOTS Clients 1640 While DDoS mitigation is in progress, due to the likelihood of packet 1641 loss, a DOTS client MAY periodically transmit DOTS mitigation 1642 efficacy updates to the relevant DOTS server. A PUT request is used 1643 to convey the mitigation efficacy update to the DOTS server. This 1644 PUT request is treated as a refresh of the current mitigation. 1646 The PUT request used for efficacy update MUST include all the 1647 parameters used in the PUT request to carry the DOTS mitigation 1648 request (Section 4.4.1) unchanged apart from the 'lifetime' parameter 1649 value. If this is not the case, the DOTS server MUST reject the 1650 request with a 4.00 (Bad Request). 1652 The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 1653 value is used to make the PUT request conditional on the current 1654 existence of the mitigation request. If UDP is used as transport, 1655 CoAP requests may arrive out-of-order. For example, the DOTS client 1656 may send a PUT request to convey an efficacy update to the DOTS 1657 server followed by a DELETE request to withdraw the mitigation 1658 request, but the DELETE request arrives at the DOTS server before the 1659 PUT request. To handle out-of-order delivery of requests, if an If- 1660 Match Option is present in the PUT request and the 'mid' in the 1661 request matches a mitigation request from that DOTS client, the 1662 request is processed by the DOTS server. If no match is found, the 1663 PUT request is silently ignored by the DOTS server. 1665 An example of an efficacy update message, which includes an If-Match 1666 Option with an empty value, is depicted in Figure 16. 1668 Header: PUT (Code=0.03) 1669 Uri-Path: ".well-known" 1670 Uri-Path: "dots" 1671 Uri-Path: "mitigate" 1672 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1673 Uri-Path: "mid=123" 1674 If-Match: 1675 Content-Format: "application/dots+cbor" 1677 { 1678 "ietf-dots-signal-channel:mitigation-scope": { 1679 "scope": [ 1680 { 1681 "target-prefix": [ 1682 "2001:db8:6401::1/128", 1683 "2001:db8:6401::2/128" 1684 ], 1685 "target-port-range": [ 1686 { 1687 "lower-port": 80 1688 }, 1689 { 1690 "lower-port": 443 1691 }, 1692 { 1693 "lower-port": 8080 1694 } 1695 ], 1696 "target-protocol": [ 1697 6 1698 ], 1699 "attack-status": "under-attack" 1700 } 1701 ] 1702 } 1703 } 1705 Figure 16: An Example of Efficacy Update 1707 The 'attack-status' parameter is a mandatory attribute when 1708 performing an efficacy update. The various possible values contained 1709 in the 'attack-status' parameter are described in Table 3. 1711 +-----------+-------------------------------------------------------+ 1712 | Parameter | Description | 1713 | value | | 1714 +-----------+-------------------------------------------------------+ 1715 | 1 | The DOTS client determines that it is still under | 1716 | | attack. | 1717 +-----------+-------------------------------------------------------+ 1718 | 2 | The DOTS client determines that the attack is | 1719 | | successfully mitigated (e.g., attack traffic is not | 1720 | | seen). | 1721 +-----------+-------------------------------------------------------+ 1723 Table 3: Values of 'attack-status' Parameter 1725 The DOTS server indicates the result of processing a PUT request 1726 using CoAP response codes. The response code 2.04 (Changed) is 1727 returned if the DOTS server has accepted the mitigation efficacy 1728 update. The error response code 5.03 (Service Unavailable) is 1729 returned if the DOTS server has erred or is incapable of performing 1730 the mitigation. As specified in [RFC7252], 5.03 uses Max-Age option 1731 to indicate the number of seconds after which to retry. 1733 4.4.4. Withdraw a Mitigation 1735 DELETE requests are used to withdraw DOTS mitigation requests from 1736 DOTS servers (Figure 17). 1738 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE 1739 requests. 1741 The same considerations for manipulating 'cdid' parameter by DOTS 1742 gateways, as specified in Section 4.4.1, MUST be followed for DELETE 1743 requests. Uri-Path parameters with empty values MUST NOT be present 1744 in a request. 1746 Header: DELETE (Code=0.04) 1747 Uri-Path: ".well-known" 1748 Uri-Path: "dots" 1749 Uri-Path: "mitigate" 1750 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1751 Uri-Path: "mid=123" 1753 Figure 17: Withdraw a DOTS Mitigation 1755 If the DELETE request does not include 'cuid' and 'mid' parameters, 1756 the DOTS server MUST reply with a 4.00 (Bad Request). 1758 Once the request is validated, the DOTS server immediately 1759 acknowledges a DOTS client's request to withdraw the DOTS signal 1760 using 2.02 (Deleted) response code with no response payload. A 2.02 1761 (Deleted) Response Code is returned even if the 'mid' parameter value 1762 conveyed in the DELETE request does not exist in its configuration 1763 data before the request. 1765 If the DOTS server finds the 'mid' parameter value conveyed in the 1766 DELETE request in its configuration data for the DOTS client, then to 1767 protect against route or DNS flapping caused by a DOTS client rapidly 1768 removing a mitigation, and to dampen the effect of oscillating 1769 attacks, the DOTS server MAY allow mitigation to continue for a 1770 limited period after acknowledging a DOTS client's withdrawal of a 1771 mitigation request. During this period, the DOTS server status 1772 messages SHOULD indicate that mitigation is active but terminating 1773 (Section 4.4.2). 1775 The initial active-but-terminating period SHOULD be sufficiently long 1776 to absorb latency incurred by route propagation. The active-but- 1777 terminating period SHOULD be set by default to 120 seconds. If the 1778 client requests mitigation again before the initial active-but- 1779 terminating period elapses, the DOTS server MAY exponentially 1780 increase (the base of the exponent is 2) the active-but-terminating 1781 period up to a maximum of 300 seconds (5 minutes). 1783 Once the active-but-terminating period elapses, the DOTS server MUST 1784 treat the mitigation as terminated, as the DOTS client is no longer 1785 responsible for the mitigation. 1787 If a mitigation is triggered due to a signal channel loss, the DOTS 1788 server relies upon normal triggers to stop that mitigation 1789 (typically, receipt of a valid DELETE request, expiry of the 1790 mitigation lifetime, or scrubbing the traffic to the attack target). 1791 In particular, the DOTS server MUST NOT consider the signal channel 1792 recovery as a trigger to stop the mitigation. 1794 4.5. DOTS Signal Channel Session Configuration 1796 A DOTS client can negotiate, configure, and retrieve the DOTS signal 1797 channel session behavior with its DOTS peers. The DOTS signal 1798 channel can be used, for example, to configure the following: 1800 a. Heartbeat interval (heartbeat-interval): DOTS agents regularly 1801 send heartbeats to each other after mutual authentication is 1802 successfully completed in order to keep the DOTS signal channel 1803 open. Heartbeat messages are exchanged between DOTS agents every 1804 'heartbeat-interval' seconds to detect the current status of the 1805 DOTS signal channel session. 1807 b. Missing heartbeats allowed (missing-hb-allowed): This variable 1808 indicates the maximum number of consecutive heartbeat messages 1809 for which a DOTS agent did not receive a response before 1810 concluding that the session is disconnected or defunct. 1812 c. Acceptable signal loss ratio: Maximum retransmissions, 1813 retransmission timeout value, and other message transmission 1814 parameters for the DOTS signal channel. 1816 The same or distinct configuration sets may be used during times when 1817 a mitigation is active ('mitigating-config') and when no mitigation 1818 is active ('idle-config'). This is particularly useful for DOTS 1819 servers that might want to reduce heartbeat frequency or cease 1820 heartbeat exchanges when an active DOTS client has not requested 1821 mitigation. If distinct configurations are used, DOTS agents MUST 1822 follow the appropriate configuration set as a function of the 1823 mitigation activity (e.g., if no mitigation request is active (also 1824 referred to as 'idle' time), 'idle-config'-related values must be 1825 followed). Additionally, DOTS agents MUST automatically switch to 1826 the other configuration upon a change in the mitigation activity 1827 (e.g., if an attack mitigation is launched after an 'idle' time, the 1828 DOTS agent switches from 'idle-config' to 'mitigating-config'-related 1829 values). 1831 CoAP Requests and responses are indicated for reliable delivery by 1832 marking them as Confirmable messages. DOTS signal channel session 1833 configuration requests and responses are marked as Confirmable 1834 messages. As explained in Section 2.1 of [RFC7252], a Confirmable 1835 message is retransmitted using a default timeout and exponential 1836 back-off between retransmissions, until the DOTS server sends an 1837 Acknowledgement message (ACK) with the same Message ID conveyed from 1838 the DOTS client. 1840 Message transmission parameters are defined in Section 4.8 of 1841 [RFC7252]. The DOTS server can either piggyback the response in the 1842 acknowledgement message or, if the DOTS server cannot respond 1843 immediately to a request carried in a Confirmable message, it simply 1844 responds with an Empty Acknowledgement message so that the DOTS 1845 client can stop retransmitting the request. Empty Acknowledgement 1846 messages are explained in Section 2.2 of [RFC7252]. When the 1847 response is ready, the server sends it in a new Confirmable message 1848 which in turn needs to be acknowledged by the DOTS client (see 1849 Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and responses 1850 exchanged between DOTS agents during 'idle' time are marked as 1851 Confirmable messages. 1853 Implementation Note: A DOTS client that receives a response in a 1854 Confirmable message may want to clean up the message state right 1855 after sending the ACK. If that ACK is lost and the DOTS server 1856 retransmits the Confirmable message, the DOTS client may no longer 1857 have any state that would help it correlate this response: from 1858 the DOTS client's standpoint, the retransmission message is 1859 unexpected. The DOTS client will send a Reset message so it does 1860 not receive any more retransmissions. This behavior is normal and 1861 not an indication of an error (see Section 5.3.2 of [RFC7252] for 1862 more details). 1864 4.5.1. Discover Configuration Parameters 1866 A GET request is used to obtain acceptable (e.g., minimum and maximum 1867 values) and current configuration parameters on the DOTS server for 1868 DOTS signal channel session configuration. This procedure occurs 1869 between a DOTS client and its immediate peer DOTS server. As such, 1870 this GET request MUST NOT be relayed by a DOTS gateway. 1872 Figure 18 shows how to obtain acceptable configuration parameters for 1873 the DOTS server. 1875 Header: GET (Code=0.01) 1876 Uri-Path: ".well-known" 1877 Uri-Path: "dots" 1878 Uri-Path: "config" 1880 Figure 18: GET to Retrieve Configuration 1882 The DOTS server in the 2.05 (Content) response conveys the current, 1883 minimum, and maximum attribute values acceptable by the DOTS server 1884 (Figure 19). 1886 { 1887 "ietf-dots-signal-channel:signal-config": { 1888 "mitigating-config": { 1889 "heartbeat-interval": { 1890 "max-value": number, 1891 "min-value": number, 1892 "current-value": number 1893 }, 1894 "missing-hb-allowed": { 1895 "max-value": number, 1896 "min-value": number, 1897 "current-value": number 1898 }, 1899 "max-retransmit": { 1900 "max-value": number, 1901 "min-value": number, 1902 "current-value": number 1904 }, 1905 "ack-timeout": { 1906 "max-value-decimal": "string", 1907 "min-value-decimal": "string", 1908 "current-value-decimal": "string" 1909 }, 1910 "ack-random-factor": { 1911 "max-value-decimal": "string", 1912 "min-value-decimal": "string", 1913 "current-value-decimal": "string" 1914 } 1915 }, 1916 "idle-config": { 1917 "heartbeat-interval": { 1918 "max-value": number, 1919 "min-value": number, 1920 "current-value": number 1921 }, 1922 "missing-hb-allowed": { 1923 "max-value": number, 1924 "min-value": number, 1925 "current-value": number 1926 }, 1927 "max-retransmit": { 1928 "max-value": number, 1929 "min-value": number, 1930 "current-value": number 1931 }, 1932 "ack-timeout": { 1933 "max-value-decimal": "string", 1934 "min-value-decimal": "string", 1935 "current-value-decimal": "string" 1936 }, 1937 "ack-random-factor": { 1938 "max-value-decimal": "string", 1939 "min-value-decimal": "string", 1940 "current-value-decimal": "string" 1941 } 1942 } 1943 } 1944 } 1946 Figure 19: GET Configuration Response Body Schema 1948 The parameters in Figure 19 are described below: 1950 mitigating-config: Set of configuration parameters to use when a 1951 mitigation is active. The following parameters may be included: 1953 heartbeat-interval: Time interval in seconds between two 1954 consecutive heartbeat messages. 1956 '0' is used to disable the heartbeat mechanism. 1958 This is an optional attribute. 1960 missing-hb-allowed: Maximum number of consecutive heartbeat 1961 messages for which the DOTS agent did not receive a response 1962 before concluding that the session is disconnected. 1964 This is an optional attribute. 1966 max-retransmit: Maximum number of retransmissions for a message 1967 (referred to as MAX_RETRANSMIT parameter in CoAP). 1969 This is an optional attribute. 1971 ack-timeout: Timeout value in seconds used to calculate the 1972 initial retransmission timeout value (referred to as 1973 ACK_TIMEOUT parameter in CoAP). 1975 This is an optional attribute. 1977 ack-random-factor: Random factor used to influence the timing of 1978 retransmissions (referred to as ACK_RANDOM_FACTOR parameter in 1979 CoAP). 1981 This is an optional attribute. 1983 idle-config: Set of configuration parameters to use when no 1984 mitigation is active. This attribute has the same structure as 1985 'mitigating-config'. 1987 Figure 20 shows an example of acceptable and current configuration 1988 parameters on a DOTS server for DOTS signal channel session 1989 configuration. The same acceptable configuration is used during 1990 mitigation and idle times. 1992 { 1993 "ietf-dots-signal-channel:signal-config": { 1994 "mitigating-config": { 1995 "heartbeat-interval": { 1996 "max-value": 240, 1997 "min-value": 15, 1998 "current-value": 30 1999 }, 2000 "missing-hb-allowed": { 2001 "max-value": 9, 2002 "min-value": 3, 2003 "current-value": 5 2004 }, 2005 "max-retransmit": { 2006 "max-value": 15, 2007 "min-value": 2, 2008 "current-value": 3 2009 }, 2010 "ack-timeout": { 2011 "max-value-decimal": "30.00", 2012 "min-value-decimal": "1.00", 2013 "current-value-decimal": "2.00" 2014 }, 2015 "ack-random-factor": { 2016 "max-value-decimal": "4.00", 2017 "min-value-decimal": "1.10", 2018 "current-value-decimal": "1.50" 2019 } 2020 }, 2021 "idle-config": { 2022 "heartbeat-interval": { 2023 "max-value": 240, 2024 "min-value": 15, 2025 "current-value": 30 2026 }, 2027 "missing-hb-allowed": { 2028 "max-value": 9, 2029 "min-value": 3, 2030 "current-value": 5 2031 }, 2032 "max-retransmit": { 2033 "max-value": 15, 2034 "min-value": 2, 2035 "current-value": 3 2036 }, 2037 "ack-timeout": { 2038 "max-value-decimal": "30.00", 2039 "min-value-decimal": "1.00", 2040 "current-value-decimal": "2.00" 2041 }, 2042 "ack-random-factor": { 2043 "max-value-decimal": "4.00", 2044 "min-value-decimal": "1.10", 2045 "current-value-decimal": "1.50" 2046 } 2047 } 2048 } 2050 } 2052 Figure 20: Example of a Configuration Response Body 2054 4.5.2. Convey DOTS Signal Channel Session Configuration 2056 A PUT request (Figures 21 and 22) is used to convey the configuration 2057 parameters for the signal channel (e.g., heartbeat interval, maximum 2058 retransmissions). Message transmission parameters for CoAP are 2059 defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of 2060 transmission parameter values are ack-timeout (2 seconds), max- 2061 retransmit (3), ack-random-factor (1.5). In addition to those 2062 parameters, the RECOMMENDED specific DOTS transmission parameter 2063 values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' 2064 (5). 2066 Note: heartbeat-interval should be tweaked to also assist DOTS 2067 messages for NAT traversal (SIG-011 of 2068 [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive 2069 messages must not be sent more frequently than once every 15 2070 seconds and should use longer intervals when possible. 2071 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 2072 minutes or longer, but experience shows that sending packets every 2073 15 to 30 seconds is necessary to prevent the majority of 2074 middleboxes from losing state for UDP flows. From that 2075 standpoint, the RECOMMENDED minimum heartbeat-interval is 15 2076 seconds and the RECOMMENDED maximum heartbeat-interval is 240 2077 seconds. The recommended value of 30 seconds is selected to 2078 anticipate the expiry of NAT state. 2080 A heartbeat-interval of 30 seconds may be considered as too chatty 2081 in some deployments. For such deployments, DOTS agents may 2082 negotiate longer heartbeat-interval values to prevent any network 2083 overload with too frequent keepalives. 2085 Different heartbeat intervals can be defined for 'mitigating- 2086 config' and 'idle-config' to reduce being too chatty during idle 2087 times. If there is an on-path translator between the DOTS client 2088 (standalone or part of a DOTS gateway) and the DOTS server, the 2089 'mitigating-config' heartbeat-interval has to be smaller than the 2090 translator session timeout. It is recommended that the 'idle- 2091 config' heartbeat-interval is also smaller than the translator 2092 session timeout to prevent translator traversal issues, or 2093 disabled entirely. Means to discover the lifetime assigned by a 2094 translator are out of scope. 2096 Section 4.2 of [RFC7252] defines a "CoAP Ping" mechanism. 2097 Concretely, the DOTS agent sends an Empty Confirmable message and the 2098 peer DOTS agent will respond by sending a Reset message. 2100 When a Confirmable "CoAP Ping" is sent, and if there is no response, 2101 the "CoAP Ping" is retransmitted max-retransmit number of times by 2102 the CoAP layer using an initial timeout set to a random duration 2103 between ack-timeout and (ack-timeout*ack-random-factor) and 2104 exponential back-off between retransmissions. By choosing the 2105 recommended transmission parameters, the "CoAP Ping" will timeout 2106 after 45 seconds. If the DOTS agent does not receive any response 2107 from the peer DOTS agent for 'missing-hb-allowed' number of 2108 consecutive "CoAP Ping" Confirmable messages, it concludes that the 2109 DOTS signal channel session is disconnected. A DOTS client MUST NOT 2110 transmit a "CoAP Ping" while waiting for the previous "CoAP Ping" 2111 response from the same DOTS server. 2113 If the DOTS agent wishes to change the default values of message 2114 transmission parameters, it SHOULD follow the guidance given in 2115 Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated 2116 values for message transmission parameters and default values for 2117 non-negotiated message transmission parameters. 2119 The signal channel session configuration is applicable to a single 2120 DOTS signal channel session between DOTS agents, so the 'cuid' Uri- 2121 Path MUST NOT be used. 2123 Header: PUT (Code=0.03) 2124 Uri-Path: ".well-known" 2125 Uri-Path: "dots" 2126 Uri-Path: "config" 2127 Uri-Path: "sid=123" 2128 Content-Format: "application/dots+cbor" 2130 { 2131 ... 2132 } 2134 Figure 21: PUT to Convey the DOTS Signal Channel Session 2135 Configuration Data 2137 The additional Uri-Path parameter to those defined in Table 1 is as 2138 follows: 2140 sid: Session Identifier is an identifier for the DOTS signal channel 2141 session configuration data represented as an integer. This 2142 identifier MUST be generated by DOTS clients. 'sid' values MUST 2143 increase monotonically (when a new PUT is generated by a DOTS 2144 client to convey the configuration parameters for the signal 2145 channel). 2147 This is a mandatory attribute. 2149 { 2150 "ietf-dots-signal-channel:signal-config": { 2151 "mitigating-config": { 2152 "heartbeat-interval": { 2153 "current-value": number 2154 }, 2155 "missing-hb-allowed": { 2156 "current-value": number 2157 }, 2158 "max-retransmit": { 2159 "current-value": number 2160 }, 2161 "ack-timeout": { 2162 "current-value-decimal": "string" 2163 }, 2164 "ack-random-factor": { 2165 "current-value-decimal": "string" 2166 } 2167 }, 2168 "idle-config": { 2169 "heartbeat-interval": { 2170 "current-value": number 2171 }, 2172 "missing-hb-allowed": { 2173 "current-value": number 2174 }, 2175 "max-retransmit": { 2176 "current-value": number 2177 }, 2178 "ack-timeout": { 2179 "current-value-decimal": "string" 2180 }, 2181 "ack-random-factor": { 2182 "current-value-decimal": "string" 2183 } 2184 } 2185 } 2186 } 2188 Figure 22: PUT to Convey the DOTS Signal Channel Session 2189 Configuration Data (Message Body Schema) 2191 The meaning of the parameters in the CBOR body (Figure 22) is defined 2192 in Section 4.5.1. 2194 At least one of the attributes 'heartbeat-interval', 'missing-hb- 2195 allowed', 'max-retransmit', 'ack-timeout', and 'ack-random-factor' 2196 MUST be present in the PUT request. Note that 'heartbeat-interval', 2197 'missing-hb-allowed', 'max-retransmit', 'ack-timeout', and 'ack- 2198 random-factor', if present, do not need to be provided for both 2199 'mitigating-config', and 'idle-config' in a PUT request. 2201 The PUT request with a higher numeric 'sid' value overrides the DOTS 2202 signal channel session configuration data installed by a PUT request 2203 with a lower numeric 'sid' value. To avoid maintaining a long list 2204 of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be 2205 automatically deleted and no longer available at the DOTS server. 2207 Figure 23 shows a PUT request example to convey the configuration 2208 parameters for the DOTS signal channel. In this example, the 2209 heartbeat mechanism is disabled when no mitigation is active, while 2210 the heartbeat interval is set to '91' when a mitigation is active. 2212 Header: PUT (Code=0.03) 2213 Uri-Path: ".well-known" 2214 Uri-Path: "dots" 2215 Uri-Path: "config" 2216 Uri-Path: "sid=123" 2217 Content-Format: "application/dots+cbor" 2219 { 2220 "ietf-dots-signal-channel:signal-config": { 2221 "mitigating-config": { 2222 "heartbeat-interval": { 2223 "current-value": 91 2224 }, 2225 "missing-hb-allowed": { 2226 "current-value": 3 2227 }, 2228 "max-retransmit": { 2229 "current-value": 3 2230 }, 2231 "ack-timeout": { 2232 "current-value-decimal": "2.00" 2233 }, 2234 "ack-random-factor": { 2235 "current-value-decimal": "1.50" 2236 } 2237 }, 2238 "idle-config": { 2239 "heartbeat-interval": { 2240 "current-value": 0 2241 }, 2242 "max-retransmit": { 2243 "current-value": 3 2244 }, 2245 "ack-timeout": { 2246 "current-value-decimal": "2.00" 2247 }, 2248 "ack-random-factor": { 2249 "current-value-decimal": "1.50" 2250 } 2251 } 2252 } 2253 } 2255 Figure 23: PUT to Convey the Configuration Parameters 2257 The DOTS server indicates the result of processing the PUT request 2258 using CoAP response codes: 2260 o If the request is missing a mandatory attribute, does not include 2261 a 'sid' Uri-Path, or contains one or more invalid or unknown 2262 parameters, 4.00 (Bad Request) MUST be returned in the response. 2264 o If the DOTS server does not find the 'sid' parameter value 2265 conveyed in the PUT request in its configuration data and if the 2266 DOTS server has accepted the configuration parameters, then a 2267 response code 2.01 (Created) MUST be returned in the response. 2269 o If the DOTS server finds the 'sid' parameter value conveyed in the 2270 PUT request in its configuration data and if the DOTS server has 2271 accepted the updated configuration parameters, 2.04 (Changed) MUST 2272 be returned in the response. 2274 o If any of the 'heartbeat-interval', 'missing-hb-allowed', 'max- 2275 retransmit', 'target-protocol', 'ack-timeout', and 'ack-random- 2276 factor' attribute values are not acceptable to the DOTS server, 2277 4.22 (Unprocessable Entity) MUST be returned in the response. 2278 Upon receipt of this error code, the DOTS client SHOULD retrieve 2279 the maximum and minimum attribute values acceptable to the DOTS 2280 server (Section 4.5.1). 2282 The DOTS client may re-try and send the PUT request with updated 2283 attribute values acceptable to the DOTS server. 2285 A DOTS client may issue a GET message with 'sid' Uri-Path parameter 2286 to retrieve the negotiated configuration. The response does not need 2287 to include 'sid' in its message body. 2289 4.5.3. Configuration Freshness and Notifications 2291 Max-Age Option (Section 5.10.5 of [RFC7252]) SHOULD be returned by a 2292 DOTS server to associate a validity time with a configuration it 2293 sends. This feature allows the update of the configuration data if a 2294 change occurs at the DOTS server side. For example, the new 2295 configuration may instruct a DOTS client to cease heartbeats or 2296 reduce heartbeat frequency. 2298 It is NOT RECOMMENDED to return a Max-Age Option set to 0. 2300 Returning a Max-Age Option set to 2**32-1 is equivalent to 2301 associating an infinite lifetime with the configuration. 2303 If a non-zero value of Max-Age Option is received by a DOTS client, 2304 it MUST issue a GET request with 'sid' Uri-Path parameter to retrieve 2305 the current and acceptable configuration before the expiry of the 2306 value enclosed in the Max-Age option. This request is considered by 2307 the client and the server as a means to refresh the configuration 2308 parameters for the signal channel. When a DDoS attack is active, 2309 refresh requests MUST NOT be sent by DOTS clients and the DOTS server 2310 MUST NOT terminate the (D)TLS session after the expiry of the value 2311 returned in Max-Age Option. 2313 If Max-Age Option is not returned in a response, the DOTS client 2314 initiates GET requests to refresh the configuration parameters each 2315 60 seconds (Section 5.10.5 of [RFC7252]). To prevent such overload, 2316 it is RECOMMENDED that DOTS servers return a Max-Age Option in GET 2317 responses. Considerations related to which value to use and how such 2318 value is set, are implementation- and deployment-specific. 2320 If an Observe Option set to 0 is included in the configuration 2321 request, the DOTS server sends notifications of any configuration 2322 change (Section 4.2 of [RFC7641]). 2324 If a DOTS server detects that a misbehaving DOTS client does not 2325 contact the DOTS server after the expiry of Max-Age and retrieve the 2326 signal channel configuration data, it MAY terminate the (D)TLS 2327 session. A (D)TLS session is terminated by the receipt of an 2328 authenticated message that closes the connection (e.g., a fatal alert 2329 (Section 6 of [RFC8446])). 2331 4.5.4. Delete DOTS Signal Channel Session Configuration 2333 A DELETE request is used to delete the installed DOTS signal channel 2334 session configuration data (Figure 24). 2336 Header: DELETE (Code=0.04) 2337 Uri-Path: ".well-known" 2338 Uri-Path: "dots" 2339 Uri-Path: "config" 2340 Uri-Path: "sid=123" 2342 Figure 24: Delete Configuration 2344 The DOTS server resets the DOTS signal channel session configuration 2345 back to the default values and acknowledges a DOTS client's request 2346 to remove the DOTS signal channel session configuration using 2.02 2347 (Deleted) response code. 2349 Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request 2350 to set the configuration parameters to default values. Such a 2351 request does not include any 'sid'. 2353 4.6. Redirected Signaling 2355 Redirected DOTS signaling is discussed in detail in Section 3.2.2 of 2356 [I-D.ietf-dots-architecture]. 2358 If a DOTS server wants to redirect a DOTS client to an alternative 2359 DOTS server for a signal session, then the response code 5.03 2360 (Service Unavailable) will be returned in the response to the DOTS 2361 client. 2363 The DOTS server can return the error response code 5.03 in response 2364 to a request from the DOTS client or convey the error response code 2365 5.03 in a unidirectional notification response from the DOTS server. 2367 The DOTS server in the error response conveys the alternate DOTS 2368 server's FQDN, and the alternate DOTS server's IP address(es) values 2369 in the CBOR body (Figure 25). 2371 { 2372 "ietf-dots-signal-channel:redirected-signal": { 2373 "alt-server": "string", 2374 "alt-server-record": [ 2375 "string" 2376 ] 2377 } 2379 Figure 25: Redirected Server Error Response Body Schema 2381 The parameters are described below: 2383 alt-server: FQDN of an alternate DOTS server. 2385 This is a mandatory attribute. 2387 alt-server-record: A list of IP addresses of an alternate DOTS 2388 server. 2390 This is an optional attribute. 2392 The DOTS server returns the Time to live (TTL) of the alternate DOTS 2393 server in a Max-Age Option. That is, the time interval that the 2394 alternate DOTS server may be cached for use by a DOTS client. A Max- 2395 Age Option set to 2**32-1 is equivalent to receiving an infinite TTL. 2396 This value means that the alternate DOTS server is to be used until 2397 the alternate DOTS server redirects the traffic with another 5.03 2398 response which encloses an alternate server. 2400 A Max-Age Option set to '0' may be returned for redirecting 2401 mitigation requests. Such value means that the redirection applies 2402 only for the mitigation request in progress. Returning short TTL in 2403 a Max-Age Option may adversely impact DOTS clients on slow links. 2404 Returning short values should be avoided under such conditions. 2406 If the alternate DOTS server TTL has expired, the DOTS client MUST 2407 use the DOTS server(s), that was provisioned using means discussed in 2408 Section 4.1. This fall back mechanism is triggered immediately upon 2409 expiry of the TTL, except when a DDoS attack is active. 2411 Requests issued by misbehaving DOTS clients which do not honor the 2412 TTL conveyed in the Max-Age Option or react to explicit re-direct 2413 messages can be rejected by DOTS servers. 2415 Figure 26 shows a 5.03 response example to convey the DOTS alternate 2416 server 'alt-server.example' together with its IP addresses 2417 2001:db8:6401::1 and 2001:db8:6401::2. 2419 { 2420 "ietf-dots-signal-channel:redirected-signal": { 2421 "alt-server": "alt-server.example", 2422 "alt-server-record": [ 2423 "2001:db8:6401::1", 2424 "2001:db8:6401::2" 2425 ] 2426 } 2428 Figure 26: Example of Redirected Server Error Response Body 2430 When the DOTS client receives 5.03 response with an alternate server 2431 included, it considers the current request as failed, but SHOULD try 2432 re-sending the request to the alternate DOTS server. During a DDoS 2433 attack, the DNS server may be the target of another DDoS attack, 2434 alternate DOTS server's IP addresses conveyed in the 5.03 response 2435 help the DOTS client skip DNS lookup of the alternate DOTS server, at 2436 the cost of trusting the first DOTS server to provide accurate 2437 information. The DOTS client can then try to establish a UDP or a 2438 TCP session with the alternate DOTS server. The DOTS client MAY 2439 implement a method to construct IPv4-embedded IPv6 addresses 2440 [RFC6052]; this is required to handle the scenario where an IPv6-only 2441 DOTS client communicates with an IPv4-only alternate DOTS server. 2443 If the DOTS client has been redirected to a DOTS server to which it 2444 has already communicated with within the last five (5) minutes, it 2445 MUST ignore the redirection and try to contact other DOTS servers 2446 listed in the local configuration or discovered using dynamic means 2447 such as DHCP or SRV procedures [I-D.ietf-dots-server-discovery]. It 2448 is RECOMMENDED that DOTS clients support means to alert 2449 administrators about redirect loops. 2451 4.7. Heartbeat Mechanism 2453 To provide an indication of signal health and distinguish an 'idle' 2454 signal channel from a 'disconnected' or 'defunct' session, the DOTS 2455 agent sends a heartbeat over the signal channel to maintain its half 2456 of the channel. The DOTS agent similarly expects a heartbeat from 2457 its peer DOTS agent, and may consider a session terminated in the 2458 prolonged absence of a peer agent heartbeat. Concretely, while the 2459 communication between the DOTS agents is otherwise quiescent, the 2460 DOTS client will probe the DOTS server to ensure it has maintained 2461 cryptographic state and vice versa. Such probes can also keep 2462 firewalls and/or stateful translators bindings alive. This probing 2463 reduces the frequency of establishing a new handshake when a DOTS 2464 signal needs to be conveyed to the DOTS server. 2466 DOTS servers MAY trigger their heartbeat requests immediately after 2467 receiving heartbeat probes from peer DOTS clients. As a reminder, it 2468 is the responsibility of DOTS clients to ensure that on-path 2469 translators/firewalls are maintaining a binding so that the same 2470 external IP address and/or port number is retained for the DOTS 2471 signal channel session. 2473 In case of a massive DDoS attack that saturates the incoming link(s) 2474 to the DOTS client, all traffic from the DOTS server to the DOTS 2475 client will likely be dropped, although the DOTS server receives 2476 heartbeat requests in addition to DOTS messages sent by the DOTS 2477 client. In this scenario, the DOTS agents MUST behave differently to 2478 handle message transmission and DOTS signal channel session 2479 liveliness during link saturation: 2481 o The DOTS client MUST NOT consider the DOTS signal channel session 2482 terminated even after a maximum 'missing-hb-allowed' threshold is 2483 reached. The DOTS client SHOULD keep on using the current DOTS 2484 signal channel session to send heartbeat requests over it, so that 2485 the DOTS server knows the DOTS client has not disconnected the 2486 DOTS signal channel session. 2488 After the maximum 'missing-hb-allowed' threshold is reached, the 2489 DOTS client SHOULD try to resume the (D)TLS session. The DOTS 2490 client SHOULD send mitigation requests over the current DOTS 2491 signal channel session, and in parallel, for example, try to 2492 resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to 2493 piggyback the mitigation request in the ClientHello message. 2495 As soon as the link is no longer saturated, if traffic from the 2496 DOTS server reaches the DOTS client over the current DOTS signal 2497 channel session, the DOTS client can stop (D)TLS session 2498 resumption or if (D)TLS session resumption is successful then 2499 disconnect the current DOTS signal channel session. 2501 o If the DOTS server does not receive any traffic from the peer DOTS 2502 client, then the DOTS server sends heartbeat requests to the DOTS 2503 client and after maximum 'missing-hb-allowed' threshold is 2504 reached, the DOTS server concludes the session is disconnected. 2506 In DOTS over UDP, heartbeat messages MUST be exchanged between the 2507 DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of 2508 [RFC7252]. 2510 In DOTS over TCP, heartbeat messages MUST be exchanged between the 2511 DOTS agents using the Ping and Pong messages specified in Section 5.4 2512 of [RFC8323]. That is, the DOTS agent sends a Ping message and the 2513 peer DOTS agent would respond by sending a single Pong message. 2515 5. DOTS Signal Channel YANG Modules 2517 This document defines a YANG [RFC7950] module for DOTS mitigation 2518 scope, DOTS signal channel session configuration data, and DOTS 2519 redirection signaling. 2521 This YANG module (ietf-dots-signal-channel) defines the DOTS client 2522 interaction with the DOTS server as seen by the DOTS client. A DOTS 2523 server is allowed to update the non-configurable 'ro' entities in the 2524 responses. This YANG module is not intended to be used via NETCONF/ 2525 RESTCONF for DOTS server management purposes; such module is out of 2526 the scope of this document. It serves only to provide a data model 2527 and encoding, but not a management data model. 2529 A companion YANG module is defined to include a collection of types 2530 defined by IANA: "iana-dots-signal-channel" (Section 5.2). 2532 5.1. Tree Structure 2534 This document defines the YANG module "ietf-dots-signal-channel" 2535 (Section 5.3), which has the following tree structure. A DOTS signal 2536 message can be a mitigation, a configuration, or a redirect message. 2538 module: ietf-dots-signal-channel 2539 +--rw dots-signal 2540 +--rw (message-type)? 2541 +--:(mitigation-scope) 2542 | +--rw scope* [cuid mid] 2543 | +--rw cdid? string 2544 | +--rw cuid string 2545 | +--rw mid uint32 2546 | +--rw target-prefix* inet:ip-prefix 2547 | +--rw target-port-range* [lower-port] 2548 | | +--rw lower-port inet:port-number 2549 | | +--rw upper-port? inet:port-number 2550 | +--rw target-protocol* uint8 2551 | +--rw target-fqdn* inet:domain-name 2552 | +--rw target-uri* inet:uri 2553 | +--rw alias-name* string 2554 | +--rw lifetime? int32 2555 | +--rw trigger-mitigation? boolean 2556 | +--ro mitigation-start? uint64 2557 | +--ro status? iana-signal:status 2558 | +--ro conflict-information 2559 | | +--ro conflict-status? iana-signal:conflict-status 2560 | | +--ro conflict-cause? iana-signal:conflict-cause 2561 | | +--ro retry-timer? uint32 2562 | | +--ro conflict-scope 2563 | | +--ro target-prefix* inet:ip-prefix 2564 | | +--ro target-port-range* [lower-port] 2565 | | | +--ro lower-port inet:port-number 2566 | | | +--ro upper-port? inet:port-number 2567 | | +--ro target-protocol* uint8 2568 | | +--ro target-fqdn* inet:domain-name 2569 | | +--ro target-uri* inet:uri 2570 | | +--ro alias-name* string 2571 | | +--ro acl-list* [acl-name] 2572 | | | +--ro acl-name 2573 | | | | -> /ietf-data:dots-data/dots-client/acls/ 2574 | | | | acl/name 2575 | | | +--ro acl-type? 2576 | | | -> /ietf-data:dots-data/dots-client/acls/ 2577 | | | acl/type 2578 | | +--ro mid? -> ../../../mid 2579 | +--ro bytes-dropped? yang:zero-based-counter64 2580 | +--ro bps-dropped? yang:gauge64 2581 | +--ro pkts-dropped? yang:zero-based-counter64 2582 | +--ro pps-dropped? yang:gauge64 2583 | +--rw attack-status? iana-signal:attack-status 2584 +--:(signal-config) 2585 | +--rw sid uint32 2586 | +--rw mitigating-config 2587 | | +--rw heartbeat-interval 2588 | | | +--ro max-value? uint16 2589 | | | +--ro min-value? uint16 2590 | | | +--rw current-value? uint16 2591 | | +--rw missing-hb-allowed 2592 | | | +--ro max-value? uint16 2593 | | | +--ro min-value? uint16 2594 | | | +--rw current-value? uint16 2595 | | +--rw max-retransmit 2596 | | | +--ro max-value? uint16 2597 | | | +--ro min-value? uint16 2598 | | | +--rw current-value? uint16 2599 | | +--rw ack-timeout 2600 | | | +--ro max-value-decimal? decimal64 2601 | | | +--ro min-value-decimal? decimal64 2602 | | | +--rw current-value-decimal? decimal64 2603 | | +--rw ack-random-factor 2604 | | +--ro max-value-decimal? decimal64 2605 | | +--ro min-value-decimal? decimal64 2606 | | +--rw current-value-decimal? decimal64 2607 | +--rw idle-config 2608 | +--rw heartbeat-interval 2609 | | +--ro max-value? uint16 2610 | | +--ro min-value? uint16 2611 | | +--rw current-value? uint16 2612 | +--rw missing-hb-allowed 2613 | | +--ro max-value? uint16 2614 | | +--ro min-value? uint16 2615 | | +--rw current-value? uint16 2616 | +--rw max-retransmit 2617 | | +--ro max-value? uint16 2618 | | +--ro min-value? uint16 2619 | | +--rw current-value? uint16 2620 | +--rw ack-timeout 2621 | | +--ro max-value-decimal? decimal64 2622 | | +--ro min-value-decimal? decimal64 2623 | | +--rw current-value-decimal? decimal64 2624 | +--rw ack-random-factor 2625 | +--ro max-value-decimal? decimal64 2626 | +--ro min-value-decimal? decimal64 2627 | +--rw current-value-decimal? decimal64 2628 +--:(redirected-signal) 2629 +--ro alt-server string 2630 +--ro alt-server-record* inet:ip-address 2632 5.2. IANA DOTS Signal Channel YANG Module 2634 file "iana-dots-signal-channel@2019-01-17.yang" 2635 module iana-dots-signal-channel { 2636 yang-version 1.1; 2637 namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel"; 2638 prefix iana-signal; 2639 organization 2640 "IANA"; 2641 contact 2642 "Internet Assigned Numbers Authority 2644 Postal: ICANN 2645 12025 Waterfront Drive, Suite 300 2646 Los Angeles, CA 90094-2536 2647 United States of America 2648 Tel: +1 310 301 5800 2649 "; 2650 description 2651 "This module contains a collection of YANG data types defined 2652 by IANA and used for DOTS signal channel protocol. 2654 Copyright (c) 2019 IETF Trust and the persons identified as 2655 authors of the code. All rights reserved. 2657 Redistribution and use in source and binary forms, with or 2658 without modification, is permitted pursuant to, and subject 2659 to the license terms contained in, the Simplified BSD License 2660 set forth in Section 4.c of the IETF Trust's Legal Provisions 2661 Relating to IETF Documents 2662 (http://trustee.ietf.org/license-info). 2664 This version of this YANG module is part of RFC XXXX; see 2665 the RFC itself for full legal notices."; 2667 revision 2019-01-17 { 2668 description 2669 "Initial revision."; 2670 reference 2671 "RFC XXXX: Distributed Denial-of-Service Open Threat 2672 Signaling (DOTS) Signal Channel Specification"; 2673 } 2675 typedef status { 2676 type enumeration { 2677 enum attack-mitigation-in-progress { 2678 value 1; 2679 description 2680 "Attack mitigation setup is in progress (e.g., changing 2681 the network path to re-route the inbound traffic 2682 to DOTS mitigator)."; 2683 } 2684 enum attack-successfully-mitigated { 2685 value 2; 2686 description 2687 "Attack is being successfully mitigated (e.g., traffic 2688 is redirected to a DDoS mitigator and attack 2689 traffic is dropped or blackholed)."; 2690 } 2691 enum attack-stopped { 2692 value 3; 2693 description 2694 "Attack has stopped and the DOTS client can 2695 withdraw the mitigation request."; 2696 } 2697 enum attack-exceeded-capability { 2698 value 4; 2699 description 2700 "Attack has exceeded the mitigation provider 2701 capability."; 2702 } 2703 enum dots-client-withdrawn-mitigation { 2704 value 5; 2705 description 2706 "DOTS client has withdrawn the mitigation 2707 request and the mitigation is active but 2708 terminating."; 2709 } 2710 enum attack-mitigation-terminated { 2711 value 6; 2712 description 2713 "Attack mitigation is now terminated."; 2714 } 2715 enum attack-mitigation-withdrawn { 2716 value 7; 2717 description 2718 "Attack mitigation is withdrawn."; 2719 } 2720 enum attack-mitigation-signal-loss { 2721 value 8; 2722 description 2723 "Attack mitigation will be triggered 2724 for the mitigation request only when 2725 the DOTS signal channel session is lost."; 2726 } 2727 } 2728 description 2729 "Enumeration for status reported by the DOTS server."; 2730 } 2732 typedef conflict-status { 2733 type enumeration { 2734 enum request-inactive-other-active { 2735 value 1; 2736 description 2737 "DOTS Server has detected conflicting mitigation 2738 requests from different DOTS clients. 2739 This mitigation request is currently inactive 2740 until the conflicts are resolved. Another 2741 mitigation request is active."; 2742 } 2743 enum request-active { 2744 value 2; 2745 description 2746 "DOTS Server has detected conflicting mitigation 2747 requests from different DOTS clients. 2748 This mitigation request is currently active."; 2749 } 2750 enum all-requests-inactive { 2751 value 3; 2752 description 2753 "DOTS Server has detected conflicting mitigation 2754 requests from different DOTS clients. All 2755 conflicting mitigation requests are inactive."; 2756 } 2757 } 2758 description 2759 "Enumeration for conflict status."; 2760 } 2762 typedef conflict-cause { 2763 type enumeration { 2764 enum overlapping-targets { 2765 value 1; 2766 description 2767 "Overlapping targets. conflict-scope provides 2768 more details about the exact conflict."; 2769 } 2770 enum conflict-with-acceptlist { 2771 value 2; 2772 description 2773 "Conflicts with an existing accept-list. 2775 This code is returned when the DDoS mitigation 2776 detects that some of the source addresses/prefixes 2777 listed in the accept-list ACLs are actually 2778 attacking the target."; 2779 } 2780 enum cuid-collision { 2781 value 3; 2782 description 2783 "Conflicts with the cuid used by another 2784 DOTS client."; 2785 } 2786 } 2787 description 2788 "Enumeration for conflict causes."; 2789 } 2791 typedef attack-status { 2792 type enumeration { 2793 enum under-attack { 2794 value 1; 2795 description 2796 "The DOTS client determines that it is still under 2797 attack."; 2798 } 2799 enum attack-successfully-mitigated { 2800 value 2; 2801 description 2802 "The DOTS client determines that the attack is 2803 successfully mitigated."; 2804 } 2805 } 2806 description 2807 "Enumeration for attack status codes."; 2808 } 2809 } 2810 2812 5.3. IETF DOTS Signal Channel YANG Module 2814 This module uses the common YANG types defined in [RFC6991] and types 2815 defined in [I-D.ietf-dots-data-channel]. 2817 file "ietf-dots-signal-channel@2019-01-17.yang" 2818 module ietf-dots-signal-channel { 2819 yang-version 1.1; 2820 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; 2821 prefix signal; 2823 import ietf-inet-types { 2824 prefix inet; 2825 reference "Section 4 of RFC 6991"; 2826 } 2827 import ietf-yang-types { 2828 prefix yang; 2829 reference "Section 3 of RFC 6991"; 2830 } 2831 import ietf-dots-data-channel { 2832 prefix ietf-data; 2833 reference 2834 "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling 2835 (DOTS) Data Channel Specification"; 2836 } 2837 import iana-dots-signal-channel { 2838 prefix iana-signal; 2839 } 2841 organization 2842 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 2843 contact 2844 "WG Web: 2845 WG List: 2847 Editor: Konda, Tirumaleswar Reddy 2848 2850 Editor: Mohamed Boucadair 2851 2853 Author: Prashanth Patil 2854 2856 Author: Andrew Mortensen 2857 2859 Author: Nik Teague 2860 "; 2861 description 2862 "This module contains YANG definition for the signaling 2863 messages exchanged between a DOTS client and a DOTS server. 2865 Copyright (c) 2019 IETF Trust and the persons identified as 2866 authors of the code. All rights reserved. 2868 Redistribution and use in source and binary forms, with or 2869 without modification, is permitted pursuant to, and subject 2870 to the license terms contained in, the Simplified BSD License 2871 set forth in Section 4.c of the IETF Trust's Legal Provisions 2872 Relating to IETF Documents 2873 (http://trustee.ietf.org/license-info). 2875 This version of this YANG module is part of RFC XXXX; see 2876 the RFC itself for full legal notices."; 2878 revision 2019-01-17 { 2879 description 2880 "Initial revision."; 2881 reference 2882 "RFC XXXX: Distributed Denial-of-Service Open Threat 2883 Signaling (DOTS) Signal Channel Specification"; 2884 } 2886 /* 2887 * Groupings 2888 */ 2890 grouping mitigation-scope { 2891 description 2892 "Specifies the scope of the mitigation request."; 2893 list scope { 2894 key "cuid mid"; 2895 description 2896 "The scope of the request."; 2897 leaf cdid { 2898 type string; 2899 description 2900 "The cdid should be included by a server-domain 2901 DOTS gateway to propagate the client domain 2902 identification information from the 2903 gateway's client-facing-side to the gateway's 2904 server-facing-side, and from the gateway's 2905 server-facing-side to the DOTS server. 2907 It may be used by the final DOTS server 2908 for policy enforcement purposes."; 2909 } 2910 leaf cuid { 2911 type string; 2912 description 2913 "A unique identifier that is 2914 generated by a DOTS client to prevent 2915 request collisions. It is expected that the 2916 cuid will remain consistent throughout the 2917 lifetime of the DOTS client."; 2918 } 2919 leaf mid { 2920 type uint32; 2921 description 2922 "Mitigation request identifier. 2924 This identifier must be unique for each mitigation 2925 request bound to the DOTS client."; 2926 } 2927 uses ietf-data:target; 2928 leaf-list alias-name { 2929 type string; 2930 description 2931 "An alias name that points to a resource."; 2932 } 2933 leaf lifetime { 2934 type int32; 2935 units "seconds"; 2936 default "3600"; 2937 description 2938 "Indicates the lifetime of the mitigation request. 2940 A lifetime of '0' in a mitigation request is an 2941 invalid value. 2943 A lifetime of negative one (-1) indicates indefinite 2944 lifetime for the mitigation request."; 2945 } 2946 leaf trigger-mitigation { 2947 type boolean; 2948 default "true"; 2949 description 2950 "If set to 'false', DDoS mitigation will not be 2951 triggered unless the DOTS signal channel 2952 session is lost."; 2953 } 2954 leaf mitigation-start { 2955 type uint64; 2956 config false; 2957 description 2958 "Mitigation start time is represented in seconds 2959 relative to 1970-01-01T00:00:00Z in UTC time."; 2960 } 2961 leaf status { 2962 type iana-signal:status; 2963 config false; 2964 description 2965 "Indicates the status of a mitigation request. 2966 It must be included in responses only."; 2967 } 2968 container conflict-information { 2969 config false; 2970 description 2971 "Indicates that a conflict is detected. 2972 Must only be used for responses."; 2973 leaf conflict-status { 2974 type iana-signal:conflict-status; 2975 description 2976 "Indicates the conflict status."; 2977 } 2978 leaf conflict-cause { 2979 type iana-signal:conflict-cause; 2980 description 2981 "Indicates the cause of the conflict."; 2982 } 2983 leaf retry-timer { 2984 type uint32; 2985 units "seconds"; 2986 description 2987 "The DOTS client must not re-send the 2988 same request that has a conflict before the expiry of 2989 this timer."; 2990 } 2991 container conflict-scope { 2992 description 2993 "Provides more information about the conflict scope."; 2994 uses ietf-data:target { 2995 when "../conflict-cause = 'overlapping-targets'"; 2996 } 2997 leaf-list alias-name { 2998 when "../../conflict-cause = 'overlapping-targets'"; 2999 type string; 3000 description 3001 "Conflicting alias-name."; 3002 } 3003 list acl-list { 3004 when "../../conflict-cause = 'conflict-with-acceptlist'"; 3005 key "acl-name"; 3006 description 3007 "List of conflicting ACLs as defined in the DOTS data 3008 channel. These ACLs are uniquely defined by 3009 cuid and acl-name."; 3010 leaf acl-name { 3011 type leafref { 3012 path "/ietf-data:dots-data/ietf-data:dots-client/" 3013 + "ietf-data:acls/ietf-data:acl/ietf-data:name"; 3014 } 3015 description 3016 "Reference to the conflicting ACL name bound to 3017 a DOTS client."; 3018 } 3019 leaf acl-type { 3020 type leafref { 3021 path "/ietf-data:dots-data/ietf-data:dots-client/" 3022 + "ietf-data:acls/ietf-data:acl/ietf-data:type"; 3024 } 3025 description 3026 "Reference to the conflicting ACL type bound to 3027 a DOTS client."; 3028 } 3029 } 3030 leaf mid { 3031 when "../../conflict-cause = 'overlapping-targets'"; 3032 type leafref { 3033 path "../../../mid"; 3034 } 3035 description 3036 "Reference to the conflicting 'mid' bound to 3037 the same DOTS client."; 3038 } 3039 } 3040 } 3041 leaf bytes-dropped { 3042 type yang:zero-based-counter64; 3043 units "bytes"; 3044 config false; 3045 description 3046 "The total dropped byte count for the mitigation 3047 request since the attack mitigation is triggered. 3048 The count wraps around when it reaches the maximum value 3049 of counter64 for dropped bytes."; 3050 } 3051 leaf bps-dropped { 3052 type yang:gauge64; 3053 config false; 3054 description 3055 "The average number of dropped bits per second for 3056 the mitigation request since the attack 3057 mitigation is triggered. This should be over 3058 five-minute intervals (that is, measuring bytes 3059 into five-minute buckets and then averaging these 3060 buckets over the time since the mitigation was 3061 triggered)."; 3062 } 3063 leaf pkts-dropped { 3064 type yang:zero-based-counter64; 3065 config false; 3066 description 3067 "The total number of dropped packet count for the 3068 mitigation request since the attack mitigation is 3069 triggered. The count wraps around when it reaches 3070 the maximum value of counter64 for dropped packets."; 3071 } 3072 leaf pps-dropped { 3073 type yang:gauge64; 3074 config false; 3075 description 3076 "The average number of dropped packets per second 3077 for the mitigation request since the attack 3078 mitigation is triggered. This should be over 3079 five-minute intervals (that is, measuring packets 3080 into five-minute buckets and then averaging these 3081 buckets over the time since the mitigation was 3082 triggered)."; 3083 } 3084 leaf attack-status { 3085 type iana-signal:attack-status; 3086 description 3087 "Indicates the status of an attack as seen by the 3088 DOTS client."; 3089 } 3090 } 3091 } 3093 grouping config-parameters { 3094 description 3095 "Subset of DOTS signal channel session configuration."; 3096 container heartbeat-interval { 3097 description 3098 "DOTS agents regularly send heartbeats to each other 3099 after mutual authentication is successfully 3100 completed in order to keep the DOTS signal channel 3101 open."; 3102 leaf max-value { 3103 type uint16; 3104 units "seconds"; 3105 config false; 3106 description 3107 "Maximum acceptable heartbeat-interval value."; 3108 } 3109 leaf min-value { 3110 type uint16; 3111 units "seconds"; 3112 config false; 3113 description 3114 "Minimum acceptable heartbeat-interval value."; 3115 } 3116 leaf current-value { 3117 type uint16; 3118 units "seconds"; 3119 default "30"; 3120 description 3121 "Current heartbeat-interval value. 3123 '0' means that heartbeat mechanism is deactivated."; 3124 } 3125 } 3126 container missing-hb-allowed { 3127 description 3128 "Maximum number of missing heartbeats allowed."; 3129 leaf max-value { 3130 type uint16; 3131 config false; 3132 description 3133 "Maximum acceptable missing-hb-allowed value."; 3134 } 3135 leaf min-value { 3136 type uint16; 3137 config false; 3138 description 3139 "Minimum acceptable missing-hb-allowed value."; 3140 } 3141 leaf current-value { 3142 type uint16; 3143 default "5"; 3144 description 3145 "Current missing-hb-allowed value."; 3146 } 3147 } 3148 container max-retransmit { 3149 description 3150 "Maximum number of retransmissions of a Confirmable 3151 message."; 3152 leaf max-value { 3153 type uint16; 3154 config false; 3155 description 3156 "Maximum acceptable max-retransmit value."; 3157 } 3158 leaf min-value { 3159 type uint16; 3160 config false; 3161 description 3162 "Minimum acceptable max-retransmit value."; 3163 } 3164 leaf current-value { 3165 type uint16; 3166 default "3"; 3167 description 3168 "Current max-retransmit value."; 3169 } 3170 } 3171 container ack-timeout { 3172 description 3173 "Initial retransmission timeout value."; 3174 leaf max-value-decimal { 3175 type decimal64 { 3176 fraction-digits 2; 3177 } 3178 units "seconds"; 3179 config false; 3180 description 3181 "Maximum ack-timeout value."; 3182 } 3183 leaf min-value-decimal { 3184 type decimal64 { 3185 fraction-digits 2; 3186 } 3187 units "seconds"; 3188 config false; 3189 description 3190 "Minimum ack-timeout value."; 3191 } 3192 leaf current-value-decimal { 3193 type decimal64 { 3194 fraction-digits 2; 3195 } 3196 units "seconds"; 3197 default "2"; 3198 description 3199 "Current ack-timeout value."; 3200 } 3201 } 3202 container ack-random-factor { 3203 description 3204 "Random factor used to influence the timing of 3205 retransmissions."; 3206 leaf max-value-decimal { 3207 type decimal64 { 3208 fraction-digits 2; 3209 } 3210 config false; 3211 description 3212 "Maximum acceptable ack-random-factor value."; 3213 } 3214 leaf min-value-decimal { 3215 type decimal64 { 3216 fraction-digits 2; 3217 } 3218 config false; 3219 description 3220 "Minimum acceptable ack-random-factor value."; 3221 } 3222 leaf current-value-decimal { 3223 type decimal64 { 3224 fraction-digits 2; 3225 } 3226 default "1.5"; 3227 description 3228 "Current ack-random-factor value."; 3229 } 3230 } 3231 } 3233 grouping signal-config { 3234 description 3235 "DOTS signal channel session configuration."; 3236 leaf sid { 3237 type uint32; 3238 mandatory true; 3239 description 3240 "An identifier for the DOTS signal channel 3241 session configuration data."; 3242 } 3243 container mitigating-config { 3244 description 3245 "Configuration parameters to use when a mitigation 3246 is active."; 3247 uses config-parameters; 3248 } 3249 container idle-config { 3250 description 3251 "Configuration parameters to use when no mitigation 3252 is active."; 3253 uses config-parameters; 3254 } 3255 } 3257 grouping redirected-signal { 3258 description 3259 "Grouping for the redirected signaling."; 3260 leaf alt-server { 3261 type string; 3262 config false; 3263 mandatory true; 3264 description 3265 "FQDN of an alternate server."; 3266 } 3267 leaf-list alt-server-record { 3268 type inet:ip-address; 3269 config false; 3270 description 3271 "List of records for the alternate server."; 3272 } 3273 } 3275 /* 3276 * Main Container for DOTS Signal Channel 3277 */ 3279 container dots-signal { 3280 description 3281 "Main container for DOTS signal message. 3283 A DOTS signal message can be a mitigation, a configuration, 3284 or a redirected signal message."; 3285 choice message-type { 3286 description 3287 "Can be a mitigation, a configuration, or a redirect 3288 message."; 3289 case mitigation-scope { 3290 description 3291 "Mitigation scope of a mitigation message."; 3292 uses mitigation-scope; 3293 } 3294 case signal-config { 3295 description 3296 "Configuration message."; 3297 uses signal-config; 3298 } 3299 case redirected-signal { 3300 description 3301 "Redirected signaling."; 3302 uses redirected-signal; 3303 } 3304 } 3305 } 3306 } 3307 3309 6. YANG/JSON Mapping Parameters to CBOR 3311 All parameters in the payload of the DOTS signal channel MUST be 3312 mapped to CBOR types as shown in Table 4 and are assigned an integer 3313 key to save space. 3315 o Note: Implementers must check that the mapping output provided by 3316 their YANG-to-CBOR encoding schemes is aligned with the content of 3317 Table 4. 3319 The CBOR key values are divided into two types: comprehension- 3320 required and comprehension-optional. DOTS agents can safely ignore 3321 comprehension-optional values they don't understand, but cannot 3322 successfully process a request if it contains comprehension-required 3323 values that are not understood. The 4.00 response SHOULD include a 3324 diagnostic payload describing the unknown comprehension-required CBOR 3325 key values. The initial set of CBOR key values defined in this 3326 specification are of type comprehension-required. 3328 +----------------------+-------------+-----+---------------+--------+ 3329 | Parameter Name | YANG | CBOR| CBOR Major | JSON | 3330 | | Type | Key | Type & | Type | 3331 | | | | Information | | 3332 +----------------------+-------------+-----+---------------+--------+ 3333 | ietf-dots-signal-cha | | | | | 3334 | nnel:mitigation-scope| container | 1 | 5 map | Object | 3335 | scope | list | 2 | 4 array | Array | 3336 | cdid | string | 3 | 3 text string | String | 3337 | cuid | string | 4 | 3 text string | String | 3338 | mid | uint32 | 5 | 0 unsigned | Number | 3339 | target-prefix | leaf-list | 6 | 4 array | Array | 3340 | | inet: | | | | 3341 | | ip-prefix | | 3 text string | String | 3342 | target-port-range | list | 7 | 4 array | Array | 3343 | lower-port | inet: | | | | 3344 | | port-number| 8 | 0 unsigned | Number | 3345 | upper-port | inet: | | | | 3346 | | port-number| 9 | 0 unsigned | Number | 3347 | target-protocol | leaf-list | 10 | 4 array | Array | 3348 | | uint8 | | 0 unsigned | Number | 3349 | target-fqdn | leaf-list | 11 | 4 array | Array | 3350 | | inet: | | | | 3351 | | domain-name| | 3 text string | String | 3352 | target-uri | leaf-list | 12 | 4 array | Array | 3353 | | inet:uri | | 3 text string | String | 3354 | alias-name | leaf-list | 13 | 4 array | Array | 3355 | | string | | 3 text string | String | 3356 | lifetime | int32 | 14 | 0 unsigned | Number | 3357 | | | | 1 negative | Number | 3358 | mitigation-start | uint64 | 15 | 0 unsigned | String | 3359 | status | enumeration | 16 | 0 unsigned | String | 3360 | conflict-information | container | 17 | 5 map | Object | 3361 | conflict-status | enumeration | 18 | 0 unsigned | String | 3362 | conflict-cause | enumeration | 19 | 0 unsigned | String | 3363 | retry-timer | uint32 | 20 | 0 unsigned | Number | 3364 | conflict-scope | container | 21 | 5 map | Object | 3365 | acl-list | list | 22 | 4 array | Array | 3366 | acl-name | leafref | 23 | 3 text string | String | 3367 | acl-type | leafref | 24 | 3 text string | String | 3368 | bytes-dropped | yang:zero- | | | | 3369 | | based- | | | | 3370 | | counter64 | 25 | 0 unsigned | String | 3371 | bps-dropped | yang:gauge64| 26 | 0 unsigned | String | 3372 | pkts-dropped | yang:zero- | | | | 3373 | | based- | | | | 3374 | | counter64 | 27 | 0 unsigned | String | 3375 | pps-dropped | yang:gauge64| 28 | 0 unsigned | String | 3376 | attack-status | enumeration | 29 | 0 unsigned | String | 3377 | ietf-dots-signal- | | | | | 3378 | channel:signal-config| container | 30 | 5 map | Object | 3379 | sid | uint32 | 31 | 0 unsigned | Number | 3380 | mitigating-config | container | 32 | 5 map | Object | 3381 | heartbeat-interval | container | 33 | 5 map | Object | 3382 | max-value | uint16 | 34 | 0 unsigned | Number | 3383 | min-value | uint16 | 35 | 0 unsigned | Number | 3384 | current-value | uint16 | 36 | 0 unsigned | Number | 3385 | missing-hb-allowed | container | 37 | 5 map | Object | 3386 | max-retransmit | container | 38 | 5 map | Object | 3387 | ack-timeout | container | 39 | 5 map | Object | 3388 | ack-random-factor | container | 40 | 5 map | Object | 3389 | max-value-decimal | decimal64 | 41 | 6 tag 4 | | 3390 | | | | [-2, integer]| String | 3391 | min-value-decimal | decimal64 | 42 | 6 tag 4 | | 3392 | | | | [-2, integer]| String | 3393 | current-value-decimal| decimal64 | 43 | 6 tag 4 | | 3394 | | | | [-2, integer]| String | 3395 | idle-config | container | 44 | 5 map | Object | 3396 | trigger-mitigation | boolean | 45 | 7 bits 20 | False | 3397 | | | | 7 bits 21 | True | 3398 | ietf-dots-signal-cha | | | | | 3399 |nnel:redirected-signal| container | 46 | 5 map | Object | 3400 | alt-server | string | 47 | 3 text string | String | 3401 | alt-server-record | leaf-list | 48 | 4 array | Array | 3402 | | inet: | | | | 3403 | | ip-address | | 3 text string | String | 3404 +----------------------+-------------+-----+---------------+--------+ 3405 Table 4: CBOR Key Values Used in DOTS Signal Channel Messages & Their 3406 Mappings to JSON and YANG 3408 7. (D)TLS Protocol Profile and Performance Considerations 3410 7.1. (D)TLS Protocol Profile 3412 This section defines the (D)TLS protocol profile of DOTS signal 3413 channel over (D)TLS and DOTS data channel over TLS. 3415 There are known attacks on (D)TLS, such as man-in-the-middle and 3416 protocol downgrade attacks. These are general attacks on (D)TLS and, 3417 as such, they are not specific to DOTS over (D)TLS; refer to the 3418 (D)TLS RFCs for discussion of these security issues. DOTS agents 3419 MUST adhere to the (D)TLS implementation recommendations and security 3420 considerations of [RFC7525] except with respect to (D)TLS version. 3421 Since DOTS signal channel encryption relying upon (D)TLS is virtually 3422 a green-field deployment, DOTS agents MUST implement only (D)TLS 1.2 3423 or later. 3425 When a DOTS client is configured with a domain name of the DOTS 3426 server, and connects to its configured DOTS server, the server may 3427 present it with a PKIX certificate. In order to ensure proper 3428 authentication, a DOTS client MUST verify the entire certification 3429 path per [RFC5280]. Additionally, the DOTS client MUST use [RFC6125] 3430 validation techniques to compare the domain name with the certificate 3431 provided. Certification authorities that issue DOTS server 3432 certificates SHOULD support the DNS-ID and SRV-ID identifier types. 3433 DOTS server SHOULD prefer the use of DNS-ID and SRV-ID over CN-ID 3434 identifier types in certificate requests (as described in Section 2.3 3435 of [RFC6125]) and the wildcard character '*' SHOULD NOT be included 3436 in the presented identifier. DOTS doesn't use URI-IDs for server 3437 identity verification. 3439 A key challenge to deploying DOTS is the provisioning of DOTS 3440 clients, including the distribution of keying material to DOTS 3441 clients to enable the required mutual authentication of DOTS agents. 3442 Enrollment over Secure Transport (EST) [RFC7030] defines a method of 3443 certificate enrollment by which domains operating DOTS servers may 3444 provide DOTS clients with all the necessary cryptographic keying 3445 material, including a private key and a certificate to authenticate 3446 themselves. One deployment option is DOTS clients behave as EST 3447 clients for certificate enrollment from an EST server provisioned by 3448 the mitigation provider. This document does not specify which EST or 3449 other mechanism the DOTS client uses to achieve initial enrollment. 3451 The Server Name Indication (SNI) extension [RFC6066] defines a 3452 mechanism for a client to tell a (D)TLS server the name of the server 3453 it wants to contact. This is a useful extension for hosting 3454 environments where multiple virtual servers are reachable over a 3455 single IP address. The DOTS client may or may not know if it is 3456 interacting with a DOTS server in a virtual server hosting 3457 environment, so the DOTS client SHOULD include the DOTS server FQDN 3458 in the SNI extension. 3460 Implementations compliant with this profile MUST implement all of the 3461 following items: 3463 o DTLS record replay detection (Section 3.3 of [RFC6347]) or an 3464 equivalent mechanism to protect against replay attacks. 3466 o DTLS session resumption without server-side state to resume 3467 session and convey the DOTS signal. 3469 o At least one of raw public keys [RFC7250] or PSK handshake 3470 [RFC4279] with (EC)DHE key exchange which reduces the size of the 3471 ServerHello, and can be used by DOTS agents that cannot obtain 3472 certificates. 3474 Implementations compliant with this profile SHOULD implement all of 3475 the following items to reduce the delay required to deliver a DOTS 3476 signal channel message: 3478 o TLS False Start [RFC7918] which reduces round-trips by allowing 3479 the TLS client's second flight of messages (ChangeCipherSpec) to 3480 also contain the DOTS signal. TLS False Start is formally defined 3481 for use with TLS, but the same technique is applicable to DTLS as 3482 well. 3484 o Cached Information Extension [RFC7924] which avoids transmitting 3485 the server's certificate and certificate chain if the client has 3486 cached that information from a previous TLS handshake. 3488 Compared to UDP, DOTS signal channel over TCP requires an additional 3489 round-trip time (RTT) of latency to establish a TCP connection. DOTS 3490 implementations are encouraged to implement TCP Fast Open [RFC7413] 3491 to eliminate that RTT. 3493 7.2. (D)TLS 1.3 Considerations 3495 TLS 1.3 provides critical latency improvements for connection 3496 establishment over TLS 1.2. The DTLS 1.3 protocol 3497 [I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides 3498 equivalent security guarantees. (D)TLS 1.3 provides two basic 3499 handshake modes the DOTS signal channel can take advantage of: 3501 o A full handshake mode in which a DOTS client can send a DOTS 3502 mitigation request message after one round trip and the DOTS 3503 server immediately responds with a DOTS mitigation response. This 3504 assumes no packet loss is experienced. 3506 o 0-RTT mode in which the DOTS client can authenticate itself and 3507 send DOTS mitigation request messages in the first message, thus 3508 reducing handshake latency. 0-RTT only works if the DOTS client 3509 has previously communicated with that DOTS server, which is very 3510 likely with the DOTS signal channel. 3512 The DOTS client has to establish a (D)TLS session with the DOTS 3513 server during 'idle' time and share a PSK. 3515 During a DDoS attack, the DOTS client can use the (D)TLS session 3516 to convey the DOTS mitigation request message and, if there is no 3517 response from the server after multiple retries, the DOTS client 3518 can resume the (D)TLS session in 0-RTT mode using PSK. 3520 DOTS servers that support (D)TLS 1.3 MAY allow DOTS clients to 3521 send early data (0-RTT). DOTS clients MUST NOT send "CoAP Ping" 3522 as early data; such messages MUST be rejected by DOTS servers. 3523 Section 8 of [RFC8446] discusses some mechanisms to implement to 3524 limit the impact of replay attacks on 0-RTT data. If the DOTS 3525 server accepts 0-RTT, it MUST implement one of these mechanisms to 3526 prevent replay at the TLS layer. A DOTS server can reject 0-RTT 3527 by sending a TLS HelloRetryRequest. 3529 The DOTS signal channel messages sent as early data by the DOTS 3530 client are idempotent requests. As a reminder, the Message ID 3531 (Section 3 of [RFC7252]) is changed each time a new CoAP request 3532 is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized 3533 in each CoAP request. The DOTS server(s) MUST use the Message ID 3534 and the Token in the DOTS signal channel message to detect replay 3535 of early data at the application layer, and accept 0-RTT data at 3536 most once from the same DOTS client. This anti-replay defense 3537 requires sharing the Message ID and the Token in the 0-RTT data 3538 between DOTS servers in the DOTS server domain. DOTS servers do 3539 not rely on transport coordinates to identify DOTS peers. As 3540 specified in Section 4.4.1, DOTS servers couple the DOTS signal 3541 channel sessions using the DOTS client identity and optionally the 3542 'cdid' parameter value. Furthermore, 'mid' value is monotonically 3543 increased by the DOTS client for each mitigation request, 3544 attackers replaying mitigation requests with lower numeric 'mid' 3545 values and overlapping scopes with mitigation requests having 3546 higher numeric 'mid' values will be rejected systematically by the 3547 DOTS server. Likewise, 'sid' value is monotonically increased by 3548 the DOTS client for each configuration request (Section 4.5.2), 3549 attackers replaying configuration requests with lower numeric 3550 'sid' values will be rejected by the DOTS server if it maintains a 3551 higher numeric 'sid' value for this DOTS client. 3553 Owing to the aforementioned protections, all DOTS signal channel 3554 requests are safe to transmit in TLS 1.3 as early data. Refer to 3555 [I-D.boucadair-dots-earlydata] for more details. 3557 A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request 3558 message exchange is shown in Figure 27. 3560 DOTS Client DOTS Server 3562 ClientHello 3563 (0-RTT DOTS signal message) 3564 --------> 3565 ServerHello 3566 {EncryptedExtensions} 3567 {Finished} 3568 <-------- [DOTS signal message] 3569 (end_of_early_data) 3570 {Finished} --------> 3571 [DOTS signal message] <-------> [DOTS signal message] 3573 Note that: 3574 () Indicates messages protected 0-RTT keys 3575 {} Indicates messages protected using handshake keys 3576 [] Indicates messages protected using 1-RTT keys 3578 Figure 27: A Simplified TLS 1.3 Handshake with 0-RTT 3580 7.3. DTLS MTU and Fragmentation 3582 To avoid DOTS signal message fragmentation and the subsequent 3583 decreased probability of message delivery, DOTS agents MUST ensure 3584 that the DTLS record fit within a single datagram. If the PMTU 3585 cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, 3586 as IPv6 requires that every link in the Internet have an MTU of 1280 3587 octets or greater as specified in [RFC8200]. If IPv4 support on 3588 legacy or otherwise unusual networks is a consideration and the PMTU 3589 is unknown, DOTS implementations MAY assume on a PMTU of 576 bytes 3590 for IPv4 datagrams, as every IPv4 host must be capable of receiving a 3591 packet whose length is equal to 576 bytes as discussed in [RFC0791] 3592 and [RFC1122]. 3594 The DOTS client must consider the amount of record expansion expected 3595 by the DTLS processing when calculating the size of CoAP message that 3596 fits within the path MTU. Path MTU MUST be greater than or equal to 3598 [CoAP message size + DTLS 1.2 overhead of 13 octets + authentication 3599 overhead of the negotiated DTLS cipher suite + block padding] 3600 (Section 4.1.1.1 of [RFC6347]). If the total request size exceeds 3601 the path MTU then the DOTS client MUST split the DOTS signal into 3602 separate messages; for example, the list of addresses in the 'target- 3603 prefix' parameter could be split into multiple lists and each list 3604 conveyed in a new PUT request. 3606 Implementation Note: DOTS choice of message size parameters works 3607 well with IPv6 and with most of today's IPv4 paths. However, with 3608 IPv4, it is harder to safely make sure that there is no IP 3609 fragmentation. If the IPv4 path MTU is unknown, implementations may 3610 want to limit themselves to more conservative IPv4 datagram sizes 3611 such as 576 bytes, as per [RFC0791]. 3613 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 3615 (D)TLS based upon client certificate can be used for mutual 3616 authentication between DOTS agents. If, for example, a DOTS gateway 3617 is involved, DOTS clients and DOTS gateways must perform mutual 3618 authentication; only authorized DOTS clients are allowed to send DOTS 3619 signals to a DOTS gateway. The DOTS gateway and the DOTS server must 3620 perform mutual authentication; a DOTS server only allows DOTS signal 3621 channel messages from an authorized DOTS gateway, thereby creating a 3622 two-link chain of transitive authentication between the DOTS client 3623 and the DOTS server. 3625 The DOTS server should support certificate-based client 3626 authentication. The DOTS client should respond to the DOTS server's 3627 TLS CertificateRequest message with the PKIX certificate held by the 3628 DOTS client. DOTS client certificate validation must be performed as 3629 per [RFC5280] and the DOTS client certificate must conform to the 3630 [RFC5280] certificate profile. If a DOTS client does not support TLS 3631 client certificate authentication, it must support pre-shared key 3632 based or raw public key based client authentication. 3634 +-----------------------------------------------+ 3635 | example.com domain +---------+ | 3636 | | AAA | | 3637 | +---------------+ | Server | | 3638 | | Application | +------+--+ | 3639 | | server +<-----------------+ ^ | 3640 | | (DOTS client) | | | | 3641 | +---------------+ | | | 3642 | V V | example.net domain 3643 | +-----+----+--+ | +---------------+ 3644 | +--------------+ | | | | | 3645 | | Guest +<-----x----->+ DOTS +<------>+ DOTS | 3646 | | (DOTS client)| | gateway | | | server | 3647 | +--------------+ | | | | | 3648 | +----+--------+ | +---------------+ 3649 | ^ | 3650 | | | 3651 | +----------------+ | | 3652 | | DDoS detector | | | 3653 | | (DOTS client) +<---------------+ | 3654 | +----------------+ | 3655 +-----------------------------------------------+ 3657 Figure 28: Example of Authentication and Authorization of DOTS Agents 3659 In the example depicted in Figure 28, the DOTS gateway and DOTS 3660 clients within the 'example.com' domain mutually authenticate. After 3661 the DOTS gateway validates the identity of a DOTS client, it 3662 communicates with the AAA server in the 'example.com' domain to 3663 determine if the DOTS client is authorized to request DDoS 3664 mitigation. If the DOTS client is not authorized, a 4.01 3665 (Unauthorized) is returned in the response to the DOTS client. In 3666 this example, the DOTS gateway only allows the application server and 3667 DDoS attack detector to request DDoS mitigation, but does not permit 3668 the user of type 'guest' to request DDoS mitigation. 3670 Also, DOTS gateways and servers located in different domains must 3671 perform mutual authentication (e.g., using certificates). A DOTS 3672 server will only allow a DOTS gateway with a certificate for a 3673 particular domain to request mitigation for that domain. In 3674 reference to Figure 28, the DOTS server only allows the DOTS gateway 3675 to request mitigation for 'example.com' domain and not for other 3676 domains. 3678 9. IANA Considerations 3680 9.1. DOTS Signal Channel UDP and TCP Port Number 3682 IANA is requested to assign the port number TBD to the DOTS signal 3683 channel protocol for both UDP and TCP from the "Service Name and 3684 Transport Protocol Port Number Registry" available at 3685 https://www.iana.org/assignments/service-names-port-numbers/service- 3686 names-port-numbers.xhtml. 3688 The assignment of port number 4646 is strongly suggested, as 4646 is 3689 the ASCII decimal value for ".." (DOTS). 3691 9.2. Well-Known 'dots' URI 3693 This document requests IANA to register the 'dots' well-known URI 3694 (Table 5) in the Well-Known URIs registry 3695 (https://www.iana.org/assignments/well-known-uris/well-known- 3696 uris.xhtml) as defined by [RFC5785]: 3698 +----------+----------------+---------------------+-----------------+ 3699 | URI | Change | Specification | Related | 3700 | suffix | controller | document(s) | information | 3701 +----------+----------------+---------------------+-----------------+ 3702 | dots | IETF | [RFCXXXX] | None | 3703 +----------+----------------+---------------------+-----------------+ 3705 Table 5: 'dots' well-known URI 3707 9.3. Media Type Registration 3709 This document requests IANA to register the "application/dots+cbor" 3710 media type in the "Media Types" registry [IANA.MediaTypes] in the 3711 manner described in [RFC6838], which can be used to indicate that the 3712 content is a DOTS signal channel object: 3714 o Type name: application 3715 o Subtype name: dots+cbor 3716 o Required parameters: N/A 3717 o Optional parameters: N/A 3718 o Encoding considerations: binary 3719 o Security considerations: See the Security Considerations section 3720 of [RFCXXXX] 3721 o Interoperability considerations: N/A 3722 o Published specification: [RFCXXXX] 3723 o Applications that use this media type: DOTS agents sending DOTS 3724 messages over CoAP over (D)TLS. 3725 o Fragment identifier considerations: N/A 3726 o Additional information: 3728 Magic number(s): N/A 3729 File extension(s): N/A 3730 Macintosh file type code(s): N/A 3731 o Person & email address to contact for further information: 3732 IESG, iesg@ietf.org 3733 o Intended usage: COMMON 3734 o Restrictions on usage: none 3735 o Author: See Authors' Addresses section. 3736 o Change controller: IESG 3737 o Provisional registration? No 3739 9.4. CoAP Content-Formats Registration 3741 This document requests IANA to register the CoAP Content-Format ID 3742 for the "application/dots+cbor" media type in the "CoAP Content- 3743 Formats" registry [IANA.CoAP.Content-Formats] (0-255 range): 3745 o Media Type: application/dots+cbor 3746 o Encoding: - 3747 o Id: TBD1 3748 o Reference: [RFCXXXX] 3750 9.5. CBOR Tag Registration 3752 This section defines the DOTS CBOR tag as another means for 3753 applications to declare that a CBOR data structure is a DOTS signal 3754 channel object. Its use is optional and is intended for use in cases 3755 in which this information would not otherwise be known. DOTS CBOR 3756 tag is not required for DOTS signal channel protocol version 3757 specified in this document. If present, the DOTS tag MUST prefix a 3758 DOTS signal channel object. 3760 This document requests IANA to register the DOTS signal channel CBOR 3761 tag in the "CBOR Tags" registry [IANA.CBOR.Tags] using the 24-255 3762 range: 3764 o CBOR Tag: TBD2 (please assign the same value as the Content- 3765 Format) 3766 o Data Item: DDoS Open Threat Signaling (DOTS) signal channel object 3767 o Semantics: DDoS Open Threat Signaling (DOTS) signal channel 3768 object, as defined in [RFCXXXX] 3769 o Description of Semantics: [RFCXXXX] 3771 9.6. DOTS Signal Channel Protocol Registry 3773 The document requests IANA to create a new registry, entitled "DOTS 3774 Signal Channel Registry". The following sections define sub- 3775 registries. 3777 9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry 3779 The document requests IANA to create a new sub-registry, entitled 3780 "DOTS Signal Channel CBOR Key Values". 3782 The structure of this sub-registry is provided in Section 9.6.1.1. 3783 Section 9.6.1.2 provides how the registry is initially populated with 3784 the values in Table 4. 3786 9.6.1.1. Registration Template 3788 Parameter name: 3789 Parameter name as used in the DOTS signal channel. 3791 CBOR Key Value: 3792 Key value for the parameter. The key value MUST be an integer in 3793 the 1-65535 range. The key values of the comprehension-required 3794 range (0x0001 - 0x3FFF) and of the comprehension-optional range 3795 (0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of 3796 [RFC8126]). The key values of the comprehension-optional range 3797 (0x4000 - 0x7FFF) are assigned by Specification Required 3798 (Section 4.6 of [RFC8126]) and of the comprehension-optional range 3799 (0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of 3800 [RFC8126]). 3802 Registration requests for the 0x4000 - 0x7FFF range are evaluated 3803 after a three-week review period on the dots-signal-reg- 3804 review@ietf.org mailing list, on the advice of one or more 3805 Designated Experts. However, to allow for the allocation of 3806 values prior to publication, the Designated Experts may approve 3807 registration once they are satisfied that such a specification 3808 will be published. New registration requests should be sent in 3809 the form of an email to the review mailing list; the request 3810 should use an appropriate subject (e.g., "Request to register CBOR 3811 Key Value for DOTS: example"). IANA will only accept new 3812 registrations from the Designated Experts, and will check that 3813 review was requested on the mailing list in accordance with these 3814 procedures. 3816 Within the review period, the Designated Experts will either 3817 approve or deny the registration request, communicating this 3818 decision to the review list and IANA. Denials should include an 3819 explanation and, if applicable, suggestions as to how to make the 3820 request successful. Registration requests that are undetermined 3821 for a period longer than 21 days can be brought to the IESG's 3822 attention (using the iesg@ietf.org mailing list) for resolution. 3824 Criteria that should be applied by the Designated Experts includes 3825 determining whether the proposed registration duplicates existing 3826 functionality, whether it is likely to be of general applicability 3827 or whether it is useful only for a single use case, and whether 3828 the registration description is clear. IANA must only accept 3829 registry updates to the 0x4000 - 0x7FFF range from the Designated 3830 Experts and should direct all requests for registration to the 3831 review mailing list. It is suggested that multiple Designated 3832 Experts be appointed. In cases where a registration decision 3833 could be perceived as creating a conflict of interest for a 3834 particular Expert, that Expert should defer to the judgment of the 3835 other Experts. 3837 CBOR Major Type: 3838 CBOR Major type and optional tag for the parameter. 3840 Change Controller: 3841 For Standards Track RFCs, list the "IESG". For others, give the 3842 name of the responsible party. Other details (e.g., email 3843 address) may also be included. 3845 Specification Document(s): 3846 Reference to the document or documents that specify the parameter, 3847 preferably including URIs that can be used to retrieve copies of 3848 the documents. An indication of the relevant sections may also be 3849 included but is not required. 3851 9.6.1.2. Initial Sub-Registry Content 3853 +----------------------+-------+-------+------------+---------------+ 3854 | Parameter Name | CBOR | CBOR | Change | Specification | 3855 | | Key | Major | Controller | Document(s) | 3856 | | Value | Type | | | 3857 +----------------------+-------+-------+------------+---------------+ 3858 | ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] | 3859 | nel:mitigation-scope | | | | | 3860 | scope | 2 | 4 | IESG | [RFCXXXX] | 3861 | cdid | 3 | 3 | IESG | [RFCXXXX] | 3862 | cuid | 4 | 3 | IESG | [RFCXXXX] | 3863 | mid | 5 | 0 | IESG | [RFCXXXX] | 3864 | target-prefix | 6 | 4 | IESG | [RFCXXXX] | 3865 | target-port-range | 7 | 4 | IESG | [RFCXXXX] | 3866 | lower-port | 8 | 0 | IESG | [RFCXXXX] | 3867 | upper-port | 9 | 0 | IESG | [RFCXXXX] | 3868 | target-protocol | 10 | 4 | IESG | [RFCXXXX] | 3869 | target-fqdn | 11 | 4 | IESG | [RFCXXXX] | 3870 | target-uri | 12 | 4 | IESG | [RFCXXXX] | 3871 | alias-name | 13 | 4 | IESG | [RFCXXXX] | 3872 | lifetime | 14 | 0/1 | IESG | [RFCXXXX] | 3873 | mitigation-start | 15 | 0 | IESG | [RFCXXXX] | 3874 | status | 16 | 0 | IESG | [RFCXXXX] | 3875 | conflict-information | 17 | 5 | IESG | [RFCXXXX] | 3876 | conflict-status | 18 | 0 | IESG | [RFCXXXX] | 3877 | conflict-cause | 19 | 0 | IESG | [RFCXXXX] | 3878 | retry-timer | 20 | 0 | IESG | [RFCXXXX] | 3879 | conflict-scope | 21 | 5 | IESG | [RFCXXXX] | 3880 | acl-list | 22 | 4 | IESG | [RFCXXXX] | 3881 | acl-name | 23 | 3 | IESG | [RFCXXXX] | 3882 | acl-type | 24 | 3 | IESG | [RFCXXXX] | 3883 | bytes-dropped | 25 | 0 | IESG | [RFCXXXX] | 3884 | bps-dropped | 26 | 0 | IESG | [RFCXXXX] | 3885 | pkts-dropped | 27 | 0 | IESG | [RFCXXXX] | 3886 | pps-dropped | 28 | 0 | IESG | [RFCXXXX] | 3887 | attack-status | 29 | 0 | IESG | [RFCXXXX] | 3888 | ietf-dots-signal- | 30 | 5 | IESG | [RFCXXXX] | 3889 | channel:signal-config| | | | | 3890 | sid | 31 | 0 | IESG | [RFCXXXX] | 3891 | mitigating-config | 32 | 5 | IESG | [RFCXXXX] | 3892 | heartbeat-interval | 33 | 5 | IESG | [RFCXXXX] | 3893 | min-value | 34 | 0 | IESG | [RFCXXXX] | 3894 | max-value | 35 | 0 | IESG | [RFCXXXX] | 3895 | current-value | 36 | 0 | IESG | [RFCXXXX] | 3896 | missing-hb-allowed | 37 | 5 | IESG | [RFCXXXX] | 3897 | max-retransmit | 38 | 5 | IESG | [RFCXXXX] | 3898 | ack-timeout | 39 | 5 | IESG | [RFCXXXX] | 3899 | ack-random-factor | 40 | 5 | IESG | [RFCXXXX] | 3900 | min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] | 3901 | max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] | 3902 | current-value- | 43 | 6tag4 | IESG | [RFCXXXX] | 3903 | decimal | | | | | 3904 | idle-config | 44 | 5 | IESG | [RFCXXXX] | 3905 | trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | 3906 | ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] | 3907 | nel:redirected-signal| | | | | 3908 | alt-server | 47 | 3 | IESG | [RFCXXXX] | 3909 | alt-server-record | 48 | 4 | IESG | [RFCXXXX] | 3910 +----------------------+-------+-------+------------+---------------+ 3912 Table 6: Initial DOTS Signal Channel CBOR Key Values Registry 3914 9.6.2. Status Codes Sub-Registry 3916 The document requests IANA to create a new sub-registry, entitled 3917 "DOTS Signal Channel Status Codes". Codes in this registry are used 3918 as valid values of 'status' parameter. 3920 The registry is initially populated with the following values: 3922 +-----+----------------------------------+--------------+-----------+ 3923 | Cod | Label | Description | Reference | 3924 | e | | | | 3925 +-----+----------------------------------+--------------+-----------+ 3926 | 1 | attack-mitigation-in-progress | Attack | [RFCXXXX] | 3927 | | | mitigation | | 3928 | | | setup is in | | 3929 | | | progress | | 3930 | | | (e.g., | | 3931 | | | changing the | | 3932 | | | network path | | 3933 | | | to redirect | | 3934 | | | the inbound | | 3935 | | | traffic to a | | 3936 | | | DOTS | | 3937 | | | mitigator). | | 3938 | 2 | attack-successfully-mitigated | Attack is | [RFCXXXX] | 3939 | | | being | | 3940 | | | successfully | | 3941 | | | mitigated | | 3942 | | | (e.g., | | 3943 | | | traffic is | | 3944 | | | redirected | | 3945 | | | to a DDoS | | 3946 | | | mitigator | | 3947 | | | and attack | | 3948 | | | traffic is | | 3949 | | | dropped). | | 3950 | 3 | attack-stopped | Attack has | [RFCXXXX] | 3951 | | | stopped and | | 3952 | | | the DOTS | | 3953 | | | client can | | 3954 | | | withdraw the | | 3955 | | | mitigation | | 3956 | | | request. | | 3957 | 4 | attack-exceeded-capability | Attack has | [RFCXXXX] | 3958 | | | exceeded the | | 3959 | | | mitigation | | 3960 | | | provider | | 3961 | | | capability. | | 3962 | 5 | dots-client-withdrawn-mitigation | DOTS client | [RFCXXXX] | 3963 | | | has | | 3964 | | | withdrawn | | 3965 | | | the | | 3966 | | | mitigation | | 3967 | | | request and | | 3968 | | | the | | 3969 | | | mitigation | | 3970 | | | is active | | 3971 | | | but | | 3972 | | | terminating. | | 3973 | 6 | attack-mitigation-terminated | Attack | [RFCXXXX] | 3974 | | | mitigation | | 3975 | | | is now | | 3976 | | | terminated. | | 3977 | 7 | attack-mitigation-withdrawn | Attack | [RFCXXXX] | 3978 | | | mitigation | | 3979 | | | is | | 3980 | | | withdrawn. | | 3981 | 8 | attack-mitigation-signal-loss | Attack | [RFCXXXX] | 3982 | | | mitigation | | 3983 | | | will be | | 3984 | | | triggered | | 3985 | | | for the | | 3986 | | | mitigation | | 3987 | | | request only | | 3988 | | | when the | | 3989 | | | DOTS signal | | 3990 | | | channel | | 3991 | | | session is | | 3992 | | | lost. | | 3993 +-----+----------------------------------+--------------+-----------+ 3995 New codes can be assigned via Standards Action [RFC8126]. 3997 9.6.3. Conflict Status Codes Sub-Registry 3999 The document requests IANA to create a new sub-registry, entitled 4000 "DOTS Signal Channel Conflict Status Codes". Codes in this registry 4001 are used as valid values of 'conflict-status' parameter. 4003 The registry is initially populated with the following values: 4005 +------+-------------------------------+----------------+-----------+ 4006 | Code | Label | Description | Reference | 4007 +------+-------------------------------+----------------+-----------+ 4008 | 1 | request-inactive-other-active | DOTS server | [RFCXXXX] | 4009 | | | has detected | | 4010 | | | conflicting | | 4011 | | | mitigation | | 4012 | | | requests from | | 4013 | | | different DOTS | | 4014 | | | clients. This | | 4015 | | | mitigation | | 4016 | | | request is | | 4017 | | | currently | | 4018 | | | inactive until | | 4019 | | | the conflicts | | 4020 | | | are resolved. | | 4021 | | | Another | | 4022 | | | mitigation | | 4023 | | | request is | | 4024 | | | active. | | 4025 | 2 | request-active | DOTS server | [RFCXXXX] | 4026 | | | has detected | | 4027 | | | conflicting | | 4028 | | | mitigation | | 4029 | | | requests from | | 4030 | | | different DOTS | | 4031 | | | clients. This | | 4032 | | | mitigation | | 4033 | | | request is | | 4034 | | | currently | | 4035 | | | active. | | 4036 | 3 | all-requests-inactive | DOTS server | [RFCXXXX] | 4037 | | | has detected | | 4038 | | | conflicting | | 4039 | | | mitigation | | 4040 | | | requests from | | 4041 | | | different DOTS | | 4042 | | | clients. All | | 4043 | | | conflicting | | 4044 | | | mitigation | | 4045 | | | requests are | | 4046 | | | inactive. | | 4047 +------+-------------------------------+----------------+-----------+ 4049 New codes can be assigned via Standards Action [RFC8126]. 4051 9.6.4. Conflict Cause Codes Sub-Registry 4053 The document requests IANA to create a new sub-registry, entitled 4054 "DOTS Signal Channel Conflict Cause Codes". Codes in this registry 4055 are used as valid values of 'conflict-cause' parameter. 4057 The registry is initially populated with the following values: 4059 +------+--------------------------+---------------------+-----------+ 4060 | Code | Label | Description | Reference | 4061 +------+--------------------------+---------------------+-----------+ 4062 | 1 | overlapping-targets | Overlapping | [RFCXXXX] | 4063 | | | targets. | | 4064 | 2 | conflict-with-acceptlist | Conflicts with an | [RFCXXXX] | 4065 | | | existing accept- | | 4066 | | | list. This code is | | 4067 | | | returned when the | | 4068 | | | DDoS mitigation | | 4069 | | | detects source | | 4070 | | | addresses/prefixes | | 4071 | | | in the accept- | | 4072 | | | listed ACLs are | | 4073 | | | attacking the | | 4074 | | | target. | | 4075 | 3 | cuid-collision | CUID Collision. | [RFCXXXX] | 4076 | | | This code is | | 4077 | | | returned when a | | 4078 | | | DOTS client uses a | | 4079 | | | 'cuid' that is | | 4080 | | | already used by | | 4081 | | | another DOTS | | 4082 | | | client. | | 4083 +------+--------------------------+---------------------+-----------+ 4085 New codes can be assigned via Standards Action [RFC8126]. 4087 9.6.5. Attack Status Codes Sub-Registry 4089 The document requests IANA to create a new sub-registry, entitled 4090 "DOTS Signal Channel Attack Status Codes". Codes in this registry 4091 are used as valid values of 'attack-status' parameter. 4093 The registry is initially populated with the following values: 4095 +------+-------------------------------+----------------+-----------+ 4096 | Code | Label | Description | Reference | 4097 +------+-------------------------------+----------------+-----------+ 4098 | 1 | under-attack | The DOTS | [RFCXXXX] | 4099 | | | client | | 4100 | | | determines | | 4101 | | | that it is | | 4102 | | | still under | | 4103 | | | attack. | | 4104 | 2 | attack-successfully-mitigated | The DOTS | [RFCXXXX] | 4105 | | | client | | 4106 | | | determines | | 4107 | | | that the | | 4108 | | | attack is | | 4109 | | | successfully | | 4110 | | | mitigated. | | 4111 +------+-------------------------------+----------------+-----------+ 4113 New codes can be assigned via Standards Action [RFC8126]. 4115 9.7. DOTS Signal Channel YANG Modules 4117 This document requests IANA to register the following URIs in the 4118 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 4120 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 4121 Registrant Contact: The IESG. 4122 XML: N/A; the requested URI is an XML namespace. 4124 URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel 4125 Registrant Contact: IANA. 4126 XML: N/A; the requested URI is an XML namespace. 4128 This document requests IANA to register the following YANG modules in 4129 the "YANG Module Names" subregistry [RFC7950] within the "YANG 4130 Parameters" registry. 4132 Name: ietf-signal 4133 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 4134 Maintained by IANA: N 4135 Prefix: signal 4136 Reference: RFC XXXX 4138 Name: iana-signal 4139 Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel 4140 Maintained by IANA: Y 4141 Prefix: iana-signal 4142 Reference: RFC XXXX 4144 This document defines the initial version of the IANA-maintained 4145 iana-dots-signal-channel YANG module. IANA is requested to add this 4146 note: 4148 Status, conflict status, conflict cause, and attack status values 4149 must not be directly added to the iana-dots-signal-channel YANG 4150 module. They must instead be respectively added to the "DOTS 4151 Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause 4152 Codes", and "DOTS Attack Status Codes" registries. 4154 When a 'status', 'conflict-status', 'conflict-cause', or 'attack- 4155 status' value is respectively added to the "DOTS Status Codes", "DOTS 4156 Conflict Status Codes", "DOTS Conflict Cause Codes", or "DOTS Attack 4157 Status Codes" registry, a new "enum" statement must be added to the 4158 iana-dots-signal-channel YANG module. The following "enum" 4159 statement, and substatements thereof, should be defined: 4161 "enum": Replicates the label from the registry. 4163 "value": Contains the IANA-assigned value corresponding to the 4164 'status', 'conflict-status', 'conflict-cause', or 4165 'attack-status'. 4167 "description": Replicates the description from the registry. 4169 "reference": Replicates the reference from the registry and add the 4170 title of the document. 4172 When the iana-dots-signal-channel YANG module is updated, a new 4173 "revision" statement must be added in front of the existing revision 4174 statements. 4176 IANA is requested to add this note to "DOTS Status Codes", "DOTS 4177 Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack 4178 Status Codes" registries: 4180 When this registry is modified, the YANG module iana-dots-signal- 4181 channel must be updated as defined in [RFCXXXX]. 4183 10. Security Considerations 4185 High-level DOTS security considerations are documented in 4186 [I-D.ietf-dots-requirements] and [I-D.ietf-dots-architecture]. 4188 Authenticated encryption MUST be used for data confidentiality and 4189 message integrity. The interaction between the DOTS agents requires 4190 Datagram Transport Layer Security (DTLS) or Transport Layer Security 4191 (TLS) with a cipher suite offering confidentiality protection, and 4192 the guidance given in [RFC7525] MUST be followed to avoid attacks on 4193 (D)TLS. The (D)TLS protocol profile used for the DOTS signal channel 4194 is specified in Section 7. 4196 If TCP is used between DOTS agents, an attacker may be able to inject 4197 RST packets, bogus application segments, etc., regardless of whether 4198 TLS authentication is used. Because the application data is TLS 4199 protected, this will not result in the application receiving bogus 4200 data, but it will constitute a DoS on the connection. This attack 4201 can be countered by using TCP-AO [RFC5925]. Although not widely 4202 adopted, if TCP-AO is used, then any bogus packets injected by an 4203 attacker will be rejected by the TCP-AO integrity check and therefore 4204 will never reach the TLS layer. 4206 An attack vector that can be achieved if the 'cuid' is guessable is a 4207 misbehaving DOTS client from within the client's domain which uses 4208 the 'cuid' of another DOTS client of the domain to delete or alter 4209 active mitigations. For this attack vector to happen, the 4210 misbehaving client needs to pass the security validation checks by 4211 the DOTS server, and eventually the checks of a client-domain DOTS 4212 gateway. 4214 A similar attack can be achieved by a compromised DOTS client which 4215 can sniff the TLS 1.2 handshake, use the client certificate to 4216 identify the 'cuid' used by another DOTS client. This attack is not 4217 possible if algorithms such as version 4 Universally Unique 4218 IDentifiers (UUIDs) in Section 4.4 of [RFC4122] are used to generate 4219 the 'cuid' because such UUIDs are not a deterministic function of the 4220 client certificate. Likewise, this attack is not possible with TLS 4221 1.3 because most of the TLS handshake is encrypted and the client 4222 certificate is not visible to eavesdroppers. 4224 A compromised DOTS client can collude with a DDoS attacker to send 4225 mitigation request for a target resource, gets the mitigation 4226 efficacy from the DOTS server, and conveys the mitigation efficacy to 4227 the DDoS attacker to possibly change the DDoS attack strategy. 4228 Obviously, signaling an attack by the compromised DOTS client to the 4229 DOTS server will trigger attack mitigation. This attack can be 4230 prevented by monitoring and auditing DOTS clients to detect 4231 misbehavior and to deter misuse, and by only authorizing the DOTS 4232 client to request mitigation for specific target resources (e.g., an 4233 application server is authorized to request mitigation for its IP 4234 addresses but a DDoS mitigator can request mitigation for any target 4235 resource in the network). Furthermore, DOTS clients are typically 4236 co-located on network security services (e.g., firewall) and a 4237 compromised security service potentially can do a lot more damage to 4238 the network. 4240 Rate-limiting DOTS requests, including those with new 'cuid' values, 4241 from the same DOTS client defends against DoS attacks that would 4242 result in varying the 'cuid' to exhaust DOTS server resources. Rate- 4243 limit policies SHOULD be enforced on DOTS gateways (if deployed) and 4244 DOTS servers. 4246 In order to prevent leaking internal information outside a client- 4247 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 4248 the identification information that pertains to internal DOTS clients 4249 (e.g., source IP address, client's hostname) unless explicitly 4250 configured to do so. 4252 DOTS servers MUST verify that requesting DOTS clients are entitled to 4253 trigger actions on a given IP prefix. That is, only actions on IP 4254 resources that belong to the DOTS client' domain MUST be authorized 4255 by a DOTS server. The exact mechanism for the DOTS servers to 4256 validate that the target prefixes are within the scope of the DOTS 4257 client domain is deployment-specific. 4259 The presence of DOTS gateways may lead to infinite forwarding loops, 4260 which is undesirable. To prevent and detect such loops, this 4261 document uses the Hop-Limit Option. 4263 When FQDNs are used as targets, the DOTS server MUST rely upon DNS 4264 privacy enabling protocols (e.g., DNS over TLS [RFC7858] or DoH 4265 [RFC8484]) to prevent eavesdroppers from possibly identifying the 4266 target resources protected by the DDoS mitigation service, and means 4267 to ensure the target FQDN resolution is authentic (e.g., DNSSEC 4268 [RFC4034]). 4270 CoAP-specific security considerations are discussed in Section 11 of 4271 [RFC7252], while CBOR-related security considerations are discussed 4272 in Section 8 of [RFC7049]. 4274 11. Contributors 4276 The following individuals have contributed to this document: 4278 o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust 4280 o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email: 4281 mgeller@cisco.com 4283 o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States, 4284 Email: rgm@htt-consult.com 4286 o Dan Wing, Email: dwing-ietf@fuggles.com 4288 12. Acknowledgements 4290 Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael 4291 Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia, 4292 Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien 4293 Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion 4294 and comments. 4296 The authors would like to give special thanks to Kaname Nishizuka and 4297 Jon Shallow for their efforts in implementing the protocol and 4298 performing interop testing at IETF Hackathons. 4300 Thanks to the core WG for the recommendations on Hop-Limit and 4301 redirect signaling. 4303 Special thanks to Benjamin Kaduk for the detailed AD review. 4305 Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja 4306 Kuehlewind, and Alissa Cooper for the review. 4308 13. References 4310 13.1. Normative References 4312 [I-D.ietf-core-hop-limit] 4313 Boucadair, M., K, R., and J. Shallow, "Constrained 4314 Application Protocol (CoAP) Hop Limit Option", draft-ietf- 4315 core-hop-limit-03 (work in progress), February 2019. 4317 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4318 DOI 10.17487/RFC0791, September 1981, 4319 . 4321 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 4322 Communication Layers", STD 3, RFC 1122, 4323 DOI 10.17487/RFC1122, October 1989, 4324 . 4326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4327 Requirement Levels", BCP 14, RFC 2119, 4328 DOI 10.17487/RFC2119, March 1997, 4329 . 4331 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4332 DOI 10.17487/RFC3688, January 2004, 4333 . 4335 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4336 Resource Identifier (URI): Generic Syntax", STD 66, 4337 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4338 . 4340 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 4341 Ciphersuites for Transport Layer Security (TLS)", 4342 RFC 4279, DOI 10.17487/RFC4279, December 2005, 4343 . 4345 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 4346 (CIDR): The Internet Address Assignment and Aggregation 4347 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 4348 2006, . 4350 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 4351 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 4352 . 4354 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4355 (TLS) Protocol Version 1.2", RFC 5246, 4356 DOI 10.17487/RFC5246, August 2008, 4357 . 4359 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4360 Housley, R., and W. Polk, "Internet X.509 Public Key 4361 Infrastructure Certificate and Certificate Revocation List 4362 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4363 . 4365 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 4366 Uniform Resource Identifiers (URIs)", RFC 5785, 4367 DOI 10.17487/RFC5785, April 2010, 4368 . 4370 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 4371 Extensions: Extension Definitions", RFC 6066, 4372 DOI 10.17487/RFC6066, January 2011, 4373 . 4375 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 4376 Verification of Domain-Based Application Service Identity 4377 within Internet Public Key Infrastructure Using X.509 4378 (PKIX) Certificates in the Context of Transport Layer 4379 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 4380 2011, . 4382 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4383 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 4384 January 2012, . 4386 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4387 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4388 . 4390 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 4391 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 4392 October 2013, . 4394 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 4395 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 4396 Transport Layer Security (TLS) and Datagram Transport 4397 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 4398 June 2014, . 4400 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 4401 Application Protocol (CoAP)", RFC 7252, 4402 DOI 10.17487/RFC7252, June 2014, 4403 . 4405 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 4406 "Recommendations for Secure Use of Transport Layer 4407 Security (TLS) and Datagram Transport Layer Security 4408 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 4409 2015, . 4411 [RFC7641] Hartke, K., "Observing Resources in the Constrained 4412 Application Protocol (CoAP)", RFC 7641, 4413 DOI 10.17487/RFC7641, September 2015, 4414 . 4416 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 4417 Layer Security (TLS) False Start", RFC 7918, 4418 DOI 10.17487/RFC7918, August 2016, 4419 . 4421 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 4422 (TLS) Cached Information Extension", RFC 7924, 4423 DOI 10.17487/RFC7924, July 2016, 4424 . 4426 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4427 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4428 . 4430 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 4431 RFC 7951, DOI 10.17487/RFC7951, August 2016, 4432 . 4434 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 4435 the Constrained Application Protocol (CoAP)", RFC 7959, 4436 DOI 10.17487/RFC7959, August 2016, 4437 . 4439 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 4440 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 4441 March 2017, . 4443 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4444 Writing an IANA Considerations Section in RFCs", BCP 26, 4445 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4446 . 4448 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4449 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4450 May 2017, . 4452 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4453 (IPv6) Specification", STD 86, RFC 8200, 4454 DOI 10.17487/RFC8200, July 2017, 4455 . 4457 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 4458 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 4459 Application Protocol) over TCP, TLS, and WebSockets", 4460 RFC 8323, DOI 10.17487/RFC8323, February 2018, 4461 . 4463 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4464 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4465 . 4467 13.2. Informative References 4469 [I-D.boucadair-dots-earlydata] 4470 Boucadair, M. and R. K, "Using Early Data in DOTS", draft- 4471 boucadair-dots-earlydata-00 (work in progress), January 4472 2019. 4474 [I-D.ietf-core-comi] 4475 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 4476 Management Interface", draft-ietf-core-comi-04 (work in 4477 progress), November 2018. 4479 [I-D.ietf-core-yang-cbor] 4480 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 4481 Data Modeled with YANG", draft-ietf-core-yang-cbor-10 4482 (work in progress), April 2019. 4484 [I-D.ietf-dots-architecture] 4485 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 4486 Compton, "Distributed-Denial-of-Service Open Threat 4487 Signaling (DOTS) Architecture", draft-ietf-dots- 4488 architecture-13 (work in progress), April 2019. 4490 [I-D.ietf-dots-data-channel] 4491 Boucadair, M. and R. K, "Distributed Denial-of-Service 4492 Open Threat Signaling (DOTS) Data Channel Specification", 4493 draft-ietf-dots-data-channel-28 (work in progress), March 4494 2019. 4496 [I-D.ietf-dots-multihoming] 4497 Boucadair, M. and R. K, "Multi-homing Deployment 4498 Considerations for Distributed-Denial-of-Service Open 4499 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 4500 (work in progress), January 2019. 4502 [I-D.ietf-dots-requirements] 4503 Mortensen, A., K, R., and R. Moskowitz, "Distributed 4504 Denial of Service (DDoS) Open Threat Signaling 4505 Requirements", draft-ietf-dots-requirements-22 (work in 4506 progress), March 2019. 4508 [I-D.ietf-dots-server-discovery] 4509 Boucadair, M., K, R., and P. Patil, "Distributed-Denial- 4510 of-Service Open Threat Signaling (DOTS) Server Discovery", 4511 draft-ietf-dots-server-discovery-02 (work in progress), 4512 May 2019. 4514 [I-D.ietf-dots-use-cases] 4515 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 4516 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 4517 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 4518 in progress), January 2019. 4520 [I-D.ietf-tls-dtls13] 4521 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 4522 Datagram Transport Layer Security (DTLS) Protocol Version 4523 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 4524 2019. 4526 [IANA.CBOR.Tags] 4527 IANA, "Concise Binary Object Representation (CBOR) Tags", 4528 . 4531 [IANA.CoAP.Content-Formats] 4532 IANA, "CoAP Content-Formats", 4533 . 4536 [IANA.MediaTypes] 4537 IANA, "Media Types", 4538 . 4540 [proto_numbers] 4541 "IANA, "Protocol Numbers"", 2011, 4542 . 4544 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 4545 Address Translator (Traditional NAT)", RFC 3022, 4546 DOI 10.17487/RFC3022, January 2001, 4547 . 4549 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 4550 Rose, "Resource Records for the DNS Security Extensions", 4551 RFC 4034, DOI 10.17487/RFC4034, March 2005, 4552 . 4554 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 4555 Unique IDentifier (UUID) URN Namespace", RFC 4122, 4556 DOI 10.17487/RFC4122, July 2005, 4557 . 4559 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 4560 Congestion Control Protocol (DCCP)", RFC 4340, 4561 DOI 10.17487/RFC4340, March 2006, 4562 . 4564 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 4565 Denial-of-Service Considerations", RFC 4732, 4566 DOI 10.17487/RFC4732, December 2006, 4567 . 4569 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 4570 Translation (NAT) Behavioral Requirements for Unicast 4571 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 4572 2007, . 4574 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 4575 RFC 4960, DOI 10.17487/RFC4960, September 2007, 4576 . 4578 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 4579 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 4580 . 4582 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 4583 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 4584 DOI 10.17487/RFC5389, October 2008, 4585 . 4587 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 4588 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 4589 June 2010, . 4591 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 4592 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 4593 DOI 10.17487/RFC6052, October 2010, 4594 . 4596 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 4597 NAT64: Network Address and Protocol Translation from IPv6 4598 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 4599 April 2011, . 4601 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 4602 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 4603 DOI 10.17487/RFC6234, May 2011, 4604 . 4606 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 4607 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 4608 . 4610 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 4611 "Default Address Selection for Internet Protocol Version 6 4612 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 4613 . 4615 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 4616 Specifications and Registration Procedures", BCP 13, 4617 RFC 6838, DOI 10.17487/RFC6838, January 2013, 4618 . 4620 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 4621 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 4622 DOI 10.17487/RFC6887, April 2013, 4623 . 4625 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 4626 A., and H. Ashida, "Common Requirements for Carrier-Grade 4627 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 4628 April 2013, . 4630 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4631 "Enrollment over Secure Transport", RFC 7030, 4632 DOI 10.17487/RFC7030, October 2013, 4633 . 4635 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 4636 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 4637 . 4639 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 4640 "Architectural Considerations in Smart Object Networking", 4641 RFC 7452, DOI 10.17487/RFC7452, March 2015, 4642 . 4644 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 4645 NETCONF Protocol over Transport Layer Security (TLS) with 4646 Mutual X.509 Authentication", RFC 7589, 4647 DOI 10.17487/RFC7589, June 2015, 4648 . 4650 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 4651 and P. Hoffman, "Specification for DNS over Transport 4652 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 4653 2016, . 4655 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 4656 Better Connectivity Using Concurrency", RFC 8305, 4657 DOI 10.17487/RFC8305, December 2017, 4658 . 4660 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 4661 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 4662 . 4664 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 4665 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 4666 . 4668 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 4669 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 4670 January 2019, . 4672 Appendix A. CUID Generation 4674 The document recommends the use of SPKI to generate the 'cuid'. This 4675 design choice is motivated by the following reasons: 4677 o SPKI is globally unique. 4679 o It is deterministic. 4681 o It allows to avoid extra cycles that may be induced by 'cuid' 4682 collision. 4684 o DOTS clients do not need to store the 'cuid' in a persistent 4685 storage. 4687 o It allows to detect compromised DOTS clients that do not adhere to 4688 the 'cuid' generation algorithm. 4690 Authors' Addresses 4692 Tirumaleswar Reddy (editor) 4693 McAfee, Inc. 4694 Embassy Golf Link Business Park 4695 Bangalore, Karnataka 560071 4696 India 4698 Email: kondtir@gmail.com 4700 Mohamed Boucadair (editor) 4701 Orange 4702 Rennes 35000 4703 France 4705 Email: mohamed.boucadair@orange.com 4707 Prashanth Patil 4708 Cisco Systems, Inc. 4710 Email: praspati@cisco.com 4711 Andrew Mortensen 4712 Arbor Networks, Inc. 4713 2727 S. State St 4714 Ann Arbor, MI 48104 4715 United States 4717 Email: andrew@moretension.com 4719 Nik Teague 4720 Verisign, Inc. 4721 United States 4723 Email: nteague@verisign.com