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