idnits 2.17.1 draft-ietf-dots-architecture-16.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 28, 2020) is 1550 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 (~~), 4 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: July 31, 2020 McAfee, Inc. 6 F. Andreasen 7 Cisco 8 N. Teague 9 Iron Mountain 10 R. Compton 11 Charter 12 January 28, 2020 14 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture 15 draft-ietf-dots-architecture-16 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 July 31, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 31 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 31 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", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in BCP14 [RFC2119] 123 [RFC8174], when, and only when, they appear in all capitals. 125 1.1.2. Definition of Terms 127 This document uses the terms defined in [RFC8612]. 129 1.2. Scope 131 In this architecture, DOTS clients and servers communicate using DOTS 132 signal channel [I-D.ietf-dots-signal-channel] and data channel 133 [I-D.ietf-dots-data-channel] protocols. 135 The DOTS architecture presented here is applicable across network 136 administrative domains - for example, between an enterprise domain 137 and the domain of a third-party attack mitigation service - as well 138 as to a single administrative domain. DOTS is generally assumed to 139 be most effective when aiding coordination of attack response between 140 two or more participating networks, but single domain scenarios are 141 valuable in their own right, as when aggregating intra-domain DOTS 142 client signals for inter-domain coordinated attack response. 144 This document does not address any administrative or business 145 agreements that may be established between involved DOTS parties. 146 Those considerations are out of scope. Regardless, this document 147 assumes necessary authentication and authorization mechanisms are put 148 in place so that only authorized clients can invoke the DOTS service. 150 A detailed set of DOTS requirements are discussed in [RFC8612], and 151 the DOTS architecture is designed to follow those requirements. Only 152 new behavioral requirements are described in this document. 154 1.3. Assumptions 156 This document makes the following assumptions: 158 o All domains in which DOTS is deployed are assumed to offer the 159 required connectivity between DOTS agents and any intermediary 160 network elements, but the architecture imposes no additional 161 limitations on the form of connectivity. 163 o Congestion and resource exhaustion are intended outcomes of a DDoS 164 attack [RFC4732]. Some operators may utilize non-impacted paths 165 or networks for DOTS, but in general conditions should be assumed 166 to be hostile and DOTS must be able to function in all 167 circumstances, including when the signaling path is significantly 168 impaired. Congestion control requirements are discussed in 169 Section 3 of [RFC8612]. DOTS signal channel defined in 170 [I-D.ietf-dots-signal-channel] is designed to be extremely 171 resilient under extremely hostile network conditions and provides 172 continued contact between DOTS agents even as DDoS attack traffic 173 saturates the link. 175 o There is no universal DDoS attack scale threshold triggering a 176 coordinated response across administrative domains. A network 177 domain administrator, or service or application owner may 178 arbitrarily set attack scale threshold triggers, or manually send 179 requests for mitigation. 181 o Mitigation requests may be sent to one or more upstream DOTS 182 servers based on criteria determined by DOTS client administrators 183 and the underlying network configuration. The number of DOTS 184 servers with which a given DOTS client has established 185 communications is determined by local policy and is deployment- 186 specific. For example, a DOTS client of a multi-homed network may 187 support built-in policies to establish DOTS relationships with 188 DOTS servers located upstream of each interconnection link. 190 o The mitigation capacity and/or capability of domains receiving 191 requests for coordinated attack response is opaque to the domains 192 sending the request. The domain receiving the DOTS client signal 193 may or may not have sufficient capacity or capability to filter 194 any or all DDoS attack traffic directed at a target. In either 195 case, the upstream DOTS server may redirect a request to another 196 DOTS server. Redirection may be local to the redirecting DOTS 197 server's domain, or may involve a third-party domain. 199 o DOTS client and server signals, as well as messages sent through 200 the data channel, are sent across any transit networks with the 201 same probability of delivery as any other traffic between the DOTS 202 client domain and the DOTS server domain. Any encapsulation 203 required for successful delivery is left untouched by transit 204 network elements. DOTS server and DOTS client cannot assume any 205 preferential treatment of DOTS signals. Such preferential 206 treatment may be available in some deployments (e.g., intra-domain 207 scenarios), and the DOTS architecture does not preclude its use 208 when available. However, DOTS itself does not address how that 209 may be done. 211 o The architecture allows for, but does not assume, the presence of 212 Quality of Service (QoS) policy agreements between DOTS-enabled 213 peer networks or local QoS prioritization aimed at ensuring 214 delivery of DOTS messages between DOTS agents. QoS is an 215 operational consideration only, not a functional part of the DOTS 216 architecture. 218 o The signal and data channels are loosely coupled, and may not 219 terminate on the same DOTS server. How the DOTS servers 220 synchronize the DOTS configuration is out of scope of this 221 specification. 223 2. DOTS Architecture 225 The basic high-level DOTS architecture is illustrated in Figure 1: 227 +-----------+ +-------------+ 228 | Mitigator | ~~~~~~~~~~ | DOTS Server | 229 +-----------+ +-------------+ 230 | 231 | 232 | 233 +---------------+ +-------------+ 234 | Attack Target | ~~~~~~ | DOTS Client | 235 +---------------+ +-------------+ 237 Figure 1: Basic DOTS Architecture 239 A simple example instantiation of the DOTS architecture could be an 240 enterprise as the attack target for a volumetric DDoS attack, and an 241 upstream DDoS mitigation service as the mitigator. The service 242 provided by the mitigator is called: DDoS mitigation service. The 243 enterprise (attack target) is connected to the Internet via a link 244 that is getting saturated, and the enterprise suspects it is under 245 DDoS attack. The enterprise has a DOTS client, which obtains 246 information about the DDoS attack, and signals the DOTS server for 247 help in mitigating the attack. The DOTS server in turn invokes one 248 or more mitigators, which are tasked with mitigating the actual DDoS 249 attack, and hence aim to suppress the attack traffic while allowing 250 valid traffic to reach the attack target. 252 The scope of the DOTS specifications is the interfaces between the 253 DOTS client and DOTS server. The interfaces to the attack target and 254 the mitigator are out of scope of DOTS. Similarly, the operation of 255 both the attack target and the mitigator is out of scope of DOTS. 256 Thus, DOTS neither specifies how an attack target decides it is under 257 DDoS attack, nor does DOTS specify how a mitigator may actually 258 mitigate such an attack. A DOTS client's request for mitigation is 259 advisory in nature, and may not lead to any mitigation at all, 260 depending on the DOTS server domain's capacity and willingness to 261 mitigate on behalf of the DOTS client domain. 263 The DOTS client may be provided with a list of DOTS servers, each 264 associated with one or more IP addresses. These addresses may or may 265 not be of the same address family. The DOTS client establishes one 266 or more sessions by connecting to the provided DOTS server addresses. 268 As illustrated in Figure 2, there are two interfaces between a DOTS 269 server and a DOTS client; a signal channel and (optionally) a data 270 channel. 272 +---------------+ +---------------+ 273 | | <------- Signal Channel ------> | | 274 | DOTS Client | | DOTS Server | 275 | | <======= Data Channel ======> | | 276 +---------------+ +---------------+ 278 Figure 2: DOTS Interfaces 280 The primary purpose of the signal channel is for a DOTS client to ask 281 a DOTS server for help in mitigating an attack, and for the DOTS 282 server to inform the DOTS client about the status of such mitigation. 283 The DOTS client does this by sending a client signal, which contains 284 information about the attack target(s). The client signal may also 285 include telemetry information about the attack, if the DOTS client 286 has such information available. The DOTS server in turn sends a 287 server signal to inform the DOTS client of whether it will honor the 288 mitigation request. Assuming it will, the DOTS server initiates 289 attack mitigation, and periodically informs the DOTS client about the 290 status of the mitigation. Similarly, the DOTS client periodically 291 informs the DOTS server about the client's status, which at a minimum 292 provides client (attack target) health information, but it should 293 also include efficacy information about the attack mitigation as it 294 is now seen by the client. At some point, the DOTS client may decide 295 to terminate the server-side attack mitigation, which it indicates to 296 the DOTS server over the signal channel. A mitigation may also be 297 terminated if a DOTS client-specified mitigation lifetime is 298 exceeded. Note that the signal channel may need to operate over a 299 link that is experiencing a DDoS attack and hence is subject to 300 severe packet loss and high latency. 302 While DOTS is able to request mitigation with just the signal 303 channel, the addition of the DOTS data channel provides for 304 additional and more efficient capabilities. The primary purpose of 305 the data channel is to support DOTS related configuration and policy 306 information exchange between the DOTS client and the DOTS server. 307 Examples of such information include, but are not limited to: 309 o Creating identifiers, such as names or aliases, for resources for 310 which mitigation may be requested. Such identifiers may then be 311 used in subsequent signal channel exchanges to refer more 312 efficiently to the resources under attack. 314 o Drop-list management, which enables a DOTS client to inform the 315 DOTS server about sources to suppress. 317 o Accept-list management, which enables a DOTS client to inform the 318 DOTS server about sources from which traffic is always accepted. 320 o Filter management, which enables a DOTS client to install or 321 remove traffic filters dropping or rate-limiting unwanted traffic. 323 o DOTS client provisioning. 325 Note that while it is possible to exchange the above information 326 before, during or after a DDoS attack, DOTS requires reliable 327 delivery of this information and does not provide any special means 328 for ensuring timely delivery of it during an attack. In practice, 329 this means that DOTS deployments should rely on such information 330 being exchanged only under normal traffic conditions. 332 2.1. DOTS Operations 334 DOTS does not prescribe any specific deployment models, however DOTS 335 is designed with some specific requirements around the different DOTS 336 agents and their relationships. 338 First of all, a DOTS agent belongs to a domain that has an identity 339 which can be authenticated and authorized. DOTS agents communicate 340 with each other over a mutually authenticated signal channel and 341 (optionally) data channel. However, before they can do so, a service 342 relationship needs to be established between them. The details and 343 means by which this is done is outside the scope of DOTS, however an 344 example would be for an enterprise A (DOTS client) to sign up for 345 DDoS service from provider B (DOTS server). This would establish a 346 (service) relationship between the two that enables enterprise A's 347 DOTS client to establish a signal channel with provider B's DOTS 348 server. A and B will authenticate each other, and B can verify that 349 A is authorized for its service. 351 From an operational and design point of view, DOTS assumes that the 352 above relationship is established prior to a request for DDoS attack 353 mitigation. In particular, it is assumed that bi-directional 354 communication is possible at this time between the DOTS client and 355 DOTS server. Furthermore, it is assumed that additional service 356 provisioning, configuration and information exchange can be performed 357 by use of the data channel, if operationally required. It is not 358 until this point that the mitigation service is available for use. 360 Once the mutually authenticated signal channel has been established, 361 it will remain active. This is done to increase the likelihood that 362 the DOTS client can signal the DOTS server for help when the attack 363 target is being flooded, and similarly raise the probability that 364 DOTS server signals reach the client regardless of inbound link 365 congestion. This does not necessarily imply that the attack target 366 and the DOTS client have to be co-located in the same administrative 367 domain, but it is expected to be a common scenario. 369 DDoS mitigation with the help of an upstream mitigator may involve 370 some form of traffic redirection whereby traffic destined for the 371 attack target is steered towards the mitigator. Common mechanisms to 372 achieve this redirection depend on BGP [RFC4271] and DNS [RFC1035]. 373 The mitigator in turn inspects and scrubs the traffic, and forwards 374 the resulting (hopefully non-attack) traffic to the attack target. 375 Thus, when a DOTS server receives an attack mitigation request from a 376 DOTS client, it can be viewed as a way of causing traffic redirection 377 for the attack target indicated. 379 DOTS relies on mutual authentication and the pre-established service 380 relationship between the DOTS client domain and the DOTS server 381 domain to provide authorization. The DOTS server should enforce 382 authorization mechanisms to restrict the mitigation scope a DOTS 383 client can request, but such authorization mechanisms are deployment- 384 specific. 386 Although co-location of DOTS server and mitigator within the same 387 domain is expected to be a common deployment model, it is assumed 388 that operators may require alternative models. Nothing in this 389 document precludes such alternatives. 391 2.2. Components 393 2.2.1. DOTS Client 395 A DOTS client is a DOTS agent from which requests for help 396 coordinating attack response originate. The requests may be in 397 response to an active, ongoing attack against a target in the DOTS 398 client domain, but no active attack is required for a DOTS client to 399 request help. Operators may wish to have upstream mitigators in the 400 network path for an indefinite period, and are restricted only by 401 business relationships when it comes to duration and scope of 402 requested mitigation. 404 The DOTS client requests attack response coordination from a DOTS 405 server over the signal channel, including in the request the DOTS 406 client's desired mitigation scoping, as described in [RFC8612] (SIG- 407 008). The actual mitigation scope and countermeasures used in 408 response to the attack are up to the DOTS server and mitigator 409 operators, as the DOTS client may have a narrow perspective on the 410 ongoing attack. As such, the DOTS client's request for mitigation 411 should be considered advisory: guarantees of DOTS server availability 412 or mitigation capacity constitute service level agreements and are 413 out of scope for this document. 415 The DOTS client adjusts mitigation scope and provides available 416 mitigation feedback (e.g., mitigation efficacy) at the direction of 417 its local administrator. Such direction may involve manual or 418 automated adjustments in response to updates from the DOTS server. 420 To provide a metric of signal health and distinguish an idle signal 421 channel from a disconnected or defunct session, the DOTS client sends 422 a heartbeat over the signal channel to maintain its half of the 423 channel. The DOTS client similarly expects a heartbeat from the DOTS 424 server, and may consider a session terminated in the extended absence 425 of a DOTS server heartbeat. 427 2.2.2. DOTS Server 429 A DOTS server is a DOTS agent capable of receiving, processing and 430 possibly acting on requests for help coordinating attack response 431 from DOTS clients. The DOTS server authenticates and authorizes DOTS 432 clients as described in Section 3.1, and maintains session state, 433 tracking requests for mitigation, reporting on the status of active 434 mitigations, and terminating sessions in the extended absence of a 435 client heartbeat or when a session times out. 437 Assuming the preconditions discussed below exist, a DOTS client 438 maintaining an active session with a DOTS server may reasonably 439 expect some level of mitigation in response to a request for 440 coordinated attack response. 442 For a given DOTS client (administrative) domain, the DOTS server 443 needs to be able to determine whether a given resource is in that 444 domain. For example, this could take the form of associating a set 445 of IP addresses and/or prefixes per DOTS client domain. The DOTS 446 server enforces authorization of signals for mitigation, filtering 447 rules and aliases for resources from DOTS clients. The mechanism of 448 enforcement is not in scope for this document, but is expected to 449 restrict mitigation requests, filtering rules and aliases scope to 450 addresses, prefixes, and/or services owned by the DOTS client domain, 451 such that a DOTS client from one domain is not able to influence the 452 network path to another domain. A DOTS server MUST reject mitigation 453 requests, filtering rules and aliases for resources not owned by the 454 requesting DOTS client's administrative domain. The exact mechanism 455 for the DOTS servers to validate that the resources are within the 456 scope of the DOTS client domain is deployment-specific. For example, 457 if the DOTS client domain leverages the DDoS mitigation service of 458 its Internet Transit Provider (ITP), the ITP knows the prefixes 459 assigned to the DOTS client domain. However, if the DDoS Mitigation 460 is offered by a third party DDoS mitigation service provider, it does 461 not know the resources owned by the DOTS client domain. The DDoS 462 mitigation service provider and the DOTS client domain can opt to use 463 the identifier validation challenges discussed in [RFC8555] and 464 [I-D.ietf-acme-ip] to identify whether the DOTS client domain 465 actually controls the resources. The challenges for validating 466 control of resources must be performed when no attack traffic is 467 present and works only for "dns" and "ip" identifier types. Further, 468 if the DOTS client lies about the resources owned by the DOTS client 469 domain, the DDoS mitigation service provider can impose penalties for 470 violating the service level agreement. A DOTS server MAY also refuse 471 a DOTS client's mitigation request for arbitrary reasons, within any 472 limits imposed by business or service level agreements between client 473 and server domains. If a DOTS server refuses a DOTS client's request 474 for mitigation, the DOTS server MUST include the refusal reason in 475 the server signal sent to the client. 477 A DOTS server is in regular contact with one or more mitigators. If 478 a DOTS server accepts a DOTS client's request for help, the DOTS 479 server forwards a translated form of that request to the mitigator(s) 480 responsible for scrubbing attack traffic. Note that the form of the 481 translated request passed from the DOTS server to the mitigator is 482 not in scope: it may be as simple as an alert to mitigator operators, 483 or highly automated using vendor or open application programming 484 interfaces supported by the mitigator. The DOTS server MUST report 485 the actual scope of any mitigation enabled on behalf of a client. 487 The DOTS server SHOULD retrieve available metrics for any mitigations 488 activated on behalf of a DOTS client, and SHOULD include them in 489 server signals sent to the DOTS client originating the request for 490 mitigation. 492 To provide a metric of signal health and distinguish an idle signal 493 channel from a disconnected or defunct channel, the DOTS server MUST 494 send a heartbeat over the signal channel to maintain its half of the 495 channel. The DOTS server similarly expects a heartbeat from the DOTS 496 client, and MAY consider a session terminated in the extended absence 497 of a DOTS client heartbeat. 499 2.2.3. DOTS Gateway 501 Traditional client/server relationships may be expanded by chaining 502 DOTS sessions. This chaining is enabled through "logical 503 concatenation" of a DOTS server and a DOTS client, resulting in an 504 application analogous to the Session Initiation Protocol (SIP) 505 [RFC3261] logical entity of a Back-to-Back User Agent (B2BUA) 506 [RFC7092]. The term DOTS gateway is used here in the descriptions of 507 selected scenarios involving this application. 509 A DOTS gateway may be deployed client-side, server-side or both. The 510 gateway may terminate multiple discrete client connections and may 511 aggregate these into a single or multiple DOTS sessions. 513 The DOTS gateway will appear as a server to its downstream agents and 514 as a client to its upstream agents, a functional concatenation of the 515 DOTS client and server roles, as depicted in Figure 3: 517 +-------------+ 518 | | D | | 519 +----+ | | O | | +----+ 520 | c1 |----------| s1 | T | c2 |---------| s2 | 521 +----+ | | S | | +----+ 522 | | G | | 523 +-------------+ 525 Figure 3: DOTS gateway 527 The DOTS gateway MUST perform full stack DOTS session termination and 528 reorigination between its client and server side. The details of how 529 this is achieved are implementation specific. The DOTS protocol does 530 not include any special features related to DOTS gateways, and hence 531 from a DOTS perspective, whenever a DOTS gateway is present, the DOTS 532 session simply terminates/originates there. 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 may 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 CPE to aggregate requests from multiple DOTS clients enabled in an 705 enterprise network. The second DOTS gateway is deployed on the 706 provider side. This scenario can be seen as a combination of the 707 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 ephemeral security association 736 (a TLS or DTLS session). Similarly, a DOTS data channel session is 737 associated with a single TCP connection and an ephemeral TLS security 738 association. 740 Mitigation requests created using DOTS signal channel are not bound 741 to the DOTS signal channel session. Instead, mitigation requests are 742 associated with a DOTS client and can be managed using different DOTS 743 signal channel sessions. 745 3.1.1. Preconditions 747 Prior to establishing a DOTS session between agents, the owners of 748 the networks, domains, services or applications involved are assumed 749 to have agreed upon the terms of the relationship involved. Such 750 agreements are out of scope for this document, but must be in place 751 for a functional DOTS architecture. 753 It is assumed that as part of any DOTS service agreement, the DOTS 754 client is provided with all data and metadata required to establish 755 communication with the DOTS server. Such data and metadata would 756 include any cryptographic information necessary to meet the message 757 confidentiality, integrity and authenticity requirement (SEC-002) in 758 [RFC8612], and might also include the pool of DOTS server addresses 759 and ports the DOTS client should use for signal and data channel 760 messaging. 762 3.1.2. Establishing the DOTS Session 764 With the required business agreements in place, the DOTS client 765 initiates a DOTS session by contacting its DOTS server(s) over the 766 signal channel and (possibly) the data channel. To allow for DOTS 767 service flexibility, neither the order of contact nor the time 768 interval between channel creations is specified. A DOTS client MAY 769 establish signal channel first, and then data channel, or vice versa. 771 The methods by which a DOTS client receives the address and 772 associated service details of the DOTS server are not prescribed by 773 this document. For example, a DOTS client may be directly configured 774 to use a specific DOTS server IP address and port, and directly 775 provided with any data necessary to satisfy the Peer Mutual 776 Authentication requirement (SEC-001) in [RFC8612], such as symmetric 777 or asymmetric keys, usernames and passwords, etc. All configuration 778 and authentication information in this scenario is provided out-of- 779 band by the domain operating the DOTS server. 781 At the other extreme, the architecture in this document allows for a 782 form of DOTS client auto-provisioning. For example, the domain 783 operating the DOTS server or servers might provide the client domain 784 only with symmetric or asymmetric keys to authenticate the 785 provisioned DOTS clients. Only the keys would then be directly 786 configured on DOTS clients, but the remaining configuration required 787 to provision the DOTS clients could be learned through mechanisms 788 similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. 790 The DOTS client SHOULD successfully authenticate and exchange 791 messages with the DOTS server over both signal and (if used) data 792 channel as soon as possible to confirm that both channels are 793 operational. 795 As described in [RFC8612] (DM-008), the DOTS client can configure 796 preferred values for acceptable signal loss, mitigation lifetime, and 797 heartbeat intervals when establishing the DOTS signal channel 798 session. A DOTS signal channel session is not active until DOTS 799 agents have agreed on the values for these DOTS session parameters, a 800 process defined by the protocol. 802 Once the DOTS client begins receiving DOTS server signals, the DOTS 803 session is active. At any time during the DOTS session, the DOTS 804 client may use the data channel to manage aliases, manage drop- and 805 accept-listed prefixes or addresses, leverage vendor-specific 806 extensions, and so on. Note that unlike the signal channel, there is 807 no requirement that the data channel remains operational in attack 808 conditions (See Data Channel Requirements, Section 2.3 of [RFC8612]). 810 3.1.3. Maintaining the DOTS Session 812 DOTS clients and servers periodically send heartbeats to each other 813 over the signal channel, discussed in [RFC8612] (SIG-004). DOTS 814 agent operators SHOULD configure the heartbeat interval such that the 815 frequency does not lead to accidental denials of service due to the 816 overwhelming number of heartbeats a DOTS agent must field. 818 Either DOTS agent may consider a DOTS signal channel session 819 terminated in the extended absence of a heartbeat from its peer 820 agent. The period of that absence will be established in the 821 protocol definition. 823 3.2. Modes of Signaling 825 This section examines the modes of signaling between agents in a DOTS 826 architecture. 828 3.2.1. Direct Signaling 830 A DOTS session may take the form of direct signaling between the DOTS 831 clients and servers, as shown in Figure 10. 833 +-------------+ +-------------+ 834 | DOTS client |<------signal session------>| DOTS server | 835 +-------------+ +-------------+ 837 Figure 10: Direct Signaling 839 In a direct DOTS session, the DOTS client and server are 840 communicating directly. Direct signaling may exist inter- or intra- 841 domain. The DOTS session is abstracted from the underlying networks 842 or network elements the signals traverse: in direct signaling, the 843 DOTS client and server are logically adjacent. 845 3.2.2. Redirected Signaling 847 In certain circumstances, a DOTS server may want to redirect a DOTS 848 client to an alternative DOTS server for a DOTS signal channel 849 session. Such circumstances include but are not limited to: 851 o Maximum number of DOTS signal channel sessions with clients has 852 been reached; 854 o Mitigation capacity exhaustion in the mitigator with which the 855 specific DOTS server is communicating; 857 o Mitigator outage or other downtime, such as scheduled maintenance; 859 o Scheduled DOTS server maintenance; 861 o Scheduled modifications to the network path between DOTS server 862 and DOTS client. 864 A basic redirected DOTS signal channel session resembles the 865 following, as shown in Figure 11. 867 +-------------+ +---------------+ 868 | |<-(1)--- DOTS signal ------>| | 869 | | channel session 1 | | 870 | |<=(2)== redirect to B ======| | 871 | DOTS client | | DOTS server A | 872 | |X-(4)--- DOTS signal ------X| | 873 | | channel session 1 | | 874 | | | | 875 +-------------+ +---------------+ 876 ^ 877 | 878 (3) DOTS signal channel 879 | session 2 880 v 881 +---------------+ 882 | DOTS server B | 883 +---------------+ 885 Figure 11: Redirected Signaling 887 1. Previously established DOTS signal channel session 1 exists 888 between a DOTS client and DOTS server A. 890 2. DOTS server A sends a server signal redirecting the client to 891 DOTS server B. 893 3. If the DOTS client does not already have a separate DOTS signal 894 channel session with the redirection target, the DOTS client 895 initiates and establishes DOTS signal channel session 2 with DOTS 896 server B. 898 4. Having redirected the DOTS client, DOTS server A ceases sending 899 server signals. The DOTS client likewise stops sending client 900 signals to DOTS server A. DOTS signal channel session 1 is 901 terminated. 903 3.2.3. Recursive Signaling 905 DOTS is centered around improving the speed and efficiency of 906 coordinated response to DDoS attacks. One scenario not yet discussed 907 involves coordination among federated domains operating DOTS servers 908 and mitigators. 910 In the course of normal DOTS operations, a DOTS client communicates 911 the need for mitigation to a DOTS server, and that server initiates 912 mitigation on a mitigator with which the server has an established 913 service relationship. The operator of the mitigator may in turn 914 monitor mitigation performance and capacity, as the attack being 915 mitigated may grow in severity beyond the mitigating domain's 916 capabilities. 918 The operator of the mitigator has limited options in the event a DOTS 919 client-requested mitigation is being overwhelmed by the severity of 920 the attack. Out-of-scope business or service level agreements may 921 permit the mitigating domain to drop the mitigation and let attack 922 traffic flow unchecked to the target, but this only encourages attack 923 escalation. In the case where the mitigating domain is the upstream 924 service provider for the attack target, this may mean the mitigating 925 domain and its other services and users continue to suffer the 926 incidental effects of the attack. 928 A recursive signaling model as shown in Figure 12 offers an 929 alternative. In a variation of the use case "Upstream DDoS 930 Mitigation by an Upstream Internet Transit Provider" described in 931 [I-D.ietf-dots-use-cases], a domain operating a DOTS server and 932 mitigator also operates a DOTS client. This DOTS client has an 933 established DOTS session with a DOTS server belonging to a separate 934 administrative domain. 936 With these preconditions in place, the operator of the mitigator 937 being overwhelmed or otherwise performing inadequately may request 938 mitigation for the attack target from this separate DOTS-aware 939 domain. Such a request recurses the originating mitigation request 940 to the secondary DOTS server, in the hope of building a cumulative 941 mitigation against the attack. 943 example.net domain 944 . . . . . . . . . . . . . . . . . 945 . Gn . 946 +----+ 1 . +----+ +-----------+ . 947 | Cc |<--------->| Sn |~~~~~~~| Mitigator | . 948 +----+ . +====+ | Mn | . 949 . | Cn | +-----------+ . 950 example.com . +----+ . 951 client . ^ . 952 . . .|. . . . . . . . . . . . . . 953 | 954 2 | 955 | 956 . . .|. . . . . . . . . . . . . . 957 . v . 958 . +----+ +-----------+ . 959 . | So |~~~~~~~| Mitigator | . 960 . +----+ | Mo | . 961 . +-----------+ . 962 . . 963 . . . . . . . . . . . . . . . . . 964 example.org domain 966 Figure 12: Recursive Signaling 968 In Figure 12, client Cc signals a request for mitigation across 969 inter-domain DOTS session 1 to the DOTS server Sn belonging to the 970 example.net domain. DOTS server Sn enables mitigation on mitigator 971 Mn. DOTS server Sn is half of DOTS gateway Gn, being deployed 972 logically back-to-back with DOTS client Cn, which has pre-existing 973 inter-domain DOTS session 2 with the DOTS server So belonging to the 974 example.org domain. At any point, DOTS server Sn MAY recurse an on- 975 going mitigation request through DOTS client Cn to DOTS server So, in 976 the expectation that mitigator Mo will be activated to aid in the 977 defense of the attack target. 979 Recursive signaling is opaque to the DOTS client. To maximize 980 mitigation visibility to the DOTS client, however, the recursing 981 domain SHOULD provide recursed mitigation feedback in signals 982 reporting on mitigation status to the DOTS client. For example, the 983 recursing domain's DOTS server should incorporate into mitigation 984 status messages available metrics such as dropped packet or byte 985 counts from the recursed domain's DOTS server. 987 DOTS clients involved in recursive signaling must be able to withdraw 988 requests for mitigation without warning or justification, per SIG-006 989 in [RFC8612]. 991 Operators recursing mitigation requests MAY maintain the recursed 992 mitigation for a brief, protocol-defined period in the event the DOTS 993 client originating the mitigation withdraws its request for help, as 994 per the discussion of managing mitigation toggling in SIG-006 of 995 [RFC8612]. 997 Deployment of recursive signaling may result in traffic redirection, 998 examination and mitigation extending beyond the initial bilateral 999 relationship between DOTS client and DOTS server. As such, client 1000 control over the network path of mitigated traffic may be reduced. 1001 DOTS client operators should be aware of any privacy concerns, and 1002 work with DOTS server operators employing recursive signaling to 1003 ensure shared sensitive material is suitably protected. Typically 1004 there is a contractual Service Level Agreement (SLA) negotiated among 1005 the DOTS client domain, the recursed domain and the recursing domain 1006 to meet the privacy requirements of the DOTS client domain. 1008 3.2.4. Anycast Signaling 1010 The DOTS architecture does not assume the availability of anycast 1011 within a DOTS deployment, but neither does the architecture exclude 1012 it. Domains operating DOTS servers MAY deploy DOTS servers with an 1013 anycast Service Address as described in BCP 126 [RFC4786]. In such a 1014 deployment, DOTS clients connecting to the DOTS Service Address may 1015 be communicating with distinct DOTS servers, depending on the network 1016 configuration at the time the DOTS clients connect. Among other 1017 benefits, anycast signaling potentially offers the following: 1019 o Simplified DOTS client configuration, including service discovery 1020 through the methods described in [RFC7094]. In this scenario, the 1021 "instance discovery" message would be a DOTS client initiating a 1022 DOTS session to the DOTS server anycast Service Address, to which 1023 the DOTS server would reply with a redirection to the DOTS server 1024 unicast address the client should use for DOTS. 1026 o Region- or customer-specific deployments, in which the DOTS 1027 Service Addresses route to distinct DOTS servers depending on the 1028 client region or the customer network in which a DOTS client 1029 resides. 1031 o Operational resiliency, spreading DOTS signaling traffic across 1032 the DOTS server domain's networks, and thereby also reducing the 1033 potential attack surface, as described in BCP 126 [RFC4786]. 1035 3.2.4.1. Anycast Signaling Considerations 1037 As long as network configuration remains stable, anycast DOTS 1038 signaling is to the individual DOTS client indistinct from direct 1039 signaling. However, the operational challenges inherent in anycast 1040 signaling are anything but negligible, and DOTS server operators must 1041 carefully weigh the risks against the benefits before deploying. 1043 While the DOTS signal channel primarily operates over UDP per SIG-001 1044 in [RFC8612], the signal channel also requires mutual authentication 1045 between DOTS agents, with associated security state on both ends. 1047 Network instability is of particular concern with anycast signaling, 1048 as DOTS signal channels are expected to be long-lived, and 1049 potentially operating under congested network conditions caused by a 1050 volumetric DDoS attack. 1052 For example, a network configuration altering the route to the DOTS 1053 server during active anycast signaling may cause the DOTS client to 1054 send messages to a DOTS server other than the one with which it 1055 initially established a signaling session. That second DOTS server 1056 may not have the security state of the existing session, forcing the 1057 DOTS client to initialize a new DOTS session. This challenge might 1058 in part be mitigated by use of resumption via a PSK in TLS 1.3 1059 [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in 1060 TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must 1061 be available to all DOTS servers sharing the anycast Service Address 1062 in that case. 1064 While the DOTS client will try to establish a new DOTS session with 1065 the DOTS server now acting as the anycast DOTS Service Address, the 1066 link between DOTS client and server may be congested with attack 1067 traffic, making signal session establishment difficult. In such a 1068 scenario, anycast Service Address instability becomes a sort of 1069 signal session flapping, with obvious negative consequences for the 1070 DOTS deployment. 1072 Anycast signaling deployments similarly must also take into account 1073 active mitigations. Active mitigations initiated through a DOTS 1074 session may involve diverting traffic to a scrubbing center. If the 1075 DOTS session flaps due to anycast changes as described above, 1076 mitigation may also flap as the DOTS servers sharing the anycast DOTS 1077 service address toggles mitigation on detecting DOTS session loss, 1078 depending on whether the client has configured mitigation on loss of 1079 signal. 1081 3.2.5. Signaling Considerations for Network Address Translation 1083 Network address translators (NATs) are expected to be a common 1084 feature of DOTS deployments. The Middlebox Traversal Guidelines in 1085 [RFC8085] include general NAT considerations for DOTS deployments 1086 when the signal channel is established over UDP. 1088 Additional DOTS-specific considerations arise when NATs are part of 1089 the DOTS architecture. For example, DDoS attack detection behind a 1090 NAT will detect attacks against internal addresses. A DOTS client 1091 subsequently asked to request mitigation for the attacked scope of 1092 addresses cannot reasonably perform the task, due to the lack of 1093 externally routable addresses in the mitigation scope. 1095 The following considerations do not cover all possible scenarios, but 1096 are meant rather to highlight anticipated common issues when 1097 signaling through NATs. 1099 3.2.5.1. Direct Provisioning of Internal-to-External Address Mappings 1101 Operators may circumvent the problem of translating internal 1102 addresses or prefixes to externally routable mitigation scopes by 1103 directly provisioning the mappings of external addresses to internal 1104 protected resources on the DOTS client. When the operator requests 1105 mitigation scoped for internal addresses, directly or through 1106 automated means, the DOTS client looks up the matching external 1107 addresses or prefixes, and issues a mitigation request scoped to that 1108 externally routable information. 1110 When directly provisioning the address mappings, operators must 1111 ensure the mappings remain up to date, or risk losing the ability to 1112 request accurate mitigation scopes. To that aim, the DOTS client can 1113 rely on mechanisms, such as [RFC8512] to retrieve static explicit 1114 mappings. This document does not prescribe the method by which 1115 mappings are maintained once they are provisioned on the DOTS client. 1117 3.2.5.2. Resolving Public Mitigation Scope with Port Control Protocol 1118 (PCP) 1120 Port Control Protocol (PCP) [RFC6887] may be used to retrieve the 1121 external addresses/prefixes and/or port numbers if the NAT function 1122 embeds a PCP server. 1124 A DOTS client can use the information retrieved by means of PCP to 1125 feed the DOTS protocol(s) messages that will be sent to a DOTS 1126 server. These messages will convey the external addresses/prefixes 1127 as set by the NAT. 1129 PCP also enables discovery and configuration of the lifetime of port 1130 mappings instantiated in intermediate NAT devices. Discovery of port 1131 mapping lifetimes can reduce the dependency on heartbeat messages to 1132 maintain mappings, and therefore reduce the load on DOTS servers and 1133 the network. 1135 3.2.5.3. Resolving Public Mitigation Scope with Session Traversal 1136 Utilities (STUN) 1138 An internal resource, e.g., a Web server, can discover its reflexive 1139 transport address through a STUN Binding request/response 1140 transaction, as described in [I-D.ietf-tram-stunbis]. After learning 1141 its reflexive transport address from the STUN server, the internal 1142 resource can export its reflexive transport address and internal 1143 transport address to the DOTS client, thereby enabling the DOTS 1144 client to request mitigation with the correct external scope, as 1145 depicted in Figure 13. The mechanism for providing the DOTS client 1146 with the reflexive transport address and internal transport address 1147 is unspecified in this document. 1149 In order to prevent an attacker from modifying the STUN messages in 1150 transit, the STUN client and server must use the message-integrity 1151 mechanism discussed in Section 9 of [I-D.ietf-tram-stunbis] or use 1152 STUN over DTLS [RFC7350] or use STUN over TLS. If the STUN client is 1153 behind a NAT that performs Endpoint-Dependent Mapping [RFC5128], the 1154 internal service cannot provide the DOTS client with the reflexive 1155 transport address discovered using STUN. The behavior of a NAT 1156 between the STUN client and the STUN server could be discovered using 1157 the experimental techniques discussed in [RFC5780], but note that 1158 there is currently no standardized way for a STUN client to reliably 1159 determine if it is behind a NAT that performs Endpoint-Dependent 1160 Mapping. 1162 Binding Binding 1163 +--------+ request +---+ request +--------+ 1164 | STUN |<----------| N |<----------| STUN | 1165 | server | | A | | client | 1166 | |---------->| T |---------->| | 1167 +--------+ Binding +---+ Binding +--------+ 1168 response response | 1169 | reflexive transport address 1170 | & internal transport address 1171 v 1172 +--------+ 1173 | DOTS | 1174 | client | 1175 +--------+ 1177 Figure 13: Resolving mitigation scope with STUN 1179 3.2.5.4. Resolving Requested Mitigation Scope with DNS 1181 DOTS supports mitigation scoped to DNS names. As discussed in 1182 [RFC3235], using DNS names instead of IP addresses potentially avoids 1183 the address translation problem, as long as the name is internally 1184 and externally resolvable by the same name. For example, a detected 1185 attack's internal target address can be mapped to a DNS name through 1186 a reverse lookup. The DNS name returned by the reverse lookup can 1187 then be provided to the DOTS client as the external scope for 1188 mitigation. For the reverse DNS lookup, DNS Security Extensions 1189 (DNSSEC) [RFC4033] must be used where the authenticity of response is 1190 critical. 1192 3.3. Triggering Requests for Mitigation 1194 [RFC8612] places no limitation on the circumstances in which a DOTS 1195 client operator may request mitigation, nor does it demand 1196 justification for any mitigation request, thereby reserving 1197 operational control over DDoS defense for the domain requesting 1198 mitigation. This architecture likewise does not prescribe the 1199 network conditions and mechanisms triggering a mitigation request 1200 from a DOTS client. 1202 However, considering selected possible mitigation triggers from an 1203 architectural perspective offers a model for alternative or 1204 unanticipated triggers for DOTS deployments. In all cases, what 1205 network conditions merit a mitigation request are at the discretion 1206 of the DOTS client operator. 1208 The mitigation request itself is defined by DOTS, however the 1209 interfaces required to trigger the mitigation request in the 1210 following scenarios are implementation-specific. 1212 3.3.1. Manual Mitigation Request 1214 A DOTS client operator may manually prepare a request for mitigation, 1215 including scope and duration, and manually instruct the DOTS client 1216 to send the mitigation request to the DOTS server. In context, a 1217 manual request is a request directly issued by the operator without 1218 automated decision-making performed by a device interacting with the 1219 DOTS client. Modes of manual mitigation requests include an operator 1220 entering a command into a text interface, or directly interacting 1221 with a graphical interface to send the request. 1223 An operator might do this, for example, in response to notice of an 1224 attack delivered by attack detection equipment or software, and the 1225 alerting detector lacks interfaces or is not configured to use 1226 available interfaces to translate the alert to a mitigation request 1227 automatically. 1229 In a variation of the above scenario, the operator may have 1230 preconfigured on the DOTS client mitigation requests for various 1231 resources in the operator's domain. When notified of an attack, the 1232 DOTS client operator manually instructs the DOTS client to send the 1233 relevant preconfigured mitigation request for the resources under 1234 attack. 1236 A further variant involves recursive signaling, as described in 1237 Section 3.2.3. The DOTS client in this case is the second half of a 1238 DOTS gateway (back-to-back DOTS server and client). As in the 1239 previous scenario, the scope and duration of the mitigation request 1240 are pre-existing, but in this case are derived from the mitigation 1241 request received from a downstream DOTS client by the DOTS server. 1242 Assuming the preconditions required by Section 3.2.3 are in place, 1243 the DOTS gateway operator may at any time manually request mitigation 1244 from an upstream DOTS server, sending a mitigation request derived 1245 from the downstream DOTS client's request. 1247 The motivations for a DOTS client operator to request mitigation 1248 manually are not prescribed by this architecture, but are expected to 1249 include some of the following: 1251 o Notice of an attack delivered via e-mail or alternative messaging 1253 o Notice of an attack delivered via phone call 1254 o Notice of an attack delivered through the interface(s) of 1255 networking monitoring software deployed in the operator's domain 1257 o Manual monitoring of network behavior through network monitoring 1258 software 1260 3.3.2. Automated Conditional Mitigation Request 1262 Unlike manual mitigation requests, which depend entirely on the DOTS 1263 client operator's capacity to react with speed and accuracy to every 1264 detected or detectable attack, mitigation requests triggered by 1265 detected attack conditions reduce the operational burden on the DOTS 1266 client operator, and minimize the latency between attack detection 1267 and the start of mitigation. 1269 Mitigation requests are triggered in this scenario by operator- 1270 specified network conditions. Attack detection is deployment- 1271 specific, and not constrained by this architecture. Similarly the 1272 specifics of a condition are left to the discretion of the operator, 1273 though common conditions meriting mitigation include the following: 1275 o Detected attack exceeding a rate in packets per second (pps). 1277 o Detected attack exceeding a rate in bytes per second (bps). 1279 o Detected resource exhaustion in an attack target. 1281 o Detected resource exhaustion in the local domain's mitigator. 1283 o Number of open connections to an attack target. 1285 o Number of attack sources in a given attack. 1287 o Number of active attacks against targets in the operator's domain. 1289 o Conditional detection developed through arbitrary statistical 1290 analysis or deep learning techniques. 1292 o Any combination of the above. 1294 When automated conditional mitigation requests are enabled, 1295 violations of any of the above conditions, or any additional 1296 operator-defined conditions, will trigger a mitigation request from 1297 the DOTS client to the DOTS server. The interfaces between the 1298 application detecting the condition violation and the DOTS client are 1299 implementation-specific. 1301 3.3.3. Automated Mitigation on Loss of Signal 1303 To maintain a DOTS signal channel session, the DOTS client and the 1304 DOTS server exchange regular but infrequent messages across the 1305 signal channel. In the absence of an attack, the probability of 1306 message loss in the signaling channel should be extremely low. Under 1307 attack conditions, however, some signal loss may be anticipated as 1308 attack traffic congests the link, depending on the attack type. 1310 While [RFC8612] specifies the DOTS protocol be robust when signaling 1311 under attack conditions, there are nevertheless scenarios in which 1312 the DOTS signal is lost in spite of protocol best efforts. To handle 1313 such scenarios, a DOTS operator may request one or more mitigations 1314 which are triggered only when the DOTS server ceases receiving DOTS 1315 client heartbeats beyond the miss count or interval permitted by the 1316 protocol. 1318 The impact of mitigating due to loss of signal in either direction 1319 must be considered carefully before enabling it. Signal loss is not 1320 caused by links congested with attack traffic alone, and as such 1321 mitigation requests triggered by signal channel degradation in either 1322 direction may incur unnecessary costs, in network performance and 1323 operational expense alike. 1325 4. IANA Considerations 1327 This document has no actions for IANA. 1329 5. Security Considerations 1331 This section describes identified security considerations for the 1332 DOTS architecture. 1334 DOTS is at risk from three primary attack vectors: agent 1335 impersonation, traffic injection and signal blocking. These vectors 1336 may be exploited individually or in concert by an attacker to 1337 confuse, disable, take information from, or otherwise inhibit DOTS 1338 agents. 1340 Any attacker with the ability to impersonate a legitimate DOTS client 1341 or server or, indeed, inject false messages into the stream may 1342 potentially trigger/withdraw traffic redirection, trigger/cancel 1343 mitigation activities or subvert drop-/accept-lists. From an 1344 architectural standpoint, operators MUST ensure conformance to the 1345 security requirements defined in Section 2.4 of [RFC8612] to secure 1346 data in transit. Similarly, as the received data may contain network 1347 topology, telemetry, threat and mitigation information which could be 1348 considered sensitive in certain environment, it SHOULD be protected 1349 at rest per required local policy. 1351 An attacker with control of a DOTS client may negatively influence 1352 network traffic by requesting and withdrawing requests for mitigation 1353 for particular prefixes, leading to route or DNS flapping. DOTS 1354 operators should carefully monitor and audit DOTS clients to detect 1355 misbehavior and deter misuse. 1357 Any attack targeting the availability of DOTS servers may disrupt the 1358 ability of the system to receive and process DOTS signals resulting 1359 in failure to fulfill a mitigation request. DOTS servers MUST be 1360 given adequate protections, in accordance with best current practices 1361 for network and host security. 1363 6. Contributors 1365 Mohamed Boucadair 1366 Orange 1368 mohamed.boucadair@orange.com 1370 Christopher Gray Christopher_Gray3@cable.comcast.com 1372 7. Acknowledgments 1374 Thanks to Matt Richardson, Roman Danyliw, Frank Xialiang, Roland 1375 Dobbins, Wei Pan, Kaname Nishizuka, Jon Shallow, Paul Kyzivat, and 1376 Mohamed Boucadair for their comments and suggestions. 1378 Special thanks to Roman Danyliw for the AD review. 1380 8. References 1382 8.1. Normative References 1384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1385 Requirement Levels", BCP 14, RFC 2119, 1386 DOI 10.17487/RFC2119, March 1997, 1387 . 1389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1391 May 2017, . 1393 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1394 Threat Signaling (DOTS) Requirements", RFC 8612, 1395 DOI 10.17487/RFC8612, May 2019, 1396 . 1398 8.2. Informative References 1400 [I-D.ietf-acme-ip] 1401 Shoemaker, R., "ACME IP Identifier Validation Extension", 1402 draft-ietf-acme-ip-08 (work in progress), October 2019. 1404 [I-D.ietf-dots-data-channel] 1405 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 1406 Service Open Threat Signaling (DOTS) Data Channel 1407 Specification", draft-ietf-dots-data-channel-31 (work in 1408 progress), July 2019. 1410 [I-D.ietf-dots-signal-channel] 1411 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 1412 N. Teague, "Distributed Denial-of-Service Open Threat 1413 Signaling (DOTS) Signal Channel Specification", draft- 1414 ietf-dots-signal-channel-41 (work in progress), January 1415 2020. 1417 [I-D.ietf-dots-use-cases] 1418 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1419 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1420 Signaling", draft-ietf-dots-use-cases-20 (work in 1421 progress), September 2019. 1423 [I-D.ietf-tls-dtls13] 1424 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1425 Datagram Transport Layer Security (DTLS) Protocol Version 1426 1.3", draft-ietf-tls-dtls13-34 (work in progress), 1427 November 2019. 1429 [I-D.ietf-tram-stunbis] 1430 Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 1431 D., Mahy, R., and P. Matthews, "Session Traversal 1432 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-21 1433 (work in progress), March 2019. 1435 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1436 DOI 10.17487/RFC0768, August 1980, 1437 . 1439 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1440 RFC 793, DOI 10.17487/RFC0793, September 1981, 1441 . 1443 [RFC1035] Mockapetris, P., "Domain names - implementation and 1444 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1445 November 1987, . 1447 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1448 specifying the location of services (DNS SRV)", RFC 2782, 1449 DOI 10.17487/RFC2782, February 2000, 1450 . 1452 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 1453 Application Design Guidelines", RFC 3235, 1454 DOI 10.17487/RFC3235, January 2002, 1455 . 1457 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1458 A., Peterson, J., Sparks, R., Handley, M., and E. 1459 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1460 DOI 10.17487/RFC3261, June 2002, 1461 . 1463 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1464 Rose, "DNS Security Introduction and Requirements", 1465 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1466 . 1468 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1469 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1470 DOI 10.17487/RFC4271, January 2006, 1471 . 1473 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1474 Denial-of-Service Considerations", RFC 4732, 1475 DOI 10.17487/RFC4732, December 2006, 1476 . 1478 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1479 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1480 December 2006, . 1482 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 1483 Peer (P2P) Communication across Network Address 1484 Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 1485 2008, . 1487 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1488 (TLS) Protocol Version 1.2", RFC 5246, 1489 DOI 10.17487/RFC5246, August 2008, 1490 . 1492 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 1493 Using Session Traversal Utilities for NAT (STUN)", 1494 RFC 5780, DOI 10.17487/RFC5780, May 2010, 1495 . 1497 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1498 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1499 January 2012, . 1501 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1502 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1503 . 1505 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1506 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1507 DOI 10.17487/RFC6887, April 2013, 1508 . 1510 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1511 Initiation Protocol (SIP) Back-to-Back User Agents", 1512 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1513 . 1515 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1516 "Architectural Considerations of IP Anycast", RFC 7094, 1517 DOI 10.17487/RFC7094, January 2014, 1518 . 1520 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 1521 Layer Security (DTLS) as Transport for Session Traversal 1522 Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, 1523 August 2014, . 1525 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1526 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1527 March 2017, . 1529 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1530 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1531 . 1533 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1534 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1535 Address Translation (NAT) and Network Prefix Translation 1536 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1537 . 1539 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1540 Kasten, "Automatic Certificate Management Environment 1541 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1542 . 1544 Authors' Addresses 1546 Andrew Mortensen (editor) 1547 Forcepoint 1548 United States 1550 EMail: andrewmortensen@gmail.com 1552 Tirumaleswar Reddy (editor) 1553 McAfee, Inc. 1554 Embassy Golf Link Business Park 1555 Bangalore, Karnataka 560071 1556 India 1558 EMail: kondtir@gmail.com 1560 Flemming Andreasen 1561 Cisco 1562 United States 1564 EMail: fandreas@cisco.com 1566 Nik Teague 1567 Iron Mountain 1568 United States 1570 EMail: nteague@ironmountain.co.uk 1572 Rich Compton 1573 Charter 1575 EMail: Rich.Compton@charter.com