idnits 2.17.00 (12 Aug 2021) /tmp/idnits10803/draft-ietf-dots-multihoming-08.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 (25 October 2021) is 207 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) ** Downref: Normative reference to an Informational RFC: RFC 8811 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: 28 April 2022 McAfee 6 W. Pan 7 Huawei Technologies 8 25 October 2021 10 Multi-homing Deployment Considerations for Distributed-Denial-of-Service 11 Open Threat Signaling (DOTS) 12 draft-ietf-dots-multihoming-08 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 28 April 2022. 37 Copyright Notice 39 Copyright (c) 2021 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 (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Multi-Homing Scenarios . . . . . . . . . . . . . . . . . . . 5 57 4.1. Multi-Homed Residential Single CPE . . . . . . . . . . . 5 58 4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream 59 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream 61 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7 63 5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 7 64 5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8 65 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream 66 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream 68 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 13 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 9.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 In many deployments, it may not be possible for a network to 81 determine the cause of a distributed Denial-of-Service (DoS) attack 82 [RFC4732]. Rather, the network may just realize that some resources 83 appear to be under attack. To help with such situations, the IETF 84 has specified the DDoS Open Threat Signaling (DOTS) architecture 85 [RFC8811], where a DOTS client can inform an upstream DOTS server 86 that its network is under a potential attack and that appropriate 87 mitigation actions are required. The DOTS protocols can be used to 88 coordinate real-time mitigation efforts which can evolve as the 89 attacks mutate, thereby reducing the impact of an attack and leading 90 to more efficient responsive actions. [RFC8903] identifies a set of 91 scenarios for DOTS; most of these scenarios involve a Customer 92 Premises Equipment (CPE). 94 The high-level base DOTS architecture is illustrated in Figure 1 95 ([RFC8811]): 97 +-----------+ +-------------+ 98 | Mitigator | ~~~~~~~~~~ | DOTS Server | 99 +-----------+ +-------------+ 100 | 101 | 102 | 103 +---------------+ +-------------+ 104 | Attack Target | ~~~~~~ | DOTS Client | 105 +---------------+ +-------------+ 107 Figure 1: Basic DOTS Architecture 109 [RFC8811] specifies that the DOTS client may be provided with a list 110 of DOTS servers; each of these servers is associated with one or more 111 IP addresses. These addresses may or may not be of the same address 112 family. The DOTS client establishes one or more DOTS sessions by 113 connecting to the provided DOTS server(s) addresses (e.g., by using 114 [RFC8973]). 116 DOTS may be deployed within networks that are connected to one single 117 upstream provider. DOTS 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 taken into account because: 125 * Sending a DOTS mitigation request to an arbitrary DOTS server 126 will not necessarily help in 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 services can be offered by all or a subset of upstream 136 providers. 138 3. Provide 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 for DOTS. 145 This document adopts the following methodology: 147 * Identify and extract viable deployment candidates from [RFC8903]. 149 * Augment the description with multi-homing technicalities, e.g., 151 - One vs. multiple upstream network providers 153 - One vs. multiple interconnect routers 155 - Provider-Independent (PI) vs. Provider-Aggregatable (PA) IP 156 addresses 158 * Describe the recommended behavior of DOTS clients and gateways for 159 each case. 161 Multi-homed DOTS agents are assumed to make use of the protocols 162 defined in [RFC9132] and [RFC8783]; no specific extension is required 163 to the base DOTS protocols for deploying DOTS in a multi-homed 164 context. 166 2. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119][RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 3. Terminology 176 This document makes use of the terms defined in [RFC8811] and 177 [RFC4116]. In particular: 179 Provider-Aggregatable (PA) addresses: are globally-unique addresses 180 assigned by a transit provider to a customer. The addresses are 181 considered "aggregatable" because the set of routes corresponding 182 to the PA addresses are usually covered by an aggregate route set 183 corresponding to the address space operated by the transit 184 provider, from which the assignment was made (Section 2 of 185 [RFC4116]). 187 Provider-Independent (PI) addresses: are globally-unique addresses 188 which are not assigned by a transit provider, but are provided by 189 some other organisation, usually a Regional Internet Registry 190 (RIR) (Section 2 of [RFC4116]). 192 IP indifferently refers to IPv4 or IPv6. 194 4. Multi-Homing Scenarios 196 This section describes some multi-homing scenarios that are relevant 197 to DOTS. In the following subsections, only the connections of 198 border routers are shown; internal network topologies are not 199 elaborated. 201 This section distinguishes between residential CPEs vs. enterprise 202 CPEs because PI addresses may be used for enterprises while this is 203 not the current practice for residential CPEs. 205 4.1. Multi-Homed Residential Single CPE 207 The scenario shown in Figure 2 is characterized as follows: 209 * The home network is connected to the Internet using one single 210 CPE. 212 * The CPE is connected to multiple provisioning domains (i.e., both 213 fixed and mobile networks). Provisioning domain (PvD) is 214 explained in [RFC7556]. 216 In a typical deployment scenario, these provisioning domains are 217 owned by the same provider (see Section 1 of [RFC8803]). Such a 218 deployment is meant to seamlessly use both fixed and cellular 219 networks for bonding, faster hand-overs, or better resiliency 220 purposes. 222 * Each of these provisioning domains assigns IP addresses/prefixes 223 to the CPE and provides additional configuration information such 224 as a list of DNS servers, DNS suffixes associated with the 225 network, default gateway address, and DOTS server's name 226 [RFC8973]. These addresses/prefixes are assumed to be Provider- 227 Aggregatable (PA). 229 * Because of ingress filtering, packets forwarded by the CPE towards 230 a given provisioning domain must be sent with a source IP address 231 that was assigned by that domain [RFC8043]. 233 +-------+ +-------+ 234 |Fixed | |Mobile | 235 |Network| |Network| 236 +---+---+ +---+---+ 237 | | Service Providers 238 ............|....................|....................... 239 +---------++---------+ Home Network 240 || 241 +--++-+ 242 | CPE | 243 +-----+ 244 ... (Internal Network) 246 Figure 2: Typical Multi-homed Residential CPE 248 4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 250 The scenario shown in Figure 3 is characterized as follows: 252 * The enterprise network is connected to the Internet using a single 253 router. 255 * That router is connected to multiple provisioning domains (i.e., 256 managed by distinct administrative entities). 258 Unlike the previous scenario, two sub-cases can be considered for an 259 enterprise network with regards to assigned addresses: 261 1. PI addresses/prefixes: The enterprise is the owner of the IP 262 addresses/prefixes; the same address/prefix is then used when 263 establishing communications over any of the provisioning domains. 265 2. PA addresses/prefixes: Each of the provisioning domains assigns 266 IP addresses/prefixes to the enterprise network. 268 +------+ +------+ 269 | ISP1 | | ISP2 | 270 +---+--+ +--+---+ 271 | | Service Providers 272 ............|....................|....................... 273 +---------++---------+ Enterprise Network 274 || 275 +--++-+ 276 | rtr | 277 +-----+ 278 ... (Internal Network) 280 Figure 3: Multi-homed Enterprise Network (Single CPE connected to 281 Multiple Networks) 283 4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 285 This scenario is similar to the one described in Section 4.2; the 286 main difference is that dedicated routers are used to connect to each 287 provisioning domain. 289 +------+ +------+ 290 | ISP1 | | ISP2 | 291 +---+--+ +--+---+ 292 | | Service Providers 293 ......................|..........|....................... 294 | | Enterprise Network 295 +---+--+ +--+---+ 296 | rtr1 | | rtr2 | 297 +------+ +------+ 299 ... (Internal Network) 301 Figure 4: Multi-homed Enterprise Network (Multiple CPEs, Multiple 302 ISPs) 304 4.4. Multi-homed Enterprise with the Same ISP 306 This scenario is a variant of Section 4.2 and Section 4.3 in which 307 multi-homing is supported by the same ISP (i.e., same provisioning 308 domain). 310 5. DOTS Multi-homing Deployment Considerations 312 Table 1 provides some sample, non-exhaustive, deployment schemes to 313 illustrate how DOTS agents may be deployed for each of the scenarios 314 introduced in Section 4. 316 +============================+=======================+==============+ 317 | Scenario | DOTS client | DOTS | 318 | | | gateway | 319 +============================+=======================+==============+ 320 | Residential CPE | CPE | N/A | 321 +----------------------------+-----------------------+--------------+ 322 | Single CPE, Multiple | Internal hosts or CPE | CPE | 323 | provisioning domains | | | 324 +----------------------------+-----------------------+--------------+ 325 | Multiple CPEs, Multiple | Internal hosts or all | CPEs (rtr1 | 326 | provisioning domains | CPEs (rtr1 and rtr2) | and rtr2) | 327 +----------------------------+-----------------------+--------------+ 328 | Multi-homed enterprise, | Internal hosts or all | CPEs (rtr1 | 329 | Single provisioning domain | CPEs (rtr1 and rtr2) | and rtr2) | 330 +----------------------------+-----------------------+--------------+ 332 Table 1: Sample Deployment Cases 334 These deployment schemes are further discussed in the following 335 subsections. 337 5.1. Residential CPE 339 Figure 5 depicts DOTS sessions that need to be established between a 340 DOTS client (C) and two DOTS servers (S1, S2) within the context of 341 the scenario described in Section 4.1. 343 For each provisioning domain, the DOTS client MUST resolve the DOTS 344 server's name provided by a provisioning domain ([RFC8973]) using the 345 DNS servers learned from the respective provisioning domain. 346 IPv6-capable DOTS clients MUST use the source address selection 347 algorithm defined in [RFC6724] to select the candidate source 348 addresses to contact each of these DOTS servers. DOTS sessions MUST 349 be established and MUST be maintained with each of the DOTS servers 350 because the mitigation scope of each of these servers is restricted. 351 The DOTS client SHOULD use the certificate provisioned by a 352 provisioning domain to authenticate itself to the DOTS server(s) 353 provided by the same provisioning domain. 355 When conveying a mitigation request to protect the attack target(s), 356 the DOTS client MUST select an available DOTS server whose network 357 has assigned the IP prefixes from which target prefixes/addresses are 358 derived. This implies that if no appropriate DOTS server is found, 359 the DOTS client MUST NOT send the mitigation request to any other 360 available DOTS server. 362 For example, a mitigation request to protect target resources bound 363 to a PA IP address/prefix cannot be satisfied by a provisioning 364 domain other than the one that owns those addresses/prefixes. 365 Consequently, if a CPE detects a DDoS attack that spreads over all 366 its network attachments, it MUST contact both DOTS servers for 367 mitigation purposes. 369 The DOTS client MUST be able to associate a DOTS server with each 370 provisioning domain. For example, if the DOTS client is provisioned 371 with S1 using DHCP when attaching to a first network and with S2 372 using Protocol Configuration Option (PCO) [TS.24008] when attaching 373 to a second network, the DOTS client must record the interface from 374 which a DOTS server was provisioned. DOTS signaling session to a 375 given DOTS server must be established using the interface from which 376 the DOTS server was provisioned. 378 +--+ 379 ----------|S1| 380 / +--+ 381 / DOTS Server Domain #1 382 / 383 +---+/ 384 | C | 385 +---+\ 386 \ 387 \ 388 \ +--+ 389 ----------|S2| 390 +--+ 391 DOTS Server Domain #2 393 Figure 5: DOTS Associations for a Multihomed Residential CPE 395 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 397 Figure 6 illustrates a first set of DOTS associations that can be 398 established with a DOTS gateway, which is enabled within the context 399 of the scenario described in Section 4.2. This deployment is 400 characterized as follows: 402 * One of more DOTS clients are enabled in hosts located in the 403 internal network. 405 * A DOTS gateway is enabled to aggregate and then relay the requests 406 towards upstream DOTS servers. 408 When PA addresses/prefixes are in use, the same considerations 409 discussed in Section 5.1 need to be followed by the DOTS gateway to 410 contact its DOTS server(s). The DOTS gateways can be reachable from 411 DOTS clients by using an unicast address or an anycast address. 413 Nevertheless, when PI addresses/prefixes are assigned, the DOTS 414 gateway MUST send mitigation requests to all its DOTS servers. 415 Otherwise, the attack traffic may still be delivered via the ISP 416 which hasn't received the mitigation request. 418 +--+ 419 ----------|S1| 420 +---+ / +--+ 421 | C1|----+ / DOTS Server Domain #1 422 +---+ | / 423 +---+ +-+-+/ 424 | C3|------| G | 425 +---+ +-+-+\ 426 +---+ | \ 427 | C2|----+ \ 428 +---+ \ +--+ 429 ----------|S2| 430 +--+ 431 DOTS Server Domain #2 433 Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple 434 DOTS Servers 436 An alternate deployment model is depicted in Figure 7. This 437 deployment assumes that: 439 * One or more DOTS clients are enabled in hosts located in the 440 internal network. These DOTS clients may use [RFC8973] to 441 discover their DOTS server(s). 443 * These DOTS clients communicate directly with upstream DOTS 444 servers. 446 If PI addresses/prefixes are in use, the DOTS client MUST send a 447 mitigation request to all the DOTS servers. The use of anycast 448 addresses to reach the DOTS servers is NOT RECOMMENDED. 450 If PA addresses/prefixes are used, the same considerations discussed 451 in Section 5.1 need to be followed by the DOTS clients. Because DOTS 452 clients are not embedded in the CPE and multiple addreses/prefixes 453 may not be assigned to the DOTS client (typically in an IPv4 454 context), some issues may arise in how to steer traffic towards the 455 appropriate DOTS server by using the appropriate source IP address. 456 These complications discussed in [RFC4116] are not specific to DOTS. 458 .......... 459 . +--+ . 460 +--------|C1|--------+ 461 | . +--+ . | 462 | . . | 463 +--+ . +--+ . +--+ 464 |S2|------|C3|------|S1| 465 +--+ . +--+ . +--+ 466 | . . | 467 | . +--+ . | 468 +--------|C2|--------+ 469 . +--+ . 470 .......... 471 DOTS Client 472 Domain 474 Figure 7: Multiple DOTS Clients, Multiple DOTS Servers 476 Another deployment approach is to enable many DOTS clients; each of 477 them is responsible for handling communications with a specific DOTS 478 server (see Figure 8). 480 .......... 481 . +--+ . 482 +--------|C1| . 483 | . +--+ . 484 +--+ . +--+ . +--+ 485 |S2| . |C2|------|S1| 486 +--+ . +--+ . +--+ 487 .......... 488 DOTS Client 489 Domain 491 Figure 8: Single Homed DOTS Clients 493 Each DOTS client SHOULD be provided with policies (e.g., a prefix 494 filter that will be against DDoS detection alarms) that will trigger 495 DOTS communications with the DOTS servers. Such policies will help 496 the DOTS client to select the appropriate destination DOTS server. 498 The CPE MUST select the appropriate source IP address when forwarding 499 DOTS messages received from an internal DOTS client. If anycast 500 addresses are used to reach multiple DOTS servers, the CPE may not be 501 able to select the appropriate provisioning domain to which the 502 mitigation request should be forwarded. As a consequence, the 503 request may not be forwarded to the appropriate DOTS server. 505 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 507 The deployments depicted in Figures 7 and 8 also apply to the 508 scenario described in Section 4.3. One specific problem for this 509 scenario is to select the appropriate exit router when contacting a 510 given DOTS server. 512 An alternative deployment scheme is shown in Figure 9: 514 * DOTS clients are enabled in hosts located in the internal network. 516 * A DOTS gateway is enabled in each CPE (rtr1, rtr2). 518 * Each of these DOTS gateways communicates with the DOTS server of 519 the provisioning domain. 521 When PI addresses/prefixes are used, DOTS clients MUST contact all 522 the DOTS gateways to send a DOTS message. DOTS gateways will then 523 relay the request to the DOTS server. The use of anycast addresses 524 to establish DOTS sessions between DOTS clients and DOTS gateways is 525 not an option. 527 When PA addresses/prefixes are used, but no filter rules are provided 528 to DOTS clients, the latter MUST contact all DOTS gateways 529 simultaneously to send a DOTS message. Upon receipt of a request by 530 a DOTS gateway, it MUST check whether the request is to be forwarded 531 upstream (if the target IP prefix is managed by the upstream server) 532 or rejected. 534 When PA addresses/prefixes are used, but specific filter rules are 535 provided to DOTS clients using some means that are out of scope of 536 this document, the clients MUST select the appropriate DOTS gateway 537 to reach. The use of anycast addresses is NOT RECOMMENDED to reach 538 DOTS gateways. 540 +---+ 541 +------------| C1|----+ 542 | +---+ | 543 +--+ +-+-+ +---+ +-+-+ +--+ 544 |S2|------|G2 |------| C3|------|G1 |------|S1| 545 +--+ +-+-+ +---+ +-+-+ +--+ 546 | +---+ | 547 +------------| C2|----+ 548 +---+ 550 Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple 551 DOTS Servers 553 5.4. Multi-Homed Enterprise: Single ISP 555 The key difference of the scenario described in Section 4.4 compared 556 to the other scenarios is that multi-homing is provided by the same 557 ISP. Concretely, that ISP can decide to provision the enterprise 558 network with: 560 * The same DOTS server for all network attachments. 562 * Distinct DOTS servers for each network attachment. These DOTS 563 servers need to coordinate when a mitigation action is received 564 from the enterprise network. 566 In both cases, DOTS agents enabled within the enterprise network MAY 567 decide to select one or all network attachments to send DOTS 568 mitigation requests. 570 6. Security Considerations 572 DOTS-related security considerations are discussed in Section 4 of 573 [RFC8811]. 575 DOTS clients should control the information that they share with peer 576 DOTS servers. In particular, if a DOTS client maintains DOTS 577 associations with specific DOTS servers per interconnection link, the 578 DOTS client SHOULD NOT leak information specific to a given link to 579 DOTS servers on different interconnection links that are not 580 authorized to mitigate attacks for that given link. Whether this 581 constraint is relaxed is deployment-specific and must be subject to 582 explicit consent from the DOTS client domain administrator. How to 583 seek for such consent is implementation- and deployment-specific. 585 7. IANA Considerations 587 This document does not require any action from IANA. 589 8. Acknowledgements 591 Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and 592 Christian Jacquenet for sharing their comments on the mailing list. 594 Thanks to Kirill Kasavchenko for the comments. 596 9. References 598 9.1. Normative References 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, 602 DOI 10.17487/RFC2119, March 1997, 603 . 605 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 606 "Default Address Selection for Internet Protocol Version 6 607 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 608 . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 615 Teague, N., and R. Compton, "DDoS Open Threat Signaling 616 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 617 August 2020, . 619 9.2. Informative References 621 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 622 Multihoming Architectures", RFC 3582, 623 DOI 10.17487/RFC3582, August 2003, 624 . 626 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 627 Gill, "IPv4 Multihoming Practices and Limitations", 628 RFC 4116, DOI 10.17487/RFC4116, July 2005, 629 . 631 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 632 Denial-of-Service Considerations", RFC 4732, 633 DOI 10.17487/RFC4732, December 2006, 634 . 636 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 637 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 638 . 640 [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent 641 Routing and Source Address Selection for IPv6 Hosts: 642 Overview of the Problem Space", RFC 8043, 643 DOI 10.17487/RFC8043, January 2017, 644 . 646 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 647 Denial-of-Service Open Threat Signaling (DOTS) Data 648 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 649 May 2020, . 651 [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., 652 Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", 653 RFC 8803, DOI 10.17487/RFC8803, July 2020, 654 . 656 [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 657 L., and K. Nishizuka, "Use Cases for DDoS Open Threat 658 Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, 659 . 661 [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling 662 (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, 663 January 2021, . 665 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 666 "Distributed Denial-of-Service Open Threat Signaling 667 (DOTS) Signal Channel Specification", RFC 9132, 668 DOI 10.17487/RFC9132, September 2021, 669 . 671 [TS.24008] 3GPP, "Mobile radio interface Layer 3 specification; Core 672 network protocols; Stage 3 (Release 16)", December 2019, 673 . 675 Authors' Addresses 676 Mohamed Boucadair 677 Orange 678 35000 Rennes 679 France 681 Email: mohamed.boucadair@orange.com 683 Tirumaleswar Reddy 684 McAfee, Inc. 685 Embassy Golf Link Business Park 686 Bangalore 560071 687 Karnataka 688 India 690 Email: TirumaleswarReddy_Konda@McAfee.com 692 Wei Pan 693 Huawei Technologies 695 Email: william.panwei@huawei.com