idnits 2.17.00 (12 Aug 2021) /tmp/idnits8132/draft-ietf-dots-multihoming-11.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 (10 February 2022) is 99 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: 14 August 2022 Akamai 6 W. Pan 7 Huawei Technologies 8 10 February 2022 10 Multi-homing Deployment Considerations for Distributed-Denial-of-Service 11 Open Threat Signaling (DOTS) 12 draft-ietf-dots-multihoming-11 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 14 August 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 . . . . . . . . . . . 14 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 * Blindly forking 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] and 178 [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. 284 +------+ +------+ 285 | ISP1 | | ISP2 | 286 +---+--+ +--+---+ 287 | | Service Providers 288 ............|....................|....................... 289 +---------++---------+ Enterprise Network 290 || 291 +--++-+ 292 | CPE | 293 +-----+ 294 ... (Internal Network) 296 Figure 3: Multi-homed Enterprise Network (Single CPE connected to 297 Multiple Networks) 299 4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 301 This scenario is similar to the one described in Section 4.2; the 302 main difference is that dedicated routers (rtr1 and rtr2) are used to 303 connect to each provisioning domain. 305 +------+ +------+ 306 | ISP1 | | ISP2 | 307 +---+--+ +--+---+ 308 | | Service Providers 309 ......................|..........|....................... 310 | | Enterprise Network 311 +---+--+ +--+---+ 312 | rtr1 | | rtr2 | 313 +------+ +------+ 315 ... (Internal Network) 317 Figure 4: Multi-homed Enterprise Network (Multiple CPEs, Multiple 318 ISPs) 320 4.4. Multi-homed Enterprise with the Same ISP 322 This scenario is a variant of Section 4.2 and Section 4.3 in which 323 multi-homing is supported by the same ISP (i.e., same provisioning 324 domain). 326 5. DOTS Multi-homing Deployment Considerations 328 Table 1 provides some sample, non-exhaustive, deployment schemes to 329 illustrate how DOTS agents may be deployed for each of the scenarios 330 introduced in Section 4. 332 +=========================+=======================+===============+ 333 | Scenario | DOTS client | Client-domain | 334 | | | DOTS gateway | 335 +=========================+=======================+===============+ 336 | Residential CPE | CPE | N/A | 337 +-------------------------+-----------------------+---------------+ 338 | Single CPE, Multiple | Internal hosts or CPE | CPE | 339 | provisioning domains | | | 340 +-------------------------+-----------------------+---------------+ 341 | Multiple CPEs, Multiple | Internal hosts or all | CPEs (rtr1 | 342 | provisioning domains | CPEs (rtr1 and rtr2) | and rtr2) | 343 +-------------------------+-----------------------+---------------+ 344 | Multi-homed enterprise, | Internal hosts or all | CPEs (rtr1 | 345 | Single provisioning | CPEs (rtr1 and rtr2) | and rtr2) | 346 | domain | | | 347 +-------------------------+-----------------------+---------------+ 349 Table 1: Sample Deployment Cases 351 These deployment schemes are further discussed in the following 352 subsections. 354 5.1. Residential CPE 356 Figure 5 depicts DOTS sessions that need to be established between a 357 DOTS client (C) and two DOTS servers (S1, S2) within the context of 358 the scenario described in Section 4.1. As listed in Table 1, the 359 DOTS client is hosted by the residential CPE. 361 The DOTS client MUST resolve the DOTS server's name provided by each 362 provisioning domain using either the DNS servers learned from the 363 respective provisioning domain or from the DNS servers associated 364 with the interface(s) for which a DOTS server was explicitly 365 configured (Section 4). IPv6-capable DOTS clients MUST use the 366 source address selection algorithm defined in [RFC6724] to select the 367 candidate source addresses to contact each of these DOTS servers. 368 DOTS sessions MUST be established and MUST be maintained with each of 369 the DOTS servers because the mitigation scope of each of these 370 servers is restricted. The DOTS client SHOULD use the certificate 371 provided by a provisioning domain to authenticate itself to the DOTS 372 server(s) provided by the same provisioning domain. How such a 373 certificate is provided to the DOTS client is out of the scope of 374 this document. 376 When conveying a mitigation request to protect the attack target(s), 377 the DOTS client MUST select an available DOTS server whose network 378 has assigned the IP prefixes from which target prefixes/addresses are 379 derived. This implies that if no appropriate DOTS server is found, 380 the DOTS client MUST NOT send the mitigation request to any other 381 available DOTS server. 383 For example, a mitigation request to protect target resources bound 384 to a PA IP address/prefix cannot be satisfied by a provisioning 385 domain other than the one that owns those addresses/prefixes. 386 Consequently, if a CPE detects a DDoS attack that spreads over all 387 its network attachments, it MUST contact all DOTS servers for 388 mitigation purposes. 390 The DOTS client MUST be able to associate a DOTS server with each 391 provisioning domain it serves. For example, if the DOTS client is 392 provisioned with S1 using DHCP when attaching to a first network and 393 with S2 using Protocol Configuration Option (PCO) [TS.24008] when 394 attaching to a second network, the DOTS client must record the 395 interface from which a DOTS server was provisioned. DOTS signaling 396 session to a given DOTS server must be established using the 397 interface from which the DOTS server was provisioned. If a DOTS 398 server is explicitly configured, DOTS signaling with that server must 399 be established via the interfaces that are indicated in the explicit 400 configuration or via any active interface if no interface is 401 configured. 403 +--+ 404 ----------|S1| 405 / +--+ 406 / DOTS Server Domain #1 407 / 408 +---+/ 409 | C | 410 +---+\ 411 CPE \ 412 \ 413 \ +--+ 414 ----------|S2| 415 +--+ 416 DOTS Server Domain #2 418 Figure 5: DOTS Associations for a Multihomed Residential CPE 420 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 422 Figure 6 illustrates the DOTS sessions that can be established with a 423 client-domain DOTS gateway (hosted within the CPE as per Table 1), 424 which is enabled within the context of the scenario described in 425 Section 4.2. This deployment is characterized as follows: 427 * One of more DOTS clients are enabled in hosts located in the 428 internal network. 430 * A client-domain DOTS gateway is enabled to aggregate and then 431 relay the requests towards upstream DOTS servers. 433 +--+ 434 ----------|S1| 435 +---+ / +--+ 436 | C1|----+ / DOTS Server Domain #1 437 +---+ | / 438 | / 439 +---+ +-+-+/ 440 | C3|------| G | 441 +---+ +-+-+\ 442 CPE \ 443 +---+ | \ 444 | C2|----+ \ 445 +---+ \ +--+ 446 ----------|S2| 447 +--+ 448 DOTS Server Domain #2 450 Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple 451 DOTS Servers 453 When PA addresses/prefixes are in use, the same considerations 454 discussed in Section 5.1 need to be followed by the client-domain 455 DOTS gateway to contact its DOTS server(s). The client-domain DOTS 456 gateways can be reachable from DOTS clients by using an unicast 457 address or an anycast address (Section 3.2.4 of [RFC8811]). 459 Nevertheless, when PI addresses/prefixes are assigned and absent any 460 policy, the client-domain DOTS gateway MUST send mitigation requests 461 to all its DOTS servers. Otherwise, the attack traffic may still be 462 delivered via the ISP which hasn't received the mitigation request. 464 An alternate deployment model is depicted in Figure 7. This 465 deployment assumes that: 467 * One or more DOTS clients are enabled in hosts located in the 468 internal network. These DOTS clients may use [RFC8973] to 469 discover their DOTS server(s). 471 * These DOTS clients communicate directly with upstream DOTS 472 servers. 474 .......... 475 . +--+ . 476 +--------|C1|--------+ 477 | . +--+ . | 478 | . . | 479 +--+ . +--+ . +--+ 480 |S2|------|C3|------|S1| 481 +--+ . +--+ . +--+ 482 | . . | 483 | . +--+ . | 484 +--------|C2|--------+ 485 . +--+ . 486 .......... 487 DOTS Client 488 Domain 490 Figure 7: Multiple DOTS Clients, Multiple DOTS Servers 492 If PI addresses/prefixes are in use, the DOTS client MUST send a 493 mitigation request to all the DOTS servers. The use of anycast 494 addresses to reach these DOTS servers is NOT RECOMMENDED. If a well- 495 known anycast address is used to reach multiple DOTS servers, the CPE 496 may not be able to select the appropriate provisioning domain to 497 which the mitigation request should be forwarded. As a consequence, 498 the request may not be forwarded to the appropriate DOTS server. 500 If PA addresses/prefixes are used, the same considerations discussed 501 in Section 5.1 need to be followed by the DOTS clients. Because DOTS 502 clients are not embedded in the CPE and multiple addresses/prefixes 503 may not be assigned to the DOTS client (typically in an IPv4 504 context), some issues may arise in how to steer traffic towards the 505 appropriate DOTS server by using the appropriate source IP address. 506 These complications discussed in [RFC4116] are not specific to DOTS. 508 Another deployment approach is to enable many DOTS clients; each of 509 them is responsible for handling communications with a specific DOTS 510 server (see Figure 8). 512 .......... 513 . +--+ . 514 +--------|C1| . 515 | . +--+ . 516 +--+ . +--+ . +--+ 517 |S2| . |C2|------|S1| 518 +--+ . +--+ . +--+ 519 .......... 520 DOTS Client 521 Domain 523 Figure 8: Single Homed DOTS Clients 525 For both deployments depicted in Figures 7 and 8, each DOTS client 526 SHOULD be provided with policies (e.g., a prefix filter that will be 527 against DDoS detection alarms) that will trigger DOTS communications 528 with the DOTS servers. Such policies will help the DOTS client to 529 select the appropriate destination DOTS server. The CPE MUST select 530 the appropriate source IP address when forwarding DOTS messages 531 received from an internal DOTS client. 533 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 535 The deployments depicted in Figures 7 and 8 also apply to the 536 scenario described in Section 4.3. One specific problem for this 537 scenario is to select the appropriate exit router when contacting a 538 given DOTS server. 540 An alternative deployment scheme is shown in Figure 9: 542 * DOTS clients are enabled in hosts located in the internal network. 544 * A client-domain DOTS gateway is enabled in each CPE (rtr1 and rtr2 545 per Table 1). 547 * Each of these client-domain DOTS gateways communicates with the 548 DOTS server of the provisioning domain. 550 +---+ 551 +------------| C1|----+ 552 | +---+ | 553 | | 554 +--+ +-+-+ +---+ +-+-+ +--+ 555 |S2|------|G2 |------| C3|------|G1 |------|S1| 556 +--+ +-+-+ +---+ +-+-+ +--+ 557 rtr2 rtr1 558 | +---+ | 559 +------------| C2|----+ 560 +---+ 562 Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple 563 DOTS Servers 565 When PI addresses/prefixes are used, DOTS clients MUST contact all 566 the client-domain DOTS gateways to send a DOTS message. Client- 567 domain DOTS gateways will then relay the request to the DOTS servers 568 as a function of local policy. Note that anycast addresses cannot be 569 used to establish DOTS sessions between DOTS clients and client- 570 domain DOTS gateways because only one DOTS gateway will receive the 571 mitigation request. 573 When PA addresses/prefixes are used, but no filter rules are provided 574 to DOTS clients, the latter MUST contact all client-domain DOTS 575 gateways simultaneously to send a DOTS message. Upon receipt of a 576 request by a client-domain DOTS gateway, it MUST check whether the 577 request is to be forwarded upstream (if the target IP prefix is 578 managed by the upstream server) or rejected. 580 When PA addresses/prefixes are used, but specific filter rules are 581 provided to DOTS clients using some means that are out of scope of 582 this document, the clients MUST select the appropriate client-domain 583 DOTS gateway to reach. The use of anycast addresses is NOT 584 RECOMMENDED to reach client-domain DOTS gateways. 586 5.4. Multi-Homed Enterprise: Single ISP 588 The key difference of the scenario described in Section 4.4 compared 589 to the other scenarios is that multi-homing is provided by the same 590 ISP. Concretely, that ISP can decide to provision the enterprise 591 network with: 593 * The same DOTS server for all network attachments. 595 * Distinct DOTS servers for each network attachment. These DOTS 596 servers need to coordinate when a mitigation action is received 597 from the enterprise network. 599 In both cases, DOTS agents enabled within the enterprise network MAY 600 decide to select one or all network attachments to send DOTS 601 mitigation requests. 603 6. Security Considerations 605 DOTS-related security considerations are discussed in Section 4 of 606 [RFC8811]. 608 DOTS clients should control the information that they share with peer 609 DOTS servers. In particular, if a DOTS client maintains DOTS 610 sessions with specific DOTS servers per interconnection link, the 611 DOTS client SHOULD NOT leak information specific to a given link to 612 DOTS servers on different interconnection links that are not 613 authorized to mitigate attacks for that given link. Whether this 614 constraint is relaxed is deployment-specific and must be subject to 615 explicit consent from the DOTS client domain administrator. How to 616 seek for such consent is implementation- and deployment-specific. 618 7. IANA Considerations 620 This document does not require any action from IANA. 622 8. Acknowledgements 624 Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and 625 Christian Jacquenet for sharing their comments on the mailing list. 627 Thanks to Kirill Kasavchenko for the comments. 629 Thanks to Kathleen Moriarty for the secdir review and Joel Jaeggli 630 for the opsdir review. 632 Many thanks to Roman Danyliw for the careful AD review. 634 9. References 636 9.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 644 "Default Address Selection for Internet Protocol Version 6 645 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 646 . 648 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 649 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 650 May 2017, . 652 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 653 Teague, N., and R. Compton, "DDoS Open Threat Signaling 654 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 655 August 2020, . 657 9.2. Informative References 659 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 660 Multihoming Architectures", RFC 3582, 661 DOI 10.17487/RFC3582, August 2003, 662 . 664 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 665 Gill, "IPv4 Multihoming Practices and Limitations", 666 RFC 4116, DOI 10.17487/RFC4116, July 2005, 667 . 669 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 670 Denial-of-Service Considerations", RFC 4732, 671 DOI 10.17487/RFC4732, December 2006, 672 . 674 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 675 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 676 . 678 [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent 679 Routing and Source Address Selection for IPv6 Hosts: 680 Overview of the Problem Space", RFC 8043, 681 DOI 10.17487/RFC8043, January 2017, 682 . 684 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 685 Denial-of-Service Open Threat Signaling (DOTS) Data 686 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 687 May 2020, . 689 [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., 690 Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", 691 RFC 8803, DOI 10.17487/RFC8803, July 2020, 692 . 694 [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 695 L., and K. Nishizuka, "Use Cases for DDoS Open Threat 696 Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, 697 . 699 [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling 700 (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, 701 January 2021, . 703 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 704 "Distributed Denial-of-Service Open Threat Signaling 705 (DOTS) Signal Channel Specification", RFC 9132, 706 DOI 10.17487/RFC9132, September 2021, 707 . 709 [TS.24008] 3GPP, "Mobile radio interface Layer 3 specification; Core 710 network protocols; Stage 3 (Release 16)", December 2019, 711 . 713 Authors' Addresses 715 Mohamed Boucadair 716 Orange 717 35000 Rennes 718 France 720 Email: mohamed.boucadair@orange.com 722 Tirumaleswar Reddy.K 723 Akamai 724 Embassy Golf Link Business Park 725 Bangalore 560071 726 Karnataka 727 India 729 Email: kondtir@gmail.com 731 Wei Pan 732 Huawei Technologies 734 Email: william.panwei@huawei.com