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