idnits 2.17.00 (12 Aug 2021) /tmp/idnits8832/draft-ietf-dots-multihoming-10.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 (4 January 2022) is 136 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 5 Expires: 8 July 2022 McAfee 6 W. Pan 7 Huawei Technologies 8 4 January 2022 10 Multi-homing Deployment Considerations for Distributed-Denial-of-Service 11 Open Threat Signaling (DOTS) 12 draft-ietf-dots-multihoming-10 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 8 July 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 . . . . . . . . . . . . . . . . . . . 13 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 9.2. Informative References . . . . . . . . . . . . . . . . . 14 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]; no specific extension is required 164 to the base DOTS protocols for deploying DOTS in a multi-homed 165 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 | rtr | 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 are used to connect to each 303 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. 360 For each provisioning domain, the DOTS client MUST resolve the DOTS 361 server's name provided by a provisioning domain [RFC8973] using the 362 DNS servers learned from the respective provisioning domain (or the 363 DNS servers associated with the interface(s) for which a DOTS server 364 was explicitly configured). IPv6-capable DOTS clients MUST use the 365 source address selection algorithm defined in [RFC6724] to select the 366 candidate source addresses to contact each of these DOTS servers. 367 DOTS sessions MUST be established and MUST be maintained with each of 368 the DOTS servers because the mitigation scope of each of these 369 servers is restricted. The DOTS client SHOULD use the certificate 370 provisioned by a provisioning domain to authenticate itself to the 371 DOTS server(s) provided by the same provisioning domain. 373 When conveying a mitigation request to protect the attack target(s), 374 the DOTS client MUST select an available DOTS server whose network 375 has assigned the IP prefixes from which target prefixes/addresses are 376 derived. This implies that if no appropriate DOTS server is found, 377 the DOTS client MUST NOT send the mitigation request to any other 378 available DOTS server. 380 For example, a mitigation request to protect target resources bound 381 to a PA IP address/prefix cannot be satisfied by a provisioning 382 domain other than the one that owns those addresses/prefixes. 383 Consequently, if a CPE detects a DDoS attack that spreads over all 384 its network attachments, it MUST contact all DOTS servers for 385 mitigation purposes. 387 The DOTS client MUST be able to associate a DOTS server with each 388 provisioning domain. For example, if the DOTS client is provisioned 389 with S1 using DHCP when attaching to a first network and with S2 390 using Protocol Configuration Option (PCO) [TS.24008] when attaching 391 to a second network, the DOTS client must record the interface from 392 which a DOTS server was provisioned. DOTS signaling session to a 393 given DOTS server must be established using the interface from which 394 the DOTS server was provisioned. If a DOTS server is explicitly 395 configured, DOTS signaling with that server must be established via 396 the interfaces that are indicated in the explicit configuration or 397 via any active interface if no interface is configured. 399 +--+ 400 ----------|S1| 401 / +--+ 402 / DOTS Server Domain #1 403 / 404 +---+/ 405 | C | 406 +---+\ 407 \ 408 \ 409 \ +--+ 410 ----------|S2| 411 +--+ 412 DOTS Server Domain #2 414 Figure 5: DOTS Associations for a Multihomed Residential CPE 416 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 418 Figure 6 illustrates a first set of DOTS sessions that can be 419 established with a client-domain DOTS gateway, which is enabled 420 within the context of the scenario described in Section 4.2. This 421 deployment is characterized as follows: 423 * One of more DOTS clients are enabled in hosts located in the 424 internal network. 426 * A client-domain DOTS gateway is enabled to aggregate and then 427 relay the requests towards upstream DOTS servers. 429 +--+ 430 ----------|S1| 431 +---+ / +--+ 432 | C1|----+ / DOTS Server Domain #1 433 +---+ | / 434 +---+ +-+-+/ 435 | C3|------| G | 436 +---+ +-+-+\ 437 +---+ | \ 438 | C2|----+ \ 439 +---+ \ +--+ 440 ----------|S2| 441 +--+ 442 DOTS Server Domain #2 444 Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple 445 DOTS Servers 447 When PA addresses/prefixes are in use, the same considerations 448 discussed in Section 5.1 need to be followed by the client-domain 449 DOTS gateway to contact its DOTS server(s). The client-domain DOTS 450 gateways can be reachable from DOTS clients by using an unicast 451 address or an anycast address (Section 3.2.4 of [RFC8811]). 453 Nevertheless, when PI addresses/prefixes are assigned and absent any 454 policy, the client-domain DOTS gateway MUST send mitigation requests 455 to all its DOTS servers. Otherwise, the attack traffic may still be 456 delivered via the ISP which hasn't received the mitigation request. 458 An alternate deployment model is depicted in Figure 7. This 459 deployment assumes that: 461 * One or more DOTS clients are enabled in hosts located in the 462 internal network. These DOTS clients may use [RFC8973] to 463 discover their DOTS server(s). 465 * These DOTS clients communicate directly with upstream DOTS 466 servers. 468 .......... 469 . +--+ . 470 +--------|C1|--------+ 471 | . +--+ . | 472 | . . | 473 +--+ . +--+ . +--+ 474 |S2|------|C3|------|S1| 475 +--+ . +--+ . +--+ 476 | . . | 477 | . +--+ . | 478 +--------|C2|--------+ 479 . +--+ . 480 .......... 481 DOTS Client 482 Domain 484 Figure 7: Multiple DOTS Clients, Multiple DOTS Servers 486 If PI addresses/prefixes are in use, the DOTS client MUST send a 487 mitigation request to all the DOTS servers. The use of anycast 488 addresses to reach these DOTS servers is NOT RECOMMENDED. If a well- 489 known anycast address is used to reach multiple DOTS servers, the CPE 490 may not be able to select the appropriate provisioning domain to 491 which the mitigation request should be forwarded. As a consequence, 492 the request may not be forwarded to the appropriate DOTS server. 494 If PA addresses/prefixes are used, the same considerations discussed 495 in Section 5.1 need to be followed by the DOTS clients. Because DOTS 496 clients are not embedded in the CPE and multiple addreses/prefixes 497 may not be assigned to the DOTS client (typically in an IPv4 498 context), some issues may arise in how to steer traffic towards the 499 appropriate DOTS server by using the appropriate source IP address. 500 These complications discussed in [RFC4116] are not specific to DOTS. 502 Another deployment approach is to enable many DOTS clients; each of 503 them is responsible for handling communications with a specific DOTS 504 server (see Figure 8). 506 .......... 507 . +--+ . 508 +--------|C1| . 509 | . +--+ . 510 +--+ . +--+ . +--+ 511 |S2| . |C2|------|S1| 512 +--+ . +--+ . +--+ 513 .......... 514 DOTS Client 515 Domain 517 Figure 8: Single Homed DOTS Clients 519 For both deployments depicted in Figures 7 and 8, each DOTS client 520 SHOULD be provided with policies (e.g., a prefix filter that will be 521 against DDoS detection alarms) that will trigger DOTS communications 522 with the DOTS servers. Such policies will help the DOTS client to 523 select the appropriate destination DOTS server. 525 The CPE MUST select the appropriate source IP address when forwarding 526 DOTS messages received from an internal DOTS client. 528 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 530 The deployments depicted in Figures 7 and 8 also apply to the 531 scenario described in Section 4.3. One specific problem for this 532 scenario is to select the appropriate exit router when contacting a 533 given DOTS server. 535 An alternative deployment scheme is shown in Figure 9: 537 * DOTS clients are enabled in hosts located in the internal network. 539 * A client-domain DOTS gateway is enabled in each CPE (rtr1, rtr2). 541 * Each of these client-domain DOTS gateways communicates with the 542 DOTS server of the provisioning domain. 544 +---+ 545 +------------| C1|----+ 546 | +---+ | 547 +--+ +-+-+ +---+ +-+-+ +--+ 548 |S2|------|G2 |------| C3|------|G1 |------|S1| 549 +--+ +-+-+ +---+ +-+-+ +--+ 550 | +---+ | 551 +------------| C2|----+ 552 +---+ 554 Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple 555 DOTS Servers 557 When PI addresses/prefixes are used, DOTS clients MUST contact all 558 the client-domain DOTS gateways to send a DOTS message. Client- 559 domain DOTS gateways will then relay the request to the DOTS servers 560 as a function of local policy. Note that anycast addresses cannot be 561 used to establish DOTS sessions between DOTS clients and client- 562 domain DOTS gateways because only one DOTS gateway will receive the 563 mitigation request. 565 When PA addresses/prefixes are used, but no filter rules are provided 566 to DOTS clients, the latter MUST contact all client-domain DOTS 567 gateways simultaneously to send a DOTS message. Upon receipt of a 568 request by a client-domain DOTS gateway, it MUST check whether the 569 request is to be forwarded upstream (if the target IP prefix is 570 managed by the upstream server) or rejected. 572 When PA addresses/prefixes are used, but specific filter rules are 573 provided to DOTS clients using some means that are out of scope of 574 this document, the clients MUST select the appropriate client-domain 575 DOTS gateway to reach. The use of anycast addresses is NOT 576 RECOMMENDED to reach client-domain DOTS gateways. 578 5.4. Multi-Homed Enterprise: Single ISP 580 The key difference of the scenario described in Section 4.4 compared 581 to the other scenarios is that multi-homing is provided by the same 582 ISP. Concretely, that ISP can decide to provision the enterprise 583 network with: 585 * The same DOTS server for all network attachments. 587 * Distinct DOTS servers for each network attachment. These DOTS 588 servers need to coordinate when a mitigation action is received 589 from the enterprise network. 591 In both cases, DOTS agents enabled within the enterprise network MAY 592 decide to select one or all network attachments to send DOTS 593 mitigation requests. 595 6. Security Considerations 597 DOTS-related security considerations are discussed in Section 4 of 598 [RFC8811]. 600 DOTS clients should control the information that they share with peer 601 DOTS servers. In particular, if a DOTS client maintains DOTS 602 sessions with specific DOTS servers per interconnection link, the 603 DOTS client SHOULD NOT leak information specific to a given link to 604 DOTS servers on different interconnection links that are not 605 authorized to mitigate attacks for that given link. Whether this 606 constraint is relaxed is deployment-specific and must be subject to 607 explicit consent from the DOTS client domain administrator. How to 608 seek for such consent is implementation- and deployment-specific. 610 7. IANA Considerations 612 This document does not require any action from IANA. 614 8. Acknowledgements 616 Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and 617 Christian Jacquenet for sharing their comments on the mailing list. 619 Thanks to Kirill Kasavchenko for the comments. 621 Thanks to Kathleen Moriarty for the secdir review and Joel Jaeggli 622 for the opsdir review. 624 9. References 626 9.1. Normative References 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, 630 DOI 10.17487/RFC2119, March 1997, 631 . 633 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 634 "Default Address Selection for Internet Protocol Version 6 635 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 636 . 638 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 639 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 640 May 2017, . 642 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 643 Teague, N., and R. Compton, "DDoS Open Threat Signaling 644 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 645 August 2020, . 647 9.2. Informative References 649 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 650 Multihoming Architectures", RFC 3582, 651 DOI 10.17487/RFC3582, August 2003, 652 . 654 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 655 Gill, "IPv4 Multihoming Practices and Limitations", 656 RFC 4116, DOI 10.17487/RFC4116, July 2005, 657 . 659 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 660 Denial-of-Service Considerations", RFC 4732, 661 DOI 10.17487/RFC4732, December 2006, 662 . 664 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 665 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 666 . 668 [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent 669 Routing and Source Address Selection for IPv6 Hosts: 670 Overview of the Problem Space", RFC 8043, 671 DOI 10.17487/RFC8043, January 2017, 672 . 674 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 675 Denial-of-Service Open Threat Signaling (DOTS) Data 676 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 677 May 2020, . 679 [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., 680 Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", 681 RFC 8803, DOI 10.17487/RFC8803, July 2020, 682 . 684 [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 685 L., and K. Nishizuka, "Use Cases for DDoS Open Threat 686 Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, 687 . 689 [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling 690 (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, 691 January 2021, . 693 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 694 "Distributed Denial-of-Service Open Threat Signaling 695 (DOTS) Signal Channel Specification", RFC 9132, 696 DOI 10.17487/RFC9132, September 2021, 697 . 699 [TS.24008] 3GPP, "Mobile radio interface Layer 3 specification; Core 700 network protocols; Stage 3 (Release 16)", December 2019, 701 . 703 Authors' Addresses 705 Mohamed Boucadair 706 Orange 707 35000 Rennes 708 France 710 Email: mohamed.boucadair@orange.com 712 Tirumaleswar Reddy 713 McAfee, Inc. 714 Embassy Golf Link Business Park 715 Bangalore 560071 716 Karnataka 717 India 719 Email: TirumaleswarReddy_Konda@McAfee.com 721 Wei Pan 722 Huawei Technologies 724 Email: william.panwei@huawei.com