idnits 2.17.00 (12 Aug 2021) /tmp/idnits10291/draft-ietf-dots-multihoming-01.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 (January 21, 2019) is 1215 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) == Outdated reference: draft-ietf-dots-architecture has been published as RFC 8811 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-architecture (ref. 'I-D.ietf-dots-architecture') == Outdated reference: draft-ietf-dots-data-channel has been published as RFC 8783 == Outdated reference: draft-ietf-dots-signal-channel has been published as RFC 8782 == Outdated reference: draft-ietf-dots-use-cases has been published as RFC 8903 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: July 25, 2019 McAfee 6 January 21, 2019 8 Multi-homing Deployment Considerations for Distributed-Denial-of-Service 9 Open Threat Signaling (DOTS) 10 draft-ietf-dots-multihoming-01 12 Abstract 14 This document discusses multi-homing considerations for Distributed- 15 Denial-of-Service Open Threat Signaling (DOTS). The goal is to 16 provide some guidance for DOTS clients/gateways when multihomed. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 25, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Multi-Homing Scenarios . . . . . . . . . . . . . . . . . . . 4 56 4.1. Residential Single CPE . . . . . . . . . . . . . . . . . 5 57 4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream 58 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream 60 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7 62 5. DOTS Deployment Considerations . . . . . . . . . . . . . . . 7 63 5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 7 64 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream 65 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream 67 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 12 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 9.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 In many deployments, it may not be possible for a network to 80 determine the cause of a distributed Denial-of-Service (DoS) attack 81 [RFC4732]. Rather, the network may just realize that some resources 82 seem to be under attack. To improve such situation, the IETF is 83 specifying the DDoS Open Threat Signaling (DOTS) 84 [I-D.ietf-dots-architecture]architecture, where a DOTS client can 85 inform a DOTS server that the network is under a potential attack and 86 that appropriate mitigation actions are required. Indeed, because 87 the lack of a common method to coordinate a real-time response among 88 involved actors and network domains jeopardizes the efficiency of 89 DDoS attack mitigation actions, the DOTS protocol is meant to carry 90 requests for DDoS attack mitigation, thereby reducing the impact of 91 an attack and leading to more efficient responsive actions. 92 [I-D.ietf-dots-use-cases] identifies a set of scenarios for DOTS; 93 most of these scenarios involve a Customer Premises Equipment (CPE). 95 The high-level DOTS architecture is illustrated in Figure 1 96 ([I-D.ietf-dots-architecture]): 98 +-----------+ +-------------+ 99 | Mitigator | ~~~~~~~~~~ | DOTS Server | 100 +-----------+ +-------------+ 101 | 102 | 103 | 104 +---------------+ +-------------+ 105 | Attack Target | ~~~~~~ | DOTS Client | 106 +---------------+ +-------------+ 108 Figure 1: Basic DOTS Architecture 110 [I-D.ietf-dots-architecture] specifies that the DOTS client may be 111 provided with a list of DOTS servers; each of these servers is 112 associated with one or more IP addresses. These addresses may or may 113 not be of the same address family. The DOTS client establishes one 114 or more DOTS sessions by connecting to the provided DOTS server(s) 115 addresses. 117 DOTS may be deployed within networks that are connected to one single 118 upstream provider. It can also be enabled within networks that are 119 multi-homed. The reader may refer to [RFC3582] for an overview of 120 multi-homing goals and motivations. This document discusses DOTS 121 multi-homing considerations. Specifically, the document aims to: 123 1. Complete the base DOTS architecture with multi-homing specifics. 124 Those specifics need to be taken into account because: 126 * Send a DOTS mitigation request to an arbitrary DOTS server 127 won't help mitigating a DDoS attack. 129 * Blindly forking all DOTS mitigation requests among all 130 available DOTS servers is suboptimal. 132 * Sequentially contacting DOTS servers may increase the delay 133 before a mitigation plan is enforced. 135 2. Identify DOTS deployment schemes in a multi-homing context, where 136 DOTS services can be offered by all or a subset of upstream 137 providers. 139 3. Sketch guidelines and recommendations for placing DOTS requests 140 in multi-homed networks, e.g.,: 142 * Select the appropriate DOTS server(s). 144 * Identify cases where anycast is not recommended. 146 This document adopts the following methodology: 148 o Identify and extract viable deployment candidates from 149 [I-D.ietf-dots-use-cases]. 151 o Augment the description with multi-homing technicalities, e.g., 153 * One vs. multiple upstream network providers 155 * One vs. multiple interconnect routers 157 * Provider-Independent (PI) vs. Provider-Aggregatable (PA) IP 158 addresses 160 o Describe the recommended behavior of DOTS clients and gateways for 161 each case. 163 Multi-homed DOTS agents are assumed to make use of the protocols 164 defined in [I-D.ietf-dots-signal-channel] and 165 [I-D.ietf-dots-data-channel]; no specific extension is required to 166 the base DOTS protocols for deploying DOTS in a multi-homed context. 168 2. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119][RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 3. Terminology 178 This document makes use of the terms defined in 179 [I-D.ietf-dots-architecture] and [RFC4116]. 181 IP indifferently refers to IPv4 or IPv6. 183 4. Multi-Homing Scenarios 185 This section describes some multi-homing scenarios that are relevant 186 to DOTS. In the following sub-sections, only the connections of 187 border routers are shown; internal network topologies are not 188 elaborated. 190 This section distinguishes between residential CPEs vs. enterprise 191 CPEs because PI addresses may be used for enterprises while this is 192 not the current practice for residential CPEs. 194 4.1. Residential Single CPE 196 The scenario shown in Figure 2 is characterized as follows: 198 o The home network is connected to the Internet using one single CPE 199 (Customer Premises Equipment). 201 o The CPE is connected to multiple provisioning domains (i.e., both 202 fixed and mobile networks). Provisioning domain (PvD) is 203 explained in [RFC7556]. 205 o Each of these provisioning domains assigns IP addresses/prefixes 206 to the CPE and provides additional configuration information such 207 as a list of DNS servers, DNS suffixes associated with the 208 network, default gateway address, and DOTS server's name 209 [I-D.boucadair-dots-server-discovery]. These addresses/prefixes 210 are assumed to be Provider-Aggregatable (PA). 212 o Because of ingress filtering, packets forwarded by the CPE towards 213 a given provisioning domain must be sent with a source IP address 214 that was assigned by that domain [RFC8043]. 216 +-------+ +-------+ 217 |Fixed | |Mobile | 218 |Network| |Network| 219 +---+---+ +---+---+ 220 | | Service Providers 221 ............|....................|....................... 222 +---------++---------+ Home Network 223 || 224 +--++-+ 225 | CPE | 226 +-----+ 227 ... (Internal Network) 229 Figure 2: Typical Multi-homed Residential CPE 231 4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 233 The scenario shown in Figure 3 is characterized as follows: 235 o The enterprise network is connected to the Internet using one 236 single router. 238 o That router is connected to multiple provisioning domains (i.e., 239 managed by distinct administrative entities). 241 Unlike the previous scenario, two sub-cases can be considered for an 242 enterprise network with regards to assigned addresses: 244 1. PI addresses/prefixes: The enterprise is the owner of the IP 245 addresses/prefixes; the same address/prefix is then used when 246 establishing communications over any of the provisioning domains. 248 2. PA addresses/prefixes: each of the provisioning domains assigns 249 IP addresses/prefixes to the enterprise network. 251 +------+ +------+ 252 | ISP1 | | ISP2 | 253 +---+--+ +--+---+ 254 | | Service Providers 255 ............|....................|....................... 256 +---------++---------+ Enterprise Network 257 || 258 +--++-+ 259 | rtr | 260 +-----+ 261 ... (Internal Network) 263 Figure 3: Multi-homed Enterprise Network (Single CPE connected to 264 Multiple Networks) 266 4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 268 This scenario is similar to the one described in Section 4.2; the 269 main difference is that dedicated routers are used to connect to each 270 provisioning domain. 272 +------+ +------+ 273 | ISP1 | | ISP2 | 274 +---+--+ +--+---+ 275 | | Service Providers 276 ......................|..........|....................... 277 | | Enterprise Network 278 +---+--+ +--+---+ 279 | rtr1 | | rtr2 | 280 +------+ +------+ 282 ... (Internal Network) 284 Figure 4: Multi-homed Enterprise Network (Multiple CPEs, Multiple 285 ISPs) 287 4.4. Multi-homed Enterprise with the Same ISP 289 This scenario is a variant of Section 4.2 and Section 4.3 in which 290 multi-homing is supported by the same ISP (i.e., same provisioning 291 domain). 293 Editor's Note: The use of anycast addresses is to be consistently 294 discussed. 296 5. DOTS Deployment Considerations 298 Table 1 provides some sample, non-exhaustive, deployment schemes to 299 illustrate how DOTS agents may be deployed for each of the scenarios 300 introduced in Section 4. 302 +---------------------------+-------------------------+-------------+ 303 | Scenario | DOTS client | DOTS | 304 | | | gateway | 305 +---------------------------+-------------------------+-------------+ 306 | Residential CPE | CPE | N/A | 307 +---------------------------+-------------------------+-------------+ 308 | Single CPE, Multiple | internal hosts or CPE | CPE | 309 | provisioning domains | | | 310 +---------------------------+-------------------------+-------------+ 311 | Multiple CPEs, Multiple | internal hosts or all | CPEs (rtr1 | 312 | provisioning domains | CPEs (rtr1 and rtr2) | and rtr2) | 313 +---------------------------+-------------------------+-------------+ 314 | Multi-homed enterprise, | internal hosts or all | CPEs (rtr1 | 315 | Single provisioning | CPEs (rtr1 and rtr2) | and rtr2) | 316 | domain | | | 317 +---------------------------+-------------------------+-------------+ 319 Table 1: Sample Deployment Cases 321 These deployment schemes are further discussed in the following sub- 322 sections. 324 5.1. Residential CPE 326 Figure 5 depicts DOTS sessions that need to be established between a 327 DOTS client (C) and two DOTS servers (S1, S2) within the context of 328 the scenario described in Section 4.1. 330 For each provisioning domain, the DOTS client MUST resolve the DOTS 331 server's name provided by a provisioning domain 332 ([I-D.boucadair-dots-server-discovery]) using the DNS servers learned 333 from the respective provisioning domain. The DOTS client MUST use 334 the source address selection algorithm defined in [RFC6724] to select 335 the candidate source addresses to contact each of these DOTS servers. 336 DOTS sessions must be established and maintained with each of the 337 DOTS servers because the mitigation scope of these servers is 338 restricted. The DOTS client SHOULD use the certificate provisioned 339 by a provisioning domain to authenticate itself to the DOTS server 340 provided by the same provisioning domain. 342 When conveying a mitigation request to protect the attack target(s), 343 the DOTS client among the DOTS servers available MUST select a DOTS 344 server whose network has assigned the prefixes from which target 345 prefixes and target IP addresses are derived. This implies that if 346 no appropriate DOTS server is found, the DOTS client must not send 347 the mitigation request to any DOTS server. 349 For example, a mitigation request to protect target resources bound 350 to a PA IP address/prefix cannot be satisfied by a provisioning 351 domain another domain than the one that owns those addresses/ 352 prefixes. Consequently, if a CPE detects a DDoS attack that spreads 353 over all its network attachments, it must contact both DOTS servers 354 for mitigation purposes. Nevertheless, if the DDoS attack is 355 received from one single network, then only the DOTS server of that 356 network must be contacted. 358 The DOTS client MUST be able to associate a DOTS server with each 359 provisioning domain. For example, if the DOTS client is provisioned 360 with S1 using DHCP when attaching to a first network and with S2 361 using Protocol Configuration Option (PCO) when attaching to a second 362 network, the DOTS client must record the interface from which a DOTS 363 server was provisioned. DOTS signaling session to a given DOTS 364 server must be established using the interface from which the DOTS 365 server was provisioned. 367 +--+ 368 -----------|S1| 369 / +--+ 370 / 371 / 372 +---+/ 373 | C | 374 +---+\ 375 \ 376 \ 377 \ +--+ 378 -----------|S2| 379 +--+ 381 Figure 5: DOTS associations for a multihomed residential CPE 383 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 385 Figure 6 illustrates a first set of DOTS associations that can be 386 established with a DOTS gateway, which is enabled within the context 387 of the scenario described in Section 4.2. This deployment is 388 characterized as follows: 390 o One of more DOTS clients are enabled in hosts located in the 391 internal network. 393 o A DOTS gateway is enabled to aggregate and then relay the requests 394 towards upstream DOTS servers. 396 When PA addresses/prefixes are in use, the same considerations 397 discussed in Section 5.1 need to be followed by the DOTS gateway to 398 contact its DOTS server(s). The DOTS gateways can be reachable from 399 DOTS clients by using an unicast address or an anycast address. 401 Nevertheless, when PI addresses/prefixes are assigned, the DOTS 402 gateway MUST send the same request to all its DOTS servers. 404 +--+ 405 -----------|S1| 406 +---+ / +--+ 407 | C1|----+ / 408 +---+ | / 409 +---+ +-+-+/ 410 | C3|------| G | 411 +---+ +-+-+\ 412 +---+ | \ 413 | C2|----+ \ 414 +---+ \ +--+ 415 -----------|S2| 416 +--+ 418 Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple DOTS 419 Servers 421 An alternate deployment model is depicted in Figure 7. This 422 deployment assumes that: 424 o One or more DOTS clients are enabled in hosts located in the 425 internal network. These DOTS clients may use 426 [I-D.boucadair-dots-server-discovery] to discover their DOTS 427 server(s). 429 o These DOTS clients communicate directly with upstream DOTS 430 servers. 432 If PI addresses/prefixes are in use, the DOTS client MUST send the 433 mitigation request for all its PI addresses/prefixes to all the DOTS 434 servers. The use of anycast addresses is NOT RECOMMENDED. 436 If PA addresses/prefixes are used, the same considerations discussed 437 in Section 5.1 need to be followed by the DOTS clients. Because DOTS 438 clients are not embedded in the CPE and multiple addreses/prefixes 439 may not be assigned to the DOTS client (typically in an IPv4 440 context), some issues arise to steer traffic towards the appropriate 441 DOTS server by using the appropriate source IP address. These 442 complications discussed in [RFC4116] are not specific to DOTS. 444 +--+ 445 +--------|C1|--------+ 446 | +--+ | 447 +--+ +--+ +--+ 448 |S2|------|C3|------|S1| 449 +--+ +--+ +--+ 450 | +--+ | 451 +--------|C2|--------+ 452 +--+ 454 Figure 7: Multiple DOTS Clients, Multiple DOTS Servers 456 Another deployment approach is to enable many DOTS clients; each of 457 them is responsible for handling communications with a specific DOTS 458 server (see Figure 8). 460 +--+ 461 +--------|C1| 462 | +--+ 463 +--+ +--+ +--+ 464 |S2| |C2|------|S1| 465 +--+ +--+ +--+ 467 Figure 8: Single Homed DOTS Clients 469 Each DOTS client is provided with policies (e.g., prefix filter) that 470 will trigger DOTS communications with the DOTS servers. Such 471 policies will help the DOTS client to select the appropriate 472 destination IP address. 474 The CPE MUST select the appropriate source IP address when forwarding 475 DOTS messages received from an internal DOTS client. If anycast 476 addresses are used to reach DOTS servers, the CPE may not be able to 477 select the appropriate provisioning domain to which the mitigation 478 request should be forwarded. As a consequence, the request may not 479 be forwarded to the appropriate DOTS server. 481 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 483 The deployments depicted in Figures 7 and 8 also apply to the 484 scenario described in Section 4.3. One specific problem for this 485 scenario is to select the appropriate exit router when contacting a 486 given DOTS server. 488 An alternative deployment scheme is shown in Figure 9: 490 o DOTS clients are enabled in hosts located in the internal network. 492 o A DOTS gateway is enabled in each CPE (rtr1, rtr2). 494 o Each of these DOTS gateways communicates with the DOTS server of 495 the provisioning domain. 497 When PI addresses/prefixes are used, DOTS clients MUST contact all 498 the DOTS gateways to send a DOTS message. DOTS gateways will then 499 relay the request to the DOTS server. Note that the use of anycast 500 addresses is NOT RECOMMENDED to establish DOTS sessions between DOTS 501 clients and DOTS gateways. 503 When PA addresses/prefixes are used, but no filter rules are provided 504 to DOTS clients, the latter MUST contact all DOTS gateways 505 simultaneously to send a DOTS message. Upon receipt of a request by 506 a DOTS gateway, it MUST check whether the request is to be forwarded 507 upstream (if the target IP prefix is managed by the upstream server) 508 or rejected. 510 When PA addresses/prefixes are used, but specific filter rules are 511 provided to DOTS clients using some means that are out of scope of 512 this document, the clients MUST select the appropriate DOTS gateway 513 to reach. The use of anycast addresses is NOT RECOMMENDED to reach 514 DOTS gateways. 516 +---+ 517 +------------| C1|----+ 518 | +---+ | 519 +--+ +-+-+ +---+ +-+-+ +--+ 520 |S2|------|G2 |------| C3|------|G1 |------|S1| 521 +--+ +-+-+ +---+ +-+-+ +--+ 522 | +---+ | 523 +------------| C2|----+ 524 +---+ 526 Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple 527 DOTS Servers 529 5.4. Multi-Homed Enterprise: Single ISP 531 The key difference of the scenario described in Section 4.4 compared 532 to the other scenarios is that multi-homing is provided by the same 533 ISP. Concretely, that ISP can decide to provision the enterprise 534 network with: 536 1. The same DOTS server for all network attachments. 538 2. Distinct DOTS servers for each network attachment. These DOTS 539 servers need to coordinate when a mitigation action is received 540 from the enterprise network. 542 In both cases, DOTS agents enabled within the enterprise network MAY 543 decide to select one or all network attachments to send DOTS 544 mitigation requests. 546 6. Security Considerations 548 DOTS-related security considerations are discussed in Section 4 of 549 [I-D.ietf-dots-architecture]. 551 TBD: In Home networks, if EST is used then how will the DOTS gateway 552 (EST client) be provisioned with credentials for initial enrolment 553 (see Section 2.2 in RFC 7030). 555 7. IANA Considerations 557 This document does not require any action from IANA. 559 8. Acknowledgements 561 Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, Wei Pan, 562 and Christian Jacquenet for sharing their comments on the mailing 563 list. 565 Thanks to Kirill Kasavchenko for the comments. 567 9. References 569 9.1. Normative References 571 [I-D.ietf-dots-architecture] 572 Mortensen, A., Andreasen, F., K, R., Teague, N., Compton, 573 R., and c. christopher_gray3@cable.comcast.com, 574 "Distributed-Denial-of-Service Open Threat Signaling 575 (DOTS) Architecture", draft-ietf-dots-architecture-10 576 (work in progress), December 2018. 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, 580 DOI 10.17487/RFC2119, March 1997, 581 . 583 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 584 "Default Address Selection for Internet Protocol Version 6 585 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 586 . 588 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 589 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 590 May 2017, . 592 9.2. Informative References 594 [I-D.boucadair-dots-server-discovery] 595 Boucadair, M., K, R., and P. Patil, "Distributed-Denial- 596 of-Service Open Threat Signaling (DOTS) Server Discovery", 597 draft-boucadair-dots-server-discovery-05 (work in 598 progress), October 2018. 600 [I-D.ietf-dots-data-channel] 601 Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P., 602 Mortensen, A., and N. Teague, "Distributed Denial-of- 603 Service Open Threat Signaling (DOTS) Data Channel 604 Specification", draft-ietf-dots-data-channel-24 (work in 605 progress), December 2018. 607 [I-D.ietf-dots-signal-channel] 608 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 609 Teague, "Distributed Denial-of-Service Open Threat 610 Signaling (DOTS) Signal Channel Specification", draft- 611 ietf-dots-signal-channel-26 (work in progress), December 612 2018. 614 [I-D.ietf-dots-use-cases] 615 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 616 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 617 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 618 in progress), January 2019. 620 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 621 Multihoming Architectures", RFC 3582, 622 DOI 10.17487/RFC3582, August 2003, 623 . 625 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 626 Gill, "IPv4 Multihoming Practices and Limitations", 627 RFC 4116, DOI 10.17487/RFC4116, July 2005, 628 . 630 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 631 Denial-of-Service Considerations", RFC 4732, 632 DOI 10.17487/RFC4732, December 2006, 633 . 635 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 636 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 637 . 639 [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent 640 Routing and Source Address Selection for IPv6 Hosts: 641 Overview of the Problem Space", RFC 8043, 642 DOI 10.17487/RFC8043, January 2017, 643 . 645 Authors' Addresses 647 Mohamed Boucadair 648 Orange 649 Rennes 35000 650 France 652 Email: mohamed.boucadair@orange.com 654 Tirumaleswar Reddy 655 McAfee, Inc. 656 Embassy Golf Link Business Park 657 Bangalore, Karnataka 560071 658 India 660 Email: TirumaleswarReddy_Konda@McAfee.com