idnits 2.17.1 draft-ietf-dots-use-cases-05.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 (May 8, 2017) is 2544 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-04 Summary: 0 errors (**), 0 flaws (~~), 2 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: November 9, 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 May 8, 2017 18 Use cases for DDoS Open Threat Signaling (DDoS) Open Threat Signaling 19 draft-ietf-dots-use-cases-05 21 Abstract 23 The DDoS Open Threat Signaling (DOTS) effort is intended to provide a 24 dynamic solution for DDoS cooperation between networks to 25 appropriately react to DDoS attacks. This document presents use 26 cases to evaluate the interactions expected between the DOTS 27 components as well as the DOTS exchanges. The purpose of the use 28 cases is to identify the interacting DOTS components, how they 29 collaborate and what are the 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 November 9, 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 3. Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. Inter-domain Use Cases . . . . . . . . . . . . . . . . . 4 69 3.1.1. Enterprise with an upstream transit provider DDoS 70 mitigation Service . . . . . . . . . . . . . . . . . 4 71 3.1.2. Enterprise with a Cloud DDoS Mitigation Provider . . 5 72 3.2. Intra-domain Use Cases . . . . . . . . . . . . . . . . . 6 73 3.2.1. Homenet DDoS Detection Collaboration for ISP network 74 management . . . . . . . . . . . . . . . . . . . . . 6 75 3.2.2. DDoS Orchestration . . . . . . . . . . . . . . . . . 9 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 7. Informative References . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 Currently, distributed denial-of-service (DDoS) attack mitigation 85 solutions are largely based upon siloed, proprietary communications 86 schemes which result in vendor lock-in. As a side-effect, this makes 87 the configuration, provisioning, operation, and activation of these 88 solutions a highly manual and often time-consuming process. 89 Additionally, coordination of multiple DDoS mitigation solutions 90 simultaneously engaged in defending the same organization (resources) 91 against DDoS attacks is fraught with both technical and process- 92 related hurdles. This greatly increase operational complexity and 93 often results in suboptimal DDoS attack mitigation efficacy. 95 The DDoS Open Threat Signaling (DOTS) effort is intended to specify a 96 protocol that facilitates interoperability between multivendor DDoS 97 mitigation solutions and ensures more automation in term of 98 mitigation requests and attack characterization patterns. As DDoS 99 solutions are broadly heterogeneous among different vendors, the 100 primary goal for DOTS is to provide a high level interaction with 101 these DDoS solutions such as initiating or terminating DDoS 102 mitigation assistance. 104 It should be noted that DOTS is not in and of itself intended to 105 perform orchestration functions duplicative of the functionality 106 being developed by the [I2NSF] WG; rather, DOTS is intended to allow 107 devices, services, and applications to request DDoS attack mitigation 108 assistance and receive mitigation status updates. 110 These use cases are expected to provide inputs for the design of the 111 DOTS protocol(s). 113 2. Terminology and Acronyms 115 This document makes use of the terms defined in 116 [I-D.ietf-dots-requirements]. 118 In addition, this document introduces the following terms: 120 Inter-domain: a DOTS communications relationship between distinct 121 organizations with separate spans of administrative control. 122 Typical inter-domain DOTS communication relationships would be 123 between a DDoS mitigation service provider and an end-customer who 124 requires DDoS mitigation assistance; between multiple DDoS 125 mitigation service providers coordinating mutual defense of a 126 mutual end-customer; or between DDoS mitigation service providers 127 which are requesting additional DDoS mitigation assistance in for 128 attacks which exceed their inherent DDoS mitigation capacities 129 and/or capabilities. 131 Intra- domain: a DOTS communications relationship between various 132 (network) elements that are owned and operated by the same 133 administrative entity. A typical intra-domain DOTS communications 134 relationship would be between DOTS agents [I-D.ietf-dots- 135 requirements] within the same organization. 137 3. Use Cases Scenarios 139 This section provides a high-level description of scenarios addressed 140 by DOTS. In both sub-sections, the scenarios are provided in order 141 to illustrate the use of DOTS in typical DDoS attack scenarios. They 142 are not definitive, and other use cases are expected to emerge with 143 widespread DOTS deployment. 145 All scenarios present a coordination between the targeted 146 organization, the DDoS attack telemetry and the mitigator. The 147 coordination and communication between these entities depends, for 148 example, on the characteristic or functionality of the entity itself, 149 the reliability of the information provided by DDoS attack telemetry, 150 and the business relationship between the DDoS target domain and the 151 mitigator. 153 More explicitly, in some cases, the DDoS attack telemetry may simply 154 activate a DDoS mitigation, whereas in other cases, it may 155 collaborate by providing some information about an attack. In some 156 cases, the DDoS mitigation may be orchestrated, which includes 157 selecting a specific appliance as well as starting/ending a 158 mitigation. 160 3.1. Inter-domain Use Cases 162 3.1.1. Enterprise with an upstream transit provider DDoS mitigation 163 Service 165 In this scenario, an enterprise network with self-hosted Internet- 166 facing properties such as Web servers, authoritative DNS servers, and 167 VoIP service platforms has a DDoS mitigation system (DMS) deployed to 168 protect those servers, applications, and network resources from DDoS 169 attacks. In addition to their on-premise DDoS defense capability, 170 they have contracted with their Internet access provider for DDoS 171 mitigation services which threaten to overwhelm their WAN 172 interconnection link(s) bandwidth. 174 The DMS is configured such that if the incoming Internet traffic 175 volume exceeds, e.g., 50% of the provisioned upstream Internet 176 interconnection link(s) capacity, the DMS will request DDoS 177 mitigation assistance from the upstream access provider. 179 Before any communication takes place between DOTS agents, security 180 credentials are provisioned on these agents so that only authorized 181 entities can trigger mitigation actions. 183 The communication to trigger, manage, and terminate a DDoS mitigation 184 between the enterprise DMS and the access provider(s) is performed 185 using DOTS. The enterprise DMS implements a DOTS client while the 186 access provider implements a DOTS server. A DOTS client can 187 establish communications with multiple DOTS servers, if the 188 enterprise is multi-homed or of distinct access technologies are used 189 (e.g., fixed, LTE). 191 When the DMS detects an inbound DDoS attack targeting the enterprise 192 resources, it immediately begins mitigating the attack. 194 During the course of the attack, the inbound traffic volume exceeds 195 the 50% threshold; the DMS DOTS client signals its DOTS server(s) on 196 the upstream access provider network(s) to initiate DDoS mitigation 197 immediately. The DOTS server signals the DOTS client that it can 198 service this request, and mitigation is initiated on the access 199 provider network. 201 Over the course of the attack, the DOTS server on the transit 202 provider network periodically signals the DOTS client on the 203 enterprise DMS in order to provide mitigation status information, 204 statistics related to DDoS attack traffic mitigation, and related 205 information . Such information are collected by the DOTS server, but 206 the way these are collected are outside of DOTS. Once the DDoS 207 attack has ended, the DOTS server signals the enterprise DMS DOTS 208 client that the attack has subsided. This signal may not be sent 209 immediately, but once the peace time is judged stable; the duration 210 observation of the peace time after an attack is deployment-specific. 212 The enterprise DMS then requests that DDoS mitigation services on the 213 upstream access provider network be terminated. The DOTS server on 214 the access provider network receives this request, communicates with 215 the access provider orchestration system controlling its DDoS 216 mitigation system to terminate attack mitigation, and once the 217 mitigation has ended, confirms the end of upstream DDoS mitigation 218 service to the enterprise DMS DOTS client. 220 Request termination will be repeated with each of the upstream DOTS 221 servers reachable through links that were under DDoS attack. 223 3.1.2. Enterprise with a Cloud DDoS Mitigation Provider 225 This use case details an enterprise that has a local DDoS detection 226 and classification capability and may or may not have a mitigation 227 capability. The enterprise is contracted with a cloud DDoS 228 mitigation provider who can redirect (off-ramp) traffic away from the 229 enterprise, provide scrubbing services, and return "clean" traffic 230 back to the enterprise (on-ramp) on an ad-hoc, on demand basis. 232 The enterprise may, either by hard coding or on a case by case basis, 233 determine thresholds at which a request for mitigation is triggered 234 indicating to the cloud provider that traffic should be redirected 235 and scrubbed. 237 The communication to trigger, manage, and terminate a DDoS mitigation 238 between the enterprise and the Cloud provider is performed using 239 DOTS. The enterprise implements a DOTS client while the Cloud 240 Provider implements a DOTS server. 242 The enterprise detection and classification systems encompass a DOTS 243 client and the cloud provider a DOTS server. 245 When an attack is detected an automated or manual DOTS mitigation 246 request will be generated and sent to the cloud provider. The cloud 247 provider will assess the request for validity and if passed a 248 mitigation action may then be initiated. This action will usually 249 involve the off-ramp of all traffic destined to the target for 250 further scrutiny and filtering by the cloud provider. This should 251 not only result in an alleviation of pressure on the enterprise 252 network but also on its upstream provider and peers. How traffic 253 redirection is implemented is out of scope. 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 Detection Collaboration for ISP network management 277 Home networks run with (limited) bandwidth as well as limited routing 278 resources, while they are expected to provide services reachable from 279 the outside [RFC7368]. This makes such networks some easy targets to 280 DDoS attacks via their WAN interface. As these DDoS attacks are easy 281 to perform, they may remain undetected by the upstream ISP. When the 282 CPE is congested, the customer is likely to call the ISP hotline. In 283 order to improve the quality of experience of the connectivity as 284 well as to automate the request for DDoS mitigation, ISPs are likely 285 to consider a standard mean for CPEs to automatically inform a 286 dedicated service mitigation platform when they are under a suspected 287 DDoS. 289 Note also that this section only considers DDoS attacks CPE or 290 services in the home network are encountering. This differs from 291 DDoS attacks the CPE or any device within the home network may take 292 part of - such as botnets. In the later attacks, the home network 293 generates traffic under the control of a botmaster. Such attacks may 294 only be detected once the attacks have been characterized. It would 295 be tempting to consider a feature in the DOTS protocol to allow a 296 DOTS server to inform a CPE that some suspect traffic is being sent 297 by the CPE so that appropriate actions are undertaken by the CPE/ 298 user. Nevertheless, this feature would require some interaction with 299 the CPE administrator. Such scenario is outside the scope of this 300 document. 302 In this use case, ISPs are willing to prevent their customer 303 undergoing DDoS attacks in order to enhance the quality of experience 304 of their customers, to avoid unnecessary costly call on hot lines as 305 well as to optimize the bandwidth of their network. A key challenge 306 for the ISP is to detect DDoS attacks. In fact, DDoS detection is 307 not only fine grained but is also expected to be different for each 308 home network or small businesses networks (SOHO), and the ISP is 309 unlikely to have sufficient resource to inspect the traffic of all 310 its customers. 312 In order to address these challenges, ISPs are delegating the DDoS 313 detection to CPE of home network or SOHO. Outsourcing the detection 314 on the CPE provides the following advantages to the ISP: 1) Avoid the 315 ISP to dedicate a huge amount of resource for deep packet inspection 316 over a large amount of traffic with a specific security policies 317 associated to each home network. It is expected that such traffic 318 only constitutes a small fraction of the total traffic the ISP is 319 responsible for. 2) DDoS detection is deployed in a scalable way. 3) 320 Provide more deterministic DDoS attack detection. For example, what 321 could be suspected to be an UDP flood by the ISP may be consented by 322 the terminating point hosted in the home network or SOHO. In fact, 323 without specific home network security policies, the ISP is likely to 324 detect DDoS attack over regular traffic or to miss DDoS attacks 325 targeting a specific home network or CPE. In the first case, this 326 would result in the ISP spending unnecessary resources and in the 327 second case this would directly impact the quality of experience of 328 the customer. 330 Note that in this scenario slightly differs from the "Enterprise with 331 an upstream transit provider DDoS mitigation Service" scenario 332 described in Section 3.1.1. In this scenario, the detection DDoS is 333 motivated by the ISP in order to operate appropriately its network. 335 For that purpose, it requires some collaboration with the home 336 network. In Section 3.1.1, the target network requests a mitigation 337 service from the upstream transit provider in order to operate its 338 services. 340 Even though the motivations differ, there are still significant 341 advantages for the home network to collaborate. On the home network 342 or SOHO perspective such collaboration provides the following 343 advantages: 1) If it removes the flows contributing to a DDoS 344 attacks, then it enhances the quality of experience of the users of 345 the targeted services or the entire home network. 2) If mitigation is 346 being handled by the ISP rather then the home network, then it 347 reduces the management of DDoS attacks by the network administrator 348 which involves detection as well as mitigation as well as the 349 provisioning of extra resources. 3) If the DDoS detection is based on 350 information specific to the home network, such as for example the 351 description of the services, the hosts capacities or the network 352 topology, then performing the DDoS detection by the home network 353 instead of the ISP avoids the home network to leak private 354 information to the ISP. In that sense, it better preserves the home 355 network or SOHO privacy while enabling a better detection. However, 356 the request for mitigation may still leak some informations. ISPs 357 must not retrieve sensitive data without the consent of the user. 358 This is usually captured in administrative contracts that are out of 359 scope of this document. 361 When the CPE suspects an attack, it notifies automatically or the 362 ISP. The contact address of the DDoS Mitigation service of the ISP 363 may be hard coded or may be configured manually or automatically 364 (e.g., eventually the DHCP server may provide the DDoS mitigation 365 service via specific DHCP options). 367 The communication to trigger a DDoS mitigation between the home 368 network and the ISP is performed using DOTS. The home network CPE 369 implements a DOTS client while the ISP implements a DOTS server. 371 The DOTS client on the CPE monitors the status of CPE's resource and 372 WAN link bandwidth usage. If something unusual happens based on 373 preconfigured throughput, traffic patter, explicit action from the 374 user, or some heuristics methods, the DOTS client sends a DOTS 375 mitigation request to the ISP DOTS server. Typically, a default 376 configuration with no additional information associated to the DOTS 377 mitigation request is expected. The ISP derives traffic to mitigate 378 from the CPE IP address. 380 In some cases, the DOTS mitigation request contains options such as 381 some IP addresses or prefixes that belongs to a whitelist or a 382 blacklist. In this case, the white and black lists are not 383 associated to some analysis performed by the CPE -- as the CPE is 384 clearly not expected to analyze such attacks. Instead these are part 385 of some configuration parameters. For example, in the case of small 386 business, one may indicate specific legitimate IP addresses such as 387 those used for VPNs, or third party services the company is likely to 388 set a session. Similarly, the CPE may provide the IP addresses 389 targeting the assets to be protected inside the network. Note that 390 the IP address is the IP address used to reach the asset from the 391 internet, and as such is expected to be globally routable. Such 392 options may include the IP address as well as a service description. 393 Similarly to the previous blacklist and whitelist, such information 394 are likely not derived from a traffic analysis performed by the CPE, 395 but instead are more related to configuration parameters. 397 Upon receiving the DOTS mitigation request, the DOTS server 398 acknowledges its reception and confirms DDoS mitigation starts or 399 not. Such feed back is mostly to avoid retransmission of the 400 request. 402 Note that the ISP is connected to multiple CPEs and as such the CPE 403 can potentially perform DDoS attack to the DOTS server. ISP may use 404 gateways to absorbs the traffic. These gateways, will typically 405 aggregate a smaller number of CPEs and retransmit to the destination 406 DOTS Server a selected information. Note that such gateways may 407 somehow act as a DOTS relay, which is implemented with a DOTS Server 408 and a DOTS Client. Note also that the case of a large DDoS attack 409 targeting simultaneously multiple CPEs is expected to be detected and 410 mitigated by the upstream architecture, eventually without DOTS 411 alerts sent by each single CPE. 413 ISP may activate mitigation for the traffic associated to the CPE 414 sending the alert or instead to the traffic associated to all CPE. 415 Such decisions are not part of DOTS, but instead depend on the 416 policies of the ISP. 418 It is unlikely the CPE will follow the status of the mitigation. The 419 ISP is only expected to inform the CPE the mitigation has been 420 stopped. 422 Upon receipt of such notification the CPE may, for example, re- 423 activate the monitoring jobs and thus is likely to provide some 424 further DOTS alert. 426 3.2.2. DDoS Orchestration 428 In this use case, one or multiple DDoS telemetry systems like a flow 429 collector monitor a network -- typically an ISP network. Upon 430 detection of a DDoS attack, these telemetry systems alert an 431 orchestrator in charge of coordinating the various DDoS mitigation 432 systems within the domain. The telemetry systems may be configured 433 to provide some necessary or useful pieces of information, such as a 434 preliminary analysis of the observation to the orchestrator. 436 The orchestrator analyses the various information it receives from 437 specialized equipment, and elaborates one or multiple DDoS mitigation 438 strategies. In some case, a manual confirmation may also be required 439 to choose a proposed strategy or to start the DDoS mitigation. The 440 DDoS mitigation may consists in multiple steps such as configuring 441 the network, the various hardware or already instantiated DDoS 442 mitigation functions. In some cases, some specific virtual DDoS 443 mitigation functions need to be instantiated and properly chained 444 between each other. Eventually, the coordination of the mitigation 445 may involve external DDoS resources such as a transit provider 446 (Section 3.1) or a cloud provider (Section 3.1.2). 448 The communication to trigger a DDoS mitigation between the telemetry 449 and monitoring systems and the orchestrator is performed using DOTS. 450 The telemetry systems implements a DOTS client while the Orchestrator 451 implements a DOTS server. 453 The communication between a network administrator and the 454 orchestrator is also performed using DOTS. The network administrator 455 via its web interfaces implements a DOTS client while the 456 Orchestrator implements a DOTS server. 458 The communication between the Orchestrator and the DDoS mitigation 459 systems is performed using DOTS. The Orchestrator implements a DOTS 460 client while the DDoS mitigation systems implement a DOTS server. 462 The configuration aspects of each DDoS mitigation systems, as well as 463 the instantiations of DDoS mitigation functions or network 464 configuration is not part of DOTS. Similarly the discovery of the 465 available DDoS mitigation functions is not part of DOTS. 467 +----------+ 468 | network |C 469 | adminis |<-+ 470 | trator | | 471 +----------+ | 472 | (internal) 473 +----------+ | S+--------------+ +-----------+ 474 |telemetry/| +->| |C S| DDoS |+ 475 |monitoring|<--->| Orchestrator |<--->| mitigation|| 476 |systems |C S| |<-+ | systems || 477 +----------+ +--------------+C | +-----------+| 478 | +----------+ 479 | 480 | (external) 481 | +-----------+ 482 | S| DDoS | 483 +->| mitigation| 484 | systems | 485 +-----------+ 486 * C is for DOTS client functionality 487 * S is for DOTS server functionality 489 Figure 1: DDoS Orchestration 491 The telemetry systems monitor various traffic network and perform 492 their measurement tasks. They are configured so that when an event 493 or some measurements reach a predefined level to report a DOTS 494 mitigation request to the Orchestrator. The DOTS mitigation request 495 may be associated with some element such as specific reporting. 497 Upon receipt of the DOTS mitigation request from the telemetry 498 system, the Orchestrator responds with an acknowledgement, to avoid 499 retransmission of the request for mitigation. The status of the DDoS 500 mitigation indicates the Orchestrator is in an analysing phase. The 501 Orchestrator begins collecting various information from various 502 telemetry systems in order to correlate the measurements and provide 503 an analysis of the event. Eventually, the Orchestrator may ask 504 additional information to the telemetry system, however, the 505 collection of these information is performed outside DOTS. 507 The Orchestrator may be configured to start a DDoS mitigation upon 508 approval from a network administrator. The analysis from the 509 orchestrator is reported to the network administrator via a web 510 interface. If the network administrator decides to start the 511 mitigation, she orders through her web interface a DOTS client to 512 send a request for DDoS mitigation. This request is expected to be 513 associated with a context that identifies the DDoS mitigation 514 selected. 516 Upon receiving the DOTS request for DDoS mitigation from the network 517 administrator, the orchestrator orchestrates the DDoS mitigation 518 according to the specified strategy. Its status indicates the DDoS 519 mitigation is starting while not effective. 521 Orchestration of the DDoS mitigation systems works similarly as 522 described in Section 3.1 and Section 3.1.2. The Orchestrator 523 indicates with its status whether the DDoS mitigation is effective. 525 When the DDoS mitigation is finished on the DDoS mitigation systems, 526 the Orchestrator indicates to the telemetry systems as well as to the 527 network administrator the DDoS mitigation is finished. 529 4. Security Considerations 531 DOTS is at risk from three primary attacks: DOTS agent impersonation, 532 traffic injection, and signaling blocking. Associated security 533 requirements and additional ones are defined in 534 [I-D.ietf-dots-requirements]. 536 Impersonation and traffic injection mitigation can be managed through 537 current secure communications best practices. DOTS is not subject to 538 anything new in this area. One consideration could be to minimize 539 the security technologies in use at any one time. The more needed, 540 the greater the risk of failures coming from assumptions on one 541 technology providing protection that it does not in the presence of 542 another technology. 544 5. IANA Considerations 546 No IANA considerations exist for this document at this time. 548 6. Acknowledgments 550 The authors would like to thank among others Tirumaleswar Reddy, , 551 Andrew Mortensen, Mohamed Boucadaire, the DOTS WG chairs Roman D. 552 Danyliw and Tobias Gondrom for their valuable feed backs. 554 7. Informative References 556 [I-D.ietf-dots-requirements] 557 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 558 Denial of Service (DDoS) Open Threat Signaling 559 Requirements", draft-ietf-dots-requirements-04 (work in 560 progress), March 2017. 562 [I2NSF] "Interface to Network Security Functions (i2nsf)", 563 . 565 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 566 Weil, "IPv6 Home Networking Architecture Principles", 567 RFC 7368, DOI 10.17487/RFC7368, October 2014, 568 . 570 Authors' Addresses 572 Roland Dobbins (editor) 573 Arbor Networks 574 30 Raffles Place 575 Level 17 Chevron House 576 Singapore 048622 577 Singapore 579 Email: rdobbins@arbor.net 581 Stefan Fouant 583 Email: stefan.fouant@copperriverit.com 585 Daniel Migault 586 Ericsson 587 8400 boulevard Decarie 588 Montreal, QC H4P 2N2 589 Canada 591 Phone: +1 514-452-2160 592 Email: daniel.migault@ericsson.com 594 Robert Moskowitz 595 HTT Consulting 596 Oak Park, MI 48237 597 USA 599 Email: rgm@labs.htt-consult.com 601 Nik Teague 602 Verisign Inc 603 12061 Bluemont Way 604 Reston, VA 20190 605 USA 607 Phone: +44 791 763 5384 608 Email: nteague@verisign.com 609 Liang Xia 610 Huawei 611 No. 101, Software Avenue, Yuhuatai District 612 Nanjing 613 China 615 Email: Frank.xialiang@huawei.com 617 Kaname Nishizuka 618 NTT Communications 619 GranPark 16F 3-4-1 Shibaura, Minato-ku 620 Tokyo 108-8118 621 Japan 623 Email: kaname@nttv6.jp