idnits 2.17.1 draft-ietf-dots-architecture-18.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 (March 6, 2020) is 1505 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-20 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-34 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS A. Mortensen, Ed. 3 Internet-Draft Forcepoint 4 Intended status: Informational T. Reddy, Ed. 5 Expires: September 7, 2020 McAfee, Inc. 6 F. Andreasen 7 Cisco 8 N. Teague 9 Iron Mountain 10 R. Compton 11 Charter 12 March 6, 2020 14 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture 15 draft-ietf-dots-architecture-18 17 Abstract 19 This document describes an architecture for establishing and 20 maintaining Distributed Denial of Service (DDoS) Open Threat 21 Signaling (DOTS) within and between domains. The document does not 22 specify protocols or protocol extensions, instead focusing on 23 defining architectural relationships, components and concepts used in 24 a DOTS deployment. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 7, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Context and Motivation . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1.2. Definition of Terms . . . . . . . . . . . . . . . . . 3 64 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. DOTS Architecture . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8 68 2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9 70 2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10 71 2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11 72 2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 12 73 2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 14 74 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 3.1. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 16 76 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 17 77 3.1.2. Establishing the DOTS Session . . . . . . . . . . . . 17 78 3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 18 79 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18 80 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 19 81 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 19 82 3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 20 83 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 23 84 3.2.5. Signaling Considerations for Network Address 85 Translation . . . . . . . . . . . . . . . . . . . . . 25 86 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 27 87 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 28 88 3.3.2. Automated Conditional Mitigation Request . . . . . . 29 89 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 30 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 92 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 93 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 96 8.2. Informative References . . . . . . . . . . . . . . . . . 32 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 99 1. Context and Motivation 101 Signaling the need for help to defend against an active distributed 102 denial of service (DDoS) attack requires a common understanding of 103 mechanisms and roles among the parties coordinating defensive 104 response. The signaling layer and supplementary messaging is the 105 focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of 106 coordinating defensive measures among willing peers to mitigate 107 attacks quickly and efficiently, enabling hybrid attack responses 108 coordinated locally at or near the target of an active attack, or 109 anywhere in-path between attack sources and target. Sample DOTS use 110 cases are elaborated in [I-D.ietf-dots-use-cases]. 112 This document describes an architecture used in establishing, 113 maintaining or terminating a DOTS relationship within a domain or 114 between domains. 116 1.1. Terminology 118 1.1.1. Key Words 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 1.1.2. Definition of Terms 128 This document uses the terms defined in [RFC8612]. 130 1.2. Scope 132 In this architecture, DOTS clients and servers communicate using DOTS 133 signal channel [I-D.ietf-dots-signal-channel] and data channel 134 [I-D.ietf-dots-data-channel] protocols. 136 The DOTS architecture presented here is applicable across network 137 administrative domains - for example, between an enterprise domain 138 and the domain of a third-party attack mitigation service - as well 139 as to a single administrative domain. DOTS is generally assumed to 140 be most effective when aiding coordination of attack response between 141 two or more participating networks, but single domain scenarios are 142 valuable in their own right, as when aggregating intra-domain DOTS 143 client signals for inter-domain coordinated attack response. 145 This document does not address any administrative or business 146 agreements that may be established between involved DOTS parties. 147 Those considerations are out of scope. Regardless, this document 148 assumes necessary authentication and authorization mechanisms are put 149 in place so that only authorized clients can invoke the DOTS service. 151 A detailed set of DOTS requirements are discussed in [RFC8612], and 152 the DOTS architecture is designed to follow those requirements. Only 153 new behavioral requirements are described in this document. 155 1.3. Assumptions 157 This document makes the following assumptions: 159 o All domains in which DOTS is deployed are assumed to offer the 160 required connectivity between DOTS agents and any intermediary 161 network elements, but the architecture imposes no additional 162 limitations on the form of connectivity. 164 o Congestion and resource exhaustion are intended outcomes of a DDoS 165 attack [RFC4732]. Some operators may utilize non-impacted paths 166 or networks for DOTS, but in general conditions should be assumed 167 to be hostile and DOTS must be able to function in all 168 circumstances, including when the signaling path is significantly 169 impaired. Congestion control requirements are discussed in 170 Section 3 of [RFC8612]. DOTS signal channel defined in 171 [I-D.ietf-dots-signal-channel] is designed to be extremely 172 resilient under extremely hostile network conditions and provides 173 continued contact between DOTS agents even as DDoS attack traffic 174 saturates the link. 176 o There is no universal DDoS attack scale threshold triggering a 177 coordinated response across administrative domains. A network 178 domain administrator, or service or application owner may 179 arbitrarily set attack scale threshold triggers, or manually send 180 requests for mitigation. 182 o Mitigation requests may be sent to one or more upstream DOTS 183 servers based on criteria determined by DOTS client administrators 184 and the underlying network configuration. The number of DOTS 185 servers with which a given DOTS client has established 186 communications is determined by local policy and is deployment- 187 specific. For example, a DOTS client of a multi-homed network may 188 support built-in policies to establish DOTS relationships with 189 DOTS servers located upstream of each interconnection link. 191 o The mitigation capacity and/or capability of domains receiving 192 requests for coordinated attack response is opaque to the domains 193 sending the request. The domain receiving the DOTS client signal 194 may or may not have sufficient capacity or capability to filter 195 any or all DDoS attack traffic directed at a target. In either 196 case, the upstream DOTS server may redirect a request to another 197 DOTS server. Redirection may be local to the redirecting DOTS 198 server's domain, or may involve a third-party domain. 200 o DOTS client and server signals, as well as messages sent through 201 the data channel, are sent across any transit networks with the 202 same probability of delivery as any other traffic between the DOTS 203 client domain and the DOTS server domain. Any encapsulation 204 required for successful delivery is left untouched by transit 205 network elements. DOTS server and DOTS client cannot assume any 206 preferential treatment of DOTS signals. Such preferential 207 treatment may be available in some deployments (e.g., intra-domain 208 scenarios), and the DOTS architecture does not preclude its use 209 when available. However, DOTS itself does not address how that 210 may be done. 212 o The architecture allows for, but does not assume, the presence of 213 Quality of Service (QoS) policy agreements between DOTS-enabled 214 peer networks or local QoS prioritization aimed at ensuring 215 delivery of DOTS messages between DOTS agents. QoS is an 216 operational consideration only, not a functional part of the DOTS 217 architecture. 219 o The signal and data channels are loosely coupled, and might not 220 terminate on the same DOTS server. How the DOTS servers 221 synchronize the DOTS configuration is out of scope of this 222 specification. 224 2. DOTS Architecture 226 The basic high-level DOTS architecture is illustrated in Figure 1: 228 +-----------+ +-------------+ 229 | Mitigator | ~~~~~~~~~~ | DOTS Server | 230 +-----------+ +-------------+ 231 | 232 | 233 | 234 +---------------+ +-------------+ 235 | Attack Target | ~~~~~~ | DOTS Client | 236 +---------------+ +-------------+ 238 Figure 1: Basic DOTS Architecture 240 A simple example instantiation of the DOTS architecture could be an 241 enterprise as the attack target for a volumetric DDoS attack, and an 242 upstream DDoS mitigation service as the mitigator. The service 243 provided by the mitigator is called: DDoS mitigation service. The 244 enterprise (attack target) is connected to the Internet via a link 245 that is getting saturated, and the enterprise suspects it is under 246 DDoS attack. The enterprise has a DOTS client, which obtains 247 information about the DDoS attack, and signals the DOTS server for 248 help in mitigating the attack. The DOTS server in turn invokes one 249 or more mitigators, which are tasked with mitigating the actual DDoS 250 attack, and hence aim to suppress the attack traffic while allowing 251 valid traffic to reach the attack target. 253 The scope of the DOTS specifications is the interfaces between the 254 DOTS client and DOTS server. The interfaces to the attack target and 255 the mitigator are out of scope of DOTS. Similarly, the operation of 256 both the attack target and the mitigator is out of scope of DOTS. 257 Thus, DOTS specifies neither how an attack target decides it is under 258 DDoS attack, nor does DOTS specify how a mitigator may actually 259 mitigate such an attack. A DOTS client's request for mitigation is 260 advisory in nature, and might not lead to any mitigation at all, 261 depending on the DOTS server domain's capacity and willingness to 262 mitigate on behalf of the DOTS client domain. 264 The DOTS client may be provided with a list of DOTS servers, each 265 associated with one or more IP addresses. These addresses may or may 266 not be of the same address family. The DOTS client establishes one 267 or more sessions by connecting to the provided DOTS server addresses. 269 As illustrated in Figure 2, there are two interfaces between a DOTS 270 server and a DOTS client; a signal channel and (optionally) a data 271 channel. 273 +---------------+ +---------------+ 274 | | <------- Signal Channel ------> | | 275 | DOTS Client | | DOTS Server | 276 | | <======= Data Channel ======> | | 277 +---------------+ +---------------+ 279 Figure 2: DOTS Interfaces 281 The primary purpose of the signal channel is for a DOTS client to ask 282 a DOTS server for help in mitigating an attack, and for the DOTS 283 server to inform the DOTS client about the status of such mitigation. 284 The DOTS client does this by sending a client signal, which contains 285 information about the attack target(s). The client signal may also 286 include telemetry information about the attack, if the DOTS client 287 has such information available. The DOTS server in turn sends a 288 server signal to inform the DOTS client of whether it will honor the 289 mitigation request. Assuming it will, the DOTS server initiates 290 attack mitigation, and periodically informs the DOTS client about the 291 status of the mitigation. Similarly, the DOTS client periodically 292 informs the DOTS server about the client's status, which at a minimum 293 provides client (attack target) health information, but it should 294 also include efficacy information about the attack mitigation as it 295 is now seen by the client. At some point, the DOTS client may decide 296 to terminate the server-side attack mitigation, which it indicates to 297 the DOTS server over the signal channel. A mitigation may also be 298 terminated if a DOTS client-specified mitigation lifetime is 299 exceeded. Note that the signal channel may need to operate over a 300 link that is experiencing a DDoS attack and hence is subject to 301 severe packet loss and high latency. 303 While DOTS is able to request mitigation with just the signal 304 channel, the addition of the DOTS data channel provides for 305 additional and more efficient capabilities. The primary purpose of 306 the data channel is to support DOTS related configuration and policy 307 information exchange between the DOTS client and the DOTS server. 308 Examples of such information include, but are not limited to: 310 o Creating identifiers, such as names or aliases, for resources for 311 which mitigation may be requested. Such identifiers may then be 312 used in subsequent signal channel exchanges to refer more 313 efficiently to the resources under attack. 315 o Drop-list management, which enables a DOTS client to inform the 316 DOTS server about sources to suppress. 318 o Accept-list management, which enables a DOTS client to inform the 319 DOTS server about sources from which traffic is always accepted. 321 o Filter management, which enables a DOTS client to install or 322 remove traffic filters dropping or rate-limiting unwanted traffic. 324 o DOTS client provisioning. 326 Note that while it is possible to exchange the above information 327 before, during or after a DDoS attack, DOTS requires reliable 328 delivery of this information and does not provide any special means 329 for ensuring timely delivery of it during an attack. In practice, 330 this means that DOTS deployments should rely on such information 331 being exchanged only under normal traffic conditions. 333 2.1. DOTS Operations 335 DOTS does not prescribe any specific deployment models, however DOTS 336 is designed with some specific requirements around the different DOTS 337 agents and their relationships. 339 First of all, a DOTS agent belongs to a domain that has an identity 340 which can be authenticated and authorized. DOTS agents communicate 341 with each other over a mutually authenticated signal channel and 342 (optionally) data channel. However, before they can do so, a service 343 relationship needs to be established between them. The details and 344 means by which this is done is outside the scope of DOTS, however an 345 example would be for an enterprise A (DOTS client) to sign up for 346 DDoS service from provider B (DOTS server). This would establish a 347 (service) relationship between the two that enables enterprise A's 348 DOTS client to establish a signal channel with provider B's DOTS 349 server. A and B will authenticate each other, and B can verify that 350 A is authorized for its service. 352 From an operational and design point of view, DOTS assumes that the 353 above relationship is established prior to a request for DDoS attack 354 mitigation. In particular, it is assumed that bi-directional 355 communication is possible at this time between the DOTS client and 356 DOTS server. Furthermore, it is assumed that additional service 357 provisioning, configuration and information exchange can be performed 358 by use of the data channel, if operationally required. It is not 359 until this point that the mitigation service is available for use. 361 Once the mutually authenticated signal channel has been established, 362 it will remain active. This is done to increase the likelihood that 363 the DOTS client can signal the DOTS server for help when the attack 364 target is being flooded, and similarly raise the probability that 365 DOTS server signals reach the client regardless of inbound link 366 congestion. This does not necessarily imply that the attack target 367 and the DOTS client have to be co-located in the same administrative 368 domain, but it is expected to be a common scenario. 370 DDoS mitigation with the help of an upstream mitigator may involve 371 some form of traffic redirection whereby traffic destined for the 372 attack target is steered towards the mitigator. Common mechanisms to 373 achieve this redirection depend on BGP [RFC4271] and DNS [RFC1035]. 374 The mitigator in turn inspects and scrubs the traffic, and forwards 375 the resulting (hopefully non-attack) traffic to the attack target. 376 Thus, when a DOTS server receives an attack mitigation request from a 377 DOTS client, it can be viewed as a way of causing traffic redirection 378 for the attack target indicated. 380 DOTS relies on mutual authentication and the pre-established service 381 relationship between the DOTS client domain and the DOTS server 382 domain to provide authorization. The DOTS server should enforce 383 authorization mechanisms to restrict the mitigation scope a DOTS 384 client can request, but such authorization mechanisms are deployment- 385 specific. 387 Although co-location of DOTS server and mitigator within the same 388 domain is expected to be a common deployment model, it is assumed 389 that operators may require alternative models. Nothing in this 390 document precludes such alternatives. 392 2.2. Components 394 2.2.1. DOTS Client 396 A DOTS client is a DOTS agent from which requests for help 397 coordinating attack response originate. The requests may be in 398 response to an active, ongoing attack against a target in the DOTS 399 client domain, but no active attack is required for a DOTS client to 400 request help. Operators may wish to have upstream mitigators in the 401 network path for an indefinite period, and are restricted only by 402 business relationships when it comes to duration and scope of 403 requested mitigation. 405 The DOTS client requests attack response coordination from a DOTS 406 server over the signal channel, including in the request the DOTS 407 client's desired mitigation scoping, as described in [RFC8612] (SIG- 408 008). The actual mitigation scope and countermeasures used in 409 response to the attack are up to the DOTS server and mitigator 410 operators, as the DOTS client may have a narrow perspective on the 411 ongoing attack. As such, the DOTS client's request for mitigation 412 should be considered advisory: guarantees of DOTS server availability 413 or mitigation capacity constitute service level agreements and are 414 out of scope for this document. 416 The DOTS client adjusts mitigation scope and provides available 417 mitigation feedback (e.g., mitigation efficacy) at the direction of 418 its local administrator. Such direction may involve manual or 419 automated adjustments in response to updates from the DOTS server. 421 To provide a metric of signal health and distinguish an idle signal 422 channel from a disconnected or defunct session, the DOTS client sends 423 a heartbeat over the signal channel to maintain its half of the 424 channel. The DOTS client similarly expects a heartbeat from the DOTS 425 server, and may consider a session terminated in the extended absence 426 of a DOTS server heartbeat. 428 2.2.2. DOTS Server 430 A DOTS server is a DOTS agent capable of receiving, processing and 431 possibly acting on requests for help coordinating attack response 432 from DOTS clients. The DOTS server authenticates and authorizes DOTS 433 clients as described in Section 3.1, and maintains session state, 434 tracking requests for mitigation, reporting on the status of active 435 mitigations, and terminating sessions in the extended absence of a 436 client heartbeat or when a session times out. 438 Assuming the preconditions discussed below exist, a DOTS client 439 maintaining an active session with a DOTS server may reasonably 440 expect some level of mitigation in response to a request for 441 coordinated attack response. 443 For a given DOTS client (administrative) domain, the DOTS server 444 needs to be able to determine whether a given resource is in that 445 domain. For example, this could take the form of associating a set 446 of IP addresses and/or prefixes per DOTS client domain. The DOTS 447 server enforces authorization of signals for mitigation, filtering 448 rules and aliases for resources from DOTS clients. The mechanism of 449 enforcement is not in scope for this document, but is expected to 450 restrict mitigation requests, filtering rules and aliases scope to 451 addresses, prefixes, and/or services owned by the DOTS client domain, 452 such that a DOTS client from one domain is not able to influence the 453 network path to another domain. A DOTS server MUST reject mitigation 454 requests, filtering rules and aliases for resources not owned by the 455 requesting DOTS client's administrative domain. The exact mechanism 456 for the DOTS servers to validate that the resources are within the 457 scope of the DOTS client domain is deployment-specific. For example, 458 if the DOTS client domain uses Provider-Aggregatable prefixes for its 459 resources and leverages the DDoS mitigation service of the Internet 460 Transit Provider (ITP), the ITP knows the prefixes assigned to the 461 DOTS client domain because they are assigned by the ITP itself. 462 However, if the DDoS Mitigation is offered by a third party DDoS 463 mitigation service provider, it does not know the resources owned by 464 the DOTS client domain. The DDoS mitigation service provider and the 465 DOTS client domain can opt to use the identifier validation 466 challenges discussed in [RFC8555] and [I-D.ietf-acme-ip] to identify 467 whether the DOTS client domain actually controls the resources. The 468 challenges for validating control of resources must be performed when 469 no attack traffic is present and works only for "dns" and "ip" 470 identifier types. Further, if the DOTS client lies about the 471 resources owned by the DOTS client domain, the DDoS mitigation 472 service provider can impose penalties for violating the service level 473 agreement. A DOTS server MAY also refuse a DOTS client's mitigation 474 request for arbitrary reasons, within any limits imposed by business 475 or service level agreements between client and server domains. If a 476 DOTS server refuses a DOTS client's request for mitigation, the DOTS 477 server MUST include the refusal reason in the server signal sent to 478 the client. 480 A DOTS server is in regular contact with one or more mitigators. If 481 a DOTS server accepts a DOTS client's request for help, the DOTS 482 server forwards a translated form of that request to the mitigator(s) 483 responsible for scrubbing attack traffic. Note that the form of the 484 translated request passed from the DOTS server to the mitigator is 485 not in scope: it may be as simple as an alert to mitigator operators, 486 or highly automated using vendor or open application programming 487 interfaces supported by the mitigator. The DOTS server MUST report 488 the actual scope of any mitigation enabled on behalf of a client. 490 The DOTS server SHOULD retrieve available metrics for any mitigations 491 activated on behalf of a DOTS client, and SHOULD include them in 492 server signals sent to the DOTS client originating the request for 493 mitigation. 495 To provide a metric of signal health and distinguish an idle signal 496 channel from a disconnected or defunct channel, the DOTS server MUST 497 send a heartbeat over the signal channel to maintain its half of the 498 channel. The DOTS server similarly expects a heartbeat from the DOTS 499 client, and MAY consider a session terminated in the extended absence 500 of a DOTS client heartbeat. 502 2.2.3. DOTS Gateway 504 Traditional client/server relationships may be expanded by chaining 505 DOTS sessions. This chaining is enabled through "logical 506 concatenation" of a DOTS server and a DOTS client, resulting in an 507 application analogous to the Session Initiation Protocol (SIP) 508 [RFC3261] logical entity of a Back-to-Back User Agent (B2BUA) 509 [RFC7092]. The term DOTS gateway is used here in the descriptions of 510 selected scenarios involving this application. 512 A DOTS gateway may be deployed client-side, server-side or both. The 513 gateway may terminate multiple discrete client connections and may 514 aggregate these into a single or multiple DOTS sessions. 516 The DOTS gateway will appear as a server to its downstream agents and 517 as a client to its upstream agents, a functional concatenation of the 518 DOTS client and server roles, as depicted in Figure 3: 520 +-------------+ 521 | | D | | 522 +----+ | | O | | +----+ 523 | c1 |----------| s1 | T | c2 |---------| s2 | 524 +----+ | | S | | +----+ 525 | | G | | 526 +-------------+ 528 Figure 3: DOTS gateway 530 The DOTS gateway MUST perform full stack DOTS session termination and 531 reorigination between its client and server side. The details of how 532 this is achieved are implementation specific. 534 2.3. DOTS Agent Relationships 536 So far, we have only considered a relatively simple scenario of a 537 single DOTS client associated with a single DOTS server, however DOTS 538 supports more advanced relationships. 540 A DOTS server may be associated with one or more DOTS clients, and 541 those DOTS clients may belong to different domains. An example 542 scenario is a mitigation provider serving multiple attack targets 543 (Figure 4). 545 DOTS clients DOTS server 546 +---+ 547 | c |----------- 548 +---+ \ 549 c1.example.org \ 550 \ 551 +---+ \ +---+ 552 | c |----------------| S | 553 +---+ / +---+ 554 c1.example.com / dots1.example.net 555 / 556 +---+ / 557 | c |----------- 558 +---+ 559 c2.example.com 561 Figure 4: DOTS server with multiple clients 563 A DOTS client may be associated with one or more DOTS servers, and 564 those DOTS servers may belong to different domains. This may be to 565 ensure high availability or co-ordinate mitigation with more than one 566 directly connected ISP. An example scenario is for an enterprise to 567 have DDoS mitigation service from multiple providers, as shown in 568 Figure 5. 570 DOTS client DOTS servers 571 +---+ 572 -----------| S | 573 / +---+ 574 / dots1.example.net 575 / 576 +---+/ +---+ 577 | c |---------------| S | 578 +---+\ +---+ 579 \ dots.example.org 580 \ 581 \ +---+ 582 -----------| S | 583 +---+ 584 c.example.com dots2.example.net 586 Figure 5: Multi-Homed DOTS Client 588 Deploying a multi-homed client requires extra care and planning, as 589 the DOTS servers with which the multi-homed client communicates might 590 not be affiliated. Should the multi-homed client simultaneously 591 request for mitigation from all servers with which it has established 592 signal channels, the client may unintentionally inflict additional 593 network disruption on the resources it intends to protect. In one of 594 the worst cases, a multi-homed DOTS client could cause a permanent 595 routing loop of traffic destined for the client's protected services, 596 as the uncoordinated DOTS servers' mitigators all try to divert that 597 traffic to their own scrubbing centers. 599 The DOTS protocol itself provides no fool-proof method to prevent 600 such self-inflicted harms as a result deploying multi-homed DOTS 601 clients. If DOTS client implementations nevertheless include support 602 for multi-homing, they are expected to be aware of the risks, and 603 consequently to include measures aimed at reducing the likelihood of 604 negative outcomes. Simple measures might include: 606 o Requesting mitigation serially, ensuring only one mitigation 607 request for a given address space is active at any given time; 609 o Dividing the protected resources among the DOTS servers, such that 610 no two mitigators will be attempting to divert and scrub the same 611 traffic; 613 o Restricting multi-homing to deployments in which all DOTS servers 614 are coordinating management of a shared pool of mitigation 615 resources. 617 2.3.1. Gatewayed Signaling 619 As discussed in Section 2.2.3, a DOTS gateway is a logical function 620 chaining DOTS sessions through concatenation of a DOTS server and 621 DOTS client. 623 An example scenario, as shown in Figure 6 and Figure 7, is for an 624 enterprise to have deployed multiple DOTS capable devices which are 625 able to signal intra-domain using TCP [RFC0793] on un-congested links 626 to a DOTS gateway which may then transform these to a UDP [RFC0768] 627 transport inter-domain where connection oriented transports may 628 degrade; this applies to the signal channel only, as the data channel 629 requires a connection-oriented transport. The relationship between 630 the gateway and its upstream agents is opaque to the initial clients. 632 +---+ 633 | c |\ 634 +---+ \ +---+ 635 \-----TCP-----| D | +---+ 636 +---+ | O | | | 637 | c |--------TCP-----| T |------UDP------| S | 638 +---+ | S | | | 639 /-----TCP-----| G | +---+ 640 +---+ / +---+ 641 | c |/ 642 +---+ 643 example.com example.com example.net 644 DOTS clients DOTS gateway (DOTSG) DOTS server 646 Figure 6: Client-Side Gateway with Aggregation 648 +---+ 649 | c |\ 650 +---+ \ +---+ 651 \-----TCP-----| D |------UDP------+---+ 652 +---+ | O | | | 653 | c |--------TCP-----| T |------UDP------| S | 654 +---+ | S | | | 655 /-----TCP-----| G |------UDP------+---+ 656 +---+ / +---+ 657 | c |/ 658 +---+ 659 example.com example.com example.net 660 DOTS clients DOTS gateway (DOTSG) DOTS server 662 Figure 7: Client-Side Gateway without Aggregation 664 This may similarly be deployed in the inverse scenario where the 665 gateway resides in the server-side domain and may be used to 666 terminate and/or aggregate multiple clients to single transport as 667 shown in figures Figure 8 and Figure 9. 669 +---+ 670 | c |\ 671 +---+ \ +---+ 672 \-----UDP-----| D | +---+ 673 +---+ | O | | | 674 | c |--------TCP-----| T |------TCP------| S | 675 +---+ | S | | | 676 /-----TCP-----| G | +---+ 677 +---+ / +---+ 678 | c |/ 679 +---+ 680 example.com example.net example.net 681 DOTS clients DOTS gateway (DOTSG) DOTS server 683 Figure 8: Server-Side Gateway with Aggregation 685 +---+ 686 | c |\ 687 +---+ \ +---+ 688 \-----UDP-----| D |------TCP------+---+ 689 +---+ | O | | | 690 | c |--------TCP-----| T |------TCP------| S | 691 +---+ | S | | | 692 /-----UDP-----| G |------TCP------+---+ 693 +---+ / +---+ 694 | c |/ 695 +---+ 696 example.com example.net example.net 697 DOTS clients DOTS gateway (DOTSG) DOTS server 699 Figure 9: Server-Side Gateway without Aggregation 701 This document anticipates scenarios involving multiple DOTS gateways. 702 An example is a DOTS gateway at the network client's side, and 703 another one at the server side. The first gateway can be located at 704 a Customer Premises Equipment (CPE) to aggregate requests from 705 multiple DOTS clients enabled in an enterprise network. The second 706 DOTS gateway is deployed on the provider side. This scenario can be 707 seen as a combination of the client-side and server-side scenarios. 709 3. Concepts 711 3.1. DOTS Sessions 713 In order for DOTS to be effective as a vehicle for DDoS mitigation 714 requests, one or more DOTS clients must establish ongoing 715 communication with one or more DOTS servers. While the preconditions 716 for enabling DOTS in or among network domains may also involve 717 business relationships, service level agreements, or other formal or 718 informal understandings between network operators, such 719 considerations are out of scope for this document. 721 A DOTS session is established to support bilateral exchange of data 722 between an associated DOTS client and a DOTS server. In the DOTS 723 architecture, data is exchanged between DOTS agents over signal and 724 data channels. As such, a DOTS session can be a DOTS signal channel 725 session, a DOTS data channel session, or both. The DOTS server 726 couples the DOTS signal and data channel sessions using the DOTS 727 client identity. The DOTS session is further elaborated in the DOTS 728 signal channel protocol defined in [I-D.ietf-dots-signal-channel] and 729 the DOTS data channel protocol defined in 730 [I-D.ietf-dots-data-channel]. 732 A DOTS agent can maintain one or more DOTS sessions. 734 A DOTS signal channel session is associated with a single transport 735 connection (TCP or UDP session) and an security association (a TLS or 736 DTLS session). Similarly, a DOTS data channel session is associated 737 with a single TCP connection and an TLS security association. 739 Mitigation requests created using DOTS signal channel are not bound 740 to the DOTS signal channel session. Instead, mitigation requests are 741 associated with a DOTS client and can be managed using different DOTS 742 signal channel sessions. 744 3.1.1. Preconditions 746 Prior to establishing a DOTS session between agents, the owners of 747 the networks, domains, services or applications involved are assumed 748 to have agreed upon the terms of the relationship involved. Such 749 agreements are out of scope for this document, but must be in place 750 for a functional DOTS architecture. 752 It is assumed that as part of any DOTS service agreement, the DOTS 753 client is provided with all data and metadata required to establish 754 communication with the DOTS server. Such data and metadata would 755 include any cryptographic information necessary to meet the message 756 confidentiality, integrity and authenticity requirement (SEC-002) in 757 [RFC8612], and might also include the pool of DOTS server addresses 758 and ports the DOTS client should use for signal and data channel 759 messaging. 761 3.1.2. Establishing the DOTS Session 763 With the required business agreements in place, the DOTS client 764 initiates a DOTS session by contacting its DOTS server(s) over the 765 signal channel and (possibly) the data channel. To allow for DOTS 766 service flexibility, neither the order of contact nor the time 767 interval between channel creations is specified. A DOTS client MAY 768 establish signal channel first, and then data channel, or vice versa. 770 The methods by which a DOTS client receives the address and 771 associated service details of the DOTS server are not prescribed by 772 this document. For example, a DOTS client may be directly configured 773 to use a specific DOTS server IP address and port, and directly 774 provided with any data necessary to satisfy the Peer Mutual 775 Authentication requirement (SEC-001) in [RFC8612], such as symmetric 776 or asymmetric keys, usernames and passwords, etc. All configuration 777 and authentication information in this scenario is provided out-of- 778 band by the domain operating the DOTS server. 780 At the other extreme, the architecture in this document allows for a 781 form of DOTS client auto-provisioning. For example, the domain 782 operating the DOTS server or servers might provide the client domain 783 only with symmetric or asymmetric keys to authenticate the 784 provisioned DOTS clients. Only the keys would then be directly 785 configured on DOTS clients, but the remaining configuration required 786 to provision the DOTS clients could be learned through mechanisms 787 similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. 789 The DOTS client SHOULD successfully authenticate and exchange 790 messages with the DOTS server over both signal and (if used) data 791 channel as soon as possible to confirm that both channels are 792 operational. 794 As described in [RFC8612] (DM-008), the DOTS client can configure 795 preferred values for acceptable signal loss, mitigation lifetime, and 796 heartbeat intervals when establishing the DOTS signal channel 797 session. A DOTS signal channel session is not active until DOTS 798 agents have agreed on the values for these DOTS session parameters, a 799 process defined by the protocol. 801 Once the DOTS client begins receiving DOTS server signals, the DOTS 802 session is active. At any time during the DOTS session, the DOTS 803 client may use the data channel to manage aliases, manage drop- and 804 accept-listed prefixes or addresses, leverage vendor-specific 805 extensions, and so on. Note that unlike the signal channel, there is 806 no requirement that the data channel remains operational in attack 807 conditions (See Data Channel Requirements, Section 2.3 of [RFC8612]). 809 3.1.3. Maintaining the DOTS Session 811 DOTS clients and servers periodically send heartbeats to each other 812 over the signal channel, discussed in [RFC8612] (SIG-004). DOTS 813 agent operators SHOULD configure the heartbeat interval such that the 814 frequency does not lead to accidental denials of service due to the 815 overwhelming number of heartbeats a DOTS agent must field. 817 Either DOTS agent may consider a DOTS signal channel session 818 terminated in the extended absence of a heartbeat from its peer 819 agent. The period of that absence will be established in the 820 protocol definition. 822 3.2. Modes of Signaling 824 This section examines the modes of signaling between agents in a DOTS 825 architecture. 827 3.2.1. Direct Signaling 829 A DOTS session may take the form of direct signaling between the DOTS 830 clients and servers, as shown in Figure 10. 832 +-------------+ +-------------+ 833 | DOTS client |<------signal session------>| DOTS server | 834 +-------------+ +-------------+ 836 Figure 10: Direct Signaling 838 In a direct DOTS session, the DOTS client and server are 839 communicating directly. Direct signaling may exist inter- or intra- 840 domain. The DOTS session is abstracted from the underlying networks 841 or network elements the signals traverse: in direct signaling, the 842 DOTS client and server are logically adjacent. 844 3.2.2. Redirected Signaling 846 In certain circumstances, a DOTS server may want to redirect a DOTS 847 client to an alternative DOTS server for a DOTS signal channel 848 session. Such circumstances include but are not limited to: 850 o Maximum number of DOTS signal channel sessions with clients has 851 been reached; 853 o Mitigation capacity exhaustion in the mitigator with which the 854 specific DOTS server is communicating; 856 o Mitigator outage or other downtime, such as scheduled maintenance; 858 o Scheduled DOTS server maintenance; 860 o Scheduled modifications to the network path between DOTS server 861 and DOTS client. 863 A basic redirected DOTS signal channel session resembles the 864 following, as shown in Figure 11. 866 +-------------+ +---------------+ 867 | |<-(1)--- DOTS signal ------>| | 868 | | channel session 1 | | 869 | |<=(2)== redirect to B ======| | 870 | DOTS client | | DOTS server A | 871 | |X-(4)--- DOTS signal ------X| | 872 | | channel session 1 | | 873 | | | | 874 +-------------+ +---------------+ 875 ^ 876 | 877 (3) DOTS signal channel 878 | session 2 879 v 880 +---------------+ 881 | DOTS server B | 882 +---------------+ 884 Figure 11: Redirected Signaling 886 1. Previously established DOTS signal channel session 1 exists 887 between a DOTS client and DOTS server A. 889 2. DOTS server A sends a server signal redirecting the client to 890 DOTS server B. 892 3. If the DOTS client does not already have a separate DOTS signal 893 channel session with the redirection target, the DOTS client 894 initiates and establishes DOTS signal channel session 2 with DOTS 895 server B. 897 4. Having redirected the DOTS client, DOTS server A ceases sending 898 server signals. The DOTS client likewise stops sending client 899 signals to DOTS server A. DOTS signal channel session 1 is 900 terminated. 902 3.2.3. Recursive Signaling 904 DOTS is centered around improving the speed and efficiency of 905 coordinated response to DDoS attacks. One scenario not yet discussed 906 involves coordination among federated domains operating DOTS servers 907 and mitigators. 909 In the course of normal DOTS operations, a DOTS client communicates 910 the need for mitigation to a DOTS server, and that server initiates 911 mitigation on a mitigator with which the server has an established 912 service relationship. The operator of the mitigator may in turn 913 monitor mitigation performance and capacity, as the attack being 914 mitigated may grow in severity beyond the mitigating domain's 915 capabilities. 917 The operator of the mitigator has limited options in the event a DOTS 918 client-requested mitigation is being overwhelmed by the severity of 919 the attack. Out-of-scope business or service level agreements may 920 permit the mitigating domain to drop the mitigation and let attack 921 traffic flow unchecked to the target, but this only encourages attack 922 escalation. In the case where the mitigating domain is the upstream 923 service provider for the attack target, this may mean the mitigating 924 domain and its other services and users continue to suffer the 925 incidental effects of the attack. 927 A recursive signaling model as shown in Figure 12 offers an 928 alternative. In a variation of the use case "Upstream DDoS 929 Mitigation by an Upstream Internet Transit Provider" described in 930 [I-D.ietf-dots-use-cases], a domain operating a DOTS server and 931 mitigator also operates a DOTS client. This DOTS client has an 932 established DOTS session with a DOTS server belonging to a separate 933 administrative domain. 935 With these preconditions in place, the operator of the mitigator 936 being overwhelmed or otherwise performing inadequately may request 937 mitigation for the attack target from this separate DOTS-aware 938 domain. Such a request recurses the originating mitigation request 939 to the secondary DOTS server, in the hope of building a cumulative 940 mitigation against the attack. 942 example.net domain 943 . . . . . . . . . . . . . . . . . 944 . Gn . 945 +----+ 1 . +----+ +-----------+ . 946 | Cc |<--------->| Sn |~~~~~~~| Mitigator | . 947 +----+ . +====+ | Mn | . 948 . | Cn | +-----------+ . 949 example.com . +----+ . 950 client . ^ . 951 . . .|. . . . . . . . . . . . . . 952 | 953 2 | 954 | 955 . . .|. . . . . . . . . . . . . . 956 . v . 957 . +----+ +-----------+ . 958 . | So |~~~~~~~| Mitigator | . 959 . +----+ | Mo | . 960 . +-----------+ . 961 . . 962 . . . . . . . . . . . . . . . . . 963 example.org domain 965 Figure 12: Recursive Signaling 967 In Figure 12, client Cc signals a request for mitigation across 968 inter-domain DOTS session 1 to the DOTS server Sn belonging to the 969 example.net domain. DOTS server Sn enables mitigation on mitigator 970 Mn. DOTS server Sn is half of DOTS gateway Gn, being deployed 971 logically back-to-back with DOTS client Cn, which has pre-existing 972 inter-domain DOTS session 2 with the DOTS server So belonging to the 973 example.org domain. At any point, DOTS server Sn MAY recurse an on- 974 going mitigation request through DOTS client Cn to DOTS server So, in 975 the expectation that mitigator Mo will be activated to aid in the 976 defense of the attack target. 978 Recursive signaling is opaque to the DOTS client. To maximize 979 mitigation visibility to the DOTS client, however, the recursing 980 domain SHOULD provide recursed mitigation feedback in signals 981 reporting on mitigation status to the DOTS client. For example, the 982 recursing domain's DOTS server should incorporate into mitigation 983 status messages available metrics such as dropped packet or byte 984 counts from the recursed domain's DOTS server. 986 DOTS clients involved in recursive signaling must be able to withdraw 987 requests for mitigation without warning or justification, per SIG-006 988 in [RFC8612]. 990 Operators recursing mitigation requests MAY maintain the recursed 991 mitigation for a brief, protocol-defined period in the event the DOTS 992 client originating the mitigation withdraws its request for help, as 993 per the discussion of managing mitigation toggling in SIG-006 of 994 [RFC8612]. 996 Deployment of recursive signaling may result in traffic redirection, 997 examination and mitigation extending beyond the initial bilateral 998 relationship between DOTS client and DOTS server. As such, client 999 control over the network path of mitigated traffic may be reduced. 1000 DOTS client operators should be aware of any privacy concerns, and 1001 work with DOTS server operators employing recursive signaling to 1002 ensure shared sensitive material is suitably protected. Typically 1003 there is a contractual Service Level Agreement (SLA) negotiated among 1004 the DOTS client domain, the recursed domain and the recursing domain 1005 to meet the privacy requirements of the DOTS client domain and 1006 authorization for the recursing domain to request mitigation for the 1007 resources controlled by the DOTS client domain. 1009 3.2.4. Anycast Signaling 1011 The DOTS architecture does not assume the availability of anycast 1012 within a DOTS deployment, but neither does the architecture exclude 1013 it. Domains operating DOTS servers MAY deploy DOTS servers with an 1014 anycast Service Address as described in BCP 126 [RFC4786]. In such a 1015 deployment, DOTS clients connecting to the DOTS Service Address may 1016 be communicating with distinct DOTS servers, depending on the network 1017 configuration at the time the DOTS clients connect. Among other 1018 benefits, anycast signaling potentially offers the following: 1020 o Simplified DOTS client configuration, including service discovery 1021 through the methods described in [RFC7094]. In this scenario, the 1022 "instance discovery" message would be a DOTS client initiating a 1023 DOTS session to the DOTS server anycast Service Address, to which 1024 the DOTS server would reply with a redirection to the DOTS server 1025 unicast address the client should use for DOTS. 1027 o Region- or customer-specific deployments, in which the DOTS 1028 Service Addresses route to distinct DOTS servers depending on the 1029 client region or the customer network in which a DOTS client 1030 resides. 1032 o Operational resiliency, spreading DOTS signaling traffic across 1033 the DOTS server domain's networks, and thereby also reducing the 1034 potential attack surface, as described in BCP 126 [RFC4786]. 1036 3.2.4.1. Anycast Signaling Considerations 1038 As long as network configuration remains stable, anycast DOTS 1039 signaling is to the individual DOTS client indistinct from direct 1040 signaling. However, the operational challenges inherent in anycast 1041 signaling are anything but negligible, and DOTS server operators must 1042 carefully weigh the risks against the benefits before deploying. 1044 While the DOTS signal channel primarily operates over UDP per SIG-001 1045 in [RFC8612], the signal channel also requires mutual authentication 1046 between DOTS agents, with associated security state on both ends. 1048 Network instability is of particular concern with anycast signaling, 1049 as DOTS signal channels are expected to be long-lived, and 1050 potentially operating under congested network conditions caused by a 1051 volumetric DDoS attack. 1053 For example, a network configuration altering the route to the DOTS 1054 server during active anycast signaling may cause the DOTS client to 1055 send messages to a DOTS server other than the one with which it 1056 initially established a signaling session. That second DOTS server 1057 might not have the security state of the existing session, forcing 1058 the DOTS client to initialize a new DOTS session. This challenge 1059 might in part be mitigated by use of resumption via a PSK in TLS 1.3 1060 [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in 1061 TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must 1062 be available to all DOTS servers sharing the anycast Service Address 1063 in that case which has operational challenges of its own. 1065 While the DOTS client will try to establish a new DOTS session with 1066 the DOTS server now acting as the anycast DOTS Service Address, the 1067 link between DOTS client and server may be congested with attack 1068 traffic, making signal session establishment difficult. In such a 1069 scenario, anycast Service Address instability becomes a sort of 1070 signal session flapping, with obvious negative consequences for the 1071 DOTS deployment. 1073 Anycast signaling deployments similarly must also take into account 1074 active mitigations. Active mitigations initiated through a DOTS 1075 session may involve diverting traffic to a scrubbing center. If the 1076 DOTS session flaps due to anycast changes as described above, 1077 mitigation may also flap as the DOTS servers sharing the anycast DOTS 1078 service address toggles mitigation on detecting DOTS session loss, 1079 depending on whether the client has configured mitigation on loss of 1080 signal (Section 3.3.3). 1082 3.2.5. Signaling Considerations for Network Address Translation 1084 Network address translators (NATs) are expected to be a common 1085 feature of DOTS deployments. The Middlebox Traversal Guidelines in 1086 [RFC8085] include general NAT considerations that are applicable to 1087 DOTS deployments when the signal channel is established over UDP. 1089 Additional DOTS-specific considerations arise when NATs are part of 1090 the DOTS architecture. For example, DDoS attack detection behind a 1091 NAT will detect attacks against internal addresses. A DOTS client 1092 subsequently asked to request mitigation for the attacked scope of 1093 addresses cannot reasonably perform the task, due to the lack of 1094 externally routable addresses in the mitigation scope. 1096 The following considerations do not cover all possible scenarios, but 1097 are meant rather to highlight anticipated common issues when 1098 signaling through NATs. 1100 3.2.5.1. Direct Provisioning of Internal-to-External Address Mappings 1102 Operators may circumvent the problem of translating internal 1103 addresses or prefixes to externally routable mitigation scopes by 1104 directly provisioning the mappings of external addresses to internal 1105 protected resources on the DOTS client. When the operator requests 1106 mitigation scoped for internal addresses, directly or through 1107 automated means, the DOTS client looks up the matching external 1108 addresses or prefixes, and issues a mitigation request scoped to that 1109 externally routable information. 1111 When directly provisioning the address mappings, operators must 1112 ensure the mappings remain up to date, or risk losing the ability to 1113 request accurate mitigation scopes. To that aim, the DOTS client can 1114 rely on mechanisms such as [RFC8512] or [RFC7658] to retrieve static 1115 explicit mappings. This document does not prescribe the method by 1116 which mappings are maintained once they are provisioned on the DOTS 1117 client. 1119 3.2.5.2. Resolving Public Mitigation Scope with Port Control Protocol 1120 (PCP) 1122 Port Control Protocol (PCP) [RFC6887] may be used to retrieve the 1123 external addresses/prefixes and/or port numbers if the NAT function 1124 embeds a PCP server. 1126 A DOTS client can use the information retrieved by means of PCP to 1127 feed the DOTS protocol(s) messages that will be sent to a DOTS 1128 server. These messages will convey the external addresses/prefixes 1129 as set by the NAT. 1131 PCP also enables discovery and configuration of the lifetime of port 1132 mappings instantiated in intermediate NAT devices. Discovery of port 1133 mapping lifetimes can reduce the dependency on heartbeat messages to 1134 maintain mappings, and therefore reduce the load on DOTS servers and 1135 the network. 1137 3.2.5.3. Resolving Public Mitigation Scope with Session Traversal 1138 Utilities (STUN) 1140 An internal resource, e.g., a Web server, can discover its reflexive 1141 transport address through a STUN Binding request/response 1142 transaction, as described in [I-D.ietf-tram-stunbis]. After learning 1143 its reflexive transport address from the STUN server, the internal 1144 resource can export its reflexive transport address and internal 1145 transport address to the DOTS client, thereby enabling the DOTS 1146 client to request mitigation with the correct external scope, as 1147 depicted in Figure 13. The mechanism for providing the DOTS client 1148 with the reflexive transport address and internal transport address 1149 is unspecified in this document. 1151 In order to prevent an attacker from modifying the STUN messages in 1152 transit, the STUN client and server must use the message-integrity 1153 mechanism discussed in Section 9 of [I-D.ietf-tram-stunbis] or use 1154 STUN over DTLS [RFC7350] or use STUN over TLS. If the STUN client is 1155 behind a NAT that performs Endpoint-Dependent Mapping [RFC5128], the 1156 internal service cannot provide the DOTS client with the reflexive 1157 transport address discovered using STUN. The behavior of a NAT 1158 between the STUN client and the STUN server could be discovered using 1159 the experimental techniques discussed in [RFC5780], but note that 1160 there is currently no standardized way for a STUN client to reliably 1161 determine if it is behind a NAT that performs Endpoint-Dependent 1162 Mapping. 1164 Binding Binding 1165 +--------+ request +---+ request +--------+ 1166 | STUN |<----------| N |<----------| STUN | 1167 | server | | A | | client | 1168 | |---------->| T |---------->| | 1169 +--------+ Binding +---+ Binding +--------+ 1170 response response | 1171 | reflexive transport address 1172 | & internal transport address 1173 v 1174 +--------+ 1175 | DOTS | 1176 | client | 1177 +--------+ 1179 Figure 13: Resolving mitigation scope with STUN 1181 3.2.5.4. Resolving Requested Mitigation Scope with DNS 1183 DOTS supports mitigation scoped to DNS names. As discussed in 1184 [RFC3235], using DNS names instead of IP addresses potentially avoids 1185 the address translation problem, as long as the same domain name is 1186 internally and externally resolvable. For example, a detected 1187 attack's internal target address can be mapped to a DNS name through 1188 a reverse lookup. The DNS name returned by the reverse lookup can 1189 then be provided to the DOTS client as the external scope for 1190 mitigation. For the reverse DNS lookup, DNS Security Extensions 1191 (DNSSEC) [RFC4033] must be used where the authenticity of response is 1192 critical. 1194 3.3. Triggering Requests for Mitigation 1196 [RFC8612] places no limitation on the circumstances in which a DOTS 1197 client operator may request mitigation, nor does it demand 1198 justification for any mitigation request, thereby reserving 1199 operational control over DDoS defense for the domain requesting 1200 mitigation. This architecture likewise does not prescribe the 1201 network conditions and mechanisms triggering a mitigation request 1202 from a DOTS client. 1204 However, considering selected possible mitigation triggers from an 1205 architectural perspective offers a model for alternative or 1206 unanticipated triggers for DOTS deployments. In all cases, what 1207 network conditions merit a mitigation request are at the discretion 1208 of the DOTS client operator. 1210 The mitigation request itself is defined by DOTS, however the 1211 interfaces required to trigger the mitigation request in the 1212 following scenarios are implementation-specific. 1214 3.3.1. Manual Mitigation Request 1216 A DOTS client operator may manually prepare a request for mitigation, 1217 including scope and duration, and manually instruct the DOTS client 1218 to send the mitigation request to the DOTS server. In context, a 1219 manual request is a request directly issued by the operator without 1220 automated decision-making performed by a device interacting with the 1221 DOTS client. Modes of manual mitigation requests include an operator 1222 entering a command into a text interface, or directly interacting 1223 with a graphical interface to send the request. 1225 An operator might do this, for example, in response to notice of an 1226 attack delivered by attack detection equipment or software, and the 1227 alerting detector lacks interfaces or is not configured to use 1228 available interfaces to translate the alert to a mitigation request 1229 automatically. 1231 In a variation of the above scenario, the operator may have 1232 preconfigured on the DOTS client mitigation requests for various 1233 resources in the operator's domain. When notified of an attack, the 1234 DOTS client operator manually instructs the DOTS client to send the 1235 relevant preconfigured mitigation request for the resources under 1236 attack. 1238 A further variant involves recursive signaling, as described in 1239 Section 3.2.3. The DOTS client in this case is the second half of a 1240 DOTS gateway (back-to-back DOTS server and client). As in the 1241 previous scenario, the scope and duration of the mitigation request 1242 are pre-existing, but in this case are derived from the mitigation 1243 request received from a downstream DOTS client by the DOTS server. 1244 Assuming the preconditions required by Section 3.2.3 are in place, 1245 the DOTS gateway operator may at any time manually request mitigation 1246 from an upstream DOTS server, sending a mitigation request derived 1247 from the downstream DOTS client's request. 1249 The motivations for a DOTS client operator to request mitigation 1250 manually are not prescribed by this architecture, but are expected to 1251 include some of the following: 1253 o Notice of an attack delivered via e-mail or alternative messaging 1255 o Notice of an attack delivered via phone call 1256 o Notice of an attack delivered through the interface(s) of 1257 networking monitoring software deployed in the operator's domain 1259 o Manual monitoring of network behavior through network monitoring 1260 software 1262 3.3.2. Automated Conditional Mitigation Request 1264 Unlike manual mitigation requests, which depend entirely on the DOTS 1265 client operator's capacity to react with speed and accuracy to every 1266 detected or detectable attack, mitigation requests triggered by 1267 detected attack conditions reduce the operational burden on the DOTS 1268 client operator, and minimize the latency between attack detection 1269 and the start of mitigation. 1271 Mitigation requests are triggered in this scenario by operator- 1272 specified network conditions. Attack detection is deployment- 1273 specific, and not constrained by this architecture. Similarly the 1274 specifics of a condition are left to the discretion of the operator, 1275 though common conditions meriting mitigation include the following: 1277 o Detected attack exceeding a rate in packets per second (pps). 1279 o Detected attack exceeding a rate in bytes per second (bps). 1281 o Detected resource exhaustion in an attack target. 1283 o Detected resource exhaustion in the local domain's mitigator. 1285 o Number of open connections to an attack target. 1287 o Number of attack sources in a given attack. 1289 o Number of active attacks against targets in the operator's domain. 1291 o Conditional detection developed through arbitrary statistical 1292 analysis or deep learning techniques. 1294 o Any combination of the above. 1296 When automated conditional mitigation requests are enabled, 1297 violations of any of the above conditions, or any additional 1298 operator-defined conditions, will trigger a mitigation request from 1299 the DOTS client to the DOTS server. The interfaces between the 1300 application detecting the condition violation and the DOTS client are 1301 implementation-specific. 1303 3.3.3. Automated Mitigation on Loss of Signal 1305 To maintain a DOTS signal channel session, the DOTS client and the 1306 DOTS server exchange regular but infrequent messages across the 1307 signal channel. In the absence of an attack, the probability of 1308 message loss in the signaling channel should be extremely low. Under 1309 attack conditions, however, some signal loss may be anticipated as 1310 attack traffic congests the link, depending on the attack type. 1312 While [RFC8612] specifies the DOTS protocol be robust when signaling 1313 under attack conditions, there are nevertheless scenarios in which 1314 the DOTS signal is lost in spite of protocol best efforts. To handle 1315 such scenarios, a DOTS operator may request one or more mitigations 1316 which are triggered only when the DOTS server ceases receiving DOTS 1317 client heartbeats beyond the miss count or interval permitted by the 1318 protocol. 1320 The impact of mitigating due to loss of signal in either direction 1321 must be considered carefully before enabling it. Attack traffic 1322 congesting links is not the only reason why signal could be lost, and 1323 as such mitigation requests triggered by signal channel degradation 1324 in either direction may incur unnecessary costs due to scrubbing 1325 traffic, adversely impact network performance and operational expense 1326 alike. 1328 4. IANA Considerations 1330 This document has no actions for IANA. 1332 5. Security Considerations 1334 This section describes identified security considerations for the 1335 DOTS architecture. 1337 Security considerations and security requirements discussed in 1338 [RFC8612] need to be taken into account. 1340 DOTS is at risk from three primary attack vectors: agent 1341 impersonation, traffic injection and signal blocking. These vectors 1342 may be exploited individually or in concert by an attacker to 1343 confuse, disable, take information from, or otherwise inhibit DOTS 1344 agents. 1346 Any attacker with the ability to impersonate a legitimate DOTS client 1347 or server or, indeed, inject false messages into the stream may 1348 potentially trigger/withdraw traffic redirection, trigger/cancel 1349 mitigation activities or subvert drop-/accept-lists. From an 1350 architectural standpoint, operators MUST ensure conformance to the 1351 security requirements defined in Section 2.4 of [RFC8612] to secure 1352 data in transit. Similarly, as the received data may contain network 1353 topology, telemetry, threat and mitigation information which could be 1354 considered sensitive in certain environment, it SHOULD be protected 1355 at rest per required local policy. 1357 DOTS agents MUST perform mutual authentication to ensure authenticity 1358 of each other and DOTS servers MUST verify that the requesting DOTS 1359 client is authorized to request mitigation for specific target 1360 resources (see Section 2.2.2). 1362 An MITM attacker can intercept and drop packets, preventing the DOTS 1363 peers from receiving some or all of the DOTS messages, automated 1364 mitigation on loss of signal can be used as a countermeasure but with 1365 risks discussed in Section 3.3.3. 1367 An attacker with control of a DOTS client may negatively influence 1368 network traffic by requesting and withdrawing requests for mitigation 1369 for particular prefixes, leading to route or DNS flapping. DOTS 1370 operators should carefully monitor and audit DOTS clients to detect 1371 misbehavior and deter misuse. 1373 Any attack targeting the availability of DOTS servers may disrupt the 1374 ability of the system to receive and process DOTS signals resulting 1375 in failure to fulfill a mitigation request. DOTS servers MUST be 1376 given adequate protections, in accordance with best current practices 1377 for network and host security. 1379 6. Contributors 1381 Mohamed Boucadair 1382 Orange 1384 mohamed.boucadair@orange.com 1386 Christopher Gray Christopher_Gray3@cable.comcast.com 1388 7. Acknowledgments 1390 Thanks to Matt Richardson, Roman Danyliw, Frank Xialiang, Roland 1391 Dobbins, Wei Pan, Kaname Nishizuka, Jon Shallow, Paul Kyzivat, Warren 1392 Kumari, Benjamin Kaduk, and Mohamed Boucadair for their comments and 1393 suggestions. 1395 Special thanks to Roman Danyliw for the AD review. 1397 8. References 1399 8.1. Normative References 1401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1402 Requirement Levels", BCP 14, RFC 2119, 1403 DOI 10.17487/RFC2119, March 1997, 1404 . 1406 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1407 Rose, "DNS Security Introduction and Requirements", 1408 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1409 . 1411 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1412 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1413 December 2006, . 1415 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1416 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1417 DOI 10.17487/RFC6887, April 2013, 1418 . 1420 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1421 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1422 May 2017, . 1424 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1425 Threat Signaling (DOTS) Requirements", RFC 8612, 1426 DOI 10.17487/RFC8612, May 2019, 1427 . 1429 8.2. Informative References 1431 [I-D.ietf-acme-ip] 1432 Shoemaker, R., "ACME IP Identifier Validation Extension", 1433 draft-ietf-acme-ip-08 (work in progress), October 2019. 1435 [I-D.ietf-dots-data-channel] 1436 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 1437 Service Open Threat Signaling (DOTS) Data Channel 1438 Specification", draft-ietf-dots-data-channel-31 (work in 1439 progress), July 2019. 1441 [I-D.ietf-dots-signal-channel] 1442 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 1443 N. Teague, "Distributed Denial-of-Service Open Threat 1444 Signaling (DOTS) Signal Channel Specification", draft- 1445 ietf-dots-signal-channel-41 (work in progress), January 1446 2020. 1448 [I-D.ietf-dots-use-cases] 1449 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1450 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1451 Signaling", draft-ietf-dots-use-cases-20 (work in 1452 progress), September 2019. 1454 [I-D.ietf-tls-dtls13] 1455 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1456 Datagram Transport Layer Security (DTLS) Protocol Version 1457 1.3", draft-ietf-tls-dtls13-34 (work in progress), 1458 November 2019. 1460 [I-D.ietf-tram-stunbis] 1461 Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 1462 D., Mahy, R., and P. Matthews, "Session Traversal 1463 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-21 1464 (work in progress), March 2019. 1466 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1467 DOI 10.17487/RFC0768, August 1980, 1468 . 1470 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1471 RFC 793, DOI 10.17487/RFC0793, September 1981, 1472 . 1474 [RFC1035] Mockapetris, P., "Domain names - implementation and 1475 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1476 November 1987, . 1478 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1479 specifying the location of services (DNS SRV)", RFC 2782, 1480 DOI 10.17487/RFC2782, February 2000, 1481 . 1483 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 1484 Application Design Guidelines", RFC 3235, 1485 DOI 10.17487/RFC3235, January 2002, 1486 . 1488 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1489 A., Peterson, J., Sparks, R., Handley, M., and E. 1490 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1491 DOI 10.17487/RFC3261, June 2002, 1492 . 1494 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1495 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1496 DOI 10.17487/RFC4271, January 2006, 1497 . 1499 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1500 Denial-of-Service Considerations", RFC 4732, 1501 DOI 10.17487/RFC4732, December 2006, 1502 . 1504 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 1505 Peer (P2P) Communication across Network Address 1506 Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 1507 2008, . 1509 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1510 (TLS) Protocol Version 1.2", RFC 5246, 1511 DOI 10.17487/RFC5246, August 2008, 1512 . 1514 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 1515 Using Session Traversal Utilities for NAT (STUN)", 1516 RFC 5780, DOI 10.17487/RFC5780, May 2010, 1517 . 1519 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1520 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1521 January 2012, . 1523 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1524 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1525 . 1527 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1528 Initiation Protocol (SIP) Back-to-Back User Agents", 1529 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1530 . 1532 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1533 "Architectural Considerations of IP Anycast", RFC 7094, 1534 DOI 10.17487/RFC7094, January 2014, 1535 . 1537 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 1538 Layer Security (DTLS) as Transport for Session Traversal 1539 Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, 1540 August 2014, . 1542 [RFC7658] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor, 1543 "Deprecation of MIB Module NAT-MIB: Managed Objects for 1544 Network Address Translators (NATs)", RFC 7658, 1545 DOI 10.17487/RFC7658, October 2015, 1546 . 1548 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1549 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1550 March 2017, . 1552 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1553 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1554 . 1556 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1557 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1558 Address Translation (NAT) and Network Prefix Translation 1559 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1560 . 1562 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1563 Kasten, "Automatic Certificate Management Environment 1564 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1565 . 1567 Authors' Addresses 1569 Andrew Mortensen (editor) 1570 Forcepoint 1571 United States 1573 EMail: andrewmortensen@gmail.com 1575 Tirumaleswar Reddy (editor) 1576 McAfee, Inc. 1577 Embassy Golf Link Business Park 1578 Bangalore, Karnataka 560071 1579 India 1581 EMail: kondtir@gmail.com 1582 Flemming Andreasen 1583 Cisco 1584 United States 1586 EMail: fandreas@cisco.com 1588 Nik Teague 1589 Iron Mountain 1590 United States 1592 EMail: nteague@ironmountain.co.uk 1594 Rich Compton 1595 Charter 1597 EMail: Rich.Compton@charter.com