idnits 2.17.1 draft-ietf-dots-multihoming-07.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 == Line 180 has weird spacing: '...dresses are g...' == Line 188 has weird spacing: '...dresses are g...' -- The document date (July 6, 2021) is 1025 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8811 == Outdated reference: A later version (-08) exists of draft-ietf-dots-rfc8782-bis-06 Summary: 1 error (**), 0 flaws (~~), 4 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: Standards Track T. Reddy 5 Expires: January 7, 2022 McAfee 6 W. Pan 7 Huawei Technologies 8 July 6, 2021 10 Multi-homing Deployment Considerations for Distributed-Denial-of-Service 11 Open Threat Signaling (DOTS) 12 draft-ietf-dots-multihoming-07 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 January 7, 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 15 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. It 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 o Identify and extract viable deployment candidates from [RFC8903]. 150 o 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 o Describe the recommended behavior of DOTS clients and gateways for 160 each case. 162 Multi-homed DOTS agents are assumed to make use of the protocols 163 defined in [I-D.ietf-dots-rfc8782-bis] and [RFC8783]; no specific 164 extension is required 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 This section distinguishes between residential CPEs vs. enterprise 203 CPEs because PI addresses may be used for enterprises while this is 204 not the current practice for residential CPEs. 206 4.1. Multi-Homed Residential Single CPE 208 The scenario shown in Figure 2 is characterized as follows: 210 o The home network is connected to the Internet using one single 211 CPE. 213 o The CPE is connected to multiple provisioning domains (i.e., both 214 fixed and mobile networks). Provisioning domain (PvD) is 215 explained in [RFC7556]. 217 In a typical deployment scenario, these provisioning domains are 218 owned by the same provider (see Section 1 of [RFC8803]). Such a 219 deployment is meant to seamlessly use both fixed and cellular 220 networks for bonding, faster hand-overs, or better resiliency 221 purposes. 223 o Each of these provisioning domains assigns IP addresses/prefixes 224 to the CPE and provides additional configuration information such 225 as a list of DNS servers, DNS suffixes associated with the 226 network, default gateway address, and DOTS server's name 227 [RFC8973]. These addresses/prefixes are assumed to be Provider- 228 Aggregatable (PA). 230 o Because of ingress filtering, packets forwarded by the CPE towards 231 a given provisioning domain must be sent with a source IP address 232 that was assigned by that domain [RFC8043]. 234 +-------+ +-------+ 235 |Fixed | |Mobile | 236 |Network| |Network| 237 +---+---+ +---+---+ 238 | | Service Providers 239 ............|....................|....................... 240 +---------++---------+ Home Network 241 || 242 +--++-+ 243 | CPE | 244 +-----+ 245 ... (Internal Network) 247 Figure 2: Typical Multi-homed Residential CPE 249 4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 251 The scenario shown in Figure 3 is characterized as follows: 253 o The enterprise network is connected to the Internet using a single 254 router. 256 o That router is connected to multiple provisioning domains (i.e., 257 managed by distinct administrative entities). 259 Unlike the previous scenario, two sub-cases can be considered for an 260 enterprise network with regards to assigned addresses: 262 1. PI addresses/prefixes: The enterprise is the owner of the IP 263 addresses/prefixes; the same address/prefix is then used when 264 establishing communications over any of the provisioning domains. 266 2. PA addresses/prefixes: Each of the provisioning domains assigns 267 IP addresses/prefixes to the enterprise network. 269 +------+ +------+ 270 | ISP1 | | ISP2 | 271 +---+--+ +--+---+ 272 | | Service Providers 273 ............|....................|....................... 274 +---------++---------+ Enterprise Network 275 || 276 +--++-+ 277 | rtr | 278 +-----+ 279 ... (Internal Network) 281 Figure 3: Multi-homed Enterprise Network (Single CPE connected to 282 Multiple Networks) 284 4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 286 This scenario is similar to the one described in Section 4.2; the 287 main difference is that dedicated routers are used to connect to each 288 provisioning domain. 290 +------+ +------+ 291 | ISP1 | | ISP2 | 292 +---+--+ +--+---+ 293 | | Service Providers 294 ......................|..........|....................... 295 | | Enterprise Network 296 +---+--+ +--+---+ 297 | rtr1 | | rtr2 | 298 +------+ +------+ 300 ... (Internal Network) 302 Figure 4: Multi-homed Enterprise Network (Multiple CPEs, Multiple 303 ISPs) 305 4.4. Multi-homed Enterprise with the Same ISP 307 This scenario is a variant of Section 4.2 and Section 4.3 in which 308 multi-homing is supported by the same ISP (i.e., same provisioning 309 domain). 311 5. DOTS Multi-homing Deployment Considerations 313 Table 1 provides some sample, non-exhaustive, deployment schemes to 314 illustrate how DOTS agents may be deployed for each of the scenarios 315 introduced in Section 4. 317 +---------------------------+-------------------------+-------------+ 318 | Scenario | DOTS client | DOTS | 319 | | | gateway | 320 +---------------------------+-------------------------+-------------+ 321 | Residential CPE | CPE | N/A | 322 +---------------------------+-------------------------+-------------+ 323 | Single CPE, Multiple | Internal hosts or CPE | CPE | 324 | provisioning domains | | | 325 +---------------------------+-------------------------+-------------+ 326 | Multiple CPEs, Multiple | Internal hosts or all | CPEs (rtr1 | 327 | provisioning domains | CPEs (rtr1 and rtr2) | and rtr2) | 328 +---------------------------+-------------------------+-------------+ 329 | Multi-homed enterprise, | Internal hosts or all | CPEs (rtr1 | 330 | Single provisioning | CPEs (rtr1 and rtr2) | and rtr2) | 331 | domain | | | 332 +---------------------------+-------------------------+-------------+ 334 Table 1: Sample Deployment Cases 336 These deployment schemes are further discussed in the following 337 subsections. 339 5.1. Residential CPE 341 Figure 5 depicts DOTS sessions that need to be established between a 342 DOTS client (C) and two DOTS servers (S1, S2) within the context of 343 the scenario described in Section 4.1. 345 For each provisioning domain, the DOTS client MUST resolve the DOTS 346 server's name provided by a provisioning domain ([RFC8973]) using the 347 DNS servers learned from the respective provisioning domain. 348 IPv6-capable DOTS clients MUST use the source address selection 349 algorithm defined in [RFC6724] to select the candidate source 350 addresses to contact each of these DOTS servers. DOTS sessions MUST 351 be established and MUST be maintained with each of the DOTS servers 352 because the mitigation scope of each of these servers is restricted. 353 The DOTS client SHOULD use the certificate provisioned by a 354 provisioning domain to authenticate itself to the DOTS server(s) 355 provided by the same provisioning domain. 357 When conveying a mitigation request to protect the attack target(s), 358 the DOTS client MUST select an available DOTS server whose network 359 has assigned the IP prefixes from which target prefixes/addresses are 360 derived. This implies that if no appropriate DOTS server is found, 361 the DOTS client MUST NOT send the mitigation request to any other 362 available DOTS server. 364 For example, a mitigation request to protect target resources bound 365 to a PA IP address/prefix cannot be satisfied by a provisioning 366 domain other than the one that owns those addresses/prefixes. 367 Consequently, if a CPE detects a DDoS attack that spreads over all 368 its network attachments, it MUST contact both DOTS servers for 369 mitigation purposes. 371 The DOTS client MUST be able to associate a DOTS server with each 372 provisioning domain. For example, if the DOTS client is provisioned 373 with S1 using DHCP when attaching to a first network and with S2 374 using Protocol Configuration Option (PCO) when attaching to a second 375 network, the DOTS client must record the interface from which a DOTS 376 server was provisioned. DOTS signaling session to a given DOTS 377 server must be established using the interface from which the DOTS 378 server was provisioned. 380 +--+ 381 ----------|S1| 382 / +--+ 383 / DOTS Server Domain #1 384 / 385 +---+/ 386 | C | 387 +---+\ 388 \ 389 \ 390 \ +--+ 391 ----------|S2| 392 +--+ 393 DOTS Server Domain #2 395 Figure 5: DOTS Associations for a Multihomed Residential CPE 397 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs 399 Figure 6 illustrates a first set of DOTS associations that can be 400 established with a DOTS gateway, which is enabled within the context 401 of the scenario described in Section 4.2. This deployment is 402 characterized as follows: 404 o One of more DOTS clients are enabled in hosts located in the 405 internal network. 407 o A DOTS gateway is enabled to aggregate and then relay the requests 408 towards upstream DOTS servers. 410 When PA addresses/prefixes are in use, the same considerations 411 discussed in Section 5.1 need to be followed by the DOTS gateway to 412 contact its DOTS server(s). The DOTS gateways can be reachable from 413 DOTS clients by using an unicast address or an anycast address. 415 Nevertheless, when PI addresses/prefixes are assigned, the DOTS 416 gateway MUST send mitigation requests to all its DOTS servers. 417 Otherwise, the attack traffic may still be delivered via the ISP 418 which hasn't received the mitigation request. 420 +--+ 421 ----------|S1| 422 +---+ / +--+ 423 | C1|----+ / DOTS Server Domain #1 424 +---+ | / 425 +---+ +-+-+/ 426 | C3|------| G | 427 +---+ +-+-+\ 428 +---+ | \ 429 | C2|----+ \ 430 +---+ \ +--+ 431 ----------|S2| 432 +--+ 433 DOTS Server Domain #2 435 Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple DOTS 436 Servers 438 An alternate deployment model is depicted in Figure 7. This 439 deployment assumes that: 441 o One or more DOTS clients are enabled in hosts located in the 442 internal network. These DOTS clients may use [RFC8973] to 443 discover their DOTS server(s). 445 o These DOTS clients communicate directly with upstream DOTS 446 servers. 448 If PI addresses/prefixes are in use, the DOTS client MUST send a 449 mitigation request to all the DOTS servers. The use of anycast 450 addresses to reach the DOTS servers is NOT RECOMMENDED. 452 If PA addresses/prefixes are used, the same considerations discussed 453 in Section 5.1 need to be followed by the DOTS clients. Because DOTS 454 clients are not embedded in the CPE and multiple addreses/prefixes 455 may not be assigned to the DOTS client (typically in an IPv4 456 context), some issues may arise in how to steer traffic towards the 457 appropriate DOTS server by using the appropriate source IP address. 458 These complications discussed in [RFC4116] are not specific to DOTS. 460 .......... 461 . +--+ . 462 +--------|C1|--------+ 463 | . +--+ . | 464 | . . | 465 +--+ . +--+ . +--+ 466 |S2|------|C3|------|S1| 467 +--+ . +--+ . +--+ 468 | . . | 469 | . +--+ . | 470 +--------|C2|--------+ 471 . +--+ . 472 .......... 473 DOTS Client 474 Domain 476 Figure 7: Multiple DOTS Clients, Multiple DOTS Servers 478 Another deployment approach is to enable many DOTS clients; each of 479 them is responsible for handling communications with a specific DOTS 480 server (see Figure 8). 482 .......... 483 . +--+ . 484 +--------|C1| . 485 | . +--+ . 486 +--+ . +--+ . +--+ 487 |S2| . |C2|------|S1| 488 +--+ . +--+ . +--+ 489 .......... 490 DOTS Client 491 Domain 493 Figure 8: Single Homed DOTS Clients 495 Each DOTS client SHOULD be provided with policies (e.g., a prefix 496 filter that will be against DDoS detection alarms) that will trigger 497 DOTS communications with the DOTS servers. Such policies will help 498 the DOTS client to select the appropriate destination DOTS server. 500 The CPE MUST select the appropriate source IP address when forwarding 501 DOTS messages received from an internal DOTS client. If anycast 502 addresses are used to reach DOTS servers, the CPE may not be able to 503 select the appropriate provisioning domain to which the mitigation 504 request should be forwarded. As a consequence, the request may not 505 be forwarded to the appropriate DOTS server. 507 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs 509 The deployments depicted in Figures 7 and 8 also apply to the 510 scenario described in Section 4.3. One specific problem for this 511 scenario is to select the appropriate exit router when contacting a 512 given DOTS server. 514 An alternative deployment scheme is shown in Figure 9: 516 o DOTS clients are enabled in hosts located in the internal network. 518 o A DOTS gateway is enabled in each CPE (rtr1, rtr2). 520 o Each of these DOTS gateways communicates with the DOTS server of 521 the provisioning domain. 523 When PI addresses/prefixes are used, DOTS clients MUST contact all 524 the DOTS gateways to send a DOTS message. DOTS gateways will then 525 relay the request to the DOTS server. Note that the use of anycast 526 addresses is NOT RECOMMENDED to establish DOTS sessions between DOTS 527 clients and DOTS gateways. 529 When PA addresses/prefixes are used, but no filter rules are provided 530 to DOTS clients, the latter MUST contact all DOTS gateways 531 simultaneously to send a DOTS message. Upon receipt of a request by 532 a DOTS gateway, it MUST check whether the request is to be forwarded 533 upstream (if the target IP prefix is managed by the upstream server) 534 or rejected. 536 When PA addresses/prefixes are used, but specific filter rules are 537 provided to DOTS clients using some means that are out of scope of 538 this document, the clients MUST select the appropriate DOTS gateway 539 to reach. The use of anycast addresses is NOT RECOMMENDED to reach 540 DOTS gateways. 542 +---+ 543 +------------| C1|----+ 544 | +---+ | 545 +--+ +-+-+ +---+ +-+-+ +--+ 546 |S2|------|G2 |------| C3|------|G1 |------|S1| 547 +--+ +-+-+ +---+ +-+-+ +--+ 548 | +---+ | 549 +------------| C2|----+ 550 +---+ 552 Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple 553 DOTS Servers 555 5.4. Multi-Homed Enterprise: Single ISP 557 The key difference of the scenario described in Section 4.4 compared 558 to the other scenarios is that multi-homing is provided by the same 559 ISP. Concretely, that ISP can decide to provision the enterprise 560 network with: 562 o The same DOTS server for all network attachments. 564 o Distinct DOTS servers for each network attachment. These DOTS 565 servers need to coordinate when a mitigation action is received 566 from the enterprise network. 568 In both cases, DOTS agents enabled within the enterprise network MAY 569 decide to select one or all network attachments to send DOTS 570 mitigation requests. 572 6. Security Considerations 574 DOTS-related security considerations are discussed in Section 4 of 575 [RFC8811]. 577 DOTS clients should control the information that they share with peer 578 DOTS servers. In particular, if a DOTS client maintains DOTS 579 associations with specific DOTS servers per interconnection link, the 580 DOTS client SHOULD NOT leak information specific to a given link to 581 DOTS servers on different interconnection links that are not 582 authorized to mitigate attacks for that given link. Whether this 583 constraint is relaxed is deployment-specific and must be subject to 584 explicit consent from the DOTS client domain administrator. How to 585 seek for such consent is implementation- and deployment-specific. 587 7. IANA Considerations 589 This document does not require any action from IANA. 591 8. Acknowledgements 593 Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and 594 Christian Jacquenet for sharing their comments on the mailing list. 596 Thanks to Kirill Kasavchenko for the comments. 598 9. References 600 9.1. Normative References 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, 604 DOI 10.17487/RFC2119, March 1997, 605 . 607 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 608 "Default Address Selection for Internet Protocol Version 6 609 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 610 . 612 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 613 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 614 May 2017, . 616 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 617 Teague, N., and R. Compton, "DDoS Open Threat Signaling 618 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 619 August 2020, . 621 9.2. Informative References 623 [I-D.ietf-dots-rfc8782-bis] 624 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 625 Denial-of-Service Open Threat Signaling (DOTS) Signal 626 Channel Specification", draft-ietf-dots-rfc8782-bis-06 627 (work in progress), March 2021. 629 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 630 Multihoming Architectures", RFC 3582, 631 DOI 10.17487/RFC3582, August 2003, 632 . 634 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 635 Gill, "IPv4 Multihoming Practices and Limitations", 636 RFC 4116, DOI 10.17487/RFC4116, July 2005, 637 . 639 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 640 Denial-of-Service Considerations", RFC 4732, 641 DOI 10.17487/RFC4732, December 2006, 642 . 644 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 645 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 646 . 648 [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent 649 Routing and Source Address Selection for IPv6 Hosts: 650 Overview of the Problem Space", RFC 8043, 651 DOI 10.17487/RFC8043, January 2017, 652 . 654 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 655 Denial-of-Service Open Threat Signaling (DOTS) Data 656 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 657 May 2020, . 659 [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., 660 Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", 661 RFC 8803, DOI 10.17487/RFC8803, July 2020, 662 . 664 [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 665 L., and K. Nishizuka, "Use Cases for DDoS Open Threat 666 Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, 667 . 669 [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling 670 (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, 671 January 2021, . 673 Authors' Addresses 675 Mohamed Boucadair 676 Orange 677 Rennes 35000 678 France 680 Email: mohamed.boucadair@orange.com 681 Tirumaleswar Reddy 682 McAfee, Inc. 683 Embassy Golf Link Business Park 684 Bangalore, Karnataka 560071 685 India 687 Email: TirumaleswarReddy_Konda@McAfee.com 689 Wei Pan 690 Huawei Technologies 692 Email: william.panwei@huawei.com