idnits 2.17.00 (12 Aug 2021) /tmp/idnits9495/draft-ietf-dots-multihoming-00.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 14, 2019) is 1222 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 18, 2019 McAfee 6 January 14, 2019 8 Multi-homing Deployment Considerations for Distributed-Denial-of-Service 9 Open Threat Signaling (DOTS) 10 draft-ietf-dots-multihoming-00 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 a set of 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 18, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream 67 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.4. Multi-homed Enterprise: Single ISP . . . . . . . . . . . 11 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 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 for a distributed Denial-of-Service (DoS) attack 81 [RFC4732], but instead just realize that some resources seem to be 82 under attack. To fill that gap, the IETF is specifying an 83 architecture, called DDoS Open Threat Signaling (DOTS) 84 [I-D.ietf-dots-architecture], in which a DOTS client can inform a 85 DOTS server that the network is under a potential attack and that 86 appropriate mitigation actions are required. Indeed, because the 87 lack of a common method to coordinate a real-time response among 88 involved actors and network domains inhibits the effectiveness of 89 DDoS attack mitigation, DOTS protocol is meant to carry requests for 90 DDoS attack mitigation, thereby reducing the impact of an attack and 91 leading to more efficient defensive actions. 92 [I-D.ietf-dots-use-cases] identifies a set of scenarios for DOTS; 93 almost all these scenarios involve a CPE. 95 The basic 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 associated with one or 112 more IP addresses. These addresses may or may not be of the same 113 address family. The DOTS client establishes one or more DOTS 114 sessions by connecting to the provided DOTS server(s) addresses. 116 DOTS may be deployed within networks that are connected to one single 117 upstream provider. It can also be enabled within networks that are 118 multi-homed. The reader may refer to [RFC3582] for an overview of 119 multi-homing goals and motivations. This document discusses DOTS 120 multi-homing considerations. Specifically, the document aims to: 122 1. Complete the base DOTS architecture with multi-homing specifics. 123 Those specifics need to be taking into account because: 125 * Send a DOTS mitigation request to an arbitrary DOTS server 126 won't help mitigating a DDoS attack. 128 * Blindly forking all DOTS mitigation requests among all 129 available DOTS servers is suboptimal. 131 * Sequentially contacting DOTS servers may increase the delay 132 before a mitigation plan is enforced. 134 2. Identify DOTS deployment schemes in a multi-homing context, where 135 DOTS service can be offered by all or a subset of upstream 136 providers. 138 3. Sketch guidelines and recommendations for placing DOTS requests 139 in multi-homed networks, e.g.,: 141 * Select the appropriate DOTS server(s). 143 * Identify cases where anycast is not recommended. 145 This document adopts the following methodology: 147 o Identify and extract viable deployment candidates from 148 [I-D.ietf-dots-use-cases]. 150 o Augment the description with multi-homing technicalities, e.g., 152 * One vs. multiple upstream network providers 154 * One vs. multiple interconnect routers 156 * Provider-Independent (PI) vs. Provider-Aggregatable (PA) IP 157 addresses 159 o Describe the recommended behavior of DOTS clients and gateways for 160 each case. 162 Multi-homed DOTS agents are assumed to make use of the protocols 163 defined in [I-D.ietf-dots-signal-channel] and 164 [I-D.ietf-dots-data-channel]; no specific extension is required to 165 the base DOTS protocols for deploying DOTS in a multihomed context. 167 2. Requirements Language 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119][RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 3. Terminology 177 This document makes use of the terms defined in 178 [I-D.ietf-dots-architecture] and [RFC4116]. 180 IP refers to both IPv4 and IPv6. 182 4. Multi-Homing Scenarios 184 This section briefly describes some multi-homing scenarios that are 185 relevant to DOTS. In the following sub-sections, only the 186 connections of border routers are shown; internal network topologies 187 are not elaborated hereafter. 189 This section distinguishes between residential CPEs vs. enterprise 190 CPEs because PI addresses may be used for enterprises while this is 191 not the current practice for residential CPEs. 193 4.1. Residential Single CPE 195 The scenario shown in Figure 2 is characterized as follows: 197 o The home network is connected to the Internet using one single CPE 198 (Customer Premises Equipment). 200 o The CPE is connected to multiple provisioning domains (i.e., both 201 fixed and mobile networks). Provisioning domain (PvD) is 202 explained in [RFC7556]. 204 o Each of these provisioning domains assigns IP addresses/prefixes 205 to the CPE and provides additional configuration information such 206 as a list of DNS servers, DNS suffixes associated with the 207 network, default gateway address, and DOTS server's name 208 [I-D.boucadair-dots-server-discovery]. These addresses/prefixes 209 are said to be Provider-Aggregatable (PA). 211 o Because of ingress filtering, packets forwarded by the CPE to a 212 given provisioning domain must be send with a source IP address 213 that was assigned by that network [RFC8043]. 215 +-------+ +-------+ 216 |Fixed | |Mobile | 217 |Network| |Network| 218 +---+---+ +---+---+ 219 | | Service Providers 220 ............|....................|....................... 221 +---------++---------+ Home Network 222 || 223 +--++-+ 224 | CPE | 225 +-----+ 226 ... (Internal Network) 228 Figure 2: Typical Multi-homed Residential CPE 230 4.2. Multi-homed Enterprise: Single CPE, Multiple Upstream ISPs 232 The scenario shown in Figure 3 is characterized as follows: 234 o The enterprise network is connected to the Internet using one 235 single router. 237 o That router is connected to multiple provisioning domains (i.e., 238 managed by distinct administrative entities). 240 Unlike the previous scenario, two sub-cases can be considered for an 241 enterprise network with regards to assigned addresses: 243 1. PI addresses/prefixes: The enterprise is the owner of the IP 244 addresses/prefixes; the same address/prefix is then used for 245 communication placed using any of the provisioning domains. 247 2. PA addresses/prefixes: each of provisioning domains assigns IP 248 addresses/prefixes to the enterprise network. 250 +------+ +------+ 251 | ISP1 | | ISP2 | 252 +---+--+ +--+---+ 253 | | Service Providers 254 ............|....................|....................... 255 +---------++---------+ Enterprise Network 256 || 257 +--++-+ 258 | rtr | 259 +-----+ 260 ... (Internal Network) 262 Figure 3: Multi-homed Enterprise Network (Single CPE connected to 263 Multiple Networks) 265 4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 267 This scenario is similar to the one in Section 4.2; the main 268 difference is that dedicated routers are used to connect to each 269 provisioning domain. 271 +------+ +------+ 272 | ISP1 | | ISP2 | 273 +---+--+ +--+---+ 274 | | Service Providers 275 ......................|..........|....................... 276 | | Enterprise Network 277 +---+--+ +--+---+ 278 | rtr1 | | rtr2 | 279 +------+ +------+ 281 ... (Internal Network) 283 Figure 4: Multi-homed Enterprise Network (Multiple CPEs, Multiple 284 ISPs) 286 4.4. Multi-homed Enterprise with the Same ISP 288 This scenario is a variant of Section 4.2 and Section 4.3 in which 289 multi-homing is provided by the same ISP (i.e., same provisioning 290 domain). 292 5. DOTS Deployment Considerations 294 Table 1 provides some sample (non-exhaustive) deployment schemes to 295 illustrate how DOTS agents may be deployed for each of the scenarios 296 introduced in Section 4. 298 +---------------------------+-------------------------+-------------+ 299 | Scenario | DOTS client | DOTS | 300 | | | gateway | 301 +---------------------------+-------------------------+-------------+ 302 | Residential CPE | CPE | N/A | 303 +---------------------------+-------------------------+-------------+ 304 | Single CPE, Multiple | internal hosts or CPE | CPE | 305 | provisioning domains | | | 306 +---------------------------+-------------------------+-------------+ 307 | Multiple CPEs, Multiple | internal hosts or all | CPEs (rtr1 | 308 | provisioning domains | CPEs (rtr1 and rtr2) | and rtr2) | 309 +---------------------------+-------------------------+-------------+ 310 | Multi-homed enterprise, | internal hosts or all | CPEs (rtr1 | 311 | Single provisioning | CPEs (rtr1 and rtr2) | and rtr2) | 312 | domain | | | 313 +---------------------------+-------------------------+-------------+ 315 Table 1: Sample Deployment Cases 317 These deployment schemes are further discussed in the following sub- 318 sections. 320 5.1. Residential CPE 322 Figure 5 depicts DOTS sessions that are required to be established 323 between a DOTS client (C) and DOTS servers (S1, S2) in the context of 324 the scenario described in Section 4.1. 326 For each provisioning domain, the DOTS client MUST resolve the DOTS 327 server's name provided by a provisioning domain 328 ([I-D.boucadair-dots-server-discovery]) using the DNS servers learned 329 from the same provisioning domain. The DOTS client MUST use the 330 source address selection algorithm defined in [RFC6724] to select the 331 candidate source addresses to contact each of these DOTS servers. 332 DOTS sessions must be established and maintained with each of the 333 DOTS servers because the mitigation scope of these servers is 334 restricted. The DOTS client SHOULD use the certificate provisioned 335 by a provisioning domain to authenticate itself to the DOTS server 336 provided by the same provisioning domain. When conveying a 337 mitigation request to protect the attack target(s), the DOTS client 338 among the DOTS servers available MUST select a DOTS server whose 339 network has assigned the prefixes from which target prefixes and 340 target IP addresses are derived. This implies that if no appropriate 341 DOTS server is found, the DOTS client must not send the mitigation 342 request to any DOTS server. For example, mitigation request to 343 protect target resources bound to a PA IP address/prefix cannot be 344 honored by an provisioning domain other than the one that owns those 345 addresses/prefixes. Consequently, Typically, if a CPE detects a DDoS 346 attack on all its network attachments, it must contact both DOTS 347 servers for mitigation. Nevertheless, if the DDoS attack is received 348 from one single network, then only the DOTS server of that network 349 must be contacted. 351 The DOTS client MUST be able to associate a DOTS server with each 352 provisioning domain. For example, if the DOTS client is provisioned 353 with S1 using DHCP when attaching to a first network and with S2 354 using Protocol Configuration Option (PCO) when attaching to a second 355 network, the DOTS client must record the interface from which a DOTS 356 server was provisioned. DOTS signaling session to a given DOTS 357 server must be established using the interface from which the DOTS 358 server was provisioned. 360 +--+ 361 -----------|S1| 362 / +--+ 363 / 364 / 365 +---+/ 366 | C | 367 +---+\ 368 \ 369 \ 370 \ +--+ 371 -----------|S2| 372 +--+ 374 Figure 5: DOTS associations for a multihomed residential CPE 376 5.2. Multi-homed Enterprise: Single CPE, Multiple Upstream ISPs 378 Figure 6 illustrates a first set of DOTS associations that can be 379 established with a DOTS gateway is enabled in the context of the 380 scenario described in Section 4.2. This deployment is characterized 381 as follows: 383 o One of more DOTS clients are enabled in hosts located in the 384 internal network. 386 o A DOTS gateway is enabled to aggregate/relay the requests to 387 upstream DOTS servers. 389 When PA addresses/prefixes are in use, the same considerations 390 discussed in Section 5.1 are to be followed by the DOTS gateway to 391 contact its DOTS server(s). The DOTS gateways can be reachable from 392 DOTS client using a unicast or anycast address. 394 Nevertheless, when PI addresses/prefixes are assigned, the DOTS 395 gateway MUST sent the same request to all its DOTS servers. 397 +--+ 398 -----------|S1| 399 +---+ / +--+ 400 | C1|----+ / 401 +---+ | / 402 +---+ +-+-+/ 403 | C3|------| G | 404 +---+ +-+-+\ 405 +---+ | \ 406 | C2|----+ \ 407 +---+ \ +--+ 408 -----------|S2| 409 +--+ 411 Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple DOTS 412 Servers 414 An alternate deployment model is depicted in Figure 7. This 415 deployment assumes that: 417 o One of more DOTS clients are enabled in hosts located in the 418 internal network. These DOTS client may use 419 [I-D.boucadair-dots-server-discovery] to discover its DOTS 420 server(s). 422 o These DOTS clients communicate directly with upstream DOTS 423 servers. 425 If PI addresses/prefixes are in use, the DOTS client can send the 426 mitigation request for all its PI addresses/prefixes to any one of 427 the DOTS servers. The use of anycast addresses is NOT RECOMMENDED. 429 If PA addresses/prefxies are used, the same considerations discussed 430 in Section 5.1 are to be followed by the DOTS clients. Because DOTS 431 clients are not located on the CPE and multiple addreses/prefixes may 432 not be assigned to the DOTS client (IPv4 context, typically), some 433 complications arise to steer the traffic to the appropriate DOTS 434 server using the appropriate source IP address. These complications 435 discussed in [RFC4116] are not specific to DOTS . 437 +--+ 438 +--------|C1|--------+ 439 | +--+ | 440 +--+ +--+ +--+ 441 |S2|------|C3|------|S1| 442 +--+ +--+ +--+ 443 | +--+ | 444 +--------|C2|--------+ 445 +--+ 447 Figure 7: Multiple DOTS Clients, Multiple DOTS Servers 449 Another deployment approach is to enable many DOTS clients; each of 450 them responsible to handle communication with a specific DOTS server 451 (see Figure 8). Each DOTS client is provided with policies (e.g., 452 prefix filter) that will trigger DOTS communications with the DOTS 453 servers. The CPE MUST select the appropriate source IP address when 454 forwarding DOTS messages received from an internal DOTS client. If 455 anycast addresses are used to reach DOTS servers, the CPE may not be 456 able to select the appropriate provisioning domain to which the 457 mitigation request should be forwarded. As a consequence, the 458 request may not be forwarded to the appropriate DOTS server. 460 +--+ 461 +--------|C1| 462 | +--+ 463 +--+ +--+ +--+ 464 |S2| |C2|------|S1| 465 +--+ +--+ +--+ 467 Figure 8: Single Homed DOTS Clients 469 5.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 471 The deployments depicted in Figure 7 and Figure 8 apply also for the 472 scenario described in Section 4.3. One specific problem for this 473 scenario is to select the appropriate exit router when contacting a 474 given DOTS server. 476 An alternative deployment scheme is shown in Figure 9: 478 o DOTS clients are enabled in hosts located in the internal network. 480 o A DOTS gateway is enabled in each CPE (rtr1, rtr2). 482 o Each of these DOTS gateways communicate with the DOTS server of 483 the provisioning domain. 485 When PI addresses/prefixes are used, DOTS clients can contact any of 486 the DOTS gateways to send a DOTS message. DOTS gateway will then 487 relay the request to the DOTS server. Note that the use of anycast 488 addresses is NOT RECOMMENDED to establish DOTS sessions between DOTS 489 client and DOTS gateways. 491 When PA addresses/prefixes are used, but no filter rules are provided 492 to DOTS clients, these MUST contact all DOTS gateways simultaneously 493 to send a DOTS message. Upon receipt of a request by a DOTS gateway, 494 it MUST check whether the request is to be forwarded upstream or be 495 rejected. 497 When PA addresses/prefixes are used, but specific filter rules are 498 provided to DOTS clients using some means that are out of scope, 499 these later MUST select the appropriate DOTS gateway to be contacted. 500 The use of anycast is NOT RECOMMENDED to reach DOTS gateways. 502 +---+ 503 +------------| C1|----+ 504 | +---+ | 505 +--+ +-+-+ +---+ +-+-+ +--+ 506 |S2|------|G2 |------| C3|------|G1 |------|S1| 507 +--+ +-+-+ +---+ +-+-+ +--+ 508 | +---+ | 509 +------------| C2|----+ 510 +---+ 512 Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple 513 DOTS Servers 515 5.4. Multi-homed Enterprise: Single ISP 517 The key difference of the scenario described in Section 4.4 compared 518 to the other scenarios is that multi-homing is provided by the same 519 ISP. Concretely, that ISP can decided to provision the enterprise 520 network with: 522 1. The same DOTS server for all network attachments. 524 2. Distinct DOTS servers for each network attachment. These DOTS 525 servers needs to coordinate when a mitigation action is received 526 from the enterprise network. 528 In both cases, DOTS agents enabled within the enterprise network may 529 decide to select one or all network attachments to place DOTS 530 mitigation requests. 532 6. Security Considerations 534 DOTS-related security considerations are discussed in Section 4 of 535 [I-D.ietf-dots-architecture]. 537 TBD: In Home networks, if EST is used then how will the DOTS gateway 538 (EST client) be provisioned with credentials for initial enrolment 539 (see Section 2.2 in RFC 7030). 541 7. IANA Considerations 543 This document does not require any action from IANA. 545 8. Acknowledgements 547 Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and Wei 548 Pan for sharing their comments on the mailing list. 550 Thanks to Kirill Kasavchenko for the comments. 552 9. References 554 9.1. Normative References 556 [I-D.ietf-dots-architecture] 557 Mortensen, A., Andreasen, F., K, R., Teague, N., Compton, 558 R., and c. christopher_gray3@cable.comcast.com, 559 "Distributed-Denial-of-Service Open Threat Signaling 560 (DOTS) Architecture", draft-ietf-dots-architecture-10 561 (work in progress), December 2018. 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, 565 DOI 10.17487/RFC2119, March 1997, 566 . 568 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 569 "Default Address Selection for Internet Protocol Version 6 570 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 571 . 573 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 574 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 575 May 2017, . 577 9.2. Informative References 579 [I-D.boucadair-dots-server-discovery] 580 Boucadair, M., K, R., and P. Patil, "Distributed-Denial- 581 of-Service Open Threat Signaling (DOTS) Server Discovery", 582 draft-boucadair-dots-server-discovery-05 (work in 583 progress), October 2018. 585 [I-D.ietf-dots-data-channel] 586 Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P., 587 Mortensen, A., and N. Teague, "Distributed Denial-of- 588 Service Open Threat Signaling (DOTS) Data Channel 589 Specification", draft-ietf-dots-data-channel-24 (work in 590 progress), December 2018. 592 [I-D.ietf-dots-signal-channel] 593 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 594 Teague, "Distributed Denial-of-Service Open Threat 595 Signaling (DOTS) Signal Channel Specification", draft- 596 ietf-dots-signal-channel-26 (work in progress), December 597 2018. 599 [I-D.ietf-dots-use-cases] 600 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 601 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 602 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 603 in progress), January 2019. 605 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 606 Multihoming Architectures", RFC 3582, 607 DOI 10.17487/RFC3582, August 2003, 608 . 610 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 611 Gill, "IPv4 Multihoming Practices and Limitations", 612 RFC 4116, DOI 10.17487/RFC4116, July 2005, 613 . 615 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 616 Denial-of-Service Considerations", RFC 4732, 617 DOI 10.17487/RFC4732, December 2006, 618 . 620 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 621 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 622 . 624 [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent 625 Routing and Source Address Selection for IPv6 Hosts: 626 Overview of the Problem Space", RFC 8043, 627 DOI 10.17487/RFC8043, January 2017, 628 . 630 Authors' Addresses 632 Mohamed Boucadair 633 Orange 634 Rennes 35000 635 France 637 Email: mohamed.boucadair@orange.com 639 Tirumaleswar Reddy 640 McAfee, Inc. 641 Embassy Golf Link Business Park 642 Bangalore, Karnataka 560071 643 India 645 Email: TirumaleswarReddy_Konda@McAfee.com