idnits 2.17.1 draft-ietf-dots-use-cases-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2017) is 2587 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I2NSF' is mentioned on line 110, but not defined == Unused Reference: 'APACHE' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RRL' is defined on line 499, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS WG R. Dobbins, Ed. 3 Internet-Draft Arbor Networks 4 Intended status: Informational S. Fouant 5 Expires: September 28, 2017 6 D. Migault 7 Ericsson 8 R. Moskowitz 9 HTT Consulting 10 N. Teague 11 Verisign Inc 12 L. Xia 13 Huawei 14 K. Nishizuka 15 NTT Communications 16 March 27, 2017 18 Use cases for DDoS Open Threat Signaling 19 draft-ietf-dots-use-cases-04.txt 21 Abstract 23 The DDoS Open Threat Signaling (DOTS) effort is intended to provide a 24 protocol that facilitates interoperability between multivendor 25 solutions/services. This document presents use cases to evaluate the 26 interactions expected between the DOTS components as well as the DOTS 27 exchanges. The purpose of the use cases is to identify the 28 interacting DOTS component, how they collaborate and what are the 29 types of information to be exchanged. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 28, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 67 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 68 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Inter-domain Use Cases . . . . . . . . . . . . . . . . . 4 72 3.1.1. Enterprise with an upsteam transit provider DDoS 73 mitigation Service . . . . . . . . . . . . . . . . . 4 74 3.1.2. Enterprise with on Cloud DDoS mitigation provider . . 5 75 3.2. Intra-domain Use Cases . . . . . . . . . . . . . . . . . 6 76 3.2.1. Homenet DDoS protection by ISP . . . . . . . . . . . 6 77 3.2.2. DDoS Orchestration . . . . . . . . . . . . . . . . . 8 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 7.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 Currently, distributed denial-of-service (DDoS) attack mitigation 89 solutions/services are largely based upon siloed, proprietary 90 communications paradigms which result in vendor/service lock-in. As 91 a side-effect, this makes the configuration, provisioning, operation, 92 and activation of these solutions a highly manual and often time- 93 consuming process. Additionally, coordination of multiple DDoS 94 mitigation solutions/services simultaneously engaged in defending the 95 same organization against DDoS attacks is fraught with both technical 96 and process-related hurdles. This greatly increase operational 97 complexity and often results in suboptimal DDoS attack mitigation 98 efficacy. 100 The DDoS Open Threat Signaling (DOTS) effort is intended to provide a 101 protocol that facilitates interoperability between multivendor DDoS 102 mitigation solutions/services. As DDoS solutions/services are 103 broadly heterogeneous among different vendors, the primary goal for 104 DOTS is to provide a high level interaction with these DDoS 105 solutions/services such as initiating or terminating DDoS mitigation 106 assistance. 108 It should be noted that DOTS is not in and of itself intended to 109 perform orchestration functions duplicative of the functionality 110 being developed by the [I2NSF] WG; rather, DOTS is intended to allow 111 devices, services, and applications to request DDoS attack mitigation 112 assistance and receive mitigation status updates from systems of this 113 nature. 115 The use cases presented in the document are intended to provide 116 examples of communications interactions DOTS-enabled nodes in both 117 inter- and intra-organizational DDoS mitigation scenarios. These use 118 cases are expected to provide inputs for the design of the DOTS 119 protocol(s). 121 2. Terminology and Acronyms 123 2.1. Requirements Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2.2. Acronyms 131 This document makes use of the same terminology and definitions as 132 [I-D.ietf-dots-requirements], except where noted. 134 2.3. Terms 136 Inter-organizational: a DOTS communications relationship between 137 distinct organizations with separate spans of administrative control. 138 Typical inter-organizational DOTS communication relationships would 139 be between a DDoS mitigation service provider and an end-customer 140 organizational which requires DDoS mitigation assistance; between 141 multiple DDoS mitigation service providers coordinating mutual 142 defense of a mutual end-customer; or between DDoS mitigation service 143 providers which are requesting additional DDoS mitigation assistance 144 in for attacks which exceed their inherent DDoS mitigation capacities 145 and/or capabilities. 147 Intra-organizational: a DOTS communications relationship between 148 various elements within a single span of administrative control. A 149 typical intra-organizational DOTS communications relationship would 150 be between DOTS clients, DOTS gateways, and DOTS servers within the 151 same organization. 153 3. Use Cases Scenarios 155 This section provides a high-level description of scenarios addressed 156 by DOTS. In both sections, the scenarios are provided in order to 157 illustrate the use of DOTS in typical DDoS attack scenarios. They 158 are not definitive, and other use cases are expected to emerge with 159 widespread DOTS deployment. 161 All scenarios present a coordination between the targeted 162 organization, the DDoS attack telemetry and the mitigator. The 163 coordination and communication between these entity depends, for 164 example on the characteristic or functionality of the equipment, the 165 reliability of the information provided by DDoS attack telemetry, and 166 the business relationship between the DDoS target domain and the 167 mitigator. 169 More explicitly, in some cases, the DDoS attack telemetry may simply 170 activate a DDoS mitigation, whereas in other cases, it may 171 collaborate by providing some information about an attack. In some 172 cases, the DDoS mitigation may be orchestrated, which includes 173 selecting a specific appliance as well as starting/ending a 174 mitigation. 176 3.1. Inter-domain Use Cases 178 3.1.1. Enterprise with an upsteam transit provider DDoS mitigation 179 Service 181 In this scenario, an enterprise network with self-hosted Internet- 182 facing properties such as Web servers, authoritative DNS servers, and 183 VoIP PBXes has an intelligent DDoS mitigation system (IDMS) deployed 184 to protect those servers and applications from DDoS attacks. In 185 addition to their on-premise DDoS defense capability, they have 186 contracted with their Internet transit provider for DDoS mitigation 187 services which threaten to overwhelm their transit link bandwidth. 189 The IDMS is configured such that if the incoming Internet traffic 190 volume exceeds 50% of the provisioned upstream Internet transit link 191 capacity, the IDMS will request DDoS mitigation assistance from the 192 upstream transit provider. 194 The communication to trigger, manage, and finalize a DDoS mitigation 195 between the enterprise IDMS and the transit provider is performed 196 using DOTS. The enterprise IDMS implements a DOTS client while the 197 transit provider implements a DOTS server. 199 When the IDMS detects an inbound DDoS attack targeting the enterprise 200 servers and applications, it immediately begins mitigating the 201 attack. 203 During the course of the attack, the inbound traffic volume exceeds 204 the 50% threshold; the IDMS DOTS client signals the DOTS server on 205 the upstream transit provider network to initiate DDoS mitigation. 206 The DOTS server signals the DOTS client that it can service this 207 request, and mitigation is initiated on the transit provider network. 209 Over the course of the attack, the DOTS server on the transit 210 provider network periodically signals the DOTS client on the 211 enterprise IDMS in order to provide mitigation status information, 212 statistics related to DDoS attack traffic mitigation, and related 213 information. Once the DDoS attack has ended, the DOTS server signals 214 the enterprise IDMS DOTS client that the attack has subsided. 216 The enterprise IDMS then requests that DDoS mitigation services on 217 the upstream transit provider network be terminated. The DOTS server 218 on the transit provider network receives this request, communicates 219 with the transit provider orchestration system controlling its DDoS 220 mitigation system to terminate attack mitigation, and once the 221 mitigation has ended, confirms the end of upstream DDoS mitigation 222 service to the enterprise IDMS DOTS client. 224 3.1.2. Enterprise with on Cloud DDoS mitigation provider 226 This use case details an enterprise that has a local DDoS detection 227 and classification capability and may or may not have a mitigation 228 capability. The enterprise is contracted with a cloud DDoS 229 mitigation provider who can redirect (offramp) traffic away from the 230 enterprise, provide scrubbing services and return clean traffic back 231 to the enterprise (onramp) on an ad-hoc, on demand basis. 233 The enterprise may, either by hard coding or on a case by case basis, 234 determine thresholds at which a request for mitigation is triggered 235 indicating to the cloud provider that traffic should be redirected 236 and scrubbed. 238 The communication to trigger, manage, and finalize a DDoS mitigation 239 between the enterprise and the Cloud provider is performed using 240 DOTS. The enterprise implements a DOTS client while the Cloud 241 Provider implements a DOTS server. 243 The enterprise detection and classification systems encompass a DOTS 244 client and the cloud provider a DOTS server. 246 When an attack is detected an automated or manual DOTS mitigation 247 request will be generatd and sent to the cloud provider. The cloud 248 provider will assess the request for validity and if passed a 249 mitigation action may then be initiated. This action will usually 250 involve the offramp of all traffic destined to the target for further 251 scrutiny and filtering by the cloud provider. This should not only 252 result in an alleviation of pressure on the enterprise network but 253 also on its upstream provider and peers. 255 The cloud provider should signal via DOTS to the enterprise that a 256 mitigation request has been received and acted upon and should also 257 include a basic situational status of the attack. The cloud provider 258 may respond periodically with additional updates on the status to 259 enable the enterprise to make an informed decision on whether to 260 maintain or cancel the mitigation. An alternative approach would be 261 for the DOTS client mitigation request to include a time to live 262 (ttl) for the mitigation which may be extended by the client should 263 the attack still be ongoing as the ttl reaches expiration. 265 A variation of this use case may be that the enterprise is providing 266 a flow based monitoring and analysis service to customers whose 267 networks may be protected by any one of a number of 3rd party 268 providers. The enterprise in question may integrate with these 3rd 269 party providers using DOTS and signal accordingly when a customer is 270 attacked - the enterprise may then manage the life-cycle of the 271 attack on behalf of the enterprise. 273 3.2. Intra-domain Use Cases 275 3.2.1. Homenet DDoS protection by ISP 277 In this use case home networks or small businesses networks (SOHO), 278 subscribe with their upstream ISP a DDoS mitigation service. 280 Home networks run with limited bandwidth as well as limited routing 281 resources, while they are expected to provide services reachable from 282 the outside [RFC7368]. This makes such organizations some easy 283 targets to DDoS attacks. In addition, these DDoS attacks might even 284 not be noticed by the upstream ISP. 286 This scenario is considered as an intra-domain as ISPs have a 287 specific relationship with these customers. The ISP is the 288 connectivity provider, and in some cases, they even provides the CPE 289 with a set of associated services. Moreover, in case of any 290 connectivity issue the customer is likely to call the hotline. In 291 order to improve the QoS of the connectivity as well as to automate 292 the request for DDoS mitigation, ISP is likely to consider a standard 293 mean for CPEs to notify when they are under a suspected DDoS. Such 294 notification may be triggered automatically or manually. As the ISP 295 and the customer share a common interest in mitigating the DDoS 296 attack, this slightly differs from cases where a contract is 297 negotiated with a third party, such as in the inter-domain use cases. 299 In most cases, CPEs are unlikely to diagnose whether an DDoS attack 300 is ongoing or not and simply rely on the upstream equipment provided 301 by the ISP for detection and potential mitigation. 303 The DDoS Mitigation service of the ISP may be hard coded or may be 304 configured by the customer manually or automatically while the CPE is 305 being connected to the Internet -- eventually the DHCP server may 306 provide the DDoS Mitigation service via specific DHCP options. 308 The communication to trigger a DDoS mitigation between the home 309 network and the ISP is performed using DOTS. The home network CPE 310 implements a DOTS client while the ISP implements a DOTS server. 312 The DOTS Client on the CPE monitors the status of CPE's resource and 313 link bandwidth usage. If something unusual happens based on 314 preconfigured throughput or some heuristics methods, the DOTS Client 315 sends a DOTS mitigation request to the ISP DOTS Server. Typically, a 316 default configuration with no additional information associated to 317 the DOTS mitigation request is expected. The ISP derives traffic to 318 mitigate from the CPE IP address. 320 In some cases, the DOTS mitigation request contains options such as 321 some IP addresses or prefixes that belongs to a whitelist or 322 respectively to a blacklist. In this case, the white and black lists 323 are not associated to some analysis performed by the CPE -- as the 324 CPE is clearly not expected to analyze such attacks. Instead these 325 are part of some configuration parameters. For example, in the case 326 of small business, one may indicate specific legitimate IP addresses 327 such as those used for VPNs, or third party services the company is 328 likely to set a session. Similarly, the CPE may provides the IP 329 addresses of the assets to be protected inside the network. Such 330 options may include the IP address as well as a service description. 331 Similarly to the previous blacklist and whitelist, such information 332 are not derived from a traffic analysis performed by the CPE, but 333 instead are more related to configuration parameters. 335 Upon receiving the DOTS mitigation request, the ISP acknowledges its 336 reception and confirms DDoS mitigation starts or not. Such feed back 337 is mostly to avoid retransmission of the request. 339 Note that the ISP is connected to multiple CPEs and as such the CPE 340 can potentially perform DDoS attack to the DOTS server. ISP may use 341 relays to absorbs the traffic. In addition, such attack may be 342 triggered by a large scale DDoS attack, which is expected to be 343 detected and mitigated by the upstream architecture. 345 ISP may activate mitigation for the traffic associated to the CPE 346 sending the alert or instead to the traffic associated to all CPE. 347 Such decisions are not part of DOTS, but instead depend on the 348 policies of the ISP network administrator. 350 It is unlikely the CPE will follow the status of the mitigation. The 351 ISP is only expected to inform the CPE the mitigation has been 352 stopped. 354 Upon receipt of such notification the CPE may re-activate the 355 monitoring jobs and thus is likely to provide some further DOTS 356 alert. 358 3.2.2. DDoS Orchestration 360 In this use case, one or multiple telemetry systems or monitoring 361 devices like a flow collector monitor a network -- typically an ISP 362 network. Upon detection of a DDoS attack, these telemetry systems 363 alert an orchestrator in charge of coordinating the various DDoS 364 mitigation systems within the domain. The telemetry systems may be 365 configured to provide some necessary or useful pieces of 366 informations, such as a preliminary analysis of the observation to 367 the orchestrator. 369 The orchestrator analyses the various information it receives from 370 specialized equipements, and elaborates one or multiple DDoS 371 mitigation strategies. In some case, a manual confirmation may also 372 be required to chose a proposed strategy or to start the DDoS 373 mitigation. The DDoS mitigation may consists in multiple steps such 374 as configuring the network, the various hardware or already 375 instantiated DDoS mitigation functions. In some cases, some specific 376 virtual DDoS mitigation functions need to be instantiated and 377 properly chained between each other. Eventually, the coordination of 378 the mitigation may involved external DDoS resources such as a transit 379 provider Section 3.1 or a cloud provider Section 3.1.2. 381 The communication to trigger a DDoS mitigation between the telemetry 382 and monitoring systems and the orchestrator is performed using DOTS. 384 The telemetry systems implements a DOTS client while the Orchestrator 385 implements a DOTS server. 387 The communication between to select a DDoS strategy by a network 388 administrator and the orchestrator is also performed using DOTS. The 389 network administrator via its web interfaces implements a DOTS client 390 while the Orchestrator implements a DOTS server. 392 The communication between the Orchestrator and the DDoS mitigation 393 systems is performed using DOTS. The Orchestrator implements a DOTS 394 client while the DDoS mitigation systems implement a DOTS server. 396 The configuration aspects of each DDoS mitigation systems, as well as 397 the instantiations of DDoS mitigation functions or network 398 configuration is not part of DOTS. Similarly the discovery of the 399 available DDoS mitigation functions is not pat of DOTS. 401 The Telemetry or monitoring systems monitors each various traffic 402 network and each performs their measurement tasks. They are 403 configure so that when an event or some measurements reach a 404 predefined level to report a DOTS mitigation request to the 405 orchestrator. The DOTS mitigation request may be associated with 406 some element such as specific reporting, or analysis. 408 Upon receipt of the DOTS mitigation request from the telemetry 409 system, the orchestrator responds with an acknowledgement, to avoid 410 retransmission of the request for mitigation. The status of the DDoS 411 mitigation indicates the orchestrator is in an analysing phase. The 412 orchestrator begins collecting various informations from various 413 telemetry systems on the network in order to correlate the 414 measurements and provide an analyse of the event. Eventually, the 415 orchestrator may ask additional informations to the telemetry system 416 that just sent the DOTS request, however, the collection of these 417 information is performed outside DOTS. 419 The orchestrator may be configured to start a DDoS mitigation upon 420 approval from a network administrator. The analysis from the 421 orchestrator is reported to the network administrator via a web 422 interface. If the network administrator decides to start the 423 mitigation, she order through her web interface a DOTS client to send 424 a request for DDoS mitigation. This request is expected to be 425 associated with a context that identifies the DDoS mitigation 426 selected. 428 Upon receiving the DOTS request for DDoS mitigation from the network 429 administrator, the orchestrator orchestrates the DDoS mitigation 430 according to the specified strategy. It status first indicates the 431 DDoS mitigation is starting while not effective. In fact the 432 orchestrator is expected to proceed to a significant number of 433 configurations. 435 Orchestration of the DDoS mitigation systems works similarly as 436 described in Section 3.1 or Section 3.1.2. The orchestrator 437 indicates with its status the DDoS Mitigation is effective. 439 When the DDoS mitigation is finished on the DDoS mitigation systems, 440 the orchestrator indicates to the Telemetry systems as well as to the 441 network administrator the DDoS mitigation is finished. 443 4. Security Considerations 445 DOTS is at risk from three primary attacks: DOTS agent impersonation, 446 traffic injection, and signaling blocking. The DOTS protocol MUST be 447 designed for minimal data transfer to address the blocking risk. 449 Impersonation and traffic injection mitigation can be managed through 450 current secure communications best practices. DOTS is not subject to 451 anything new in this area. One consideration could be to minimize 452 the security technologies in use at any one time. The more needed, 453 the greater the risk of failures coming from assumptions on one 454 technology providing protection that it does not in the presence of 455 another technology. 457 Additional details of DOTS security requirements may be found in 458 [I-D.ietf-dots-requirements]. 460 5. IANA Considerations 462 No IANA considerations exist for this document at this time. 464 6. Acknowledgments 466 TBD 468 7. References 470 7.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 7.2. Informative References 479 [APACHE] "Apache mod_security", . 481 [I-D.ietf-dots-requirements] 482 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 483 Denial of Service (DDoS) Open Threat Signaling 484 Requirements", draft-ietf-dots-requirements-04 (work in 485 progress), March 2017. 487 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 488 Cheshire, "Internet Assigned Numbers Authority (IANA) 489 Procedures for the Management of the Service Name and 490 Transport Protocol Port Number Registry", BCP 165, 491 RFC 6335, DOI 10.17487/RFC6335, August 2011, 492 . 494 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 495 Weil, "IPv6 Home Networking Architecture Principles", 496 RFC 7368, DOI 10.17487/RFC7368, October 2014, 497 . 499 [RRL] "BIND RRL", . 503 Authors' Addresses 505 Roland Dobbins (editor) 506 Arbor Networks 507 30 Raffles Place 508 Level 17 Chevron House 509 Singapore 048622 510 Singapore 512 Email: rdobbins@arbor.net 514 Stefan Fouant 516 Email: stefan.fouant@copperriverit.com 517 Daniel Migault 518 Ericsson 519 8400 boulevard Decarie 520 Montreal, QC H4P 2N2 521 Canada 523 Phone: +1 514-452-2160 524 Email: daniel.migault@ericsson.com 526 Robert Moskowitz 527 HTT Consulting 528 Oak Park, MI 48237 529 USA 531 Email: rgm@labs.htt-consult.com 533 Nik Teague 534 Verisign Inc 535 12061 Bluemont Way 536 Reston, VA 20190 537 USA 539 Phone: +44 791 763 5384 540 Email: nteague@verisign.com 542 Liang Xia 543 Huawei 544 No. 101, Software Avenue, Yuhuatai District 545 Nanjing 546 China 548 Email: Frank.xialiang@huawei.com 550 Kaname Nishizuka 551 NTT Communications 552 GranPark 16F 3-4-1 Shibaura, Minato-ku 553 Tokyo 108-8118 554 Japan 556 Email: kaname@nttv6.jp