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