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