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