idnits 2.17.1 draft-reddy-dots-transport-06.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 12 instances of too long lines in the document, the longest one being 14 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (August 8, 2016) is 2789 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: 'RFC7049' is mentioned on line 306, but not defined ** Obsolete undefined reference: RFC 7049 (Obsoleted by RFC 8949) == Unused Reference: 'RFC5575' is defined on line 1183, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-00 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-02 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-01 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft D. Wing 4 Intended status: Standards Track P. Patil 5 Expires: February 9, 2017 M. Geller 6 Cisco 7 M. Boucadair 8 Orange 9 August 8, 2016 11 Co-operative DDoS Mitigation 12 draft-reddy-dots-transport-06 14 Abstract 16 This document specifies a mechanism that a DOTS client can use to 17 signal that a network is under a Distributed Denial-of-Service (DDoS) 18 attack to an upstream DOTS server so that appropriate mitigation 19 actions are undertaken (including, blackhole, drop, rate-limit, or 20 add to watch list) on the suspect traffic. The document specifies 21 both DOTS signal and data channels. Happy Eyeballs considerations 22 for the DOTS signal channel are also elaborated. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 9, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Notational Conventions and Terminology . . . . . . . . . . . 3 60 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . . . 5 62 5. DOTS Signal Channel . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Mitigation Service Requests . . . . . . . . . . . . . . . 7 65 5.2.1. Convey DOTS Signals . . . . . . . . . . . . . . . . . 8 66 5.2.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 11 67 5.2.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 12 68 5.2.4. Efficacy Update from DOTS Client . . . . . . . . . . 16 69 6. DOTS Data Channel . . . . . . . . . . . . . . . . . . . . . . 16 70 6.1. Filtering Rules . . . . . . . . . . . . . . . . . . . . . 17 71 6.1.1. Install Filtering Rules . . . . . . . . . . . . . . . 18 72 6.1.2. Remove Filtering Rules . . . . . . . . . . . . . . . 20 73 6.1.3. Retrieving Installed Filtering Rules . . . . . . . . 20 74 7. (D)TLS Protocol Profile and Performance considerations . . . 22 75 8. Mutual Authentication of DOTS Agents & Authorization of DOTS 76 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 79 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 83 13.2. Informative References . . . . . . . . . . . . . . . . . 27 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 86 1. Introduction 88 A distributed denial-of-service (DDoS) attack is an attempt to make 89 machines or network resources unavailable to their intended users. 90 In most cases, sufficient scale can be achieved by compromising 91 enough end-hosts and using those infected hosts to perpetrate and 92 amplify the attack. The victim in this attack can be an application 93 server, a client, a router, a firewall, or an entire network, etc. 95 In a lot of cases, it may not be possible for an enterprise to 96 determine the cause for an attack, but instead just realize that 97 certain resources seem to be under attack. The document proposes 98 that, in such cases, the DOTS client just inform the DOTS server that 99 the enterprise is under a potential attack and that the Mitigator 100 monitor traffic to the enterprise to mitigate any possible attack. 101 This document also describes a means for an enterprise, which act as 102 DOTS clients, to dynamically inform its DOTS server of the IP 103 addresses or prefixes that are causing DDoS. A Mitigator can use 104 this information to discard flows from such IP addresses reaching the 105 customer network. 107 The proposed mechanism can also be used between applications from 108 various vendors that are deployed within the same network, some of 109 them are responsible for monitoring and detecting attacks while 110 others are responsible for enforcing policies on appropriate network 111 elements. This cooperations contributes to a ensure a highly 112 automated network that is also robust, reliable and secure. The 113 advantage of this mechanism is that the DOTS server can provide 114 protection to the DOTS client from bandwidth-saturating DDoS traffic. 116 How a Mitigator determines which network elements should be modified 117 to install appropriate filtering rules is out of scope. A variety of 118 mechanisms and protocols (including NETCONF [RFC6241]) may be 119 considered to exchange information through a communication interface 120 between the server and these underlying elements; the selection of 121 appropriate mechanisms and protocols to be invoked for that 122 interfaces is deployment-specific. 124 Terminology and protocol requirements for co-operative DDoS 125 mitigation are obtained from DOTS requirements 126 [I-D.ietf-dots-requirements]. This document satisfies all the use 127 cases discussed in [I-D.ietf-dots-use-cases] except the Third-party 128 DOTS notifications use case in Section 3.2.3 of 129 [I-D.ietf-dots-use-cases] which is an optional feature and not a core 130 use case. Third-party DOTS notifications are not part of the DOTS 131 requirements document and the DOTS architecture 132 [I-D.ietf-dots-architecture] does not assess whether that use case 133 may have an impact on the architecture itself and/or trust model. 135 2. Notational Conventions and Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 (D)TLS: For brevity this term is used for statements that apply to 142 both Transport Layer Security [RFC5246] and Datagram Transport Layer 143 Security [RFC6347]. Specific terms will be used for any statement 144 that applies to either protocol alone. 146 3. Solution Overview 148 Network applications have finite resources like CPU cycles, number of 149 processes or threads they can create and use, maximum number of 150 simultaneous connections it can handle, limited resources of the 151 control plane, etc. When processing network traffic, such an 152 application uses these resources to offer its intended task in the 153 most efficient fashion. However, an attacker may be able to prevent 154 the application from performing its intended task by causing the 155 application to exhaust the finite supply of a specific resource. 157 TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the 158 victim and ACK-flood is a CPU exhaustion attack on the victim 159 ([RFC4987]). Attacks on the link are carried out by sending enough 160 traffic such that the link becomes excessively congested, and 161 legitimate traffic suffers high packet loss. Stateful firewalls can 162 also be attacked by sending traffic that causes the firewall to hold 163 excessive state and the firewall runs out of memory, and can no 164 longer instantiate the state required to pass legitimate flows. 165 Other possible DDoS attacks are discussed in [RFC4732]. 167 In each of the cases described above, the possible arrangements 168 between the DOTS client and DOTS server to mitigate the attack are 169 discussed in [I-D.ietf-dots-use-cases]. An example of network 170 diagram showing a deployment of these elements is shown in Figure 1. 171 Architectural relationship between DOTS agents is explained in 172 [I-D.ietf-dots-architecture]. In this example, the DOTS server is 173 operating on the access network. 175 Network 176 Resource CPE router Access network __________ 177 +-----------+ +--------------+ +-------------+ / \ 178 | |____| |_______| |___ | Internet | 179 |DOTS client| | DOTS gateway | | DOTS server | | | 180 | | | | | | | | 181 +-----------+ +--------------+ +-------------+ \__________/ 183 Figure 1 185 The DOTS server can also be running on the Internet, as depicted in 186 Figure 2. 188 Network DDoS mitigation 189 Resource CPE router __________ service 190 +-----------+ +-------------+ / \ +-------------+ 191 | |____| |_______| |___ | | 192 |DOTS client| |DOTS gateway | | Internet | | DOTS server | 193 | | | | | | | | | 194 +-----------+ +-------------+ \__________/ +-------------+ 196 Figure 2 198 In typical deployments, the DOTS client belongs to a different 199 administrative domain than the DOTS server. For example, the DOTS 200 client is a web server serving content owned and operated by an 201 domain, while the DOTS server is owned and operated by a different 202 domain providing DDoS mitigation services. That domain providing 203 DDoS mitigation service might, or might not, also provide Internet 204 access service to the website operator. 206 The DOTS server may (not) be co-located with the DOTS mitigator. In 207 typical deployments, the DOTS server belongs to the same 208 administrative domain as the mitigator. 210 The DOTS client can communicate directly with the DOTS server or 211 indirectly with the DOTS server via a DOTS gateway. 213 4. Happy Eyeballs for DOTS Signal Channel 215 DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS 216 [RFC5246] over TCP. A DOTS client can use DNS to determine the IP 217 address(es) of a DOTS server or a DOTS client may be provided with 218 the list of DOTS server IP addresses. The DOTS client MUST know a 219 DOTS server's domain name; hard-coding the domain name of the DOTS 220 server into software is NOT RECOMMENDED in case the domain name is 221 not valid or needs to change for legal or other reasons. The DOTS 222 client performs A and/or AAAA record lookup of the domain name and 223 the result will be a list of IP addresses, each of which can be used 224 to contact the DOTS server using UDP and TCP. 226 If an IPv4 path to reach a DOTS server is found, but the DOTS 227 server's IPv6 path is not working, a dual-stack DOTS client can 228 experience a significant connection delay compared to an IPv4-only 229 DOTS client. The other problem is that if a middlebox between the 230 DOTS client and DOTS server is configured to block UDP, the DOTS 231 client will fail to establish a DTLS session with the DOTS server and 232 will, then, have to fall back to TLS over TCP incurring significant 233 connection delays. [I-D.ietf-dots-requirements] discusses that DOTS 234 client and server will have to support both connectionless and 235 connection-oriented protocols. 237 To overcome these connection setup problems, the DOTS client can try 238 connecting to the DOTS server using both IPv6 and IPv4, and try both 239 DTLS over UDP and TLS over TCP in a fashion similar to the Happy 240 Eyeballs mechanism [RFC6555]. These connection attempts are 241 performed by the DOTS client when its initializes, and the client 242 uses that information for its subsequent alert to the DOTS server. 243 In order of preference (most preferred first), it is UDP over IPv6, 244 UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which 245 adheres to address preference order [RFC6724] and the DOTS preference 246 that UDP be used over TCP (to avoid TCP's head of line blocking). 248 DOTS client DOTS server 249 | | 250 |--DTLS ClientHello, IPv6 ---->X | 251 |--TCP SYN, IPv6-------------->X | 252 |--DTLS ClientHello, IPv4 ---->X | 253 |--TCP SYN, IPv4----------------------------------------->| 254 |--DTLS ClientHello, IPv6 ---->X | 255 |--TCP SYN, IPv6-------------->X | 256 |<-TCP SYNACK---------------------------------------------| 257 |--DTLS ClientHello, IPv4 ---->X | 258 |--TCP ACK----------------------------------------------->| 259 |<------------Establish TLS Session---------------------->| 260 |----------------DOTS signal----------------------------->| 261 | | 263 Figure 3: Happy Eyeballs 265 In reference to Figure 3, the DOTS client sends two TCP SYNs and two 266 DTLS ClientHello messages at the same time over IPv6 and IPv4. In 267 this example, it is assumed that the IPv6 path is broken and UDP is 268 dropped by a middle box but has little impact to the DOTS client 269 because there is no long delay before using IPv4 and TCP. The IPv6 270 path and UDP over IPv6 and IPv4 is retried until the DOTS client 271 gives up. 273 5. DOTS Signal Channel 275 5.1. Overview 277 Constrained Application Protocol (CoAP) [RFC7252] is used for DOTS 278 signal channel. COAP was designed according to the REST 279 architecture, and thus exhibits functionality similar to that of 280 HTTP, it is quite straightforward to map from CoAP to HTTP and from 281 HTTP to CoAP. CoAP has been defined to make use of both DTLS over 282 UDP and TLS over TCP. The advantages of COAP are: (1) Like HTTP, 283 CoAP is based on the successful REST model, (2) CoAP is designed to 284 use minimal resources, (3) CoAP integrates with JSON, CBOR or any 285 other data format, (4) asynchronous message exchanges, etc. 287 +--------------+ 288 | DOTS | 289 +--------------+ 290 | CoAP | 291 +--------------+ 292 | TLS | DTLS | 293 +--------------+ 294 | TCP | UDP | 295 +--------------+ 296 | IP | 297 +--------------+ 299 Figure 4: Abstract Layering of DOTS signal channel over CoAP over 300 (D)TLS 302 JSON [RFC7159] payloads are used to convey signal channel specific 303 payload messages that convey request parameters and response 304 information such as errors. 306 TBD: Do we want to use CBOR [RFC7049] instead of JSON? 308 5.2. Mitigation Service Requests 310 The following APIs define the means to convey a DOTS signal from a 311 DOTS client to a DOTS server: 313 POST requests: are used to convey the DOTS signal from a DOTS client 314 to a DOTS server over the signal channel, possibly traversing a 315 DOTS gateway, indicating the DOTS client's need for mitigation, as 316 well as the scope of any requested mitigation (Section 5.2.1). 317 DOTS gateway act as a CoAP-to-CoAP Proxy (explained in [RFC7252]). 319 DELETE requests: are used by the DOTS client to withdraw the request 320 for mitigation from the DOTS server (Section 5.2.2). 322 GET requests: are used by the DOTS client to retrieve the DOTS 323 signal(s) it had conveyed to the DOTS server (Section 5.2.3). 325 PUT requests: are used by the DOTS client to convey mitigation 326 efficacy updates to the DOTS server (Section 5.2.4). 328 Reliability is provided to the POST, DELETE, GET, and PUT requests by 329 marking them as Confirmable (CON) messages. As explained in 330 Section 2.1 of [RFC7252], a Confirmable message is retransmitted 331 using a default timeout and exponential back-off between 332 retransmissions, until the DOTS server sends an Acknowledgement 333 message (ACK) with the same Message ID conveyed from the DOTS client. 334 Message transmission parameters are defined in Section 4.8 of 335 [RFC7252]. Reliablity is provided to the responses by marking them 336 as Confirmable (CON) messages. The DOTS server can either piggback 337 the response in the acknowledgement message or if the DOTS server is 338 not able to respond immediately to a request carried in a Confirmable 339 message, it simply responds with an Empty Acknowledgement message so 340 that the DOTS client can stop retransmitting the request. Empty 341 Acknowledgement message is explained in Section 2.2 of [RFC7252]. 342 When the response is ready, the server sends it in a new Confirmable 343 message which then in turn needs to be acknowledged by the DOTS 344 client (see Sections 5.2.1 and Sections 5.2.2 in [RFC7252]). 346 Implementation Note: A DOTS client that receives a response in a CON 347 message may want to clean up the message state right after sending 348 the ACK. If that ACK is lost and the DOTS server retransmits the 349 CON, the DOTS client may no longer have any state to which to 350 correlate this response, making the retransmission an unexpected 351 message; the DOTS client will send a Reset message so it does not 352 receive any more retransmissions. This behavior is normal and not an 353 indication of an error (see Section 5.3.2 in [RFC7252] for more 354 details). 356 5.2.1. Convey DOTS Signals 358 When suffering an attack and desiring DoS/DDoS mitigation, a DOTS 359 signal is sent by the DOTS client to the DOTS server. A POST request 360 is used to convey a DOTS signal to the DOTS server (Figure 5). The 361 DOTS server can enable mitigation on behalf of the DOTS client by 362 communicating the DOTS client's request to the mitigator and relaying 363 any mitigator feedback to the requesting DOTS client. 365 Header: POST (Code=0.02) 366 Uri-Host: "host" 367 Uri-Path: ".well-known" 368 Uri-Path: "DOTS-signal" 369 Uri-Path: "version" 370 Content-Type: "application/json" 371 { 372 "policy-id": "integer", 373 "target-ip": "string", 374 "target-port": "string", 375 "target-protocol": "string", 376 "lifetime": "number" 377 } 379 Figure 5: POST to convey DOTS signals 381 The header fields are described below. 383 policy-id: Identifier of the policy represented using a integer. 384 This identifier MUST be unique for each policy bound to the DOTS 385 client, i.e. ,the policy-id needs to be unique relative to the 386 active policies with the DOTS server. This identifier must be 387 generated by the DOTS client. This document does not make any 388 assumption about how this identifier is generated. This is a 389 mandatory attribute. 391 target-ip: A list of IP addresses or prefixes under attack. IP 392 addresses and prefixes are separated by commas. Prefixes are 393 represented using CIDR notation [RFC4632]. This is an optional 394 attribute. 396 target-port: A list of ports under attack. Ports are seperated by 397 commas and port number range (using "-"). For TCP, UDP, SCTP, or 398 DCCP: the range of ports (e.g., 1024-65535). This is an optional 399 attribute. 401 target-protocol: A list of protocols under attack. Valid protocol 402 values include tcp, udp, sctp, and dccp. Protocol values are 403 seperated by commas. This is an optional attribute. 405 lifetime: Lifetime of the mitigation request policy in seconds. 406 Upon the expiry of this lifetime, and if the request is not 407 refreshed, the mitigation request is removed. The request can be 408 refreshed by sending the same request again. The default lifetime 409 of the policy is 60 minutes -- this value was chosen to be long 410 enough so that refreshing is not typically a burden on the DOTS 411 client, while expiring the policy where the client has 412 unexpectedly quit in a timely manner. A lifetime of zero 413 indicates indefinite lifetime for the mitigation request. The 414 server MUST always indicate the actual lifetime in the response. 415 This is an optional attribute in the request. 417 The relative order of two rules is determined by comparing their 418 respective policy identifiers. The rule with lower numeric policy 419 identifier value has higher precedence (and thus will match before) 420 than the rule with higher numeric policy identifier value. 422 To avoid DOTS signal message fragmentation and the consequently 423 decreased probability of message delivery, DOTS agents MUST ensure 424 that the DTLS record MUST fit within a single datagram. If the Path 425 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD 426 be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 427 is used to convey the DOTS signal and the request size exceeds the 428 Path MTU then the DOTS client MUST split the DOTS signal into 429 separate messages, for example the list of addresses in the 'target- 430 ip' field could be split into multiple lists and each list conveyed 431 in a new POST request. 433 Implementation Note: DOTS choice of message size parameters works 434 well with IPv6 and with most of today's IPv4 paths. However, with 435 IPv4, it is harder to absolutely ensure that there is no IP 436 fragmentation. If IPv4 support on unusual networks is a 437 consideration and path MTU is unknown, implementations may want to 438 limit themselves to more conservative IPv4 datagram sizes such as 576 439 bytes, as per [RFC0791] IP packets up to 576 bytes should never need 440 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal 441 over a UDP datagram will generally avoid IP fragmentation. 443 Figure 6 shows a POST request to signal that ports 80, 8080, and 443 444 on the servers 2002:db8:6401::1 and 2002:db8:6401::2 are being 445 attacked. 447 Header: POST (Code=0.02) 448 Uri-Host: "www.example.com" 449 Uri-Path: ".well-known" 450 Uri-Path: "v1" 451 Uri-Path: "DOTS-signal" 452 Content-Type: "application/json" 453 { 454 "policy-id":123321333242, 455 "target-ip":[ 456 "2002:db8:6401::1", 457 "2002:db8:6401::2" 458 ], 459 "target-port":[ 460 "80", 461 "8080", 462 "443" 463 ], 464 "target-protocol":"tcp" 465 } 467 Figure 6: POST for DOTS signal 469 The DOTS server indicates the result of processing the POST request 470 using CoAP response codes. CoAP 2xx codes are success, CoAP 4xx 471 codes are some sort of invalid request and 5xx codes are returned if 472 the DOTS server has erred or is incapable of performing the 473 mitigation. Response code 2.01 (Created) will be returned in the 474 response if the DOTS server has accepted the mitigation request and 475 will try to mitigate the attack. If the request is missing one or 476 more mandatory attributes then 4.00 (Bad Request) will be returned in 477 the response or if the request contains invalid or unknown parameters 478 then 4.02 (Invalid query) will be returned in the response. The CoAP 479 response will include the JSON body received in the request. 481 5.2.2. Withdraw a DOTS Signal 483 A DELETE request is used to withdraw a DOTS signal from a DOTS server 484 (Figure 7). 486 Header: DELETE (Code=0.04) 487 Uri-Host: "host" 488 Uri-Path: ".well-known" 489 Uri-Path: "version" 490 Uri-Path: "DOTS-signal" 491 Content-Type: "application/json" 492 { 493 "policy-id": "number" 494 } 496 Figure 7: Withdraw DOTS signal 498 If the DOTS server does not find the policy number conveyed in the 499 DELETE request in its policy state data, then it responds with a 4.04 500 (Not Found) error response code. The DOTS server successfully 501 acknowledges a DOTS client's request to withdraw the DOTS signal 502 using 2.02 (Deleted) response code, and ceases mitigation activity as 503 quickly as possible. 505 5.2.3. Retrieving a DOTS Signal 507 A GET request is used to retrieve information and status of a DOTS 508 signal from a DOTS server (Figure 8). If the DOTS server does not 509 find the policy number conveyed in the GET request in its policy 510 state data, then it responds with a 4.04 (Not Found) error response 511 code. 513 1) To retrieve all DOTS signals signaled by the DOTS client. 515 Header: GET (Code=0.01) 516 Uri-Host: "host" 517 Uri-Path: ".well-known" 518 Uri-Path: "version" 519 Uri-Path: "DOTS-signal" 520 Uri-Path: "list" 521 Observe : 0 523 2) To retrieve a specific DOTS signal signaled by the DOTS client. 524 The policy information in the response will be formatted in the 525 same order it was processed at the DOTS server. 527 Header: GET (Code=0.01) 528 Uri-Host: "host" 529 Uri-Path: ".well-known" 530 Uri-Path: "version" 531 Uri-Path: "DOTS-signal" 532 Uri-Path: "policy-id value" 533 Observe : 0 535 Figure 8: GET to retrieve the rules 537 Figure 9 shows the response of all the active policies on the DOTS 538 server. 540 { 541 "policy-data":[ 542 { 543 "policy-id":123321333242, 544 "target-protocol":"tcp", 545 "lifetime":3600, 546 "status":"mitigation in progress" 547 }, 548 { 549 "policy-id":123321333244, 550 "target-protocol":"udp", 551 "lifetime":1800, 552 "status":"mitigation complete" 553 }, 554 { 555 "policy-id":123321333245, 556 "target-protocol":"tcp", 557 "lifetime":1800, 558 "status":"attack stopped" 559 } 560 ] 561 } 563 Figure 9: Response body 565 The various possible values of status field are explained below: 567 mitigation in progress: Attack mitigation is in progress (e.g., 568 changing the network path to re-route the inbound traffic to DOTS 569 mitigator). 571 mitigation complete: Attack is successfully mitigated (e.g., attack 572 traffic is dropped). 574 attack stopped: Attack has stopped and the DOTS client can withdraw 575 the mitigation request. 577 The observe option defined in [RFC7641] extends the CoAP core 578 protocol with a mechanism for a CoAP client to "observe" a resource 579 on a CoAP server: the client retrieves a representation of the 580 resource and requests this representation be updated by the server as 581 long as the client is interested in the resource. A DOTS client 582 conveys the observe option set to 0 in the GET request to receive 583 unsolicited notifications of attack mitigation status from the DOTS 584 server. Unidirectional notifications within the bidirectional signal 585 channel allows unsolicited message delivery, enabling asynchronous 586 notifications between the agents. A DOTS client that is no longer 587 interested in receiving notifications from the DOTS server can simply 588 "forget" the observation. When the DOTS server then sends the next 589 notification, the DOTS client will not recognize the token in the 590 message and thus will return a Reset message. This causes the DOTS 591 server to remove the associated entry. 593 DOTS Client DOTS Server 594 | | 595 | GET / | 596 | Token: 0x4a | Registration 597 | Observe: 0 | 598 +-------------------------->| 599 | | 600 | 2.05 Content | 601 | Token: 0x4a | Notification of 602 | Observe: 12 | the current state 603 | status: "mitigation | 604 | in progress" | 605 |<--------------------------+ 606 | 2.05 Content | 607 | Token: 0x4a | Notification upon 608 | Observe: 44 | a state change 609 | status: "mitigation | 610 | complete" | 611 |<--------------------------+ 612 | 2.05 Content | 613 | Token: 0x4a | Notification upon 614 | Observe: 60 | a state change 615 | status: "attack stopped" | 616 |<--------------------------+ 617 | | 619 Figure 10: Notifications of attack mitigation status 621 5.2.3.1. Mitigation Status 623 A DOTS client retrieves the information about a DOTS signal at 624 frequent intervals to determine the status of an attack. If the DOTS 625 server has been able to mitigate the attack and the attack has 626 stopped, the DOTS server indicates as such in the status, and the 627 DOTS client recalls the mitigation request. 629 A DOTS client should react to the status of the attack from the DOTS 630 server and not the fact that it has recognized, using its own means, 631 that the attack has been mitigated. This ensures that the DOTS 632 client does not recall a mitigation request in a premature fashion 633 because it is possible that the DOTS client does not sense the DDOS 634 attack on its resources but the DOTS server could be actively 635 mitigating the attack and the attack is not completely averted. 637 5.2.4. Efficacy Update from DOTS Client 639 While DDoS mitigation is active, a DOTS client MAY frequently 640 transmit DOTS mitigation efficacy updates to the relevant DOTS 641 server. An PUT request (Figure 11) is used to convey the mitigation 642 efficacy update to the DOTS server. The PUT request MUST include all 643 the header fields used in the POST request to convey the DOTS signal 644 (Section 5.2.1). If the DOTS server does not find the policy number 645 conveyed in the PUT request in its policy state data, it responds 646 with a 4.04 (Not Found) error response code. 648 Header: PUT (Code=0.03) 649 Uri-Host: "host" 650 Uri-Path: ".well-known" 651 Uri-Path: "version" 652 Uri-Path: "DOTS-signal" 653 Uri-Path: "policy-id value" 654 Content-Type: "application/json" 655 { 656 "target-ip": "string", 657 "target-port": "string", 658 "target-protocol": "string", 659 "lifetime": "number", 660 "attack-status": "string" 661 } 663 Figure 11: Efficacy Update 665 The 'attack-status' field is a mandatory attribute. The various 666 possible values contained in the 'attack-status' field are explained 667 below: 669 in-progress: DOTS client determines that it is still under attack. 671 terminated: Attack is successfully mitigated (e.g., attack traffic 672 is dropped). 674 6. DOTS Data Channel 676 Note: Based on discussions at IETF-96 DOTS implementers meeting, in 677 later revision this section becomes its own stand-alone specification 678 and will include https://tools.ietf.org/html/draft-nishizuka-dots- 679 inter-domain-mechanism-01. 681 The DOTS data channel is intended to be used for bulk data exchanges 682 between DOTS agents. Unlike the signal channel, which must operate 683 nominally even when confronted with despite signal degradation due to 684 packet loss, the data channel is not expected to be constructed to 685 deal with attack conditions. As the primary function of the data 686 channel is data exchange, a reliable transport is required in order 687 for DOTS agents to detect data delivery success or failure. CoAP 688 over TLS over TCP is used for DOTS data channel. 690 +--------------+ 691 | DOTS | 692 +--------------+ 693 | CoAP | 694 +--------------+ 695 | TLS | 696 +--------------+ 697 | TCP | 698 +--------------+ 699 | IP | 700 +--------------+ 702 Figure 12: Abstract Layering of DOTS data channel over CoAP over TLS 704 JSON payloads is used to convey both filtering rules as well as data 705 channel specific payload messages that convey request parameters and 706 response information such as errors. All data channel URIs defined 707 in this document, and in subsequent documents, MUST NOT have a URI 708 containing "/DOTS-signal". 710 One of the possible arrangements for DOTS client to signal filtering 711 rules to a DOTS server via the DOTS gateway is discussed below: 713 The DOTS data channel conveys the filtering rules to the DOTS 714 gateway. The DOTS gateway validates if the DOTS client is authorized 715 to signal the filtering rules and if the client is authorized 716 propagates the rules to the DOTS server. Likewise, the DOTS server 717 validates if the DOTS gateway is authorized to signal the filtering 718 rules. To create or purge filters, the DOTS client sends CoAP 719 requests to the DOTS gateway. The DOTS gateway acts as a proxy, 720 validates the rules and proxies the requests containing the filtering 721 rules to a DOTS server. When the DOTS gateway receives the 722 associated CoAP response from the DOTS server, it propagates the 723 response back to the DOTS client. 725 6.1. Filtering Rules 727 The following APIs define means for a DOTS client to configure 728 filtering rules on a DOTS server. 730 6.1.1. Install Filtering Rules 732 An POST request is used to push filtering rules to a DOTS server 733 (Figure 13). 735 Header: POST (Code=0.02) 736 Uri-Host: "host" 737 Uri-Path: ".well-known" 738 Uri-Path: "version" 739 Uri-Path: "DOTS-data-channel" 740 Content-Type: "application/json" 741 { 742 "policy-id": "integer", 743 "traffic-protocol": "string", 744 "source-protocol-port": "string", 745 "destination-protocol-port": "string", 746 "destination-ip": "string", 747 "source-ip": "string", 748 "lifetime": "number", 749 "traffic-rate" : "number" 750 } 752 Figure 13: POST to install filtering rules 754 The header fields are described below: 756 policy-id: Identifier of the policy represented using a integer. 757 This identifier MUST be unique for each policy bound to the DOTS 758 client, i.e., the policy-id needs to be unique relative to the 759 active policies with the DOTS server. This identifier must be 760 generated by the client. This document does not make any 761 assumption about how this identifier is generated. This is an 762 mandatory attribute. 764 traffic-protocol: Valid protocol values include tcp, udp, sctp, and 765 dccp. Protocol values are seperated by commas (e.g. "tcp, udp"). 766 This is an mandatory attribute. 768 source-protocol-port: The source port number. Ports are seperated 769 by commas and port number range (using "-"). For TCP, UDP, SCTP, 770 or DCCP: the source range of ports (e.g., 1024-65535). This is an 771 optional attribute. 773 destination-protocol-port: The destination port number. Ports are 774 seperated by commas and port number range (using "-"). For TCP, 775 UDP, SCTP, or DCCP: the destination range of ports (e.g., 776 443-443). This information is useful to avoid disturbing a group 777 of customers when address sharing is in use [RFC6269]. This is an 778 optional attribute. 780 destination-ip: The destination IP address or prefix. IP addresses 781 and prefixes are separated by commas. Prefixes are represented 782 using CIDR notation. This is an optional attribute. 784 source-ip: The source IP addresses or prefix. IP addresses and 785 prefixes are separated by commas. Prefixes are represented using 786 CIDR notation. This is an optional attribute. 788 lifetime: Lifetime of the rule in seconds. Upon the expiry of this 789 lifetime, and if the request is not refreshed, this particular 790 rule is removed. The rule can be refreshed by sending the same 791 message again. The default lifetime of the rule is 60 minutes -- 792 this value was chosen to be long enough so that refreshing is not 793 typically a burden on the DOTS client, while expiring the rule 794 where the client has unexpectedly quit in a timely manner. A 795 lifetime of zero indicates indefinite lifetime for the rule. The 796 server MUST always indicate the actual lifetime in the response. 797 This is an optional attribute in the request. 799 traffic-rate: This is the allowed traffic rate in bytes per second 800 indicated in IEEE floating point [IEEE.754.1985] format. The 801 value 0 indicates all traffic for the particular flow to be 802 discarded. This is a mandatory attribute. 804 The relative order of two rules is determined by comparing their 805 respective policy identifiers. The rule with lower numeric policy 806 identifier value has higher precedence (and thus will match before) 807 than the rule with higher numeric policy identifier value. 809 Figure 14 shows a POST request to block traffic from attacker IPv6 810 prefix 2001:db8:abcd:3f01::/64 to network resource using IPv6 address 811 2002:db8:6401::1 to operate a server on TCP port 443. 813 Header: POST (Code=0.02) 814 Uri-Host: "www.example.com" 815 Uri-Path: ".well-known" 816 Uri-Path: "v1" 817 Uri-Path: "DOTS-data-channel" 818 Content-Type: "application/json" 819 { 820 "policy-id": 123321333242, 821 "traffic-protocol": "tcp", 822 "source-protocol-port": "0-65535", 823 "destination-protocol-port": "443", 824 "destination-ip": "2001:db8:abcd:3f01::/64", 825 "source-ip": "2002:db8:6401::1", 826 "lifetime": 1800, 827 "traffic-rate": 0 828 } 830 Figure 14: POST to Install Black-list Rules 832 6.1.2. Remove Filtering Rules 834 A DELETE request is used to delete filtering rules from a DOTS server 835 (Figure 15). 837 Header: DELETE (Code=0.04) 838 Uri-Host: "host" 839 Uri-Path: ".well-known" 840 Uri-Path: "version" 841 Uri-Path: "DOTS-data-channel" 842 Content-Type: "application/json" 843 { 844 "policy-id": "number" 845 } 847 Figure 15: DELETE to remove the rules 849 6.1.3. Retrieving Installed Filtering Rules 851 The DOTS client periodically queries the DOTS server to check the 852 counters for installed filtering rules. A GET request is used to 853 retrieve filtering rules from a DOTS server. 855 Figure 16 shows an example to retrieve all the filtering rules 856 programmed by the DOTS client while Figure 17 shows an example to 857 retrieve specific filtering rules programmed by the DOTS client. 859 Header: GET (Code=0.01) 860 Uri-Host: "host" 861 Uri-Path: ".well-known" 862 Uri-Path: "version" 863 Uri-Path: "DOTS-data-channel" 864 Uri-Path: "list" 866 Figure 16: GET to retrieve the rules (1) 868 Header: GET (Code=0.01) 869 Uri-Host: "host" 870 Uri-Path: ".well-known" 871 Uri-Path: "version" 872 Uri-Path: "DOTS-data-channel" 873 Uri-Path: "policy-id value" 875 Figure 17: GET to retrieve the rules (2) 877 Figure 18 shows response for all active policies on the DOTS server. 879 { 880 "policy-data":[ 881 { 882 "policy-id":123321333242, 883 "traffic-protocol": "tcp", 884 "source-protocol-port": "0-65535", 885 "destination-protocol-port": "443", 886 "destination-ip": "2001:db8:abcd:3f01::/64", 887 "source-ip": "2002:db8:6401::1", 888 "lifetime": 1800, 889 "traffic-rate": 0, 890 "match-count": 689324, 891 }, 892 { 893 "policy-id":123321333242, 894 "traffic-protocol": "udp", 895 "source-protocol-port": "0-65535", 896 "destination-protocol-port": "53", 897 "destination-ip": "2001:db8:abcd:3f01::/64", 898 "source-ip": "2002:db8:6401::2", 899 "lifetime": 1800, 900 "traffic-rate": 0, 901 "match-count": 6666, 902 } 903 ] 904 } 906 Figure 18: Response body 908 7. (D)TLS Protocol Profile and Performance considerations 910 This section defines the (D)TLS protocol profile of DOTS signal 911 channel over (D)TLS and DOTS data channel over TLS. 913 There are known attacks on (D)TLS, such as machine-in-the-middle and 914 protocol downgrade. These are general attacks on (D)TLS and not 915 specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for 916 discussion of these security issues. DOTS agents MUST adhere to the 917 (D)TLS implementation recommendations and security considerations of 918 [RFC7525] except with respect to (D)TLS version. Since encryption of 919 DOTS using (D)TLS is virtually a green-field deployment DOTS agents 920 MUST implement only (D)TLS 1.2 or later. 922 Implementations compliant with this profile MUST implement all of the 923 following items: 925 o DOTS client can use (D)TLS session resumption without server-side 926 state [RFC5077] to resume session and convey the DOTS signal. 928 o While the communication to the DOTS server is quiescent, the DOTS 929 client MAY probe the server to ensure it has maintained 930 cryptographic state. Such probes can also keep alive firewall or 931 NAT bindings. This probing reduces the frequency of needing a new 932 handshake when a DOTS signal needs to be conveyed to the DOTS 933 server. 935 * A (D)TLS heartbeat [RFC6520] verifies the DOTS server still has 936 DTLS state by returning a DTLS message. If the server has lost 937 state, it returns a DTLS Alert. Upon receipt of an 938 unauthenticated DTLS Alert, the DTLS client validates the Alert 939 is within the replay window (Section 4.1.2.6 of [RFC6347]). It 940 is difficult for the DTLS client to validate the DTLS Alert was 941 generated by the DTLS server in response to a request or was 942 generated by an on- or off-path attacker. Thus, upon receipt 943 of an in-window DTLS Alert, the client SHOULD continue re- 944 transmitting the DTLS packet (in the event the Alert was 945 spoofed), and at the same time it SHOULD initiate DTLS session 946 resumption. 948 * TLS runs over TCP, so a simple probe is a 0-length TCP packet 949 (a "window probe"). This verifies the TCP connection is still 950 working, which is also sufficient to prove the server has 951 retained TLS state, because if the server loses TLS state it 952 abandons the TCP connection. If the server has lost state, a 953 TCP RST is returned immediately. 955 * Raw public keys [RFC7250] which reduce the size of the 956 ServerHello, and can be used by servers that cannot obtain 957 certificates (e.g., DOTS gateways on private networks). 959 Implementations compliant with this profile SHOULD implement all of 960 the following items to reduce the delay required to deliver a DOTS 961 signal: 963 o TLS False Start [I-D.ietf-tls-falsestart] which reduces round- 964 trips by allowing the TLS second flight of messages 965 (ChangeCipherSpec) to also contain the DOTS signal. 967 o Cached Information Extension [I-D.ietf-tls-cached-info] which 968 avoids transmitting the server's certificate and certificate chain 969 if the client has cached that information from a previous TLS 970 handshake. 972 o TCP Fast Open [RFC7413] can reduce the number of round-trips to 973 convey DOTS signal. 975 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 977 (D)TLS based on client certificate can be used for mutual 978 authentication between DOTS agents. If a DOTS gateway is involved, 979 DOTS clients and DOTS gateway MUST perform mutual authentication; 980 only authorized DOTS clients are allowed to send DOTS signals to a 981 DOTS gateway. DOTS gateway and DOTS server MUST perform mutual 982 authentication; DOTS server only allows DOTS signals from authorized 983 DOTS gateway, creating a two-link chain of transitive authentication 984 between the DOTS client and the DOTS server. 986 +-------------------------------------------------+ 987 | example.com domain +---------+ | 988 | | AAA | | 989 | +---------------+ | Server | | 990 | | Application | +------+--+ | 991 | | server + ^ 992 | | (DOTS client) |<-----------------+ | | 993 | +---------------+ + | | example.net domain 994 | V V | 995 | +-------------+ | +---------------+ 996 | +--------------+ | | | | | 997 | | Guest +<-----x----->+ +<---------------->+ DOTS | 998 | | (DOTS client)| | DOTS | | | Server | 999 | +--------------+ | Gateway | | | | 1000 | +----+--------+ | +---------------+ 1001 | ^ | 1002 | | | 1003 | +----------------+ | | 1004 | | DDOS detector | | | 1005 | | (DOTS client) +<--------------+ | 1006 | +----------------+ | 1007 | | 1008 +-------------------------------------------------+ 1010 Figure 19: Example of Authentication and Authorization of DOTS Agents 1012 In the example depicted in Figure 19, the DOTS gateway and DOTS 1013 clients within the 'example.com' domain mutually authenticate with 1014 each other. After the DOTS gateway validates the identity of a DOTS 1015 client, it communicates with the AAA server in the 'example.com' 1016 domain to determine if the DOTS client is authorized to request DDOS 1017 mitigation. If the DOTS client is not authorized, a 4.01 1018 (Unauthorized) is returned in the response to the DOTS client. In 1019 this example, the DOTS gateway only allows the application server and 1020 DDOS detector to request DDOS mitigation, but does not permit the 1021 user of type 'guest' to request DDOS mitigation. 1023 Also, DOTS gateway and DOTS server MUST perform mutual authentication 1024 using certificates. A DOTS server will only allow a DOTS gateway 1025 with a certificate for a particular domain to request mitigation for 1026 that domain. In reference to Figure 19, the DOTS server only allows 1027 the DOTS gateway to request mitigation for 'example.com' domain and 1028 not for other domains. 1030 9. IANA Considerations 1032 TODO 1034 [TBD: DOTS WG will probably have to do something similar to 1035 https://tools.ietf.org/html/rfc7519#section-10, create JSON DOTS 1036 claim registry and register the JSON attributes defined in this 1037 specification]. 1039 10. Security Considerations 1041 Authenticated encryption MUST be used for data confidentiality and 1042 message integrity. (D)TLS based on client certificate MUST be used 1043 for mutual authentication. The interaction between the DOTS agents 1044 requires Datagram Transport Layer Security (DTLS) and Transport Layer 1045 Security (TLS) with a ciphersuite offering confidentiality protection 1046 and the guidance given in [RFC7525] MUST be followed to avoid attacks 1047 on (D)TLS. 1049 If TCP is used between DOTS agents, attacker may be able to inject 1050 RST packets, bogus application segments, etc., regardless of whether 1051 TLS authentication is used. Because the application data is TLS 1052 protected, this will not result in the application receiving bogus 1053 data, but it will constitute a DoS on the connection. This attack 1054 can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then 1055 any bogus packets injected by an attacker will be rejected by the 1056 TCP-AO integrity check and therefore will never reach the TLS layer. 1058 Special care should be taken in order to ensure that the activation 1059 of the proposed mechanism won't have an impact on the stability of 1060 the network (including connectivity and services delivered over that 1061 network). 1063 Involved functional elements in the cooperation system must establish 1064 exchange instructions and notification over a secure and 1065 authenticated channel. Adequate filters can be enforced to avoid 1066 that nodes outside a trusted domain can inject request such as 1067 deleting filtering rules. Nevertheless, attacks can be initiated 1068 from within the trusted domain if an entity has been corrupted. 1069 Adequate means to monitor trusted nodes should also be enabled. 1071 11. Contributors 1073 Robert Moskowitz 1075 12. Acknowledgements 1077 Thanks to Christian Jacquenet, Roland Dobbins, Andrew Mortensen, 1078 Roman D. Danyliw, and Gilbert Clark for the discussion and comments. 1080 13. References 1082 13.1. Normative References 1084 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1085 Requirement Levels", BCP 14, RFC 2119, 1086 DOI 10.17487/RFC2119, March 1997, 1087 . 1089 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1090 (TLS) Protocol Version 1.2", RFC 5246, 1091 DOI 10.17487/RFC5246, August 2008, 1092 . 1094 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1095 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1096 June 2010, . 1098 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1099 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1100 January 2012, . 1102 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1103 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1104 Transport Layer Security (TLS) and Datagram Transport 1105 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1106 June 2014, . 1108 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1109 Application Protocol (CoAP)", RFC 7252, 1110 DOI 10.17487/RFC7252, June 2014, 1111 . 1113 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1114 "Recommendations for Secure Use of Transport Layer 1115 Security (TLS) and Datagram Transport Layer Security 1116 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1117 2015, . 1119 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1120 Application Protocol (CoAP)", RFC 7641, 1121 DOI 10.17487/RFC7641, September 2015, 1122 . 1124 13.2. Informative References 1126 [I-D.ietf-dots-architecture] 1127 Mortensen, A., Andreasen, F., Reddy, T., 1128 christopher_gray3@cable.comcast.com, c., Compton, R., and 1129 N. Teague, "Distributed-Denial-of-Service Open Threat 1130 Signaling (DOTS) Architecture", draft-ietf-dots- 1131 architecture-00 (work in progress), July 2016. 1133 [I-D.ietf-dots-requirements] 1134 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1135 Denial of Service (DDoS) Open Threat Signaling 1136 Requirements", draft-ietf-dots-requirements-02 (work in 1137 progress), July 2016. 1139 [I-D.ietf-dots-use-cases] 1140 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 1141 Teague, N., and L. Xia, "Use cases for DDoS Open Threat 1142 Signaling", draft-ietf-dots-use-cases-01 (work in 1143 progress), March 2016. 1145 [I-D.ietf-tls-cached-info] 1146 Santesson, S. and H. Tschofenig, "Transport Layer Security 1147 (TLS) Cached Information Extension", draft-ietf-tls- 1148 cached-info-23 (work in progress), May 2016. 1150 [I-D.ietf-tls-falsestart] 1151 Langley, A., Modadugu, N., and B. Moeller, "Transport 1152 Layer Security (TLS) False Start", draft-ietf-tls- 1153 falsestart-02 (work in progress), May 2016. 1155 [IEEE.754.1985] 1156 Institute of Electrical and Electronics Engineers, 1157 "Standard for Binary Floating-Point Arithmetic", August 1158 1985. 1160 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1161 DOI 10.17487/RFC0791, September 1981, 1162 . 1164 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1165 (CIDR): The Internet Address Assignment and Aggregation 1166 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1167 2006, . 1169 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1170 Denial-of-Service Considerations", RFC 4732, 1171 DOI 10.17487/RFC4732, December 2006, 1172 . 1174 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1175 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1176 . 1178 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1179 "Transport Layer Security (TLS) Session Resumption without 1180 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1181 January 2008, . 1183 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1184 and D. McPherson, "Dissemination of Flow Specification 1185 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1186 . 1188 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1189 and A. Bierman, Ed., "Network Configuration Protocol 1190 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1191 . 1193 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1194 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1195 DOI 10.17487/RFC6269, June 2011, 1196 . 1198 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1199 Layer Security (TLS) and Datagram Transport Layer Security 1200 (DTLS) Heartbeat Extension", RFC 6520, 1201 DOI 10.17487/RFC6520, February 2012, 1202 . 1204 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1205 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 1206 2012, . 1208 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1209 "Default Address Selection for Internet Protocol Version 6 1210 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1211 . 1213 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1214 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1215 2014, . 1217 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1218 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1219 . 1221 Authors' Addresses 1223 Tirumaleswar Reddy 1224 Cisco Systems, Inc. 1225 Cessna Business Park, Varthur Hobli 1226 Sarjapur Marathalli Outer Ring Road 1227 Bangalore, Karnataka 560103 1228 India 1230 Email: tireddy@cisco.com 1232 Dan Wing 1233 Cisco Systems, Inc. 1234 170 West Tasman Drive 1235 San Jose, California 95134 1236 USA 1238 Email: dwing@cisco.com 1240 Prashanth Patil 1241 Cisco Systems, Inc. 1243 Email: praspati@cisco.com 1245 Mike Geller 1246 Cisco Systems, Inc. 1247 3250 1248 Florida 33309 1249 USA 1251 Email: mgeller@cisco.com 1253 Mohamed Boucadair 1254 Orange 1255 Rennes 35000 1256 France 1258 Email: mohamed.boucadair@orange.com