idnits 2.17.1 draft-ietf-dots-architecture-08.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 date (November 27, 2018) is 1976 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-16 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-16 -- 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: 2 errors (**), 0 flaws (~~), 3 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: May 31, 2019 Cisco 6 T. Reddy 7 McAfee, Inc. 8 N. Teague 9 Verisign 10 R. Compton 11 Charter 12 C. Gray 13 November 27, 2018 15 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture 16 draft-ietf-dots-architecture-08 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 May 31, 2019. 44 Copyright Notice 46 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . 11 74 2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 13 75 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 3.1. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 15 77 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 78 3.1.2. Establishing the DOTS Session . . . . . . . . . . . . 16 79 3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . 19 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. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 93 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 7.1. Normative References . . . . . . . . . . . . . . . . . . 30 96 7.2. Informative References . . . . . . . . . . . . . . . . . 30 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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 [RFC2119]. 125 1.1.2. Definition of Terms 127 This document uses the terms defined in [I-D.ietf-dots-requirements]. 129 1.2. Scope 131 In this architecture, DOTS clients and servers communicate using DOTS 132 signaling. As a result of signals from a DOTS client, the DOTS 133 server may modify the forwarding path of traffic destined for the 134 attack target(s), for example by diverting traffic to a mitigator or 135 pool of mitigators, where policy may be applied to distinguish and 136 discard attack traffic. Any such policy is deployment-specific. 138 The DOTS architecture presented here is applicable across network 139 administrative domains - for example, between an enterprise domain 140 and the domain of a third-party attack mitigation service - as well 141 as to a single administrative domain. DOTS is generally assumed to 142 be most effective when aiding coordination of attack response between 143 two or more participating networks, but single domain scenarios are 144 valuable in their own right, as when aggregating intra-domain DOTS 145 client signals for inter-domain coordinated attack response. 147 This document does not address any administrative or business 148 agreements that may be established between involved DOTS parties. 149 Those considerations are out of scope. Regardless, this document 150 assumes necessary authentication and authorization mechanisms are put 151 in place so that only authorized clients can invoke the DOTS service. 153 A detailed set of DOTS requirements are discussed in 154 [I-D.ietf-dots-requirements], and the DOTS architecture is designed 155 to follow those requirements. Only new behavioral requirements are 156 described in this document. 158 1.3. Assumptions 160 This document makes the following assumptions: 162 o All domains in which DOTS is deployed are assumed to offer the 163 required connectivity between DOTS agents and any intermediary 164 network elements, but the architecture imposes no additional 165 limitations on the form of connectivity. 167 o Congestion and resource exhaustion are intended outcomes of a DDoS 168 attack [RFC4732]. Some operators may utilize non-impacted paths 169 or networks for DOTS, but in general conditions should be assumed 170 to be hostile and DOTS must be able to function in all 171 circumstances, including when the signaling path is significantly 172 impaired. 174 o There is no universal DDoS attack scale threshold triggering a 175 coordinated response across administrative domains. A network 176 domain administrator, or service or application owner may 177 arbitrarily set attack scale threshold triggers, or manually send 178 requests for mitigation. 180 o Mitigation requests may be sent to one or more upstream DOTS 181 servers based on criteria determined by DOTS client administrators 182 and the underlying network configuration. The number of DOTS 183 servers with which a given DOTS client has established 184 communications is determined by local policy and is deployment- 185 specific. For example, a DOTS client of a multi-homed network may 186 support built-in policies to establish DOTS relationships with 187 DOTS servers located upstream of each interconnection link. 189 o The mitigation capacity and/or capability of domains receiving 190 requests for coordinated attack response is opaque to the domains 191 sending the request. The domain receiving the DOTS client signal 192 may or may not have sufficient capacity or capability to filter 193 any or all DDoS attack traffic directed at a target. In either 194 case, the upstream DOTS server may redirect a request to another 195 DOTS server. Redirection may be local to the redirecting DOTS 196 server's domain, or may involve a third-party domain. 198 o DOTS client and server signals, as well as messages sent through 199 the data channel, are sent across any transit networks with the 200 same probability of delivery as any other traffic between the DOTS 201 client domain and the DOTS server domain. Any encapsulation 202 required for successful delivery is left untouched by transit 203 network elements. DOTS server and DOTS client cannot assume any 204 preferential treatment of DOTS signals. Such preferential 205 treatment may be available in some deployments (e.g., intra-domain 206 scenarios), and the DOTS architecture does not preclude its use 207 when available. However, DOTS itself does not address how that 208 may be done. 210 o The architecture allows for, but does not assume, the presence of 211 Quality of Service (QoS) policy agreements between DOTS-enabled 212 peer networks or local QoS prioritization aimed at ensuring 213 delivery of DOTS messages between DOTS agents. QoS is an 214 operational consideration only, not a functional part of the DOTS 215 architecture. 217 o The signal and data channels are loosely coupled, and may not 218 terminate on the same DOTS server. 220 2. DOTS Architecture 222 The basic high-level DOTS architecture is illustrated in Figure 1: 224 +-----------+ +-------------+ 225 | Mitigator | ~~~~~~~~~~ | DOTS Server | 226 +-----------+ +-------------+ 227 | 228 | 229 | 230 +---------------+ +-------------+ 231 | Attack Target | ~~~~~~ | DOTS Client | 232 +---------------+ +-------------+ 234 Figure 1: Basic DOTS Architecture 236 A simple example instantiation of the DOTS architecture could be an 237 enterprise as the attack target for a volumetric DDoS attack, and an 238 upstream DDoS mitigation service as the mitigator. The enterprise 239 (attack target) is connected to the Internet via a link that is 240 getting saturated, and the enterprise suspects it is under DDoS 241 attack. The enterprise has a DOTS client, which obtains information 242 about the DDoS attack, and signals the DOTS server for help in 243 mitigating the attack. The DOTS server in turn invokes one or more 244 mitigators, which are tasked with mitigating the actual DDoS attack, 245 and hence aim to suppress the attack traffic while allowing valid 246 traffic to reach the attack target. 248 The scope of the DOTS specifications is the interfaces between the 249 DOTS client and DOTS server. The interfaces to the attack target and 250 the mitigator are out of scope of DOTS. Similarly, the operation of 251 both the attack target and the mitigator is out of scope of DOTS. 252 Thus, DOTS neither specifies how an attack target decides it is under 253 DDoS attack, nor does DOTS specify how a mitigator may actually 254 mitigate such an attack. A DOTS client's request for mitigation is 255 advisory in nature, and may not lead to any mitigation at all, 256 depending on the DOTS server domain's capacity and willingness to 257 mitigate on behalf of the DOTS client's domain. 259 The DOTS client may be provided with a list of DOTS servers, each 260 associated with one or more IP addresses. These addresses may or may 261 not be of the same address family. The DOTS client establishes one 262 or more sessions by connecting to the provided DOTS server addresses. 264 As illustrated in Figure 2, there are two interfaces between a DOTS 265 server and a DOTS client; a signal channel and (optionally) a data 266 channel. 268 +---------------+ +---------------+ 269 | | <------- Signal Channel ------> | | 270 | DOTS Client | | DOTS Server | 271 | | <======= Data Channel ======> | | 272 +---------------+ +---------------+ 274 Figure 2: DOTS Interfaces 276 The primary purpose of the signal channel is for a DOTS client to ask 277 a DOTS server for help in mitigating an attack, and for the DOTS 278 server to inform the DOTS client about the status of such mitigation. 279 The DOTS client does this by sending a client signal, which contains 280 information about the attack target(s). The client signal may also 281 include telemetry information about the attack, if the DOTS client 282 has such information available. The DOTS server in turn sends a 283 server signal to inform the DOTS client of whether it will honor the 284 mitigation request. Assuming it will, the DOTS server initiates 285 attack mitigation, and periodically informs the DOTS client about the 286 status of the mitigation. Similarly, the DOTS client periodically 287 informs the DOTS server about the client's status, which at a minimum 288 provides client (attack target) health information, but it should 289 also include efficacy information about the attack mitigation as it 290 is now seen by the client. At some point, the DOTS client may decide 291 to terminate the server-side attack mitigation, which it indicates to 292 the DOTS server over the signal channel. A mitigation may also be 293 terminated if a DOTS client-specified mitigation lifetime is 294 exceeded. Note that the signal channel may need to operate over a 295 link that is experiencing a DDoS attack and hence is subject to 296 severe packet loss and high latency. 298 While DOTS is able to request mitigation with just the signal 299 channel, the addition of the DOTS data channel provides for 300 additional and more efficient capabilities. The primary purpose of 301 the data channel is to support DOTS related configuration and policy 302 information exchange between the DOTS client and the DOTS server. 303 Examples of such information include, but are not limited to: 305 o Creating identifiers, such as names or aliases, for resources for 306 which mitigation may be requested. Such identifiers may then be 307 used in subsequent signal channel exchanges to refer more 308 efficiently to the resources under attack, as seen in Figure 3, 309 using JSON to serialize the data: 311 { 312 "https1": [ 313 "192.0.2.1:443", 314 "198.51.100.2:443", 315 ], 316 "proxies": [ 317 "203.0.113.3:3128", 318 "[2001:db8:ac10::1]:3128" 319 ], 320 "api_urls": "https://apiserver.example.com/api/v1", 321 } 323 Figure 3: Protected resource identifiers 325 o Black-list management, which enables a DOTS client to inform the 326 DOTS server about sources to suppress. 328 o White-list management, which enables a DOTS client to inform the 329 DOTS server about sources from which traffic is always accepted. 331 o Filter management, which enables a DOTS client to install or 332 remove traffic filters dropping or rate-limiting unwanted traffic. 334 o DOTS client provisioning. 336 Note that while it is possible to exchange the above information 337 before, during or after a DDoS attack, DOTS requires reliable 338 delivery of this information and does not provide any special means 339 for ensuring timely delivery of it during an attack. In practice, 340 this means that DOTS deployments should not rely on such information 341 being exchanged during a DDoS attack. 343 2.1. DOTS Operations 345 DOTS does not prescribe any specific deployment models, however DOTS 346 is designed with some specific requirements around the different DOTS 347 agents and their relationships. 349 First of all, a DOTS agent belongs to a domain that has an identity 350 which can be authenticated and authorized. DOTS agents communicate 351 with each other over a mutually authenticated signal channel and 352 (optionally) data channel. However, before they can do so, a service 353 relationship needs to be established between them. The details and 354 means by which this is done is outside the scope of DOTS, however an 355 example would be for an enterprise A (DOTS client) to sign up for 356 DDoS service from provider B (DOTS server). This would establish a 357 (service) relationship between the two that enables enterprise A's 358 DOTS client to establish a signal channel with provider B's DOTS 359 server. A and B will authenticate each other, and B can verify that 360 A is authorized for its service. 362 From an operational and design point of view, DOTS assumes that the 363 above relationship is established prior to a request for DDoS attack 364 mitigation. In particular, it is assumed that bi-directional 365 communication is possible at this time between the DOTS client and 366 DOTS server. Furthermore, it is assumed that additional service 367 provisioning, configuration and information exchange can be performed 368 by use of the data channel, if operationally required. It is not 369 until this point that the mitigation service is available for use. 371 Once the mutually authenticated signal channel has been established, 372 it will remain active. This is done to increase the likelihood that 373 the DOTS client can signal the DOTS server for help when the attack 374 target is being flooded, and similarly raise the probability that 375 DOTS server signals reach the client regardless of inbound link 376 congestion. This does not necessarily imply that the attack target 377 and the DOTS client have to be co-located in the same administrative 378 domain, but it is expected to be a common scenario. 380 DDoS mitigation with the help of an upstream mitigator may involve 381 some form of traffic redirection whereby traffic destined for the 382 attack target is steered towards the mitigator. Common mechanisms to 383 achieve this redirection depend on BGP [RFC4271] and DNS [RFC1035]. 384 The mitigator in turn inspects and scrubs the traffic, and forwards 385 the resulting (hopefully non-attack) traffic to the attack target. 386 Thus, when a DOTS server receives an attack mitigation request from a 387 DOTS client, it can be viewed as a way of causing traffic redirection 388 for the attack target indicated. 390 DOTS relies on mutual authentication and the pre-established service 391 relationship between the DOTS client's domain and the DOTS server's 392 domain to provide basic authorization. The DOTS server should 393 enforce additional authorization mechanisms to restrict the 394 mitigation scope a DOTS client can request, but such authorization 395 mechanisms are deployment-specific. 397 Although co-location of DOTS server and mitigator within the same 398 domain is expected to be a common deployment model, it is assumed 399 that operators may require alternative models. Nothing in this 400 document precludes such alternatives. 402 2.2. Components 404 2.2.1. DOTS Client 406 A DOTS client is a DOTS agent from which requests for help 407 coordinating attack response originate. The requests may be in 408 response to an active, ongoing attack against a target in the DOTS 409 client's domain, but no active attack is required for a DOTS client 410 to request help. Operators may wish to have upstream mitigators in 411 the network path for an indefinite period, and are restricted only by 412 business relationships when it comes to duration and scope of 413 requested mitigation. 415 The DOTS client requests attack response coordination from a DOTS 416 server over the signal channel, including in the request the DOTS 417 client's desired mitigation scoping, as described in 418 [I-D.ietf-dots-requirements]. The actual mitigation scope and 419 countermeasures used in response to the attack are up to the DOTS 420 server and mitigator operators, as the DOTS client may have a narrow 421 perspective on the ongoing attack. As such, the DOTS client's 422 request for mitigation should be considered advisory: guarantees of 423 DOTS server availability or mitigation capacity constitute service 424 level agreements and are out of scope for this document. 426 The DOTS client adjusts mitigation scope and provides available 427 mitigation feedback (e.g., mitigation efficacy) at the direction of 428 its local administrator. Such direction may involve manual or 429 automated adjustments in response to updates from the DOTS server. 431 To provide a metric of signal health and distinguish an idle signal 432 channel from a disconnected or defunct session, the DOTS client sends 433 a heartbeat over the signal channel to maintain its half of the 434 channel. The DOTS client similarly expects a heartbeat from the DOTS 435 server, and may consider a session terminated in the extended absence 436 of a DOTS server heartbeat. 438 2.2.2. DOTS Server 440 A DOTS server is a DOTS agent capable of receiving, processing and 441 possibly acting on requests for help coordinating attack response 442 from DOTS clients. The DOTS server authenticates and authorizes DOTS 443 clients as described in Section 3.1, and maintains session state, 444 tracking requests for mitigation, reporting on the status of active 445 mitigations, and terminating sessions in the extended absence of a 446 client heartbeat or when a session times out. 448 Assuming the preconditions discussed below exist, a DOTS client 449 maintaining an active session with a DOTS server may reasonably 450 expect some level of mitigation in response to a request for 451 coordinated attack response. 453 The DOTS server enforces authorization of DOTS clients' signals for 454 mitigation. The mechanism of enforcement is not in scope for this 455 document, but is expected to restrict requested mitigation scope to 456 addresses, prefixes, and/or services owned by the DOTS client's 457 administrative domain, such that a DOTS client from one domain is not 458 able to influence the network path to another domain. A DOTS server 459 MUST reject requests for mitigation of resources not owned by the 460 requesting DOTS client's administrative domain. A DOTS server MAY 461 also refuse a DOTS client's mitigation request for arbitrary reasons, 462 within any limits imposed by business or service level agreements 463 between client and server domains. If a DOTS server refuses a DOTS 464 client's request for mitigation, the DOTS server MUST include the 465 refusal reason in the server signal sent to the client. 467 A DOTS server is in regular contact with one or more mitigators. If 468 a DOTS server accepts a DOTS client's request for help, the DOTS 469 server forwards a translated form of that request to the mitigator(s) 470 responsible for scrubbing attack traffic. Note that the form of the 471 translated request passed from the DOTS server to the mitigator is 472 not in scope: it may be as simple as an alert to mitigator operators, 473 or highly automated using vendor or open application programming 474 interfaces supported by the mitigator. The DOTS server MUST report 475 the actual scope of any mitigation enabled on behalf of a client. 477 The DOTS server SHOULD retrieve available metrics for any mitigations 478 activated on behalf of a DOTS client, and SHOULD include them in 479 server signals sent to the DOTS client originating the request for 480 mitigation. 482 To provide a metric of signal health and distinguish an idle signal 483 channel from a disconnected or defunct channel, the DOTS server MUST 484 send a heartbeat over the signal channel to maintain its half of the 485 channel. The DOTS server similarly expects a heartbeat from the DOTS 486 client, and MAY consider a session terminated in the extended absence 487 of a DOTS client heartbeat. 489 2.2.3. DOTS Gateway 491 Traditional client/server relationships may be expanded by chaining 492 DOTS sessions. This chaining is enabled through "logical 493 concatenation" of a DOTS server and a DOTS client, resulting in an 494 application analogous to the Session Initiation Protocol (SIP) 495 [RFC3261] logical entity of a Back-to-Back User Agent (B2BUA) 496 [RFC7092]. The term DOTS gateway is used here in the descriptions of 497 selected scenarios involving this application. 499 A DOTS gateway may be deployed client-side, server-side or both. The 500 gateway may terminate multiple discrete client connections and may 501 aggregate these into a single or multiple DOTS sessions. 503 The DOTS gateway will appear as a server to its downstream agents and 504 as a client to its upstream agents, a functional concatenation of the 505 DOTS client and server roles, as depicted in Figure 4: 507 +-------------+ 508 | | D | | 509 +----+ | | O | | +----+ 510 | c1 |----------| s1 | T | c2 |---------| s2 | 511 +----+ | | S | | +----+ 512 | | G | | 513 +-------------+ 515 Figure 4: DOTS gateway 517 The DOTS gateway MUST perform full stack DOTS session termination and 518 reorigination between its client and server side. The details of how 519 this is achieved are implementation specific. The DOTS protocol does 520 not include any special features related to DOTS gateways, and hence 521 from a DOTS perspective, whenever a DOTS gateway is present, the DOTS 522 session simply terminates/originates there. 524 2.3. DOTS Agent Relationships 526 So far, we have only considered a relatively simple scenario of a 527 single DOTS client associated with a single DOTS server, however DOTS 528 supports more advanced relationships. 530 A DOTS server may be associated with one or more DOTS clients, and 531 those DOTS clients may belong to different domains. An example 532 scenario is a mitigation provider serving multiple attack targets 533 (Figure 5). 535 DOTS clients DOTS server 536 +---+ 537 | c |----------- 538 +---+ \ 539 c1.example.org \ 540 \ 541 +---+ \ +---+ 542 | c |----------------| S | 543 +---+ / +---+ 544 c1.example.com / dots1.example.net 545 / 546 +---+ / 547 | c |----------- 548 +---+ 549 c2.example.com 551 Figure 5: DOTS server with multiple clients 553 A DOTS client may be associated with one or more DOTS servers, and 554 those DOTS servers may belong to different domains. This may be to 555 ensure high availability or co-ordinate mitigation with more than one 556 directly connected ISP. An example scenario is for an enterprise to 557 have DDoS mitigation service from multiple providers, as shown in 558 Figure 6. 560 DOTS client DOTS servers 561 +---+ 562 -----------| S | 563 / +---+ 564 / dots1.example.net 565 / 566 +---+/ +---+ 567 | c |---------------| S | 568 +---+\ +---+ 569 \ dots.example.org 570 \ 571 \ +---+ 572 -----------| S | 573 +---+ 574 c.example.com dots2.example.net 576 Figure 6: Multi-Homed DOTS Client 578 Deploying a multi-homed client requires extra care and planning, as 579 the DOTS servers with which the multi-homed client communicates may 580 not be affiliated. Should the multi-homed client simultaneously 581 request for mitigation from all servers with which it has established 582 signal channels, the client may unintentionally inflict additional 583 network disruption on the resources it intends to protect. In one of 584 the worst cases, a multi-homed DOTS client could cause a permanent 585 routing loop of traffic destined for the client's protected services, 586 as the uncoordinated DOTS servers' mitigators all try to divert that 587 traffic to their own scrubbing centers. 589 The DOTS protocol itself provides no fool-proof method to prevent 590 such self-inflicted harms as a result deploying multi-homed DOTS 591 clients. If DOTS client implementations nevertheless include support 592 for multi-homing, they are expected to be aware of the risks, and 593 consequently to include measures aimed at reducing the likelihood of 594 negative outcomes. Simple measures might include: 596 o Requesting mitigation serially, ensuring only one mitigation 597 request for a given address space is active at any given time; 599 o Dividing the protected resources among the DOTS servers, such that 600 no two mitigators will be attempting to divert and scrub the same 601 traffic; 603 o Restricting multi-homing to deployments in which all DOTS servers 604 are coordinating management of a shared pool of mitigation 605 resources. 607 2.3.1. Gatewayed Signaling 609 As discussed in Section 2.2.3, a DOTS gateway is a logical function 610 chaining DOTS sessions through concatenation of a DOTS server and 611 DOTS client. 613 An example scenario, as shown in Figure 7 and Figure 8, is for an 614 enterprise to have deployed multiple DOTS capable devices which are 615 able to signal intra-domain using TCP [RFC0793] on un-congested links 616 to a DOTS gateway which may then transform these to a UDP [RFC0768] 617 transport inter-domain where connection oriented transports may 618 degrade; this applies to the signal channel only, as the data channel 619 requires a connection-oriented transport. The relationship between 620 the gateway and its upstream agents is opaque to the initial clients. 622 +---+ 623 | c |\ 624 +---+ \ +---+ 625 \-----TCP-----| D | +---+ 626 +---+ | O | | | 627 | c |--------TCP-----| T |------UDP------| S | 628 +---+ | S | | | 629 /-----TCP-----| G | +---+ 630 +---+ / +---+ 631 | c |/ 632 +---+ 633 example.com example.com example.net 634 DOTS clients DOTS gateway (DOTSG) DOTS server 636 Figure 7: Client-Side Gateway with Aggregation 638 +---+ 639 | c |\ 640 +---+ \ +---+ 641 \-----TCP-----| D |------UDP------+---+ 642 +---+ | O | | | 643 | c |--------TCP-----| T |------UDP------| S | 644 +---+ | S | | | 645 /-----TCP-----| G |------UDP------+---+ 646 +---+ / +---+ 647 | c |/ 648 +---+ 649 example.com example.com example.net 650 DOTS clients DOTS gateway (DOTSG) DOTS server 652 Figure 8: Client-Side Gateway without Aggregation 654 This may similarly be deployed in the inverse scenario where the 655 gateway resides in the server-side domain and may be used to 656 terminate and/or aggregate multiple clients to single transport as 657 shown in figures Figure 9 and Figure 10. 659 +---+ 660 | c |\ 661 +---+ \ +---+ 662 \-----UDP-----| D | +---+ 663 +---+ | O | | | 664 | c |--------TCP-----| T |------TCP------| S | 665 +---+ | S | | | 666 /-----TCP-----| G | +---+ 667 +---+ / +---+ 668 | c |/ 669 +---+ 670 example.com example.net example.net 671 DOTS clients DOTS gateway (DOTSG) DOTS server 673 Figure 9: Server-Side Gateway with Aggregation 675 +---+ 676 | c |\ 677 +---+ \ +---+ 678 \-----UDP-----| D |------TCP------+---+ 679 +---+ | O | | | 680 | c |--------TCP-----| T |------TCP------| S | 681 +---+ | S | | | 682 /-----UDP-----| G |------TCP------+---+ 683 +---+ / +---+ 684 | c |/ 685 +---+ 686 example.com example.net example.net 687 DOTS clients DOTS gateway (DOTSG) DOTS server 689 Figure 10: Server-Side Gateway without Aggregation 691 This document anticipates scenarios involving multiple DOTS gateways. 692 An example is a DOTS gateway at the network client's side, and 693 another one at the server side. The first gateway can be located at 694 a CPE to aggregate requests from multiple DOTS clients enabled in an 695 enterprise network. The second DOTS gateway is deployed on the 696 provider side. This scenario can be seen as a combination of the 697 client-side and server-side scenarios. 699 3. Concepts 701 3.1. DOTS Sessions 703 In order for DOTS to be effective as a vehicle for DDoS mitigation 704 requests, one or more DOTS clients must establish ongoing 705 communication with one or more DOTS servers. While the preconditions 706 for enabling DOTS in or among network domains may also involve 707 business relationships, service level agreements, or other formal or 708 informal understandings between network operators, such 709 considerations are out of scope for this document. 711 A DOTS session is established to support bilateral exchange of data 712 between an associated DOTS client and a DOTS server. In the DOTS 713 architecture, data is exchanged between DOTS agents over signal and 714 data channels. Regardless, a DOTS session is characterized by the 715 presence of an established signal channel. A data channel may be 716 established as well, however it is not a prerequisite. Conversely, a 717 DOTS session cannot exist without an established signal channel: when 718 an established signal channel is terminated for any reason, the DOTS 719 session is also said to be terminated. 721 3.1.1. Preconditions 723 Prior to establishing a DOTS session between agents, the owners of 724 the networks, domains, services or applications involved are assumed 725 to have agreed upon the terms of the relationship involved. Such 726 agreements are out of scope for this document, but must be in place 727 for a functional DOTS architecture. 729 It is assumed that as part of any DOTS service agreement, the DOTS 730 client is provided with all data and metadata required to establish 731 communication with the DOTS server. Such data and metadata would 732 include any cryptographic information necessary to meet the message 733 confidentiality, integrity and authenticity requirement in 734 [I-D.ietf-dots-requirements], and might also include the pool of DOTS 735 server addresses and ports the DOTS client should use for signal and 736 data channel messaging. 738 3.1.2. Establishing the DOTS Session 740 With the required business agreements in place, the DOTS client 741 initiates a signal session by contacting its DOTS server(s) over the 742 signal channel and (possibly) the data channel. To allow for DOTS 743 service flexibility, neither the order of contact nor the time 744 interval between channel creations is specified. A DOTS client MAY 745 establish signal channel first, and then data channel, or vice versa. 747 The methods by which a DOTS client receives the address and 748 associated service details of the DOTS server are not prescribed by 749 this document. For example, a DOTS client may be directly configured 750 to use a specific DOTS server IP address and port, and directly 751 provided with any data necessary to satisfy the Peer Mutual 752 Authentication requirement in [I-D.ietf-dots-requirements], such as 753 symmetric or asymmetric keys, usernames and passwords, etc. All 754 configuration and authentication information in this scenario is 755 provided out-of-band by the domain operating the DOTS server. 757 At the other extreme, the architecture in this document allows for a 758 form of DOTS client auto-provisioning. For example, the domain 759 operating the DOTS server or servers might provide the client domain 760 only with symmetric or asymmetric keys to authenticate the 761 provisioned DOTS clients. Only the keys would then be directly 762 configured on DOTS clients, but the remaining configuration required 763 to provision the DOTS clients could be learned through mechanisms 764 similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. 766 The DOTS client SHOULD successfully authenticate and exchange 767 messages with the DOTS server over both signal and (if used) data 768 channel as soon as possible to confirm that both channels are 769 operational. 771 As described in [I-D.ietf-dots-requirements], the DOTS client can 772 configure preferred values for acceptable signal loss, mitigation 773 lifetime, and heartbeat intervals when establishing the DOTS session. 774 A DOTS session is not active until DOTS agents have agreed on the 775 values for these DOTS session parameters, a process defined by the 776 protocol. 778 Once the DOTS client begins receiving DOTS server signals, the DOTS 779 session is active. At any time during the DOTS session, the DOTS 780 client may use the data channel to manage aliases, manage black- and 781 white-listed prefixes or addresses, leverage vendor-specific 782 extensions, and so on. Note that unlike the signal channel, there is 783 no requirement that the data channel remains operational in attack 784 conditions (See Data Channel Requirements, 785 [I-D.ietf-dots-requirements]). 787 3.1.3. Maintaining the DOTS Session 789 DOTS clients and servers periodically send heartbeats to each other 790 over the signal channel, per Operational Requirements discussed in 791 [I-D.ietf-dots-requirements]. DOTS agent operators SHOULD configure 792 the heartbeat interval such that the frequency does not lead to 793 accidental denials of service due to the overwhelming number of 794 heartbeats a DOTS agent must field. 796 Either DOTS agent may consider a DOTS session terminated in the 797 extended absence of a heartbeat from its peer agent. The period of 798 that absence will be established in the protocol definition. 800 3.2. Modes of Signaling 802 This section examines the modes of signaling between agents in a DOTS 803 architecture. 805 3.2.1. Direct Signaling 807 A DOTS session may take the form of direct signaling between the DOTS 808 clients and servers, as shown in Figure 11. 810 +-------------+ +-------------+ 811 | DOTS client |<------signal session------>| DOTS server | 812 +-------------+ +-------------+ 814 Figure 11: Direct Signaling 816 In a direct DOTS session, the DOTS client and server are 817 communicating directly. Direct signaling may exist inter- or intra- 818 domain. The DOTS session is abstracted from the underlying networks 819 or network elements the signals traverse: in direct signaling, the 820 DOTS client and server are logically adjacent. 822 3.2.2. Redirected Signaling 824 In certain circumstances, a DOTS server may want to redirect a DOTS 825 client to an alternative DOTS server for a DOTS session. Such 826 circumstances include but are not limited to: 828 o Maximum number of DOTS sessions with clients has been reached; 830 o Mitigation capacity exhaustion in the mitigator with which the 831 specific DOTS server is communicating; 833 o Mitigator outage or other downtime, such as scheduled maintenance; 835 o Scheduled DOTS server maintenance; 837 o Scheduled modifications to the network path between DOTS server 838 and DOTS client. 840 A basic redirected DOTS session resembles the following, as shown in 841 Figure 12. 843 +-------------+ +---------------+ 844 | |<-(1)--- DOTS session 1 --->| | 845 | | | | 846 | |<=(2)== redirect to B ======| | 847 | DOTS client | | DOTS server A | 848 | |X-(4)--- DOTS session 1 ---X| | 849 | | | | 850 | | | | 851 +-------------+ +---------------+ 852 ^ 853 | 854 (3) DOTS session 2 855 | 856 v 857 +---------------+ 858 | DOTS server B | 859 +---------------+ 861 Figure 12: Redirected Signaling 863 1. Previously established DOTS session 1 exists between a DOTS 864 client and DOTS server A. 866 2. DOTS server A sends a server signal redirecting the client to 867 DOTS server B. 869 3. If the DOTS client does not already have a separate DOTS session 870 with the redirection target, the DOTS client initiates and 871 establishes DOTS session 2 with DOTS server B. 873 4. Having redirected the DOTS client, DOTS server A ceases sending 874 server signals. The DOTS client likewise stops sending client 875 signals to DOTS server A. DOTS session 1 is terminated. 877 3.2.3. Recursive Signaling 879 DOTS is centered around improving the speed and efficiency of 880 coordinated response to DDoS attacks. One scenario not yet discussed 881 involves coordination among federated domains operating DOTS servers 882 and mitigators. 884 In the course of normal DOTS operations, a DOTS client communicates 885 the need for mitigation to a DOTS server, and that server initiates 886 mitigation on a mitigator with which the server has an established 887 service relationship. The operator of the mitigator may in turn 888 monitor mitigation performance and capacity, as the attack being 889 mitigated may grow in severity beyond the mitigating domain's 890 capabilities. 892 The operator of the mitigator has limited options in the event a DOTS 893 client-requested mitigation is being overwhelmed by the severity of 894 the attack. Out-of-scope business or service level agreements may 895 permit the mitigating domain to drop the mitigation and let attack 896 traffic flow unchecked to the target, but this only encourages attack 897 escalation. In the case where the mitigating domain is the upstream 898 service provider for the attack target, this may mean the mitigating 899 domain and its other services and users continue to suffer the 900 incidental effects of the attack. 902 A recursive signaling model as shown in Figure 13 offers an 903 alternative. In a variation of the use case "Upstream DDoS 904 Mitigation by an Upstream Internet Transit Provider" described in 905 [I-D.ietf-dots-use-cases], a domain operating a DOTS server and 906 mitigator also operates a DOTS client. This DOTS client has an 907 established DOTS session with a DOTS server belonging to a separate 908 administrative domain. 910 With these preconditions in place, the operator of the mitigator 911 being overwhelmed or otherwise performing inadequately may request 912 mitigation for the attack target from this separate DOTS-aware 913 domain. Such a request recurses the originating mitigation request 914 to the secondary DOTS server, in the hope of building a cumulative 915 mitigation against the attack. 917 example.net domain 918 . . . . . . . . . . . . . . . . . 919 . Gn . 920 +----+ 1 . +----+ +-----------+ . 921 | Cc |<--------->| Sn |~~~~~~~| Mitigator | . 922 +----+ . +====+ | Mn | . 923 . | Cn | +-----------+ . 924 example.com . +----+ . 925 client . ^ . 926 . . .|. . . . . . . . . . . . . . 927 | 928 2 | 929 | 930 . . .|. . . . . . . . . . . . . . 931 . v . 932 . +----+ +-----------+ . 933 . | So |~~~~~~~| Mitigator | . 934 . +----+ | Mo | . 935 . +-----------+ . 936 . . 937 . . . . . . . . . . . . . . . . . 938 example.org domain 940 Figure 13: Recursive Signaling 942 In Figure 13, client Cc signals a request for mitigation across 943 inter-domain DOTS session 1 to the DOTS server Sn belonging to the 944 example.net domain. DOTS server Sn enables mitigation on mitigator 945 Mn. DOTS server Sn is half of DOTS gateway Gn, being deployed 946 logically back-to-back with DOTS client Cn, which has pre-existing 947 inter-domain DOTS session 2 with the DOTS server So belonging to the 948 example.org domain. At any point, DOTS server Sn MAY recurse an on- 949 going mitigation request through DOTS client Cn to DOTS server So, in 950 the expectation that mitigator Mo will be activated to aid in the 951 defense of the attack target. 953 Recursive signaling is opaque to the DOTS client. To maximize 954 mitigation visibility to the DOTS client, however, the recursing 955 domain SHOULD provide recursed mitigation feedback in signals 956 reporting on mitigation status to the DOTS client. For example, the 957 recursing domain's mitigator should incorporate into mitigation 958 status messages available metrics such as dropped packet or byte 959 counts from the recursed mitigation. 961 DOTS clients involved in recursive signaling must be able to withdraw 962 requests for mitigation without warning or justification, per 963 [I-D.ietf-dots-requirements]. 965 Operators recursing mitigation requests MAY maintain the recursed 966 mitigation for a brief, protocol-defined period in the event the DOTS 967 client originating the mitigation withdraws its request for help, as 968 per the discussion of managing mitigation toggling in the operational 969 requirements ([I-D.ietf-dots-requirements]). 971 Deployment of recursive signaling may result in traffic redirection, 972 examination and mitigation extending beyond the initial bilateral 973 relationship between DOTS client and DOTS server. As such, client 974 control over the network path of mitigated traffic may be reduced. 975 DOTS client operators should be aware of any privacy concerns, and 976 work with DOTS server operators employing recursive signaling to 977 ensure shared sensitive material is suitably protected. 979 3.2.4. Anycast Signaling 981 The DOTS architecture does not assume the availability of anycast 982 within a DOTS deployment, but neither does the architecture exclude 983 it. Domains operating DOTS servers MAY deploy DOTS servers with an 984 anycast Service Address as described in BCP 126 [RFC4786]. In such a 985 deployment, DOTS clients connecting to the DOTS Service Address may 986 be communicating with distinct DOTS servers, depending on the network 987 configuration at the time the DOTS clients connect. Among other 988 benefits, anycast signaling potentially offers the following: 990 o Simplified DOTS client configuration, including service discovery 991 through the methods described in [RFC7094]. In this scenario, the 992 "instance discovery" message would be a DOTS client initiating a 993 DOTS session to the DOTS server anycast Service Address, to which 994 the DOTS server would reply with a redirection to the DOTS server 995 unicast address the client should use for DOTS. 997 o Region- or customer-specific deployments, in which the DOTS 998 Service Addresses route to distinct DOTS servers depending on the 999 client region or the customer network in which a DOTS client 1000 resides. 1002 o Operational resiliency, spreading DOTS signaling traffic across 1003 the DOTS server domain's networks, and thereby also reducing the 1004 potential attack surface, as described in BCP 126 [RFC4786]. 1006 3.2.4.1. Anycast Signaling Considerations 1008 As long as network configuration remains stable, anycast DOTS 1009 signaling is to the individual DOTS client indistinct from direct 1010 signaling. However, the operational challenges inherent in anycast 1011 signaling are anything but negligible, and DOTS server operators must 1012 carefully weigh the risks against the benefits before deploying. 1014 While the DOTS signal channel primarily operates over UDP per 1015 [I-D.ietf-dots-requirements], the signal channel also requires mutual 1016 authentication between DOTS agents, with associated security state on 1017 both ends. 1019 Network instability is of particular concern with anycast signaling, 1020 as DOTS signal channels are expected to be long-lived, and 1021 potentially operating under congested network conditions caused by a 1022 volumetric DDoS attack. 1024 For example, a network configuration altering the route to the DOTS 1025 server during active anycast signaling may cause the DOTS client to 1026 send messages to a DOTS server other than the one with which it 1027 initially established a signaling session. That second DOTS server 1028 may not have the security state of the existing session, forcing the 1029 DOTS client to initialize a new DOTS session. This challenge might 1030 in part be mitigated by use of pre-shared keys and session resumption 1031 [RFC5246][RFC6347], but keying material must be available to all DOTS 1032 servers sharing the anycast Service Address in that case. 1034 While the DOTS client will try to establish a new DOTS session with 1035 the DOTS server now acting as the anycast DOTS Service Address, the 1036 link between DOTS client and server may be congested with attack 1037 traffic, making signal session establishment difficult. In such a 1038 scenario, anycast Service Address instability becomes a sort of 1039 signal session flapping, with obvious negative consequences for the 1040 DOTS deployment. 1042 Anycast signaling deployments similarly must also take into account 1043 active mitigations. Active mitigations initiated through a DOTS 1044 session may involve diverting traffic to a scrubbing center. If the 1045 DOTS session flaps due to anycast changes as described above, 1046 mitigation may also flap as the DOTS servers sharing the anycast DOTS 1047 service address toggles mitigation on detecting DOTS session loss, 1048 depending on whether the client has configured mitigation on loss of 1049 signal. 1051 3.2.5. Signaling Considerations for Network Address Translation 1053 Network address translators (NATs) are expected to be a common 1054 feature of DOTS deployments. The Middlebox Traversal Guidelines in 1055 [RFC8085] include general NAT considerations for DOTS deployements 1056 when the signal channel is established over UDP. 1058 Additional DOTS-specific considerations arise when NATs are part of 1059 the DOTS architecture. For example, DDoS attack detection behind a 1060 NAT will detect attacks against internal addresses. A DOTS client 1061 subsequently asked to request mitigation for the attacked scope of 1062 addresses cannot reasonably perform the task, due to the lack of 1063 externally routable addresses in the mitigation scope. 1065 The following considerations do not cover all possible scenarios, but 1066 are meant rather to highlight anticipated common issues when 1067 signaling through NATs. 1069 3.2.5.1. Direct Provisioning of Internal-to-External Address Mappings 1071 Operators may circumvent the problem of translating internal 1072 addresses or prefixes to externally routable mitigation scopes by 1073 directly provisioning the mappings of external addresses to internal 1074 protected resources on the DOTS client. When the operator requests 1075 mitigation scoped for internal addresses, directly or through 1076 automated means, the DOTS client looks up the matching external 1077 addresses or prefixes, and issues a mitigation request scoped to that 1078 externally routable information. 1080 When directly provisioning the address mappings, operators must 1081 ensure the mappings remain up to date, or risk losing the ability to 1082 request accurate mitigation scopes. To that aim, the DOTS client can 1083 rely on mechanisms, such as [I-D.ietf-opsawg-nat-yang] to retrieve 1084 static explicit mappings. This document does not prescribe the 1085 method by which mappings are maintained once they are provisioned on 1086 the DOTS client. 1088 3.2.5.2. Resolving Public Mitigation Scope with Port Control Protocol 1089 (PCP) 1091 Port Control Protocol (PCP) [RFC6887] may be used to retrieve the 1092 external addresses/prefixes and/or port numbers if the NAT function 1093 embeds a PCP server. 1095 A DOTS client can use the information retrieved by means of PCP to 1096 feed the DOTS protocol(s) messages that will be sent to a DOTS 1097 server. These messages will convey the external addresses/prefixes 1098 as set by the NAT. 1100 PCP also enables discovery and configuration of the lifetime of port 1101 mappings instantiated in intermediate NAT devices. Discovery of port 1102 mapping lifetimes can reduce the dependency on heartbeat messages to 1103 maintain mappings, and therefore reduce the load on DOTS servers and 1104 the network. 1106 3.2.5.3. Resolving Public Mitigation Scope with Session Traversal 1107 Utilities (STUN) 1109 An internal resource, e.g., a Web server, can discover its reflexive 1110 transport address through a STUN Binding request/response 1111 transaction, as described in [RFC5389]. After learning its reflexive 1112 transport address from the STUN server, the internal resource can 1113 export its reflexive transport address and internal transport address 1114 to the DOTS client, thereby enabling the DOTS client to request 1115 mitigation with the correct external scope, as depicted in Figure 14. 1116 The mechanism for providing the DOTS client with the reflexive 1117 transport address and internal transport address is unspecified in 1118 this document. 1120 In order to prevent an attacker from modifying the STUN messages in 1121 transit, the STUN client and server MUST use the message-integrity 1122 mechanism discussed in Section 10 of [RFC5389] or use STUN over DTLS 1123 [RFC7350] or use STUN over TLS. If the STUN client is behind a NAT 1124 that performs Endpoint-Dependent Mapping, the internal service cannot 1125 provide the DOTS client with the reflexive transport address 1126 discovered using STUN. The behavior of a NAT between the STUN client 1127 and the STUN server could be discovered using the techniques 1128 discussed in [RFC5780]. 1130 Binding Binding 1131 +--------+ request +---+ request +--------+ 1132 | STUN |<----------| N |<----------| STUN | 1133 | server | | A | | client | 1134 | |---------->| T |---------->| | 1135 +--------+ Binding +---+ Binding +--------+ 1136 response response | 1137 | reflexive transport address 1138 | & internal transport address 1139 v 1140 +--------+ 1141 | DOTS | 1142 | client | 1143 +--------+ 1145 Figure 14: Resolving mitigation scope with STUN 1147 3.2.5.4. Resolving Requested Mitigation Scope with DNS 1149 DOTS supports mitigation scoped to DNS names. As discussed in 1150 [RFC3235], using DNS names instead of IP addresses potentially avoids 1151 the address translation problem, as long as the name is internally 1152 and externally resolvable by the same name. For example, a detected 1153 attack's internal target address can be mapped to a DNS name through 1154 a reverse lookup. The DNS name returned by the reverse lookup can 1155 then be provided to the DOTS client as the external scope for 1156 mitigation. For the reverse DNS lookup, DNS Security Extensions 1157 (DNSSEC) [RFC4033] must be used where the authenticity of response is 1158 critical. 1160 3.3. Triggering Requests for Mitigation 1162 [I-D.ietf-dots-requirements] places no limitation on the 1163 circumstances in which a DOTS client operator may request mitigation, 1164 nor does it demand justification for any mitigation request, thereby 1165 reserving operational control over DDoS defense for the domain 1166 requesting mitigation. This architecture likewise does not prescribe 1167 the network conditions and mechanisms triggering a mitigation request 1168 from a DOTS client. 1170 However, considering selected possible mitigation triggers from an 1171 architectural perspective offers a model for alternative or 1172 unanticipated triggers for DOTS deployments. In all cases, what 1173 network conditions merit a mitigation request are at the discretion 1174 of the DOTS client operator. 1176 The mitigation request itself is defined by DOTS, however the 1177 interfaces required to trigger the mitigation request in the 1178 following scenarios are implementation-specific. 1180 3.3.1. Manual Mitigation Request 1182 A DOTS client operator may manually prepare a request for mitigation, 1183 including scope and duration, and manually instruct the DOTS client 1184 to send the mitigation request to the DOTS server. In context, a 1185 manual request is a request directly issued by the operator without 1186 automated decision-making performed by a device interacting with the 1187 DOTS client. Modes of manual mitigation requests include an operator 1188 entering a command into a text interface, or directly interacting 1189 with a graphical interface to send the request. 1191 An operator might do this, for example, in response to notice of an 1192 attack delivered by attack detection equipment or software, and the 1193 alerting detector lacks interfaces or is not configured to use 1194 available interfaces to translate the alert to a mitigation request 1195 automatically. 1197 In a variation of the above scenario, the operator may have 1198 preconfigured on the DOTS client mitigation requests for various 1199 resources in the operator's domain. When notified of an attack, the 1200 DOTS client operator manually instructs the DOTS client to send the 1201 relevant preconfigured mitigation request for the resources under 1202 attack. 1204 A further variant involves recursive signaling, as described in 1205 Section 3.2.3. The DOTS client in this case is the second half of a 1206 DOTS gateway (back-to-back DOTS server and client). As in the 1207 previous scenario, the scope and duration of the mitigation request 1208 are pre-existing, but in this case are derived from the mitigation 1209 request received from a downstream DOTS client by the DOTS server. 1210 Assuming the preconditions required by Section 3.2.3 are in place, 1211 the DOTS gateway operator may at any time manually request mitigation 1212 from an upstream DOTS server, sending a mitigation request derived 1213 from the downstream DOTS client's request. 1215 The motivations for a DOTS client operator to request mitigation 1216 manually are not prescribed by this architecture, but are expected to 1217 include some of the following: 1219 o Notice of an attack delivered via e-mail or alternative messaging 1221 o Notice of an attack delivered via phone call 1223 o Notice of an attack delivered through the interface(s) of 1224 networking monitoring software deployed in the operator's domain 1226 o Manual monitoring of network behavior through network monitoring 1227 software 1229 3.3.2. Automated Conditional Mitigation Request 1231 Unlike manual mitigation requests, which depend entirely on the DOTS 1232 client operator's capacity to react with speed and accuracy to every 1233 detected or detectable attack, mitigation requests triggered by 1234 detected attack conditions reduce the operational burden on the DOTS 1235 client operator, and minimize the latency between attack detection 1236 and the start of mitigation. 1238 Mitigation requests are triggered in this scenario by operator- 1239 specified network conditions. Attack detection is deployment- 1240 specific, and not constrained by this architecture. Similarly the 1241 specifics of a condition are left to the discretion of the operator, 1242 though common conditions meriting mitigation include the following: 1244 o Detected attack exceeding a rate in packets per second (pps). 1246 o Detected attack exceeding a rate in bytes per second (bps). 1248 o Detected resource exhaustion in an attack target. 1250 o Detected resource exhaustion in the local domain's mitigator. 1252 o Number of open connections to an attack target. 1254 o Number of attack sources in a given attack. 1256 o Number of active attacks against targets in the operator's domain. 1258 o Conditional detection developed through arbitrary statistical 1259 analysis or deep learning techniques. 1261 o Any combination of the above. 1263 When automated conditional mitigation requests are enabled, 1264 violations of any of the above conditions, or any additional 1265 operator-defined conditions, will trigger a mitigation request from 1266 the DOTS client to the DOTS server. The interfaces between the 1267 application detecting the condition violation and the DOTS client are 1268 implementation-specific. 1270 3.3.3. Automated Mitigation on Loss of Signal 1272 To maintain a DOTS session, the DOTS client and the DOTS server 1273 exchange regular but infrequent messages across the signal channel. 1274 In the absence of an attack, the probability of message loss in the 1275 signaling channel should be extremely low. Under attack conditions, 1276 however, some signal loss may be anticipated as attack traffic 1277 congests the link, depending on the attack type. 1279 While [I-D.ietf-dots-requirements] specifies the DOTS protocol be 1280 robust when signaling under attack conditions, there are nevertheless 1281 scenarios in which the DOTS signal is lost in spite of protocol best 1282 efforts. To handle such scenarios, a DOTS operator may request one 1283 or more mitigations which are triggered only when the DOTS server 1284 ceases receiving DOTS client heartbeats beyond the miss count or 1285 interval permitted by the protocol. 1287 The impact of mitigating due to loss of signal in either direction 1288 must be considered carefully before enabling it. Signal loss is not 1289 caused by links congested with attack traffic alone, and as such 1290 mitigation requests triggered by signal channel degradation in either 1291 direction may incur unnecessary costs, in network performance and 1292 operational expense alike. 1294 4. Security Considerations 1296 This section describes identified security considerations for the 1297 DOTS architecture. 1299 DOTS is at risk from three primary attack vectors: agent 1300 impersonation, traffic injection and signal blocking. These vectors 1301 may be exploited individually or in concert by an attacker to 1302 confuse, disable, take information from, or otherwise inhibit DOTS 1303 agents. 1305 Any attacker with the ability to impersonate a legitimate DOTS client 1306 or server or, indeed, inject false messages into the stream may 1307 potentially trigger/withdraw traffic redirection, trigger/cancel 1308 mitigation activities or subvert black/whitelists. From an 1309 architectural standpoint, operators SHOULD ensure best current 1310 practices for secure communication are observed for data and signal 1311 channel confidentiality, integrity and authenticity. Care must be 1312 taken to ensure transmission is protected by appropriately secure 1313 means, reducing attack surface by exposing only the minimal required 1314 services or interfaces. Similarly, received data at rest SHOULD be 1315 stored with a satisfactory degree of security. 1317 As many mitigation systems employ diversion to scrub attack traffic, 1318 operators of DOTS agents SHOULD ensure DOTS sessions are resistant to 1319 Man-in-the-Middle (MitM) attacks. An attacker with control of a DOTS 1320 client may negatively influence network traffic by requesting and 1321 withdrawing requests for mitigation for particular prefixes, leading 1322 to route or DNS flapping. 1324 Any attack targeting the availability of DOTS servers may disrupt the 1325 ability of the system to receive and process DOTS signals resulting 1326 in failure to fulfill a mitigation request. DOTS agents SHOULD be 1327 given adequate protections, again in accordance with best current 1328 practices for network and host security. 1330 5. Contributors 1332 Mohamed Boucadair 1333 Orange 1335 mohamed.boucadair@orange.com 1337 6. Acknowledgments 1339 Thanks to Matt Richardson and Med Boucadair for their comments and 1340 suggestions. 1342 7. References 1344 7.1. Normative References 1346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1347 Requirement Levels", BCP 14, RFC 2119, 1348 DOI 10.17487/RFC2119, March 1997, 1349 . 1351 7.2. Informative References 1353 [I-D.ietf-dots-requirements] 1354 Mortensen, A., Moskowitz, R., and R. K, "Distributed 1355 Denial of Service (DDoS) Open Threat Signaling 1356 Requirements", draft-ietf-dots-requirements-16 (work in 1357 progress), October 2018. 1359 [I-D.ietf-dots-use-cases] 1360 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 1361 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 1362 Open Threat Signaling", draft-ietf-dots-use-cases-16 (work 1363 in progress), July 2018. 1365 [I-D.ietf-opsawg-nat-yang] 1366 Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, 1367 S., and Q. Wu, "A YANG Module for Network Address 1368 Translation (NAT) and Network Prefix Translation (NPT)", 1369 draft-ietf-opsawg-nat-yang-17 (work in progress), 1370 September 2018. 1372 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1373 DOI 10.17487/RFC0768, August 1980, 1374 . 1376 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1377 RFC 793, DOI 10.17487/RFC0793, September 1981, 1378 . 1380 [RFC1035] Mockapetris, P., "Domain names - implementation and 1381 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1382 November 1987, . 1384 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1385 specifying the location of services (DNS SRV)", RFC 2782, 1386 DOI 10.17487/RFC2782, February 2000, 1387 . 1389 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 1390 Application Design Guidelines", RFC 3235, 1391 DOI 10.17487/RFC3235, January 2002, 1392 . 1394 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1395 A., Peterson, J., Sparks, R., Handley, M., and E. 1396 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1397 DOI 10.17487/RFC3261, June 2002, 1398 . 1400 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1401 Rose, "DNS Security Introduction and Requirements", 1402 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1403 . 1405 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1406 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1407 DOI 10.17487/RFC4271, January 2006, 1408 . 1410 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1411 Denial-of-Service Considerations", RFC 4732, 1412 DOI 10.17487/RFC4732, December 2006, 1413 . 1415 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1416 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1417 December 2006, . 1419 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1420 (TLS) Protocol Version 1.2", RFC 5246, 1421 DOI 10.17487/RFC5246, August 2008, 1422 . 1424 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1425 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1426 DOI 10.17487/RFC5389, October 2008, 1427 . 1429 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 1430 Using Session Traversal Utilities for NAT (STUN)", 1431 RFC 5780, DOI 10.17487/RFC5780, May 2010, 1432 . 1434 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1435 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1436 January 2012, . 1438 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1439 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1440 . 1442 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1443 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1444 DOI 10.17487/RFC6887, April 2013, 1445 . 1447 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1448 Initiation Protocol (SIP) Back-to-Back User Agents", 1449 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1450 . 1452 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1453 "Architectural Considerations of IP Anycast", RFC 7094, 1454 DOI 10.17487/RFC7094, January 2014, 1455 . 1457 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 1458 Layer Security (DTLS) as Transport for Session Traversal 1459 Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, 1460 August 2014, . 1462 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1463 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1464 March 2017, . 1466 Authors' Addresses 1468 Andrew Mortensen 1469 Arbor Networks 1470 2727 S. State St 1471 Ann Arbor, MI 48104 1472 United States 1474 EMail: amortensen@arbor.net 1476 Flemming Andreasen 1477 Cisco 1478 United States 1480 EMail: fandreas@cisco.com 1481 Tirumaleswar Reddy 1482 McAfee, Inc. 1483 Embassy Golf Link Business Park 1484 Bangalore, Karnataka 560071 1485 India 1487 EMail: kondtir@gmail.com 1489 Nik Teague 1490 Verisign 1491 United States 1493 EMail: nteague@verisign.com 1495 Rich Compton 1496 Charter 1498 EMail: Rich.Compton@charter.com 1500 Christopher Gray 1501 United States 1503 EMail: Christopher_Gray3@cable.comcast.com