idnits 2.17.1 draft-ietf-dots-multihoming-13.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 (26 April 2022) is 729 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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: Informational T. Reddy.K 5 Expires: 28 October 2022 Akamai 6 W. Pan 7 Huawei Technologies 8 26 April 2022 10 Multi-homing Deployment Considerations for Distributed-Denial-of-Service 11 Open Threat Signaling (DOTS) 12 draft-ietf-dots-multihoming-13 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 and client-domain DOTS 19 gateways when multihomed. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 28 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Multi-Homing Scenarios . . . . . . . . . . . . . . . . . . . 5 58 4.1. Multi-Homed Residential Single CPE . . . . . . . . . . . 5 59 4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream 60 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream 62 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7 64 5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 8 65 5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream 67 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream 69 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 13 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 9.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 appear to be under attack. To help with such situations, the IETF 85 has specified the DDoS Open Threat Signaling (DOTS) architecture 86 [RFC8811], where a DOTS client can inform an upstream DOTS server 87 that its network is under a potential attack and that appropriate 88 mitigation actions are required. The DOTS protocols can be used to 89 coordinate real-time mitigation efforts which can evolve as the 90 attacks mutate, thereby reducing the impact of an attack and leading 91 to more efficient responsive actions. [RFC8903] identifies a set of 92 scenarios for DOTS; most of these scenarios involve a Customer 93 Premises Equipment (CPE). 95 The high-level base DOTS architecture is illustrated in Figure 1 96 ([RFC8811]): 98 +-----------+ +-------------+ 99 | Mitigator | ~~~~~~~~~~ | DOTS Server | 100 +-----------+ +-------------+ 101 | 102 | 103 | 104 +---------------+ +-------------+ 105 | Attack Target | ~~~~~~ | DOTS Client | 106 +---------------+ +-------------+ 108 Figure 1: Basic DOTS Architecture 110 [RFC8811] specifies that the DOTS client may be provided with a list 111 of DOTS servers; each of these servers is associated with one or more 112 IP addresses. These addresses may or may not be of the same address 113 family. The DOTS client establishes one or more DOTS sessions by 114 connecting to the provided DOTS server(s) addresses (e.g., by using 115 [RFC8973]). 117 DOTS may be deployed within networks that are connected to one single 118 upstream provider. DOTS 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 * Sending a DOTS mitigation request to an arbitrary DOTS server 127 will not necessarily help in mitigating a DDoS attack. 129 * Randomly replicating 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. Provide 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 for DOTS. 146 This document adopts the following methodology: 148 * Identify and extract viable deployment candidates from [RFC8903]. 150 * 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 * Describe the recommended behavior of DOTS clients and client- 160 domain DOTS gateways for each case. 162 Multi-homed DOTS agents are assumed to make use of the protocols 163 defined in [RFC9132] and [RFC8783]. This document does not require 164 any specific extension to the base DOTS protocols for deploying DOTS 165 in a multi-homed 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 [RFC8811], [RFC8612], 178 and [RFC4116]. In particular: 180 Provider-Aggregatable (PA) addresses: globally-unique addresses 181 assigned by a transit provider to a customer. The addresses are 182 considered "aggregatable" because the set of routes corresponding 183 to the PA addresses are usually covered by an aggregate route set 184 corresponding to the address space operated by the transit 185 provider, from which the assignment was made (Section 2 of 186 [RFC4116]). 188 Provider-Independent (PI) addresses: globally-unique addresses that 189 are not assigned by a transit provider, but are provided by some 190 other organisation, usually a Regional Internet Registry (RIR) 191 (Section 2 of [RFC4116]). 193 IP indifferently refers to IPv4 or IPv6. 195 4. Multi-Homing Scenarios 197 This section describes some multi-homing scenarios that are relevant 198 to DOTS. In the following subsections, only the connections of 199 border routers are shown; internal network topologies are not 200 elaborated. 202 A multihomed network may enable DOTS for all or a subset of its 203 upstream interconnection links. In such a case, DOTS servers can be 204 explicitly configured or dynamically discovered by a DOTS client 205 using means such as those discussed in [RFC8973]. These DOTS servers 206 can be owned by the upstream provider, managed by a third-party 207 (e.g., mitigation service provider), or a combination thereof. 209 If a DOTS server is explicitly configured, it is assumed that an 210 interface is also provided to bind the DOTS service to an 211 interconnection link. If no interface is provided, this means that 212 the DOTS server can be reached via any active interface. 214 This section distinguishes between residential CPEs vs. enterprise 215 CPEs because PI addresses may be used for enterprises while this is 216 not the current practice for residential CPEs. 218 In the following subsections, all or a subset of interconnection 219 links are associated with DOTS servers. 221 4.1. Multi-Homed Residential Single CPE 223 The scenario shown in Figure 2 is characterized as follows: 225 * The home network is connected to the Internet using one single 226 CPE. 228 * The CPE is connected to multiple provisioning domains (i.e., both 229 fixed and mobile networks). Provisioning domain (PvD) is 230 explained in [RFC7556]. 232 In a typical deployment scenario, these provisioning domains are 233 owned by the same provider (see Section 1 of [RFC8803]). Such a 234 deployment is meant to seamlessly use both fixed and cellular 235 networks for bonding, faster hand-overs, or better resiliency 236 purposes. 238 * Each of these provisioning domains assigns IP addresses/prefixes 239 to the CPE and provides additional configuration information such 240 as a list of DNS servers, DNS suffixes associated with the 241 network, default gateway address, and DOTS server's name 242 [RFC8973]. These addresses/prefixes are assumed to be Provider- 243 Aggregatable (PA). 245 * Because of ingress filtering, packets forwarded by the CPE towards 246 a given provisioning domain must be sent with a source IP address 247 that was assigned by that domain [RFC8043]. 249 +-------+ +-------+ 250 |Fixed | |Mobile | 251 |Network| |Network| 252 +---+---+ +---+---+ 253 | | Service Providers 254 ............|....................|....................... 255 +---------++---------+ Home Network 256 || 257 +--++-+ 258 | CPE | 259 +-----+ 260 ... (Internal Network) 262 Figure 2: Typical Multi-homed Residential CPE 264 4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 266 The scenario shown in Figure 3 is characterized as follows: 268 * The enterprise network is connected to the Internet using a single 269 router. 271 * That router is connected to multiple provisioning domains managed 272 by distinct administrative entities. 274 Unlike the previous scenario, two sub-cases can be considered for an 275 enterprise network with regards to assigned addresses: 277 1. PI addresses/prefixes: The enterprise is the owner of the IP 278 addresses/prefixes; the same address/prefix is then used when 279 establishing communications over any of the provisioning domains. 281 2. PA addresses/prefixes: Each of the provisioning domains assigns 282 IP addresses/prefixes to the enterprise network. These 283 addresses/prefixes are used when communicating over the 284 provisioning domain that assigned them. 286 +------+ +------+ 287 | ISP1 | | ISP2 | 288 +---+--+ +--+---+ 289 | | Service Providers 290 ............|....................|....................... 291 +---------++---------+ Enterprise Network 292 || 293 +--++-+ 294 | CPE | 295 +-----+ 296 ... (Internal Network) 298 Figure 3: Multi-homed Enterprise Network (Single CPE connected to 299 Multiple Networks) 301 4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 303 This scenario is similar to the one described in Section 4.2; the 304 main difference is that dedicated routers (CPE1 and CPE2) are used to 305 connect to each provisioning domain. 307 +------+ +------+ 308 | ISP1 | | ISP2 | 309 +---+--+ +--+---+ 310 | | Service Providers 311 ......................|..........|....................... 312 | | Enterprise Network 313 +---+--+ +--+---+ 314 | CPE1 | | CPE2 | 315 +------+ +------+ 317 ... (Internal Network) 319 Figure 4: Multi-homed Enterprise Network (Multiple CPEs, Multiple 320 ISPs) 322 4.4. Multi-homed Enterprise with the Same ISP 324 This scenario is a variant of Sections 4.2 and 4.3 in which multi- 325 homing is supported by the same ISP (i.e., same provisioning domain). 327 5. DOTS Multi-homing Deployment Considerations 329 Table 1 provides some sample, non-exhaustive, deployment schemes to 330 illustrate how DOTS agents may be deployed for each of the scenarios 331 introduced in Section 4. 333 +=========================+=======================+===============+ 334 | Scenario | DOTS client | Client-domain | 335 | | | DOTS gateway | 336 +=========================+=======================+===============+ 337 | Residential CPE | CPE | N/A | 338 +-------------------------+-----------------------+---------------+ 339 | Single CPE, Multiple | Internal hosts or CPE | CPE | 340 | provisioning domains | | | 341 +-------------------------+-----------------------+---------------+ 342 | Multiple CPEs, Multiple | Internal hosts or all | CPEs (CPE1 | 343 | provisioning domains | CPEs (CPE1 and CPE2) | and CPE2) | 344 +-------------------------+-----------------------+---------------+ 345 | Multi-homed enterprise, | Internal hosts or all | CPEs (CPE1 | 346 | Single provisioning | CPEs (CPE1 and CPE2) | and CPE2) | 347 | domain | | | 348 +-------------------------+-----------------------+---------------+ 350 Table 1: Sample Deployment Cases 352 These deployment schemes are further discussed in the following 353 subsections. 355 5.1. Residential CPE 357 Figure 5 depicts DOTS sessions that need to be established between a 358 DOTS client (C) and two DOTS servers (S1, S2) within the context of 359 the scenario described in Section 4.1. As listed in Table 1, the 360 DOTS client is hosted by the residential CPE. 362 +--+ 363 ----------|S1| 364 / +--+ 365 / DOTS Server Domain #1 366 / 367 +---+/ 368 | C | 369 +---+\ 370 CPE \ 371 \ 372 \ +--+ 373 ----------|S2| 374 +--+ 375 DOTS Server Domain #2 377 Figure 5: DOTS Associations for a Multihomed Residential CPE 379 The DOTS client MUST resolve the DOTS server's name provided by each 380 provisioning domain using either the DNS servers learned from the 381 respective provisioning domain or from the DNS servers associated 382 with the interface(s) for which a DOTS server was explicitly 383 configured (Section 4). IPv6-capable DOTS clients MUST use the 384 source address selection algorithm defined in [RFC6724] to select the 385 candidate source addresses to contact each of these DOTS servers. 386 DOTS sessions MUST be established and MUST be maintained with each of 387 the DOTS servers because the mitigation scope of each of these 388 servers is restricted. The DOTS client MUST use the security 389 credentials (a certificate, typically) provided by a provisioning 390 domain to authenticate itself to the DOTS server(s) provided by the 391 same provisioning domain. How such security credentials are provided 392 to the DOTS client is out of the scope of this document. The reader 393 may refer to Section 7.1 of [RFC9132] for more details about DOTS 394 authentication methods. 396 When conveying a mitigation request to protect the attack target(s), 397 the DOTS client MUST select an available DOTS server whose network 398 has assigned the IP prefixes from which target prefixes/addresses are 399 derived. This implies that if no appropriate DOTS server is found, 400 the DOTS client MUST NOT send the mitigation request to any other 401 available DOTS server. 403 For example, a mitigation request to protect target resources bound 404 to a PA IP address/prefix cannot be satisfied by a provisioning 405 domain other than the one that owns those addresses/prefixes. 406 Consequently, if a CPE detects a DDoS attack that spreads over all 407 its network attachments, it MUST contact all DOTS servers for 408 mitigation purposes. 410 The DOTS client MUST be able to associate a DOTS server with each 411 provisioning domain it serves. For example, if the DOTS client is 412 provisioned with S1 using DHCP when attaching to a first network and 413 with S2 using Protocol Configuration Option (PCO) [TS.24008] when 414 attaching to a second network, the DOTS client must record the 415 interface from which a DOTS server was provisioned. A DOTS signaling 416 session to a given DOTS server must be established using the 417 interface from which the DOTS server was provisioned. If a DOTS 418 server is explicitly configured, DOTS signaling with that server must 419 be established via the interfaces that are indicated in the explicit 420 configuration or via any active interface if no interface is 421 configured. 423 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 425 Figure 6 illustrates the DOTS sessions that can be established with a 426 client-domain DOTS gateway (hosted within the CPE as per Table 1), 427 which is enabled within the context of the scenario described in 428 Section 4.2. This deployment is characterized as follows: 430 * One or more DOTS clients are enabled in hosts located in the 431 internal network. 433 * A client-domain DOTS gateway is enabled to aggregate and then 434 relay the requests towards upstream DOTS servers. 436 +--+ 437 .................... ----------|S1| 438 . +---+ . / +--+ 439 . | C1|----+ ./ DOTS Server Domain #1 440 . +---+ | . 441 . | /. 442 .+---+ +-+-+/ . 443 .| C3|------| G | . 444 .+---+ +-+-+\ . 445 . CPE \. 446 . +---+ | . 447 . | C2|----+ .\ 448 . +---+ . \ +--+ 449 '..................' ----------|S2| 450 +--+ 451 DOTS Client Domain DOTS Server Domain #2 453 Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple 454 DOTS Servers 456 When PA addresses/prefixes are in use, the same considerations 457 discussed in Section 5.1 need to be followed by the client-domain 458 DOTS gateway to contact its DOTS server(s). The client-domain DOTS 459 gateways can be reachable from DOTS clients by using a unicast 460 address or an anycast address (Section 3.2.4 of [RFC8811]). 462 Nevertheless, when PI addresses/prefixes are assigned and absent any 463 policy, the client-domain DOTS gateway SHOULD send mitigation 464 requests to all its DOTS servers. Otherwise, the attack traffic may 465 still be delivered via the ISP that hasn't received the mitigation 466 request. 468 An alternate deployment model is depicted in Figure 7. This 469 deployment assumes that: 471 * One or more DOTS clients are enabled in hosts located in the 472 internal network. These DOTS clients may use [RFC8973] to 473 discover their DOTS server(s). 475 * These DOTS clients communicate directly with upstream DOTS 476 servers. 478 .......... 479 . +--+ . 480 +--------|C1|--------+ 481 | . +--+ . | 482 | . . | 483 +--+ . +--+ . +--+ 484 |S2|------|C3|------|S1| 485 +--+ . +--+ . +--+ 486 | . . | 487 | . +--+ . | 488 +--------|C2|--------+ 489 . +--+ . 490 '........' 491 DOTS Client 492 Domain 494 Figure 7: Multiple DOTS Clients, Multiple DOTS Servers 496 If PI addresses/prefixes are in use, the DOTS client MUST send a 497 mitigation request to all the DOTS servers. The use of the same 498 anycast addresses to reach these DOTS servers is NOT RECOMMENDED. If 499 a well-known anycast address is used to reach multiple DOTS servers, 500 the CPE may not be able to select the appropriate provisioning domain 501 to which the mitigation request should be forwarded. As a 502 consequence, the request may not be forwarded to the appropriate DOTS 503 server. 505 If PA addresses/prefixes are used, the same considerations discussed 506 in Section 5.1 need to be followed by the DOTS clients. Because DOTS 507 clients are not embedded in the CPE and multiple addresses/prefixes 508 may not be assigned to the DOTS client (typically in an IPv4 509 context), some issues may arise in how to steer traffic towards the 510 appropriate DOTS server by using the appropriate source IP address. 511 These complications discussed in [RFC4116] are not specific to DOTS. 513 Another deployment approach is to enable many DOTS clients; each of 514 them is responsible for handling communications with a specific DOTS 515 server (see Figure 8). 517 .......... 518 . +--+ . 519 +--------|C1| . 520 | . +--+ . 521 +--+ . +--+ . +--+ 522 |S2| . |C2|------|S1| 523 +--+ . +--+ . +--+ 524 '........' 525 DOTS Client 526 Domain 528 Figure 8: Single Homed DOTS Clients 530 For both deployments depicted in Figures 7 and 8, each DOTS client 531 SHOULD be provided with policies (e.g., a prefix filter that is used 532 to filter DDoS detection alarms) that will trigger DOTS 533 communications with the DOTS servers. Such policies will help the 534 DOTS client to select the appropriate destination DOTS server. The 535 CPE MUST select the appropriate source IP address when forwarding 536 DOTS messages received from an internal DOTS client. 538 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 540 The deployments depicted in Figures 7 and 8 also apply to the 541 scenario described in Section 4.3. One specific problem for this 542 scenario is to select the appropriate exit router when contacting a 543 given DOTS server. 545 An alternative deployment scheme is shown in Figure 9: 547 * DOTS clients are enabled in hosts located in the internal network. 549 * A client-domain DOTS gateway is enabled in each CPE (CPE1 and CPE2 550 per Table 1). 552 * Each of these client-domain DOTS gateways communicates with the 553 DOTS server of the provisioning domain. 555 ................................. 556 . +---+ . 557 . +------------| C1|----+ . 558 . | +---+ | . 559 . | | . 560 +--+ . +-+-+ +---+ +-+-+ . +--+ 561 |S2|------|G2 |------| C3|------|G1 |------|S1| 562 +--+ . +-+-+ +---+ +-+-+ . +--+ 563 . CPE2 CPE1 . 564 . | +---+ | . 565 . +------------| C2|----+ . 566 . +---+ . 567 '...............................' 568 DOTS Client Domain 570 Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple 571 DOTS Servers 573 When PI addresses/prefixes are used, DOTS clients MUST contact all 574 the client-domain DOTS gateways to send a DOTS message. Client- 575 domain DOTS gateways will then relay the request to the DOTS servers 576 as a function of local policy. Note that (same) anycast addresses 577 cannot be used to establish DOTS sessions between DOTS clients and 578 client-domain DOTS gateways because only one DOTS gateway will 579 receive the mitigation request. 581 When PA addresses/prefixes are used, but no filter rules are provided 582 to DOTS clients, the latter MUST contact all client-domain DOTS 583 gateways simultaneously to send a DOTS message. Upon receipt of a 584 request by a client-domain DOTS gateway, it MUST check whether the 585 request is to be forwarded upstream (if the target IP prefix is 586 managed by the upstream server) or rejected. 588 When PA addresses/prefixes are used, but specific filter rules are 589 provided to DOTS clients using some means that are out of scope of 590 this document, the clients MUST select the appropriate client-domain 591 DOTS gateway to reach. The use of the same anycast addresses is NOT 592 RECOMMENDED to reach client-domain DOTS gateways. 594 5.4. Multi-Homed Enterprise: Single ISP 596 The key difference of the scenario described in Section 4.4 compared 597 to the other scenarios is that multi-homing is provided by the same 598 ISP. Concretely, that ISP can decide to provision the enterprise 599 network with: 601 * The same DOTS server for all network attachments. 603 * Distinct DOTS servers for each network attachment. These DOTS 604 servers need to coordinate when a mitigation action is received 605 from the enterprise network. 607 In both cases, DOTS agents enabled within the enterprise network MAY 608 decide to select one or all network attachments to send DOTS 609 mitigation requests. 611 6. Security Considerations 613 A set of security threats related to multihoming are discussed in 614 [RFC4218]. 616 DOTS-related security considerations are discussed in Section 4 of 617 [RFC8811]. 619 DOTS clients should control the information that they share with peer 620 DOTS servers. In particular, if a DOTS client maintains DOTS 621 sessions with specific DOTS servers per interconnection link, the 622 DOTS client SHOULD NOT leak information specific to a given link to 623 DOTS servers on different interconnection links that are not 624 authorized to mitigate attacks for that given link. Whether this 625 constraint is relaxed is deployment-specific and must be subject to 626 explicit consent from the DOTS client domain administrator. How to 627 seek for such consent is implementation- and deployment-specific. 629 7. IANA Considerations 631 This document does not require any action from IANA. 633 8. Acknowledgements 635 Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and 636 Christian Jacquenet for sharing their comments on the mailing list. 638 Thanks to Kirill Kasavchenko for the comments. 640 Thanks to Kathleen Moriarty for the secdir review, Joel Jaeggli for 641 the opsdir review, Mirja Kuhlewind for the tsvart review, and Dave 642 Thaler for the Intdir review. 644 Many thanks to Roman Danyliw for the careful AD review. 646 Thanks to Lars Eggert, Robert Wilton, Paul Wouters, Erik Kline, and 647 Eric Vyncke for the IESG review. 649 9. References 651 9.1. Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 659 "Default Address Selection for Internet Protocol Version 6 660 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 661 . 663 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 664 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 665 May 2017, . 667 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 668 Teague, N., and R. Compton, "DDoS Open Threat Signaling 669 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 670 August 2020, . 672 9.2. Informative References 674 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 675 Multihoming Architectures", RFC 3582, 676 DOI 10.17487/RFC3582, August 2003, 677 . 679 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 680 Gill, "IPv4 Multihoming Practices and Limitations", 681 RFC 4116, DOI 10.17487/RFC4116, July 2005, 682 . 684 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 685 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, 686 October 2005, . 688 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 689 Denial-of-Service Considerations", RFC 4732, 690 DOI 10.17487/RFC4732, December 2006, 691 . 693 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 694 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 695 . 697 [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent 698 Routing and Source Address Selection for IPv6 Hosts: 699 Overview of the Problem Space", RFC 8043, 700 DOI 10.17487/RFC8043, January 2017, 701 . 703 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 704 Threat Signaling (DOTS) Requirements", RFC 8612, 705 DOI 10.17487/RFC8612, May 2019, 706 . 708 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 709 Denial-of-Service Open Threat Signaling (DOTS) Data 710 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 711 May 2020, . 713 [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., 714 Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", 715 RFC 8803, DOI 10.17487/RFC8803, July 2020, 716 . 718 [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 719 L., and K. Nishizuka, "Use Cases for DDoS Open Threat 720 Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, 721 . 723 [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling 724 (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, 725 January 2021, . 727 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 728 "Distributed Denial-of-Service Open Threat Signaling 729 (DOTS) Signal Channel Specification", RFC 9132, 730 DOI 10.17487/RFC9132, September 2021, 731 . 733 [TS.24008] 3GPP, "Mobile radio interface Layer 3 specification; Core 734 network protocols; Stage 3 (Release 16)", December 2019, 735 . 737 Authors' Addresses 739 Mohamed Boucadair 740 Orange 741 35000 Rennes 742 France 743 Email: mohamed.boucadair@orange.com 744 Tirumaleswar Reddy.K 745 Akamai 746 Embassy Golf Link Business Park 747 Bangalore 560071 748 Karnataka 749 India 750 Email: kondtir@gmail.com 752 Wei Pan 753 Huawei Technologies 754 Email: william.panwei@huawei.com