idnits 2.17.00 (12 Aug 2021) /tmp/idnits7615/draft-ietf-dots-multihoming-12.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 document date (21 April 2022) is 29 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 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: Informational T. Reddy.K 5 Expires: 23 October 2022 Akamai 6 W. Pan 7 Huawei Technologies 8 21 April 2022 10 Multi-homing Deployment Considerations for Distributed-Denial-of-Service 11 Open Threat Signaling (DOTS) 12 draft-ietf-dots-multihoming-12 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 23 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 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: are 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: are globally-unique addresses 189 which are not assigned by a transit provider, but are provided by 190 some other organisation, usually a Regional Internet Registry 191 (RIR) (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 (i.e., 272 managed 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. 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 of 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 an 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 MUST send mitigation requests 464 to all its DOTS servers. Otherwise, the attack traffic may still be 465 delivered via the ISP which hasn't received the mitigation request. 467 An alternate deployment model is depicted in Figure 7. This 468 deployment assumes that: 470 * One or more DOTS clients are enabled in hosts located in the 471 internal network. These DOTS clients may use [RFC8973] to 472 discover their DOTS server(s). 474 * These DOTS clients communicate directly with upstream DOTS 475 servers. 477 .......... 478 . +--+ . 479 +--------|C1|--------+ 480 | . +--+ . | 481 | . . | 482 +--+ . +--+ . +--+ 483 |S2|------|C3|------|S1| 484 +--+ . +--+ . +--+ 485 | . . | 486 | . +--+ . | 487 +--------|C2|--------+ 488 . +--+ . 489 '........' 490 DOTS Client 491 Domain 493 Figure 7: Multiple DOTS Clients, Multiple DOTS Servers 495 If PI addresses/prefixes are in use, the DOTS client MUST send a 496 mitigation request to all the DOTS servers. The use of anycast 497 addresses to reach these DOTS servers is NOT RECOMMENDED. If a well- 498 known anycast address is used to reach multiple DOTS servers, the CPE 499 may not be able to select the appropriate provisioning domain to 500 which the mitigation request should be forwarded. As a consequence, 501 the request may not be forwarded to the appropriate DOTS server. 503 If PA addresses/prefixes are used, the same considerations discussed 504 in Section 5.1 need to be followed by the DOTS clients. Because DOTS 505 clients are not embedded in the CPE and multiple addresses/prefixes 506 may not be assigned to the DOTS client (typically in an IPv4 507 context), some issues may arise in how to steer traffic towards the 508 appropriate DOTS server by using the appropriate source IP address. 509 These complications discussed in [RFC4116] are not specific to DOTS. 511 Another deployment approach is to enable many DOTS clients; each of 512 them is responsible for handling communications with a specific DOTS 513 server (see Figure 8). 515 .......... 516 . +--+ . 517 +--------|C1| . 518 | . +--+ . 519 +--+ . +--+ . +--+ 520 |S2| . |C2|------|S1| 521 +--+ . +--+ . +--+ 522 '........' 523 DOTS Client 524 Domain 526 Figure 8: Single Homed DOTS Clients 528 For both deployments depicted in Figures 7 and 8, each DOTS client 529 SHOULD be provided with policies (e.g., a prefix filter that is used 530 to filter DDoS detection alarms) that will trigger DOTS 531 communications with the DOTS servers. Such policies will help the 532 DOTS client to select the appropriate destination DOTS server. The 533 CPE MUST select the appropriate source IP address when forwarding 534 DOTS messages received from an internal DOTS client. 536 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 538 The deployments depicted in Figures 7 and 8 also apply to the 539 scenario described in Section 4.3. One specific problem for this 540 scenario is to select the appropriate exit router when contacting a 541 given DOTS server. 543 An alternative deployment scheme is shown in Figure 9: 545 * DOTS clients are enabled in hosts located in the internal network. 547 * A client-domain DOTS gateway is enabled in each CPE (CPE1 and CPE2 548 per Table 1). 550 * Each of these client-domain DOTS gateways communicates with the 551 DOTS server of the provisioning domain. 553 ................................. 554 . +---+ . 555 . +------------| C1|----+ . 556 . | +---+ | . 557 . | | . 558 +--+ . +-+-+ +---+ +-+-+ . +--+ 559 |S2|------|G2 |------| C3|------|G1 |------|S1| 560 +--+ . +-+-+ +---+ +-+-+ . +--+ 561 . CPE2 CPE1 . 562 . | +---+ | . 563 . +------------| C2|----+ . 564 . +---+ . 565 '...............................' 566 DOTS Client Domain 568 Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple 569 DOTS Servers 571 When PI addresses/prefixes are used, DOTS clients MUST contact all 572 the client-domain DOTS gateways to send a DOTS message. Client- 573 domain DOTS gateways will then relay the request to the DOTS servers 574 as a function of local policy. Note that anycast addresses cannot be 575 used to establish DOTS sessions between DOTS clients and client- 576 domain DOTS gateways because only one DOTS gateway will receive the 577 mitigation request. 579 When PA addresses/prefixes are used, but no filter rules are provided 580 to DOTS clients, the latter MUST contact all client-domain DOTS 581 gateways simultaneously to send a DOTS message. Upon receipt of a 582 request by a client-domain DOTS gateway, it MUST check whether the 583 request is to be forwarded upstream (if the target IP prefix is 584 managed by the upstream server) or rejected. 586 When PA addresses/prefixes are used, but specific filter rules are 587 provided to DOTS clients using some means that are out of scope of 588 this document, the clients MUST select the appropriate client-domain 589 DOTS gateway to reach. The use of anycast addresses is NOT 590 RECOMMENDED to reach client-domain DOTS gateways. 592 5.4. Multi-Homed Enterprise: Single ISP 594 The key difference of the scenario described in Section 4.4 compared 595 to the other scenarios is that multi-homing is provided by the same 596 ISP. Concretely, that ISP can decide to provision the enterprise 597 network with: 599 * The same DOTS server for all network attachments. 601 * Distinct DOTS servers for each network attachment. These DOTS 602 servers need to coordinate when a mitigation action is received 603 from the enterprise network. 605 In both cases, DOTS agents enabled within the enterprise network MAY 606 decide to select one or all network attachments to send DOTS 607 mitigation requests. 609 6. Security Considerations 611 A set of security threats related to multihoming are discussed in 612 [RFC4218]. 614 DOTS-related security considerations are discussed in Section 4 of 615 [RFC8811]. 617 DOTS clients should control the information that they share with peer 618 DOTS servers. In particular, if a DOTS client maintains DOTS 619 sessions with specific DOTS servers per interconnection link, the 620 DOTS client SHOULD NOT leak information specific to a given link to 621 DOTS servers on different interconnection links that are not 622 authorized to mitigate attacks for that given link. Whether this 623 constraint is relaxed is deployment-specific and must be subject to 624 explicit consent from the DOTS client domain administrator. How to 625 seek for such consent is implementation- and deployment-specific. 627 7. IANA Considerations 629 This document does not require any action from IANA. 631 8. Acknowledgements 633 Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and 634 Christian Jacquenet for sharing their comments on the mailing list. 636 Thanks to Kirill Kasavchenko for the comments. 638 Thanks to Kathleen Moriarty for the secdir review, Joel Jaeggli for 639 the opsdir review, and Mirja Kuhlewind for the tsvart review. 641 Many thanks to Roman Danyliw for the careful AD review. 643 Thanks to Lars Eggert, Robert Wilton, Paul Wouters, Erik Kline, and 644 Eric Vyncke for the IESG review. 646 9. References 647 9.1. Normative References 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, 651 DOI 10.17487/RFC2119, March 1997, 652 . 654 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 655 "Default Address Selection for Internet Protocol Version 6 656 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 657 . 659 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 660 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 661 May 2017, . 663 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 664 Teague, N., and R. Compton, "DDoS Open Threat Signaling 665 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 666 August 2020, . 668 9.2. Informative References 670 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 671 Multihoming Architectures", RFC 3582, 672 DOI 10.17487/RFC3582, August 2003, 673 . 675 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 676 Gill, "IPv4 Multihoming Practices and Limitations", 677 RFC 4116, DOI 10.17487/RFC4116, July 2005, 678 . 680 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 681 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, 682 October 2005, . 684 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 685 Denial-of-Service Considerations", RFC 4732, 686 DOI 10.17487/RFC4732, December 2006, 687 . 689 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 690 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 691 . 693 [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent 694 Routing and Source Address Selection for IPv6 Hosts: 695 Overview of the Problem Space", RFC 8043, 696 DOI 10.17487/RFC8043, January 2017, 697 . 699 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 700 Threat Signaling (DOTS) Requirements", RFC 8612, 701 DOI 10.17487/RFC8612, May 2019, 702 . 704 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 705 Denial-of-Service Open Threat Signaling (DOTS) Data 706 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 707 May 2020, . 709 [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., 710 Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", 711 RFC 8803, DOI 10.17487/RFC8803, July 2020, 712 . 714 [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 715 L., and K. Nishizuka, "Use Cases for DDoS Open Threat 716 Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, 717 . 719 [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling 720 (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, 721 January 2021, . 723 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 724 "Distributed Denial-of-Service Open Threat Signaling 725 (DOTS) Signal Channel Specification", RFC 9132, 726 DOI 10.17487/RFC9132, September 2021, 727 . 729 [TS.24008] 3GPP, "Mobile radio interface Layer 3 specification; Core 730 network protocols; Stage 3 (Release 16)", December 2019, 731 . 733 Authors' Addresses 735 Mohamed Boucadair 736 Orange 737 35000 Rennes 738 France 739 Email: mohamed.boucadair@orange.com 740 Tirumaleswar Reddy.K 741 Akamai 742 Embassy Golf Link Business Park 743 Bangalore 560071 744 Karnataka 745 India 746 Email: kondtir@gmail.com 748 Wei Pan 749 Huawei Technologies 750 Email: william.panwei@huawei.com