idnits 2.17.1 draft-ietf-dots-architecture-04.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2017) is 2461 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-05 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-05 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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: January 4, 2018 Cisco 6 T. Reddy 7 McAfee, Inc. 8 C. Gray 9 Comcast 10 R. Compton 11 Charter 12 N. Teague 13 Verisign 14 July 03, 2017 16 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture 17 draft-ietf-dots-architecture-04 19 Abstract 21 This document describes an architecture for establishing and 22 maintaining Distributed Denial of Service (DDoS) Open Threat 23 Signaling (DOTS) within and between domains. The document does not 24 specify protocols or protocol extensions, instead focusing on 25 defining architectural relationships, components and concepts used in 26 a DOTS deployment. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 4, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Context and Motivation . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1.2. Definition of Terms . . . . . . . . . . . . . . . . . 3 66 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. DOTS Architecture . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8 70 2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9 71 2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9 72 2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10 73 2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11 74 2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 12 75 2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 14 76 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 3.1. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 16 78 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 79 3.1.2. Establishing the DOTS Session . . . . . . . . . . . . 16 80 3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17 81 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18 82 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18 83 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18 84 3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19 85 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22 86 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 23 87 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 24 88 3.3.2. Automated Conditional Mitigation Request . . . . . . 25 89 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 26 90 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 91 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 92 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 93 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 96 8.2. Informative References . . . . . . . . . . . . . . . . . 27 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 99 1. Context and Motivation 101 Signaling the need for help defending against an active distributed 102 denial of service (DDoS) attack requires a common understanding of 103 mechanisms and roles among the parties coordinating defensive 104 response. The signaling layer and supplementary messaging is the 105 focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of 106 coordinating defensive measures among willing peers to mitigate 107 attacks quickly and efficiently, enabling hybrid attack responses 108 coordinated locally at or near the target of an active attack, or 109 anywhere in-path between attack sources and target. Sample DOTS use 110 cases are elaborated in [I-D.ietf-dots-use-cases]. 112 This document describes an architecture used in establishing, 113 maintaining or terminating a DOTS relationship within a domain or 114 between domains. 116 1.1. Terminology 118 1.1.1. Key Words 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 1.1.2. Definition of Terms 126 This document uses the terms defined in [I-D.ietf-dots-requirements]. 128 1.2. Scope 130 In this architecture, DOTS clients and servers communicate using DOTS 131 signaling. As a result of signals from a DOTS client, the DOTS 132 server may modify the forwarding path of traffic destined for the 133 attack target(s), for example by diverting traffic to a mitigator or 134 pool of mitigators, where policy may be applied to distinguish and 135 discard attack traffic. Any such policy is deployment-specific. 137 The DOTS architecture presented here is applicable across network 138 administrative domains - for example, between an enterprise domain 139 and the domain of a third-party attack mitigation service - as well 140 as to a single administrative domain. DOTS is generally assumed to 141 be most effective when aiding coordination of attack response between 142 two or more participating networks, but single domain scenarios are 143 valuable in their own right, as when aggregating intra-domain DOTS 144 client signals for inter-domain coordinated attack response. 146 This document does not address any administrative or business 147 agreements that may be established between involved DOTS parties. 148 Those considerations are out of scope. Regardless, this document 149 assumes necessary authentication and authorization mechanisms are put 150 in place so that only authorized clients can invoke the DOTS service. 152 A detailed set of DOTS requirements are discussed in 153 [I-D.ietf-dots-requirements], and the DOTS architecture is assumed to 154 follow those requirements. Only new behavioral requirements are 155 described in this document. 157 1.3. Assumptions 159 This document makes the following assumptions: 161 o All domains in which DOTS is deployed are assumed to offer the 162 required connectivity between DOTS agents and any intermediary 163 network elements, but the architecture imposes no additional 164 limitations on the form of connectivity. 166 o Congestion and resource exhaustion are intended outcomes of a DDoS 167 attack [RFC4732]. Some operators may utilize non-impacted paths 168 or networks for DOTS, but in general conditions should be assumed 169 to be hostile and that DOTS must be able to function in all 170 circumstances, including when the signaling path is significantly 171 impaired. 173 o There is no universal DDoS attack scale threshold triggering a 174 coordinated response across administrative domains. A network 175 domain administrator, or service or application owner may 176 arbitrarily set attack scale threshold triggers, or manually send 177 requests for mitigation. 179 o Mitigation requests may be sent to one or more upstream DOTS 180 servers based on criteria determined by DOTS client administrators 181 and the underlying network configuration. The number of DOTS 182 servers with which a given DOTS client has established 183 communications is determined by local policy and is deployment- 184 specific. For example, a DOTS client of a multi-homed network may 185 support built-in policies to establish DOTS relationships with 186 DOTS servers located upstream of each interconnection link. 188 o The mitigation capacity and/or capability of domains receiving 189 requests for coordinated attack response is opaque to the domains 190 sending the request. The domain receiving the DOTS client signal 191 may or may not have sufficient capacity or capability to filter 192 any or all DDoS attack traffic directed at a target. In either 193 case, the upstream DOTS server may redirect a request to another 194 DOTS server. Redirection may be local to the redirecting DOTS 195 server's domain, or may involve a third-party domain. 197 o DOTS client and server signals, as well as messages sent through 198 the data channel, are sent across any transit networks with the 199 same probability of delivery as any other traffic between the DOTS 200 client domain and the DOTS server domain. Any encapsulation 201 required for successful delivery is left untouched by transit 202 network elements. DOTS server and DOTS client cannot assume any 203 preferential treatment of DOTS signals. Such preferential 204 treatment may be available in some deployments (e.g., intra-domain 205 scenarios), and the DOTS architecture does not preclude its use 206 when available. However, DOTS itself does not address how that 207 may be done. 209 o The architecture allows for, but does not assume, the presence of 210 Quality of Service (QoS) policy agreements between DOTS-enabled 211 peer networks or local QoS prioritization aimed at ensuring 212 delivery of DOTS messages between DOTS agents. QoS is an 213 operational consideration only, not a functional part of the DOTS 214 architecture. 216 o The signal and data channels may be loosely coupled, and may not 217 terminate on the same DOTS server. 219 2. DOTS Architecture 221 The basic high-level DOTS architecture is illustrated in Figure 1: 223 +-----------+ +-------------+ 224 | Mitigator | ~~~~~~~~~~ | DOTS Server | 225 +-----------+ +-------------+ 226 | 227 | 228 | 229 +---------------+ +-------------+ 230 | Attack Target | ~~~~~~ | DOTS Client | 231 +---------------+ +-------------+ 233 Figure 1: Basic DOTS Architecture 235 A simple example instantiation of the DOTS architecture could be an 236 enterprise as the attack target for a volumetric DDoS attack, and an 237 upstream DDoS mitigation service as the mitigator. The enterprise 238 (attack target) is connected to the Internet via a link that is 239 getting saturated, and the enterprise suspects it is under DDoS 240 attack. The enterprise has a DOTS client, which obtains information 241 about the DDoS attack, and signals the DOTS server for help in 242 mitigating the attack. The DOTS server in turn invokes one or more 243 mitigators, which are tasked with mitigating the actual DDoS attack, 244 and hence aim to suppress the attack traffic while allowing valid 245 traffic to reach the attack target. 247 The scope of the DOTS specifications is the interfaces between the 248 DOTS client and DOTS server. The interfaces to the attack target and 249 the mitigator are out of scope of DOTS. Similarly, the operation of 250 both the attack target and the mitigator is out of scope of DOTS. 251 Thus, DOTS neither specifies how an attack target decides it is under 252 DDoS attack, nor does DOTS specify how a mitigator may actually 253 mitigate such an attack. A DOTS client's request for mitigation is 254 advisory in nature, and may not lead to any mitigation at all, 255 depending on the DOTS server domain's capacity and willingness to 256 mitigate on behalf of the DOTS client's domain. 258 As illustrated in Figure 2, there are two interfaces between the DOTS 259 server and the DOTS client. 261 +---------------+ +---------------+ 262 | | <------- Signal Channel ------> | | 263 | DOTS Client | | DOTS Server | 264 | | <======= Data Channel ======> | | 265 +---------------+ +---------------+ 267 Figure 2: DOTS Interfaces 269 The DOTS client may be provided with a list of DOTS servers, each 270 associated with one or more IP addresses. These addresses may or may 271 not be of the same address family. The DOTS client establishes one 272 or more sessions by connecting to the provided DOTS server addresses. 274 The primary purpose of the signal channel is for a DOTS client to ask 275 a DOTS server for help in mitigating an attack, and for the DOTS 276 server to inform the DOTS client about the status of such mitigation. 277 The DOTS client does this by sending a client signal, which contains 278 information about the attack target(s). The client signal may also 279 include telemetry information about the attack, if the DOTS client 280 has such information available. The DOTS server in turn sends a 281 server signal to inform the DOTS client of whether it will honor the 282 mitigation request. Assuming it will, the DOTS server initiates 283 attack mitigation, and periodically informs the DOTS client about the 284 status of the mitigation. Similarly, the DOTS client periodically 285 informs the DOTS server about the client's status, which at a minimum 286 provides client (attack target) health information, but it may also 287 include telemetry information about the attack as it is now seen by 288 the client. At some point, the DOTS client may decide to terminate 289 the server-side attack mitigation, which it indicates to the DOTS 290 server over the signal channel. A mitigation may also be terminated 291 if a DOTS client-specified mitigation lifetime is exceeded. Note 292 that the signal channel may need to operate over a link that is 293 experiencing a DDoS attack and hence is subject to severe packet loss 294 and high latency. 296 While DOTS is able to request mitigation with just the signal 297 channel, the addition of the DOTS data channel provides for 298 additional and more efficient capabilities; both channels are 299 required in the DOTS architecture. The primary purpose of the data 300 channel is to support DOTS related configuration and policy 301 information exchange between the DOTS client and the DOTS server. 302 Examples of such information include, but are not limited to: 304 o Creating identifiers, such as names or aliases, for resources for 305 which mitigation may be requested. Such identifiers may then be 306 used in subsequent signal channel exchanges to refer more 307 efficiently to the resources under attack, as seen in Figure 3, 308 using JSON to serialize the data: 310 { 311 "https1": [ 312 "192.0.2.1:443", 313 "198.51.100.2:443", 314 ], 315 "proxies": [ 316 "203.0.113.3:3128", 317 "[2001:db8:ac10::1]:3128" 318 ], 319 "api_urls": "https://apiserver.example.com/api/v1", 320 } 322 Figure 3: Protected resource identifiers 324 o Black-list management, which enables a DOTS client to inform the 325 DOTS server about sources to suppress. 327 o White-list management, which enables a DOTS client to inform the 328 DOTS server about sources from which traffic is always accepted. 330 o Filter management, which enables a DOTS client to install or 331 remove traffic filters dropping or rate-limiting unwanted traffic. 333 o DOTS client provisioning. 335 Note that while it is possible to exchange the above information 336 before, during or after a DDoS attack, DOTS requires reliable 337 delivery of this information and does not provide any special means 338 for ensuring timely delivery of it during an attack. In practice, 339 this means that DOTS deployments should not rely on such information 340 being exchanged during a DDoS attack. 342 2.1. DOTS Operations 344 DOTS does not prescribe any specific deployment models, however DOTS 345 is designed with some specific requirements around the different DOTS 346 agents and their relationships. 348 First of all, a DOTS agent belongs to a domain that has an identity 349 which can be authenticated and authorized. DOTS agents communicate 350 with each other over a mutually authenticated signal channel and data 351 channel. However, before they can do so, a service relationship 352 needs to be established between them. The details and means by which 353 this is done is outside the scope of DOTS, however an example would 354 be for an enterprise A (DOTS client) to sign up for DDoS service from 355 provider B (DOTS server). This would establish a (service) 356 relationship between the two that enables enterprise A's DOTS client 357 to establish a signal channel with provider B's DOTS server. A and B 358 will authenticate each other, and B can verify that A is authorized 359 for its service. 361 From an operational and design point of view, DOTS assumes that the 362 above relationship is established prior to a request for DDoS attack 363 mitigation. In particular, it is assumed that bi-directional 364 communication is possible at this time between the DOTS client and 365 DOTS server. Furthermore, it is assumed that additional service 366 provisioning, configuration and information exchange can be performed 367 by use of the data channel, if operationally required. It is not 368 until this point that the mitigation service is available for use. 370 Once the mutually authenticated signal channel has been established, 371 it will remain active. This is done to increase the likelihood that 372 the DOTS client can signal the DOTS server for help when the attack 373 target is being flooded, and similarly raise the probability that 374 DOTS server signals reach the client regardless of inbound link 375 congestion. This does not necessarily imply that the attack target 376 and the DOTS client have to be co-located in the same administrative 377 domain, but it is expected to be a common scenario. 379 DDoS mitigation with the help of an upstream mitigator may involve 380 some form of traffic redirection whereby traffic destined for the 381 attack target is steered towards the mitigator. Common mechanisms to 382 achieve this redirection depend on BGP [RFC4271] and DNS [RFC1035]. 383 The mitigator in turn inspects and scrubs the traffic, and forwards 384 the resulting (hopefully non-attack) traffic to the attack target. 385 Thus, when a DOTS server receives an attack mitigation request from a 386 DOTS client, it can be viewed as a way of causing traffic redirection 387 for the attack target indicated. 389 DOTS relies on mutual authentication and the pre-established service 390 relationship between the DOTS client's domain and the DOTS server's 391 domain to provide basic authorization. The DOTS server should 392 enforce additional authorization mechanisms to restrict the 393 mitigation scope a DOTS client can request, but such authorization 394 mechanisms are deployment-specific. 396 Although co-location of DOTS server and mitigator within the same 397 domain is expected to be a common deployment model, it is assumed 398 that operators may require alternative models. Nothing in this 399 document precludes such alternatives. 401 2.2. Components 403 2.2.1. DOTS Client 405 A DOTS client is a DOTS agent from which requests for help 406 coordinating attack response originate. The requests may be in 407 response to an active, ongoing attack against a target in the DOTS 408 client's domain, but no active attack is required for a DOTS client 409 to request help. Operators may wish to have upstream mitigators in 410 the network path for an indefinite period, and are restricted only by 411 business relationships when it comes to duration and scope of 412 requested mitigation. 414 The DOTS client requests attack response coordination from a DOTS 415 server over the signal channel, including in the request the DOTS 416 client's desired mitigation scoping, as described in 417 [I-D.ietf-dots-requirements]. The actual mitigation scope and 418 countermeasures used in response to the attack are up to the DOTS 419 server and mitigator operators, as the DOTS client may have a narrow 420 perspective on the ongoing attack. As such, the DOTS client's 421 request for mitigation should be considered advisory: guarantees of 422 DOTS server availability or mitigation capacity constitute service 423 level agreements and are out of scope for this document. 425 The DOTS client adjusts mitigation scope and provides available 426 attack details at the direction of its local administrator. Such 427 direction may involve manual or automated adjustments in response to 428 feedback from the DOTS server. 430 To provide a metric of signal health and distinguish an idle signal 431 channel from a disconnected or defunct session, the DOTS client sends 432 a heartbeat over the signal channel to maintain its half of the 433 channel. The DOTS client similarly expects a heartbeat from the DOTS 434 server, and may consider a session terminated in the extended absence 435 of a DOTS server heartbeat. 437 2.2.2. DOTS Server 439 A DOTS server is a DOTS agent capable of receiving, processing and 440 possibly acting on requests for help coordinating attack response 441 DOTS clients. The DOTS server authenticates and authorizes DOTS 442 clients as described in Section 3.1, and maintains session state, 443 tracking requests for mitigation, reporting on the status of active 444 mitigations, and terminating sessions in the extended absence of a 445 client heartbeat or when a session times out. 447 Assuming the preconditions discussed below exist, a DOTS client 448 maintaining an active session with a DOTS server may reasonably 449 expect some level of mitigation in response to a request for 450 coordinated attack response. 452 The DOTS server enforces authorization of DOTS clients' signals for 453 mitigation. The mechanism of enforcement is not in scope for this 454 document, but is expected to restrict requested mitigation scope to 455 addresses, prefixes, and/or services owned by the DOTS client's 456 administrative domain, such that a DOTS client from one domain is not 457 able to influence the network path to another domain. A DOTS server 458 MUST reject requests for mitigation of resources not owned by the 459 requesting DOTS client's administrative domain. A DOTS server MAY 460 also refuse a DOTS client's mitigation request for arbitrary reasons, 461 within any limits imposed by business or service level agreements 462 between client and server domains. If a DOTS server refuses a DOTS 463 client's request for mitigation, the DOTS server SHOULD include the 464 refusal reason in the server signal sent to the client. 466 A DOTS server is in regular contact with one or more mitigators. If 467 a DOTS server accepts a DOTS client's request for help, the DOTS 468 server forwards a translated form of that request to the mitigator(s) 469 responsible for scrubbing attack traffic. Note that the form of the 470 translated request passed from the DOTS server to the mitigator is 471 not in scope: it may be as simple as an alert to mitigator operators, 472 or highly automated using vendor or open application programming 473 interfaces supported by the mitigator. The DOTS server MUST report 474 the actual scope of any mitigation enabled on behalf of a client. 476 The DOTS server SHOULD retrieve available metrics for any mitigations 477 activated on behalf of a DOTS client, and SHOULD include them in 478 server signals sent to the DOTS client originating the request for 479 mitigation. 481 To provide a metric of signal health and distinguish an idle signal 482 channel from a disconnected or defunct channel, the DOTS server MUST 483 send a heartbeat over the signal channel to maintain its half of the 484 channel. The DOTS server similarly expects a heartbeat from the DOTS 485 client, and MAY consider a session terminated in the extended absence 486 of a DOTS client heartbeat. 488 2.2.3. DOTS Gateway 490 Traditional client/server relationships may be expanded by chaining 491 DOTS sessions. This chaining is enabled through "logical 492 concatenation" of a DOTS server and a DOTS client, resulting in an 493 application analogous to the SIP logical entity of a Back-to-Back 494 User Agent (B2BUA) [RFC7092]. The term DOTS gateway is used here in 495 the descriptions of selected scenarios involving this application. 497 A DOTS gateway may be deployed client-side, server-side or both. The 498 gateway may terminate multiple discrete client connections and may 499 aggregate these into a single or multiple DOTS sessions. 501 The DOTS gateway will appear as a server to its downstream agents and 502 as a client to its upstream agents, a functional concatenation of the 503 DOTS client and server roles, as depicted in Figure 4: 505 +-------------+ 506 | | D | | 507 +----+ | | O | | +----+ 508 | c1 |----------| s1 | T | c2 |---------| s2 | 509 +----+ | | S | | +----+ 510 | | G | | 511 +-------------+ 513 Figure 4: DOTS gateway 515 The DOTS gateway MUST perform full stack DOTS session termination and 516 reorigination between its client and server side. The details of how 517 this is achieved are implementation specific. The DOTS protocol does 518 not include any special features related to DOTS gateways, and hence 519 from a DOTS perspective, whenever a DOTS gateway is present, the DOTS 520 session simply terminates/originates there. 522 2.3. DOTS Agent Relationships 524 So far, we have only considered a relatively simple scenario of a 525 single DOTS client associated with a single DOTS server, however DOTS 526 supports more advanced relationships. 528 A DOTS server may be associated with one or more DOTS clients, and 529 those DOTS clients may belong to different domains. An example 530 scenario is a mitigation provider serving multiple attack targets 531 (Figure 5). 533 DOTS clients DOTS server 534 +---+ 535 | c |----------- 536 +---+ \ 537 c1.example.org \ 538 \ 539 +---+ \ +---+ 540 | c |----------------| S | 541 +---+ / +---+ 542 c1.example.com / dots1.example.net 543 / 544 +---+ / 545 | c |----------- 546 +---+ 547 c2.example.com 549 Figure 5: DOTS server with multiple clients 551 A DOTS client may be associated with one or more DOTS servers, and 552 those DOTS servers may belong to different domains. This may be to 553 ensure high availability or co-ordinate mitigation with more than one 554 directly connected ISP. An example scenario is for an enterprise to 555 have DDoS mitigation service from multiple providers, as shown in 556 Figure 6. 558 DOTS client DOTS servers 559 +---+ 560 -----------| S | 561 / +---+ 562 / dots1.example.net 563 / 564 +---+/ +---+ 565 | c |---------------| S | 566 +---+\ +---+ 567 \ dots.example.org 568 \ 569 \ +---+ 570 -----------| S | 571 +---+ 572 c.example.com dots2.example.net 574 Figure 6: Multi-Homed DOTS Client 576 Deploying a multi-homed client requires extra care and planning, as 577 the DOTS servers with which the multi-homed client communicates may 578 not be affiliated. Should the multi-homed client simultaneously 579 request for mitigation from all servers with which it has established 580 signal channels, the client may unintentionally inflict additional 581 network disruption on the resources it intends to protect. In one of 582 the worst cases, a multi-homed DOTS client could cause a permanent 583 routing loop of traffic destined for the client's protected protected 584 services, as the uncoordinated DOTS servers' mitigators all try to 585 divert that traffic to their own scrubbing centers. 587 The DOTS protocol itself provides no fool-proof method to prevent 588 such self-inflicted harms as a result deploying multi-homed DOTS 589 clients. If DOTS client implementations nevertheless include support 590 for multi-homing, they are expected to be aware of the risks, and 591 consequently to include measures aimed at reducing the likelihood of 592 negative outcomes. Simple measures might include: 594 o Requesting mitigation serially, ensuring only one mitigation 595 request for a given address space is active at any given time; 597 o Dividing the protected resources among the DOTS servers, such that 598 no two mitigators will be attempting to divert and scrub the same 599 traffic; 601 o Restricting multi-homing to deployments in which all DOTS servers 602 are coordinating management of a shared pool of mitigation 603 resources. 605 2.3.1. Gatewayed Signaling 607 As discussed in Section 2.2.3, a DOTS gateway is a logical function 608 chaining DOTS sessions through concatenation of a DOTS server and 609 DOTS client. 611 An example scenario, as shown in Figure 7 and Figure 8, is for an 612 enterprise to have deployed multiple DOTS capable devices which are 613 able to signal intra-domain using TCP [RFC0793] on un-congested links 614 to a DOTS gateway which may then transform these to a UDP [RFC0768] 615 transport inter-domain where connection oriented transports may 616 degrade; this applies to the signal channel only, as the data channel 617 requires a connection-oriented transport. The relationship between 618 the gateway and its upstream agents is opaque to the initial clients. 620 +---+ 621 | c |\ 622 +---+ \ +---+ 623 \-----TCP-----| D | +---+ 624 +---+ | O | | | 625 | c |--------TCP-----| T |------UDP------| S | 626 +---+ | S | | | 627 /-----TCP-----| G | +---+ 628 +---+ / +---+ 629 | c |/ 630 +---+ 631 example.com example.com example.net 632 DOTS clients DOTS gateway (DOTSG) DOTS server 634 Figure 7: Client-Side Gateway with Aggregation 636 +---+ 637 | c |\ 638 +---+ \ +---+ 639 \-----TCP-----| D |------UDP------+---+ 640 +---+ | O | | | 641 | c |--------TCP-----| T |------UDP------| S | 642 +---+ | S | | | 643 /-----TCP-----| G |------UDP------+---+ 644 +---+ / +---+ 645 | c |/ 646 +---+ 647 example.com example.com example.net 648 DOTS clients DOTS gateway (DOTSG) DOTS server 650 Figure 8: Client-Side Gateway without Aggregation 652 This may similarly be deployed in the inverse scenario where the 653 gateway resides in the server-side domain and may be used to 654 terminate and/or aggregate multiple clients to single transport as 655 shown in figures Figure 9 and Figure 10. 657 +---+ 658 | c |\ 659 +---+ \ +---+ 660 \-----UDP-----| D | +---+ 661 +---+ | O | | | 662 | c |--------TCP-----| T |------TCP------| S | 663 +---+ | S | | | 664 /-----TCP-----| G | +---+ 665 +---+ / +---+ 666 | c |/ 667 +---+ 668 example.com example.net example.net 669 DOTS clients DOTS gateway (DOTSG) DOTS server 671 Figure 9: Server-Side Gateway with Aggregation 673 +---+ 674 | c |\ 675 +---+ \ +---+ 676 \-----UDP-----| D |------TCP------+---+ 677 +---+ | O | | | 678 | c |--------TCP-----| T |------TCP------| S | 679 +---+ | S | | | 680 /-----UDP-----| G |------TCP------+---+ 681 +---+ / +---+ 682 | c |/ 683 +---+ 684 example.com example.net example.net 685 DOTS clients DOTS gateway (DOTSG) DOTS server 687 Figure 10: Server-Side Gateway without Aggregation 689 This document anticipates scenarios involving multiple DOTS gateways. 690 An example is a DOTS gateway at the network client's side, and 691 another one at the server side. The first gateway can be located at 692 a CPE to aggregate requests from multiple DOTS clients enabled in an 693 enterprise network. The second DOTS gateway is deployed on the 694 provider side. This scenario can be seen as a combination of the 695 client-side and server-side scenarios. 697 3. Concepts 699 3.1. DOTS Sessions 701 In order for DOTS to be effective as a vehicle for DDoS mitigation 702 requests, one or more DOTS clients must establish ongoing 703 communication with one or more DOTS servers. While the preconditions 704 for enabling DOTS in or among network domains may also involve 705 business relationships, service level agreements, or other formal or 706 informal understandings between network operators, such 707 considerations are out of scope for this document. 709 A DOTS session is established, bilateral exchange of data between an 710 associated DOTS client and a DOTS server. In the DOTS architecture, 711 data is exchanged between DOTS agents over signal and data channels. 712 Regardless, a DOTS session is characterized by the presence of an 713 established signal channel. A data channel associated with a signal 714 channel may be thought of as part of the DOTS session, but the 715 termination of that data channel does not terminate the DOTS session. 716 Conversely, a DOTS session cannot exist without an established signal 717 channel: when an established signal channel is terminated for any 718 reason, the DOTS session is also said to be terminated. 720 3.1.1. Preconditions 722 Prior to establishing a DOTS session between agents, the owners of 723 the networks, domains, services or applications involved are assumed 724 to have agreed upon the terms of the relationship involved. Such 725 agreements are out of scope for this document, but must be in place 726 for a functional DOTS architecture. 728 It is assumed that as part of any DOTS service agreement, the DOTS 729 client is provided with all data and metadata required to establish 730 communication with the DOTS server. Such data and metadata would 731 include any cryptographic information necessary to meet the message 732 confidentiality, integrity and authenticity requirement in 733 [I-D.ietf-dots-requirements], and might also include the pool of DOTS 734 server addresses and ports the DOTS client should use for signal and 735 data channel messaging. 737 3.1.2. Establishing the DOTS Session 739 With the required business agreements in place, the DOTS client 740 initiates a signal session by contacting its DOTS server(s) over the 741 signal channel and the data channel. To allow for DOTS service 742 flexibility, neither the order of contact nor the time interval 743 between channel creations is specified. A DOTS client MAY establish 744 signal channel first, and then data channel, or vice versa. 746 The methods by which a DOTS client receives the address and 747 associated service details of the DOTS server are not prescribed by 748 this document. For example, a DOTS client may be directly configured 749 to use a specific DOTS server IP address and port, and directly 750 provided with any data necessary to satisfy the Peer Mutual 751 Authentication requirement in [I-D.ietf-dots-requirements], such as 752 symmetric or asymmetric keys, usernames and passwords, etc. All 753 configuration and authentication information in this scenario is 754 provided out-of-band by the domain operating the DOTS server. 756 At the other extreme, the architecture in this document allows for a 757 form of DOTS client auto-provisioning. For example, the domain 758 operating the DOTS server or servers might provide the client domain 759 only with symmetric or asymmetric keys to authenticate the 760 provisioned DOTS clients. Only the keys would then be directly 761 configured on DOTS clients, but the remaining configuration required 762 to provision the DOTS clients could be learned through mechanisms 763 similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. 765 The DOTS client SHOULD successfully authenticate and exchange 766 messages with the DOTS server over both signal and data channel as 767 soon as possible to confirm that both channels are operational. 769 As described in [I-D.ietf-dots-requirements], the DOTS client can 770 configure preferred values for acceptable signal loss, mitigation 771 lifetime, and heartbeat intervals when establishing the DOTS session. 772 A DOTS session is not active until DOTS agents have agreed on the 773 values for these DOTS session parameters, a process defined by the 774 protocol. 776 Once the DOTS client begins receiving DOTS server signals, the DOTS 777 session is active. At any time during the DOTS session, the DOTS 778 client may use the data channel to adjust initial configuration, 779 manage black- and white-listed prefixes or addresses, leverage 780 vendor-specific extensions, and so on. Note that unlike the signal 781 channel, there is no requirement that the data channel remain 782 operational in attack conditions (See Data Channel Requirements, 783 [I-D.ietf-dots-requirements]). 785 3.1.3. Maintaining the DOTS Session 787 DOTS clients and servers periodically send heartbeats to each other 788 over the signal channel, per Operational Requirements discussed in 789 [I-D.ietf-dots-requirements]. DOTS agent operators SHOULD configure 790 the heartbeat interval such that the frequency does not lead to 791 accidental denials of service due to the overwhelming number of 792 heartbeats a DOTS agent must field. 794 Either DOTS agent may consider a DOTS session terminated in the 795 extended absence of a heartbeat from its peer agent. The period of 796 that absence will be established in the protocol definition. 798 3.2. Modes of Signaling 800 This section examines the modes of signaling between agents in a DOTS 801 architecture. 803 3.2.1. Direct Signaling 805 A DOTS session may take the form of direct signaling between the DOTS 806 clients and servers, as shown in Figure 11. 808 +-------------+ +-------------+ 809 | DOTS client |<------signal session------>| DOTS server | 810 +-------------+ +-------------+ 812 Figure 11: Direct Signaling 814 In a direct DOTS session, DOTS client and server are communicating 815 directly. Direct signaling may exist inter- or intra-domain. The 816 DOTS session is abstracted from the underlying networks or network 817 elements the signals traverse: in direct signaling, the DOTS client 818 and server are logically adjacent. 820 3.2.2. Redirected Signaling 822 In certain circumstances, a DOTS server may want to redirect a DOTS 823 client to an alternative DOTS server for a DOTS session. Such 824 circumstances include but are not limited to: 826 o Maximum number of DOTS sessions with clients has been reached; 828 o Mitigation capacity exhaustion in the mitigator with which the 829 specific DOTS server is communicating; 831 o Mitigator outage or other downtime, such as scheduled maintenance; 833 o Scheduled DOTS server maintenance; 835 o Scheduled modifications to the network path between DOTS server 836 and DOTS client. 838 A basic redirected DOTS session resembles the following, as shown in 839 Figure 12. 841 +-------------+ +---------------+ 842 | |<-(1)--- DOTS session 1 --->| | 843 | | | | 844 | |<=(2)== redirect to B ======| | 845 | DOTS client | | DOTS server A | 846 | |X-(4)--- DOTS session 1 ---X| | 847 | | | | 848 | | | | 849 +-------------+ +---------------+ 850 ^ 851 | 852 (3) DOTS session 2 853 | 854 v 855 +---------------+ 856 | DOTS server B | 857 +---------------+ 859 Figure 12: Redirected Signaling 861 1. Previously established DOTS session 1 exists between a DOTS 862 client and DOTS server A. 864 2. DOTS server A sends a server signal redirecting the client to 865 DOTS server B. 867 3. If the DOTS client does not already have a separate DOTS session 868 with the redirection target, the DOTS client initiates and 869 establishes DOTS session 2 with DOTS server B. 871 4. Having redirected the DOTS client, DOTS server A ceases sending 872 server signals. The DOTS client likewise stops sending client 873 signals to DOTS server A. DOTS session 1 is terminated. 875 3.2.3. Recursive Signaling 877 DOTS is centered around improving the speed and efficiency of 878 coordinated response to DDoS attacks. One scenario not yet discussed 879 involves coordination among federated domains operating DOTS servers 880 and mitigators. 882 In the course of normal DOTS operations, a DOTS client communicates 883 the need for mitigation to a DOTS server, and that server initiates 884 mitigation on a mitigator with which the server has an established 885 service relationship. The operator of the mitigator may in turn 886 monitor mitigation performance and capacity, as the attack being 887 mitigated may grow in severity beyond the mitigating domain's 888 capabilities. 890 The operator of the mitigator has limited options in the event a DOTS 891 client-requested mitigation is being overwhelmed by the severity of 892 the attack. Out-of-scope business or service level agreements may 893 permit the mitigating domain to drop the mitigation and let attack 894 traffic flow unchecked to the target, but this is only encourages 895 attack escalation. In the case where the mitigating domain is the 896 upstream service provider for the attack target, this may mean the 897 mitigating domain and its other services and users continue to suffer 898 the incidental effects of the attack. 900 A recursive signaling model as shown in Figure 13 offers an 901 alternative. In a variation of the use case "Enterprise with an 902 upstream transit provider DDoS mitigation service" described in 903 [I-D.ietf-dots-use-cases], a domain operating a DOTS server and 904 mitigator also operates a DOTS client. This DOTS client has an 905 established DOTS session with a DOTS server belonging to a separate 906 administrative domain. 908 With these preconditions in place, the operator of the mitigator 909 being overwhelmed or otherwise performing inadequately may request 910 mitigation for the attack target from this separate DOTS-aware 911 domain. Such a request recurses the originating mitigation request 912 to the secondary DOTS server, in the hope of building a cumulative 913 mitigation against the attack. 915 example.net domain 916 . . . . . . . . . . . . . . . . . 917 . Gn . 918 +----+ 1 . +----+ +-----------+ . 919 | Cc |<--------->| Sn |~~~~~~~| Mitigator | . 920 +----+ . +====+ | Mn | . 921 . | Cn | +-----------+ . 922 example.com . +----+ . 923 client . ^ . 924 . . .|. . . . . . . . . . . . . . 925 | 926 1 | 927 | 928 . . .|. . . . . . . . . . . . . . 929 . v . 930 . +----+ +-----------+ . 931 . | So |~~~~~~~| Mitigator | . 932 . +----+ | Mo | . 933 . +-----------+ . 934 . . 935 . . . . . . . . . . . . . . . . . 936 example.org domain 938 Figure 13: Recursive Signaling 940 In Figure 13, client Cc signals a request for mitigation across 941 inter-domain DOTS session 1 to the DOTS server Sn belonging to the 942 example.net domain. DOTS server Sn enables mitigation on mitigator 943 Mn. DOTS server Sn is half of DOTS gateway Gn, being deployed 944 logically back-to-back with DOTS client Cn, which has pre-existing 945 inter-domain DOTS session 2 with the DOTS server So belonging to the 946 example.org domain. At any point, DOTS server Sn MAY recurse an on- 947 going mitigation request through DOTS client Cn to DOTS server So, in 948 the expectation that mitigator Mo will be activated to aid in the 949 defense of the attack target. 951 Recursive signaling is opaque to the DOTS client. To maximize 952 mitigation visibility to the DOTS client, however, the recursing 953 domain SHOULD provide recursed mitigation feedback in signals 954 reporting on mitigation status to the DOTS client. For example, the 955 recursing domain's mitigator should incorporate into mitigation 956 status messages available metrics such as dropped packet or byte 957 counts from the recursed mitigation. 959 DOTS clients involved in recursive signaling must be able to withdraw 960 requests for mitigation without warning or justification, per 961 [I-D.ietf-dots-requirements]. 963 Operators recursing mitigation requests MAY maintain the recursed 964 mitigation for a brief, protocol-defined period in the event the DOTS 965 client originating the mitigation withdraws its request for help, as 966 per the discussion of managing mitigation toggling in the operational 967 requirements ([I-D.ietf-dots-requirements]). 969 Deployment of recursive signaling may result in traffic redirection, 970 examination and mitigation extending beyond the initial bilateral 971 relationship between DOTS client and DOTS server. As such, client 972 control over the network path of mitigated traffic may be reduced. 973 DOTS client operators should be aware of any privacy concerns, and 974 work with DOTS server operators employing recursive signaling to 975 ensure shared sensitive material is suitably protected. 977 3.2.4. Anycast Signaling 979 The DOTS architecture does not assume the availability of anycast 980 within a DOTS deployment, but neither does the architecture exclude 981 it. Domains operating DOTS servers MAY deploy DOTS servers with an 982 anycast Service Address as described in BCP 126 [RFC4786]. In such a 983 deployment, DOTS clients connecting to the DOTS Service Address may 984 be communicating with distinct DOTS servers, depending on the network 985 configuration at the time the DOTS clients connect. Among other 986 benefits, anycast signaling potentially offers the following: 988 o Simplified DOTS client configuration, including service discovery 989 through the methods described in [RFC7094]. In this scenario, the 990 "instance discovery" message would be a DOTS client initiating a 991 DOTS session to the DOTS server anycast Service Address, to which 992 the DOTS server would reply with a redirection to the DOTS server 993 unicast address the client should use for DOTS. 995 o Region- or customer-specific deployments, in which the DOTS 996 Service Addresses route to distinct DOTS servers depending on the 997 client region or the customer network in which a DOTS client 998 resides. 1000 o Operational resiliency, spreading DOTS signaling traffic across 1001 the DOTS server domain's networks, and thereby also reducing the 1002 potential attack surface, as described in BCP 126 [RFC4786]. 1004 3.2.4.1. Anycast Signaling Considerations 1006 As long as network configuration remains stable, anycast DOTS 1007 signaling is to the individual DOTS client indistinct from direct 1008 signaling. However, the operational challenges inherent in anycast 1009 signaling are anything but negligible, and DOTS server operators must 1010 carefully weigh the risks against the benefits before deploying. 1012 While the DOTS signal channel primarily operates over UDP per 1013 [I-D.ietf-dots-requirements], the signal channel also requires mutual 1014 authentication between DOTS agents, with associated security state on 1015 both ends. 1017 Network instability is of particular concern with anycast signaling, 1018 as DOTS signal channels are expected to be long-lived, and 1019 potentially operating under congested network conditions caused by a 1020 volumetric DDoS attack. 1022 For example, a network configuration altering the route to the DOTS 1023 server during active anycast signaling may cause the DOTS client to 1024 send messages to a DOTS server other than the one with which it 1025 initially established a signaling session. That second DOTS server 1026 may not have the security state of the existing session, forcing the 1027 DOTS client to initialize a new DOTS session. This challenge might 1028 in part be mitigated by use of pre-shared keys and session resumption 1029 [RFC5246][RFC6347], but keying material must be available to all DOTS 1030 servers sharing the anycast Service Address in that case. 1032 While the DOTS client will try to establish a new DOTS session with 1033 the DOTS server now acting as the anycast DOTS Service Address, the 1034 link between DOTS client and server may be congested with attack 1035 traffic, making signal session establishment difficult. In such a 1036 scenario, anycast Service Address instability becomes a sort of 1037 signal session flapping, with obvious negative consequences for the 1038 DOTS deployment. 1040 Anycast signaling deployments similarly must also take into account 1041 active mitigations. Active mitigations initiated through a DOTS 1042 session may involve diverting traffic to a scrubbing center. If the 1043 DOTS session flaps due to anycast changes as described above, 1044 mitigation may also flap as the DOTS servers sharing the anycast DOTS 1045 service address toggles mitigation on detecting DOTS session loss, 1046 depending on whether the client has configured mitigation on loss of 1047 signal. 1049 3.3. Triggering Requests for Mitigation 1051 [I-D.ietf-dots-requirements] places no limitation on the 1052 circumstances in which a DOTS client operator may request mitigation, 1053 nor does it demand justification for any mitigation request, thereby 1054 reserving operational control over DDoS defense for the domain 1055 requesting mitigation. This architecture likewise does not prescribe 1056 the network conditions and mechanisms triggering a mitigation request 1057 from a DOTS client. 1059 However, considering selected possible mitigation triggers from an 1060 architectural perspective offers a model for alternative or 1061 unanticipated triggers for DOTS deployments. In all cases, what 1062 network conditions merit a mitigation request are at the discretion 1063 of the DOTS client operator. 1065 The interfaces required to trigger the mitigation request in the 1066 following scenarios are implementation-specific. 1068 3.3.1. Manual Mitigation Request 1070 A DOTS client operator may manually prepare a request for mitigation, 1071 including scope and duration, and manually instruct the DOTS client 1072 to send the mitigation request to the DOTS server. In context, a 1073 manual request is a request directly issued by the operator without 1074 automated decision-making performed by a device interacting with the 1075 DOTS client. Modes of manual mitigation requests include an operator 1076 entering a command into a text interface, or directly interacting 1077 with a graphical interface to send the request. 1079 An operator might do this, for example, in response to notice of an 1080 attack delivered by attack detection equipment or software, and the 1081 alerting detector lacks interfaces or is not configured to use 1082 available interfaces to translate the alert to a mitigation request 1083 automatically. 1085 In a variation of the above scenario, the operator may have 1086 preconfigured on the DOTS client mitigation request for various 1087 resources in the operator's domain. When notified of an attack, the 1088 DOTS client operator manually instructs the DOTS client to send the 1089 preconfigured mitigation request for the resources under attack. 1091 A further variant involves recursive signaling, as described in 1092 Section 3.2.3. The DOTS client in this case is the second half of a 1093 DOTS gateway (back-to-back DOTS server and client). As in the 1094 previous scenario, the scope and duration of the mitigation request 1095 are pre-existing, but in this case are derived from the mitigation 1096 request received from a downstream DOTS client by the DOTS server. 1097 Assuming the preconditions required by Section 3.2.3 are in place, 1098 the DOTS gateway operator may at any time manually request mitigation 1099 from an upstream DOTS server, sending a mitigation request derived 1100 from the downstream DOTS client's request. 1102 The motivations for a DOTS client operator to request mitigation 1103 manually are not prescribed by this architecture, but are expected to 1104 include some of the following: 1106 o Notice of an attack delivered via e-mail or alternative messaging 1107 o Notice of an attack delivered via phone call 1109 o Notice of an attack delivered through the interface(s) of 1110 networking monitoring software deployed in the operator's domain 1112 o Manual monitoring of network behavior through network monitoring 1113 software 1115 3.3.2. Automated Conditional Mitigation Request 1117 Unlike manual mitigation requests, which depend entirely on the DOTS 1118 client operator's capacity to react with speed and accuracy to every 1119 detected or detectable attack, mitigation requests triggered by 1120 detected attack conditions reduce the operational burden on the DOTS 1121 client operator, and minimize the latency between attack detection 1122 and the start of mitigation. 1124 Mitigation requests are triggered in this scenario by operator- 1125 specified network conditions. Attack detection is deployment- 1126 specific, and not constrained by this architecture. Similarly the 1127 specifics of a condition are left to the discretion of the operator, 1128 though common conditions meriting mitigation include the following: 1130 o Detected attack exceeding a rate in packets per second (pps). 1132 o Detected attack exceeding a rate in bytes per second (bps). 1134 o Detected resource exhaustion in an attack target. 1136 o Detected resource exhaustion in the local domain's mitigator. 1138 o Number of open connections to an attack target. 1140 o Number of attack sources in a given attack. 1142 o Number of active attacks against targets in the operator's domain. 1144 o Conditional detection developed through arbitrary statistical 1145 analysis or deep learning techniques. 1147 o Any combination of the above. 1149 When automated conditional mitigation requests are enabled, 1150 violations of any of the above conditions, or any additional 1151 operator-defined conditions, will trigger a mitigation request from 1152 the DOTS client to the DOTS server. The interfaces between the 1153 application detecting the condition violation and the DOTS client are 1154 implementation-specific. 1156 3.3.3. Automated Mitigation on Loss of Signal 1158 To maintain a DOTS session, the DOTS client and the DOTS server 1159 exchange regular but infrequent messages across the signal channel. 1160 In the absence of an attack, the probability of message loss in the 1161 signaling channel should be extremely low. Under attack conditions, 1162 however, some signal loss may be anticipated as attack traffic 1163 congests the link, depending on the attack type. 1165 While [I-D.ietf-dots-requirements] specifies the DOTS protocol be 1166 robust when signaling under attack conditions, there are nevertheless 1167 scenarios in which the DOTS signal is lost in spite of protocol best 1168 efforts. To handle such scenarios, a DOTS client operator may 1169 configure the DOTS session to trigger mitigation when the DOTS server 1170 ceases receiving DOTS client signals (or vice versa) beyond the miss 1171 count or period permitted by the protocol. 1173 The impact of mitigating due to loss of signal in either direction 1174 must be considered carefully before enabling it. Signal loss is not 1175 caused by links congested with attack traffic alone, and as such 1176 mitigation requests triggered by signal channel degradation in either 1177 direction may incur unnecessary costs, in network performance and 1178 operational expense alike. 1180 4. Security Considerations 1182 This section describes identified security considerations for the 1183 DOTS architecture. 1185 DOTS is at risk from three primary attack vectors: agent 1186 impersonation, traffic injection and signal blocking. These vectors 1187 may be exploited individually or in concert by an attacker to 1188 confuse, disable, take information from, or otherwise inhibit DOTS 1189 agents. 1191 Any attacker with the ability to impersonate a legitimate client or 1192 server or, indeed, inject false messages into the stream may 1193 potentially trigger/withdraw traffic redirection, trigger/cancel 1194 mitigation activities or subvert black/whitelists. From an 1195 architectural standpoint, operators SHOULD ensure best current 1196 practices for secure communication are observed for data and signal 1197 channel confidentiality, integrity and authenticity. Care must be 1198 taken to ensure transmission is protected by appropriately secure 1199 means, reducing attack surface by exposing only the minimal required 1200 services or interfaces. Similarly, received data at rest SHOULD be 1201 stored with a satisfactory degree of security. 1203 As many mitigation systems employ diversion to scrub attack traffic, 1204 operators of DOTS agents SHOULD ensure DOTS sessions are resistant to 1205 Man-in-the-Middle (MitM) attacks. An attacker with control of a DOTS 1206 client may negatively influence network traffic by requesting and 1207 withdrawing requests for mitigation for particular prefixes, leading 1208 to route or DNS flapping. 1210 Any attack targeting the availability of DOTS servers may disrupt the 1211 ability of the system to receive and process DOTS signals resulting 1212 in failure to fulfill a mitigation request. DOTS agents SHOULD be 1213 given adequate protections, again in accordance with best current 1214 practices for network and host security. 1216 5. Contributors 1218 Mohamed Boucadair 1219 Orange 1221 mohamed.boucadair@orange.com 1223 6. Acknowledgments 1225 Thanks to Matt Richardson and Med Boucadair for their comments and 1226 suggestions. 1228 7. Change Log 1230 2016-03-18 Initial revision 1232 8. References 1234 8.1. Normative References 1236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1237 Requirement Levels", BCP 14, RFC 2119, 1238 DOI 10.17487/RFC2119, March 1997, 1239 . 1241 8.2. Informative References 1243 [I-D.ietf-dots-requirements] 1244 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1245 Denial of Service (DDoS) Open Threat Signaling 1246 Requirements", draft-ietf-dots-requirements-05 (work in 1247 progress), June 2017. 1249 [I-D.ietf-dots-use-cases] 1250 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 1251 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 1252 Open Threat Signaling (DDoS) Open Threat Signaling", 1253 draft-ietf-dots-use-cases-05 (work in progress), May 2017. 1255 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1256 DOI 10.17487/RFC0768, August 1980, 1257 . 1259 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1260 RFC 793, DOI 10.17487/RFC0793, September 1981, 1261 . 1263 [RFC1035] Mockapetris, P., "Domain names - implementation and 1264 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1265 November 1987, . 1267 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1268 specifying the location of services (DNS SRV)", RFC 2782, 1269 DOI 10.17487/RFC2782, February 2000, 1270 . 1272 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1273 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1274 DOI 10.17487/RFC4271, January 2006, 1275 . 1277 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1278 Denial-of-Service Considerations", RFC 4732, 1279 DOI 10.17487/RFC4732, December 2006, 1280 . 1282 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1283 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1284 December 2006, . 1286 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1287 (TLS) Protocol Version 1.2", RFC 5246, 1288 DOI 10.17487/RFC5246, August 2008, 1289 . 1291 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1292 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1293 January 2012, . 1295 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1296 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1297 . 1299 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1300 Initiation Protocol (SIP) Back-to-Back User Agents", 1301 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1302 . 1304 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1305 "Architectural Considerations of IP Anycast", RFC 7094, 1306 DOI 10.17487/RFC7094, January 2014, 1307 . 1309 Authors' Addresses 1311 Andrew Mortensen 1312 Arbor Networks 1313 2727 S. State St 1314 Ann Arbor, MI 48104 1315 United States 1317 EMail: amortensen@arbor.net 1319 Flemming Andreasen 1320 Cisco 1321 United States 1323 EMail: fandreas@cisco.com 1325 Tirumaleswar Reddy 1326 McAfee, Inc. 1327 Embassy Golf Link Business Park 1328 Bangalore, Karnataka 560071 1329 India 1331 EMail: tireddy@cisco.com 1333 Christopher Gray 1334 Comcast 1335 United States 1337 EMail: Christopher_Gray3@cable.comcast.com 1338 Rich Compton 1339 Charter 1341 EMail: Rich.Compton@charter.com 1343 Nik Teague 1344 Verisign 1345 United States 1347 EMail: nteague@verisign.com