idnits 2.17.1 draft-ietf-dots-architecture-01.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 (October 31, 2016) is 2734 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-02 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-01 == Outdated reference: A later version (-15) exists of draft-ietf-dprive-dnsodtls-12 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS A. Mortensen 3 Internet-Draft Arbor Networks, Inc. 4 Intended status: Informational F. Andreasen 5 Expires: May 4, 2017 T. Reddy 6 Cisco Systems, Inc. 7 C. Gray 8 Comcast, Inc. 9 R. Compton 10 Charter Communications, Inc. 11 N. Teague 12 Verisign, Inc. 13 October 31, 2016 15 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture 16 draft-ietf-dots-architecture-01 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 http://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 4, 2017. 44 Copyright Notice 46 Copyright (c) 2016 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 (http://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. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8 69 2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9 70 2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9 71 2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10 72 2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11 73 2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 12 74 2.3.1. Gatewayed signaling . . . . . . . . . . . . . . . . . 13 75 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 3.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 15 77 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 78 3.1.2. Establishing the Signaling Session . . . . . . . . . 16 79 3.1.3. Maintaining the Signaling Session . . . . . . . . . . 17 80 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 17 81 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 17 82 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18 83 3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19 84 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 21 85 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 23 86 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 23 87 3.3.2. Automated Conditional Mitigation Request . . . . . . 24 88 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 25 89 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 90 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 91 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 27 94 7.2. Informative References . . . . . . . . . . . . . . . . . 27 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 97 1. Context and Motivation 99 Signaling the need for help defending against an active distributed 100 denial of service (DDoS) attack requires a common understanding of 101 mechanisms and roles among the parties coordinating defensive 102 response. The signaling layer and supplementary messaging is the 103 focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of 104 coordinating defensive measures among willing peers to mitigate 105 attacks quickly and efficiently, enabling hybrid attack responses 106 coordinated locally at or near the target of an active attack, or 107 anywhere in-path between attack sources and target. 109 This document describes an architecture used in establishing, 110 maintaining or terminating a DOTS relationship within a domain or 111 between domains. 113 1.1. Terminology 115 1.1.1. Key Words 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 1.1.2. Definition of Terms 123 This document uses the terms defined in [I-D.ietf-dots-requirements]. 125 1.2. Scope 127 In this architecture, DOTS clients and servers communicate using the 128 DOTS signaling. As a result of signals from a DOTS client, the DOTS 129 server may modify the forwarding path of traffic destined for the 130 attack target(s), for example by diverting traffic to a mitigator or 131 pool of mitigators, where policy may be applied to distinguish and 132 discard attack traffic. Any such policy is deployment-specific. 134 The DOTS architecture presented here is applicable across network 135 administrative domains - for example, between an enterprise domain 136 and the domain of a third-party attack mitigation service - as well 137 as to a single administrative domain. DOTS is generally assumed to 138 be most effective when aiding coordination of attack response between 139 two or more participating network domains, but single domain 140 scenarios are valuable in their own right, as when aggregating intra- 141 domain DOTS client signals for inter-domain coordinated attack 142 response. 144 This document does not address any administrative or business 145 agreements that may be established between involved DOTS parties. 146 Those considerations are out of scope. Regardless, this document 147 assumes necessary authentication and authorization mechanism are put 148 in place so that only authorized clients can invoke the DOTS service. 150 1.3. Assumptions 152 This document makes the following assumptions: 154 o All domains in which DOTS is deployed are assumed to offer the 155 required connectivity between DOTS agents and any intermediary 156 network elements, but the architecture imposes no additional 157 limitations on the form of connectivity. 159 o Congestion and resource exhaustion are intended outcomes of a DDoS 160 attack [RFC4732]. Some operators may utilize non-impacted paths 161 or networks for DOTS, but in general conditions should be assumed 162 to be hostile and that DOTS must be able to function in all 163 circumstances, including when the signaling path is significantly 164 impaired. 166 o There is no universal DDoS attack scale threshold triggering a 167 coordinated response across administrative domains. A network 168 domain administrator, or service or application owner may 169 arbitrarily set attack scale threshold triggers, or manually send 170 requests for mitigation. 172 o Mitigation requests may be sent to one or more upstream DOTS 173 servers based on criteria determined by DOTS client 174 administrators. The number of DOTS servers with which a given 175 DOTS client has established signaling sessions is determined by 176 local policy and is deployment-specific. 178 o The mitigation capacity and/or capability of domains receiving 179 requests for coordinated attack response is opaque to the domains 180 sending the request. The domain receiving the DOTS client signal 181 may or may not have sufficient capacity or capability to filter 182 any or all DDoS attack traffic directed at a target. In either 183 case, the upstream DOTS server may redirect a request to another 184 DOTS server. Redirection may be local to the redirecting DOTS 185 server's domain, or may involve a third-party domain. 187 o DOTS client and server signals, as well as messages sent through 188 the data channel, are sent across any transit networks with the 189 same probability of delivery as any other traffic between the DOTS 190 client domain and the DOTS server domain. Any encapsulation 191 required for successful delivery is left untouched by transit 192 network elements. DOTS server and DOTS client cannot assume any 193 preferential treatment of DOTS signals. Such preferential 194 treatment may be available in some deployments, and the DOTS 195 architecture does not preclude its use when available. However, 196 DOTS itself does not address how that may be done. 198 o The architecture allows for, but does not assume, the presence of 199 Quality of Service (QoS) policy agreements between DOTS-enabled 200 peer networks or local QoS prioritization aimed at ensuring 201 delivery of DOTS messages between DOTS agents. QoS is an 202 operational consideration only, not a functional part of the DOTS 203 architecture. 205 o The signal channel and the data channel may be loosely coupled, 206 and need not terminate on the same DOTS server. 208 2. Architecture 210 The basic high-level DOTS architecture is illustrated in Figure 1: 212 +-----------+ +-------------+ 213 | Mitigator | ~~~~~~~~~~ | DOTS Server | 214 +-----------+ +-------------+ 215 | 216 | 217 | 218 +---------------+ +-------------+ 219 | Attack Target | ~~~~~~ | DOTS Client | 220 +---------------+ +-------------+ 222 Figure 1: Basic DOTS Architecture 224 A simple example instantiation of the DOTS architecture could be an 225 enterprise as the attack target for a volumetric DDoS attack, and an 226 upstream DDoS mitigation service as the Mitigator. The enterprise 227 (attack target) is connected to the Internet via a link that is 228 getting saturated, and the enterprise suspects it is under DDoS 229 attack. The enterprise has a DOTS client, which obtains information 230 about the DDoS attack, and signals the DOTS server for help in 231 mitigating the attack. The DOTS server in turn invokes one or more 232 mitigators, which are tasked with mitigating the actual DDoS attack, 233 and hence aim to suppress the attack traffic while allowing valid 234 traffic to reach the attack target. 236 The scope of the DOTS specifications is the interfaces between the 237 DOTS client and DOTS server. The interfaces to the attack target and 238 the mitigator are out of scope of DOTS. Similarly, the operation of 239 both the attack target and the mitigator are out of scope of DOTS. 241 Thus, DOTS neither specifies how an attack target decides it is under 242 DDoS attack, nor does DOTS specify how a mitigator may actually 243 mitigate such an attack. A DOTS client's request for mitigation is 244 advisory in nature, and may not lead to any mitigation at all, 245 depending on the DOTS server domain's capacity and willingness to 246 mitigate on behalf of the DOTS client's domain. 248 As illustrated in Figure 2, there are two interfaces between the DOTS 249 server and the DOTS client: 251 +---------------+ +---------------+ 252 | | <------- Signal Channel ------> | | 253 | DOTS Client | | DOTS Server | 254 | | <======= Data Channel ======> | | 255 +---------------+ +---------------+ 257 Figure 2: DOTS Interfaces 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 signaling sessions by connecting to the provided DOTS server 263 addresses. 265 [[EDITOR'S NOTE: We request feedback from the working group about the 266 mechanism of server discovery.]] 268 The primary purpose of the signal channel is for a DOTS client to ask 269 a DOTS server for help in mitigating an attack, and for the DOTS 270 server to inform the DOTS client about the status of such mitigation. 271 The DOTS client does this by sending a client signal, which contains 272 information about the attack target or targets. The client signal 273 may also include telemetry information about the attack, if the DOTS 274 client has such information available. The DOTS server in turn sends 275 a server signal to inform the DOTS client of whether it will honor 276 the mitigation request. Assuming it will, the DOTS server initiates 277 attack mitigation (by means outside of DOTS), and periodically 278 informs the DOTS client about the status of the mitigation. 279 Similarly, the DOTS client periodically informs the DOTS server about 280 the client's status, which at a minimum provides client (attack 281 target) health information, but it may also include telemetry 282 information about the attack as it is now seen by the client. At 283 some point, the DOTS client may decide to terminate the server-side 284 attack mitigation, which it indicates to the DOTS server over the 285 signal channel. A mitigation may also be terminated if a DOTS 286 client-specified mitigation time limit is exceeded; additional 287 considerations around mitigation time limits may be found below. 288 Note that the signal channel may need to operate over a link that is 289 experiencing a DDoS attack and hence is subject to severe packet loss 290 and high latency. 292 While DOTS is able to request mitigation with just the signal 293 channel, the addition of the DOTS data channel provides for 294 additional and more efficient capabilities; both channels are 295 required in the DOTS architecture. The primary purpose of the data 296 channel is to support DOTS related configuration and policy 297 information exchange between the DOTS client and the DOTS server. 298 Examples of such information include, but are not limited to: 300 o Creating identifiers, such as names or aliases, for resources for 301 which mitigation may be requested. Such identifiers may then be 302 used in subsequent signal channel exchanges to refer more 303 efficiently to the resources under attack, as seen in Figure 3 304 below, using JSON to serialize the data: 306 { 307 "https1": [ 308 "192.0.2.1:443", 309 "198.51.100.2:443", 310 ], 311 "proxies": [ 312 "203.0.113.3:3128", 313 "[2001:DB8:AC10::1]:3128" 314 ], 315 "api_urls": "https://apiserver.example.com/api/v1", 316 } 318 Figure 3: Protected resource identifiers 320 o Black-list management, which enables a DOTS client to inform the 321 DOTS server about sources to suppress. 323 o White-list management, which enables a DOTS client to inform the 324 DOTS server about sources from which traffic should always be 325 accepted. 327 o Filter management, which enables a DOTS client to install or 328 remove traffic filters dropping or rate-limiting unwanted traffic. 330 o DOTS client provisioning. 332 Note that while it is possible to exchange the above information 333 before, during or after a DDoS attack, DOTS requires reliable 334 delivery of the this information and does not provide any special 335 means for ensuring timely delivery of it during an attack. In 336 practice, this means that DOTS deployments SHOULD NOT rely on such 337 information being exchanged during a DDoS attack. 339 2.1. DOTS Operations 341 The scope of DOTS is focused on the signaling and data exchange 342 between the DOTS client and DOTS server. DOTS does not prescribe any 343 specific deployment models, however DOTS is designed with some 344 specific requirements around the different DOTS agents and their 345 relationships. 347 First of all, a DOTS agent belongs to an domain, and that domain has 348 an identity which can be authenticated and authorized. DOTS agents 349 communicate with each other over a mutually authenticated signal 350 channel and data channel. However, before they can do so, a service 351 relationship needs to be established between them. The details and 352 means by which this is done is outside the scope of DOTS, however an 353 example would be for an enterprise A (DOTS client) to sign up for 354 DDoS service from provider B (DOTS server). This would establish a 355 (service) relationship between the two that enables enterprise A's 356 DOTS client to establish a signal channel with provider B's DOTS 357 server. A and B will authenticate each other, and B can verify that 358 A is authorized for its service. 360 From an operational and design point of view, DOTS assumes that the 361 above relationship is established prior to a request for DDoS attack 362 mitigation. In particular, it is assumed that bi-directional 363 communication is possible at this time between the DOTS client and 364 DOTS server. Furthermore, it is assumed that additional service 365 provisioning, configuration and information exchange can be performed 366 by use of the data channel, if operationally required. It is not 367 until this point that the mitigation service is available for use. 369 Once the mutually authenticated signal channel has been established, 370 it will remain in place. This is done to increase the likelihood 371 that the DOTS client can signal the DOTS server for help when the 372 attack target is being flooded, and similarly raise the probability 373 that DOTS server signals reach the client regardless of inbound link 374 congestion. This does not necessarily imply that the attack target 375 and the DOTS client have to be co-located in the same administrative 376 domain, but it is expected to be a common scenario. 378 DDoS mitigation service with the help of an upstream mitigator will 379 often involve some form of traffic redirection whereby traffic 380 destined for the attack target is diverted towards the mitigator, 381 e.g. by use of BGP [RFC4271] or DNS [RFC1034]. The mitigator in turn 382 inspects and scrubs the traffic, and forwards the resulting 383 (hopefully non-attack) traffic to the attack target. Thus, when a 384 DOTS server receives an attack mitigation request from a DOTS client, 385 it can be viewed as a way of causing traffic redirection for the 386 attack target indicated. 388 DOTS relies on mutual authentication and the pre-established service 389 relationship between the DOTS client's domain and the DOTS server's 390 domain to provide basic authorization. The DOTS server SHOULD 391 enforce additional authorization mechanisms to restrict the 392 mitigation scope a DOTS client can request, but such authorization 393 mechanisms are deployment-specific. 395 Although co-location of DOTS server and mitigator within the same 396 domain is expected to be a common deployment model, it is assumed 397 that operators may require alternative models. Nothing in this 398 document precludes such alternatives. 400 2.2. Components 402 2.2.1. DOTS Client 404 A DOTS client is a DOTS agent from which requests for help 405 coordinating attack response originate. The requests may be in 406 response to an active, ongoing attack against a target in the DOTS 407 client's domain, but no active attack is required for a DOTS client 408 to request help. Local operators may wish to have upstream 409 mitigators in the network path for an indefinite period, and are 410 restricted only by business relationships when it comes to duration 411 and scope of requested mitigation. 413 The DOTS client requests attack response coordination from a DOTS 414 server over the signal channel, including in the request the DOTS 415 client's desired mitigation scoping, as described in 416 [I-D.ietf-dots-requirements]. The actual mitigation scope and 417 countermeasures used in response to the attack are up to the DOTS 418 server and Mitigator operators, as the DOTS client may have a narrow 419 perspective on the ongoing attack. As such, the DOTS client's 420 request for mitigation should be considered advisory: guarantees of 421 DOTS server availability or mitigation capacity constitute service 422 level agreements and are out of scope for this document. 424 The DOTS client adjusts mitigation scope and provides available 425 attack details at the direction of its local operator. Such 426 direction may involve manual or automated adjustments in response to 427 feedback from the DOTS server. 429 To provide a metric of signal health and distinguish an idle 430 signaling session from a disconnected or defunct session, the DOTS 431 client sends a heartbeat over the signal channel to maintain its half 432 of the signaling session. The DOTS client similarly expects a 433 heartbeat from the DOTS server, and MAY consider a signaling session 434 terminated in the extended absence of a DOTS server heartbeat. 436 2.2.2. DOTS Server 438 A DOTS server is a DOTS agent capable of receiving, processing and 439 possibly acting on requests for help coordinating attack response 440 from one or more DOTS clients. The DOTS server authenticates and 441 authorizes DOTS clients as described in Signaling Sessions below, and 442 maintains signaling session state, tracking requests for mitigation, 443 reporting on the status of active mitigations, and terminating 444 signaling sessions in the extended absence of a client heartbeat or 445 when a session times out. 447 Assuming the preconditions discussed below exist, a DOTS client 448 maintaining an active signaling session with a DOTS server may 449 reasonably expect some level of mitigation in response to a request 450 for 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 or 469 mitigators responsible for scrubbing attack traffic. Note that the 470 form of the translated request passed from the DOTS server to the 471 mitigator is not in scope: it may be as simple as an alert to 472 mitigator operators, or highly automated using vendor or open 473 application programming interfaces supported by the mitigator. The 474 DOTS server MUST report the actual scope of any mitigation enabled on 475 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 483 signaling session from a disconnected or defunct session, the DOTS 484 server sends a heartbeat over the signal channel to maintain its half 485 of the signaling session. The DOTS server similarly expects a 486 heartbeat from the DOTS client, and MAY consider a signaling session 487 terminated in the extended absence of a DOTS client heartbeat. 489 2.2.3. DOTS Gateway 491 Traditional client to server relationships may be expanded by 492 chaining DOTS sessions. This chaining is enabled through "logical 493 concatenation" [RFC7092] of a DOTS server and a DOTS client, 494 resulting in an application analogous to the SIP logical entity of a 495 Back-to-Back User Agent (B2BUA) [RFC3261]. The term DOTS gateway 496 will be used here and the following text will describe some 497 interactions in relation to 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 signaling 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 performs 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 example.org \ 540 \ 541 +---+ \ +---+ 542 | c |----------------| S | 543 +---+ / +---+ 544 example.com / 545 / 546 +---+ / 547 | c |----------- 548 +---+ 549 example.com example.net 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 below. Operational considerations relating to co-ordinating 559 multiple provider responses are beyond the scope of DOTS. 561 [[EDITOR'S NOTE: we request working group feedback and discussion of 562 operational considerations relating to coordinating multiple provider 563 responses to a mitigation request.]] 564 DOTS Client DOTS Servers 565 +---+ 566 ------------| S | 567 / +---+ 568 dots1.example.net 569 / 570 +---+/ +---+ 571 | c |---------------| S | 572 +---+\ +---+ 573 dots.example.org 574 \ 575 \ +---+ 576 ------------| S | 577 +---+ 578 example.com dots2.example.net 580 Figure 6: Multi-Homed DOTS Client 582 2.3.1. Gatewayed signaling 584 As discussed above in Section 2.2.3, a DOTS gateway is a logical 585 function chaining signaling sessions through concatenation of a DOTS 586 server and DOTS client. 588 An example scenario, as shown in Figure 7 and Figure 8 below, is for 589 an enterprise to have deployed multiple DOTS capable devices which 590 are able to signal intra-domain using TCP [RFC0793] on un-congested 591 links to a DOTS gateway which may then transform these to a UDP 592 [RFC0768] transport inter-domain where connection oriented transports 593 may degrade; this applies to the signal channel only, as the data 594 channel requires a connection-oriented transport. The relationship 595 between the gateway and its upstream agents is opaque to the initial 596 clients. 598 +---+ 599 | c |\ 600 +---+ \ +---+ 601 \-----TCP-----| D | +---+ 602 +---+ | O | | | 603 | c |--------TCP-----| T |------UDP------| S | 604 +---+ | S | | | 605 /-----TCP-----| G | +---+ 606 +---+ / +---+ 607 | c |/ 608 +---+ 609 example.com example.com example.net 610 DOTS Clients DOTS Gateway (DOTSG) DOTS Server 612 Figure 7: Client-Side Gateway with Aggregation 614 +---+ 615 | c |\ 616 +---+ \ +---+ 617 \-----TCP-----| D |------UDP------+---+ 618 +---+ | O | | | 619 | c |--------TCP-----| T |------UDP------| S | 620 +---+ | S | | | 621 /-----TCP-----| G |------UDP------+---+ 622 +---+ / +---+ 623 | c |/ 624 +---+ 625 example.com example.com example.net 626 DOTS Clients DOTS Gateway (DOTSG) DOTS Server 628 Figure 8: Client-Side Gateway without Aggregation 630 This may similarly be deployed in the inverse scenario where the 631 gateway resides in the server-side domain and may be used to 632 terminate and/or aggregate multiple clients to single transport as 633 shown in figures Figure 9 and Figure 10 below. 635 +---+ 636 | c |\ 637 +---+ \ +---+ 638 \-----UDP-----| D | +---+ 639 +---+ | O | | | 640 | c |--------TCP-----| T |------TCP------| S | 641 +---+ | S | | | 642 /-----TCP-----| G | +---+ 643 +---+ / +---+ 644 | c |/ 645 +---+ 646 example.com example.net example.net 647 DOTS Clients DOTS Gateway (DOTSG) DOTS Server 649 Figure 9: Server-Side Gateway with Aggregation 651 +---+ 652 | c |\ 653 +---+ \ +---+ 654 \-----UDP-----| D |------TCP------+---+ 655 +---+ | O | | | 656 | c |--------TCP-----| T |------TCP------| S | 657 +---+ | S | | | 658 /-----UDP-----| G |------TCP------+---+ 659 +---+ / +---+ 660 | c |/ 661 +---+ 662 example.com example.net example.net 663 DOTS Clients DOTS Gateway (DOTSG) DOTS Server 665 Figure 10: Server-Side Gateway without Aggregation 667 3. Concepts 669 3.1. Signaling Sessions 671 In order for DOTS to be effective as a vehicle for DDoS mitigation 672 requests, one or more DOTS clients must establish ongoing 673 communication with one or more DOTS servers. While the preconditions 674 for enabling DOTS in or among network domains may also involve 675 business relationships, service level agreements, or other formal or 676 informal understandings between network operators, such 677 considerations are out of scope for this document. 679 An established communication layer between DOTS agents is a Signaling 680 Session. At its most basic, for a DOTS signaling session to exist 681 both signal channel and data channel must be functioning between DOTS 682 agents. That is, under nominal network conditions, signals actively 683 sent from a DOTS client are received by the specific DOTS server 684 intended by the client, and vice versa. 686 3.1.1. Preconditions 688 Prior to establishing a signaling session between agents, the owners 689 of the networks, domains, services or applications involved are 690 assumed to have agreed upon the terms of the relationship involved. 691 Such agreements are out of scope for this document, but must be in 692 place for a functional DOTS architecture. 694 It is assumed that as part of any DOTS service agreement, the DOTS 695 client is provided with all data and metadata required to establish 696 communication with the DOTS server. Such data and metadata would 697 include any cryptographic information necessary to meet the message 698 confidentiality, integrity and authenticity requirement in 699 [I-D.ietf-dots-requirements], and might also include the pool of DOTS 700 server addresses and ports the DOTS client should use for signal and 701 data channel messaging. 703 3.1.2. Establishing the Signaling Session 705 With the required business or service agreements in place, the DOTS 706 client initiates a signal session by contacting the DOTS server over 707 the signal channel and the data channel. To allow for DOTS service 708 flexibility, neither the order of contact nor the time interval 709 between channel creations is specified. A DOTS client MAY establish 710 signal channel first, and then data channel, or vice versa. 712 The methods by which a DOTS client receives the address and 713 associated service details of the DOTS server are not prescribed by 714 this document. For example, a DOTS client may be directly configured 715 to use a specific DOTS server address and port, and directly provided 716 with any data necessary to satisfy the Peer Mutual Authentication 717 requirement in [I-D.ietf-dots-requirements], such as symmetric or 718 asymmetric keys, usernames and passwords, etc. All configuration and 719 authentication information in this scenario is provided out-of-band 720 by the domain operating the DOTS server. 722 At the other extreme, the architecture in this document allows for a 723 form of DOTS client auto-provisioning. For example, the domain 724 operating the DOTS server or servers might provide the client domain 725 only with symmetric or asymmetric keys to authenticate the 726 provisioned DOTS clients. Only the keys would then be directly 727 configured on DOTS clients, but the remaining configuration required 728 to provision the DOTS clients could be learned through mechanisms 729 similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. 731 The DOTS client SHOULD successfully authenticate and exchange 732 messages with the DOTS server over both signal and data channel as 733 soon as possible to confirm that both channels are operational. 735 As described in [I-D.ietf-dots-requirements], the DOTS client can 736 configure preferred values for acceptable signal loss, mitigation 737 lifetime, and heartbeat intervals when establishing the signaling 738 session. A signaling session is not active until DOTS agents have 739 agreed on the values for these signaling session parameters, a 740 process defined by the protocol. 742 Once the DOTS client begins receiving DOTS server signals, the 743 signaling session is active. At any time during the signaling 744 session, the DOTS client MAY use the data channel to adjust initial 745 configuration, manage black- and white-listed prefixes or addresses, 746 leverage vendor-specific extensions, and so on. Note that unlike the 747 signal channel, there is no requirement that the data channel remain 748 operational in attack conditions (See Data Channel Requirements, 749 [I-D.ietf-dots-requirements]). 751 3.1.3. Maintaining the Signaling Session 753 DOTS clients and servers periodically send heartbeats to each other 754 over the signal channel, per Operational Requirements discussed in 755 [I-D.ietf-dots-requirements]. DOTS agent operators SHOULD configure 756 the heartbeat interval such that the frequency does not lead to 757 accidental denials of service due to the overwhelming number of 758 heartbeats a DOTS agent must field. 760 Either DOTS agent may consider a signaling session terminated in the 761 extended absence of a heartbeat from its peer agent. The period of 762 that absence will be established in the protocol definition. 764 3.2. Modes of Signaling 766 This section examines the modes of signaling between agents in a DOTS 767 architecture. 769 3.2.1. Direct Signaling 771 A signaling session may take the form of direct signaling between the 772 DOTS clients and servers, as shown in Figure 11 below: 774 +-------------+ +-------------+ 775 | DOTS client |<------signal session------>| DOTS server | 776 +-------------+ +-------------+ 778 Figure 11: Direct Signaling 780 In a direct signaling session, DOTS client and server are 781 communicating directly. A direct signaling session MAY exist inter- 782 or intra-domain. The signaling session is abstracted from the 783 underlying networks or network elements the signals traverse: in a 784 direct signaling session, the DOTS client and server are logically 785 peer DOTS agents. 787 3.2.2. Redirected Signaling 789 In certain circumstances, a DOTS server may want to redirect a DOTS 790 client to an alternative DOTS server for a signaling session. Such 791 circumstances include but are not limited to: 793 o Maximum number of signaling sessions with clients has been 794 reached; 796 o Mitigation capacity exhaustion in the Mitigator with which the 797 specific DOTS server is communicating; 799 o Mitigator outage or other downtime, such as scheduled maintenance; 801 o Scheduled DOTS server maintenance; 803 o Scheduled modifications to the network path between DOTS server 804 and DOTS client. 806 A basic redirected signaling session resembles the following, as 807 shown in Figure 12: 809 +-------------+ +---------------+ 810 | |<-(1)-- signal session 1 -->| | 811 | | | | 812 | |<=(2)== redirect to B ======| | 813 | DOTS client | | DOTS server A | 814 | |X-(4)-- signal session 1 --X| | 815 | | | | 816 | | | | 817 +-------------+ +---------------+ 818 ^ 819 | 820 (3) signal session 2 821 | 822 v 823 +---------------+ 824 | DOTS server B | 825 +---------------+ 827 Figure 12: Redirected Signaling 829 1. Previously established signaling session 1 exists between a DOTS 830 client and DOTS server with address A. 832 2. DOTS server A sends a server signal redirecting the client to 833 DOTS server B. 835 3. If the DOTS client does not already have a separate signaling 836 session with the redirection target, the DOTS client initiates 837 and establishes a signaling session with DOTS server B as 838 described above. 840 4. Having redirected the DOTS client, DOTS server A ceases sending 841 server signals. The DOTS client likewise stops sending client 842 signals to DOTS server A. Signal session 1 is terminated. 844 [[EDITOR'S NOTE: we request working group feedback and discussion of 845 the need for redirected signaling.]] 847 3.2.3. Recursive Signaling 849 DOTS is centered around improving the speed and efficiency of 850 coordinated response to DDoS attacks. One scenario not yet discussed 851 involves coordination among federated domains operating DOTS servers 852 and mitigators. 854 In the course of normal DOTS operations, a DOTS client communicates 855 the need for mitigation to a DOTS server, and that server initiates 856 mitigation on a mitigator with which the server has an established 857 service relationship. The operator of the mitigator may in turn 858 monitor mitigation performance and capacity, as the attack being 859 mitigated may grow in severity beyond the mitigating domain's 860 capabilities. 862 The operator of the mitigator has limited options in the event a DOTS 863 client-requested mitigation is being overwhelmed by the severity of 864 the attack. Out-of-scope business or service level agreements may 865 permit the mitigating domain to drop the mitigation and let attack 866 traffic flow unchecked to the target, but this is only encourages 867 attack escalation. In the case where the mitigating domain is the 868 upstream service provider for the attack target, this may mean the 869 mitigating domain and its other services and users continue to suffer 870 the incidental effects of the attack. 872 A recursive signaling model as shown in Figure 13 below offers an 873 alternative. In a variation of the primary use case "Successful 874 Automatic or Operator-Assisted CPE or PE Mitigators Request Upstream 875 DDoS Mitigation Services" described in [I-D.ietf-dots-use-cases], an 876 domain operating a DOTS server and mitigation also operates a DOTS 877 client. This DOTS client has an established signaling session with a 878 DOTS server belonging to a separate administrative domain. 880 With these preconditions in place, the operator of the mitigator 881 being overwhelmed or otherwise performing inadequately may request 882 mitigation for the attack target from this separate DOTS-aware 883 domain. Such a request recurses the originating mitigation request 884 to the secondary DOTS server, in the hope of building a cumulative 885 mitigation against the attack: 887 example.net domain 888 . . . . . . . . . . . . . . . . . 889 . Gn . 890 +----+ A . +----+ +-----------+ . 891 | Cc |<--------->| Sn |~~~~~~~| Mitigator | . 892 +----+ . +====+ | Mn | . 893 . | Cn | +-----------+ . 894 example.com . +----+ . 895 client . ^ . 896 . . .|. . . . . . . . . . . . . . 897 | 898 B | 899 | 900 . . .|. . . . . . . . . . . . . . 901 . v . 902 . +----+ +-----------+ . 903 . | So |~~~~~~~| Mitigator | . 904 . +----+ | Mo | . 905 . +-----------+ . 906 . . 907 . . . . . . . . . . . . . . . . . 908 example.org domain 910 Figure 13: Recursive Signaling 912 In Figure 13 above, client Cc signals a request for mitigation across 913 inter-domain signaling session A to the DOTS server Sn belonging to 914 the example.net domain. DOTS server Sn enables mitigation on 915 mitigator Mn. DOTS server Sn is half of DOTS gateway Gn, being 916 deployed logically back-to-back with DOTS client Cn, which has pre- 917 existing inter-domain signaling session B with the DOTS server So 918 belonging to the example.org domain. At any point, DOTS server Sn 919 MAY recurse an on-going mitigation request through DOTS client Cn to 920 DOTS server So, in the expectation that mitigator Mo will be 921 activated to aid in the defense of the attack target. 923 Recursive signaling is opaque to the DOTS client. To maximize 924 mitigation visibility to the DOTS client, however, the recursing 925 domain SHOULD provide recursed mitigation feedback in signals 926 reporting on mitigation status to the DOTS client. For example, the 927 recursing domain's mitigator should incorporate into mitigation 928 status messages available metrics such as dropped packet or byte 929 counts from the recursed mitigation. 931 DOTS clients involved in recursive signaling MUST be able to withdraw 932 requests for mitigation without warning or justification, per 933 [I-D.ietf-dots-requirements]. 935 Operators recursing mitigation requests MAY maintain the recursed 936 mitigation for a brief, protocol-defined period in the event the DOTS 937 client originating the mitigation withdraws its request for help, as 938 per the discussion of managing mitigation toggling in the operational 939 requirements ([I-D.ietf-dots-requirements]). Service or business 940 agreements between recursing domains are not in scope for this 941 document. 943 [[EDITOR'S NOTE: Recursive signaling raises questions about 944 operational and data privacy, as well as what level of visibility a 945 client has into the recursed mitigation. We ask the working group 946 for feedback and additional discussion of these issues to help settle 947 the way forward.]] 949 3.2.4. Anycast Signaling 951 The DOTS architecture does not assume the availability of anycast 952 within a DOTS deployment, but neither does the architecture exclude 953 it. Domains operating DOTS servers MAY deploy DOTS servers with an 954 anycast Service Address as described in BCP 126 [RFC4786]. In such a 955 deployment, DOTS clients connecting to the DOTS Service Address may 956 be communicating with distinct DOTS servers, depending on the network 957 configuration at the time the DOTS clients connect. Among other 958 benefits, anycasted signaling potentially offers the following: 960 o Simplified DOTS client configuration, including service discovery 961 through the methods described in [RFC7094]. In this scenario, the 962 "instance discovery" message would be a DOTS client initiating a 963 signaling session to the DOTS server anycast Service Address, to 964 which the DOTS server would reply with a redirection to the DOTS 965 server unicast address the client should use for DOTS. 967 o Region- or customer-specific deployments, in which the DOTS 968 Service Addresses route to distinct DOTS servers depending on the 969 client region or the customer network in which a DOTS client 970 resides. 972 o Operational resiliency, spreading DOTS signaling traffic across 973 the DOTS server domain's networks, and thereby also reducing the 974 potential attack surface, as described in BCP 126 [RFC4786]. 976 3.2.4.1. Anycast Signaling Considerations 978 As long as network configuration remains stable, anycast DOTS 979 signaling is to the individual DOTS client indistinct from direct 980 signaling. However, the operational challenges inherent in anycast 981 signaling are anything but negligible, and DOTS server operators must 982 carefully weigh the risks against the benefits before deploying. 984 While the DOTS signal channel primarily operates over UDP per 985 [I-D.ietf-dots-requirements], the signal channel also requires mutual 986 authentication between DOTS agents, with associated security state on 987 both ends. The resulting considerations therefore superficially 988 resemble the deployment of anycast DNS over DTLS, as described in 989 [I-D.ietf-dprive-dnsodtls], but the similiarities only go so far. 991 Network instability is of particular concern with anycast signaling, 992 as DOTS signaling sessions are expected to be long-lived, and 993 potentially operating under congested network conditions caused by a 994 volumetric DDoS attack. 996 For example, a network configuration altering the route to the DOTS 997 server during active anycast signaling may cause the DOTS client to 998 send messages to a DOTS server other than the one with which it 999 initially established a signaling session. That second DOTS server 1000 may not have the security state of the existing session, forcing the 1001 DOTS client to initialize a new signaling session. This challenge 1002 may in part be mitigated by use of pre-shared keys, as described in 1003 [I-D.ietf-tls-tls13], but keying material must be available to all 1004 DOTS servers sharing the anycast Service Address in that case. 1006 While the DOTS client will try to establish a new signaling session 1007 with the DOTS server now acting as the anycast DOTS Service Address, 1008 the link between DOTS client and server may be congested with attack 1009 traffic, making signal session establishment difficult. In such a 1010 scenario, anycast Service Address instability becomes a sort of 1011 signal session flapping, with obvious negative consequences for the 1012 DOTS deployment. 1014 Anycast signaling deployments similarly must also take into account 1015 active mitigations. Active mitigations initiated through a signaling 1016 session may involve diverting traffic to a scrubbing center. If the 1017 signaling session flaps due to anycast changes as described above, 1018 mitigation may also flap as the DOTS servers sharing the anycast DOTS 1019 service address toggles mitigation on detecting signaling session 1020 loss, depending on whether the client has configured mitigation on 1021 loss of signal. 1023 [[EDITOR'S NOTE: We request feedback from the working group regarding 1024 the complexities inherent in an anycast DOTS deployment. Outside of 1025 using anycast for service discovery, significant challenges need to 1026 be overcome, particularly when dealing with security and mitigation 1027 state, and the resulting operational complexity may outweigh the 1028 expected benefits.]] 1030 3.3. Triggering Requests for Mitigation 1032 [I-D.ietf-dots-requirements] places no limitation on the 1033 circumstances in which a DOTS client operator may request mitigation, 1034 nor does it demand justification for any mitigation request, thereby 1035 reserving operational control over DDoS defense for the domain 1036 requesting mitigation. This architecture likewise does not prescribe 1037 the network conditions and mechanisms triggering a mitigation request 1038 from a DOTS client. 1040 However, considering selected possible mitigation triggers from an 1041 architectural perspective offers a model for alternative or 1042 unanticipated triggers for DOTS deployments. In all cases, what 1043 network conditions merit a mitigation request are at the discretion 1044 of the DOTS client operator. 1046 The interfaces required to trigger the mitigation request in the 1047 following scenarios are implementation-specific. 1049 3.3.1. Manual Mitigation Request 1051 A DOTS client operator may manually prepare a request for mitigation, 1052 including scope and duration, and manually instruct the DOTS client 1053 to send the mitigation request to the DOTS server. In context, a 1054 manual request is a request directly issued by the operator without 1055 automated decision-making performed by a device interacting with the 1056 DOTS client. Modes of manual mitigation requests include an operator 1057 entering a command into a text interface, or directly interacting 1058 with a graphical interface to send the request. 1060 An operator might do this, for example, in response to notice of an 1061 attack delivered by attack detection equipment or software, and the 1062 alerting detector lacks interfaces or is not configured to use 1063 available interfaces to translate the alert to a mitigation request 1064 automatically. 1066 In a variation of the above scenario, the operator may have 1067 preconfigured on the DOTS client mitigation request for various 1068 resources in the operator's domain. When notified of an attack, the 1069 DOTS client operator manually instructs the DOTS client to send the 1070 preconfigured mitigation request for the resources under attack. 1072 A further variant involves recursive signaling, as described in 1073 Section 3.2.3. The DOTS client in this case is the second half of a 1074 DOTS gateway (back-to-back DOTS server and client). As in the 1075 previous scenario, the scope and duration of the mitigation request 1076 are pre-existing, but in this case are derived from the mitigation 1077 request received from a downstream DOTS client by the DOTS server. 1078 Assuming the preconditions required by Section 3.2.3 are in place, 1079 the DOTS gateway operator may at any time manually request mitigation 1080 from an upstream DOTS server, sending a mitigation request derived 1081 from the downstream DOTS client's request. 1083 The motivations for a DOTS client operator to request mitigation 1084 manually are not prescribed by this architecture, but are expected to 1085 include some of the following: 1087 o Notice of an attack delivered via e-mail or alternative messaging 1089 o Notice of an attack delivered via phone call 1091 o Notice of an attack delivered through the interface(s) of 1092 networking monitoring software deployed in the operator's domain 1094 o Manual monitoring of network behavior through network monitoring 1095 software 1097 3.3.2. Automated Conditional Mitigation Request 1099 Unlike manual mitigation requests, which depend entirely on the DOTS 1100 client operator's capacity to react with speed and accuracy to every 1101 detected or detectable attack, mitigation requests triggered by 1102 detected attack conditions reduce the operational burden on the DOTS 1103 client operator, and minimize the latency between attack detection 1104 and the start of mitigation. 1106 Mitigation requests are triggered in this scenario by operator- 1107 specified network conditions. Attack detection is deployment- 1108 specific, and not constrained by this architecture. Similarly the 1109 specifics of a condition are left to the discretion of the operator, 1110 though common conditions meriting mitigation include the following: 1112 o Detected attack exceeding a rate in packets per second (pps). 1114 o Detected attack exceeding a rate in bytes per second (bps). 1116 o Detected resource exhaustion in an attack target. 1118 o Detected resource exhaustion in the local domain's mitigator. 1120 o Number of open connections to an attack target. 1122 o Number of attack sources in a given attack. 1124 o Number of active attacks against targets in the operator's domain. 1126 o Conditional detection developed through arbitrary statistical 1127 analysis or deep learning techniques. 1129 o Any combination of the above. 1131 When automated conditional mitigation requests are enabled, 1132 violations of any of the above conditions, or any additional 1133 operator-defined conditions, will trigger a mitigation request from 1134 the DOTS client to the DOTS server. The interfaces between the 1135 application detecting the condition violation and the DOTS client are 1136 implementation-specific. 1138 3.3.3. Automated Mitigation on Loss of Signal 1140 To maintain a signaling session, the DOTS client and the DOTS server 1141 exchange regular but infrequent messages across the signaling 1142 channel. In the absence of an attack, the probability of message 1143 loss in the signaling channel should be extremely low. Under attack 1144 conditions, however, some signal loss may be anticipated as attack 1145 traffic congests the link, depending on the attack type. 1147 While [I-D.ietf-dots-requirements] specifies the DOTS protocol be 1148 robust when signaling under attack conditions, there are nevertheless 1149 scenarios in which the DOTS signal is lost in spite of protocol best 1150 efforts. To handle such scenarios, a DOTS client operator may 1151 configure the signaling session to trigger mitigation when the DOTS 1152 server ceases receiving DOTS client signals (or vice versa) beyond 1153 the miss count or period permitted by the protocol. 1155 The impact of mitigating due to loss of signal in either direction 1156 must be considered carefully before enabling it. Signal loss is not 1157 caused by links congested with attack traffic alone, and as such 1158 mitigation requests triggered by signal channel degradation in either 1159 direction may incur unnecessary costs, in network performance and 1160 operational expense alike. 1162 4. Security Considerations 1164 This section describes identified security considerations for the 1165 DOTS architecture. 1167 DOTS is at risk from three primary attack vectors: agent 1168 impersonation, traffic injection and signal blocking. These vectors 1169 may be exploited individually or in concert by an attacker to 1170 confuse, disable, take information from, or otherwise inhibit DOTS 1171 agents. 1173 Any attacker with the ability to impersonate a legitimate client or 1174 server or, indeed, inject false messages into the stream may 1175 potentially trigger/withdraw traffic redirection, trigger/cancel 1176 mitigation activities or subvert black/whitelists. From an 1177 architectural standpoint, operators SHOULD ensure best current 1178 practices for secure communication are observed for data and signal 1179 channel confidentiality, integrity and authenticity. Care must be 1180 taken to ensure transmission is protected by appropriately secure 1181 means, reducing attack surface by exposing only the minimal required 1182 services or interfaces. Similarly, received data at rest SHOULD be 1183 stored with a satisfactory degree of security. 1185 As many mitigation systems employ diversion to scrub attack traffic, 1186 operators of DOTS agents SHOULD ensure signaling sessions are 1187 resistant to Man-in-the-Middle (MitM) attacks. An attacker with 1188 control of a DOTS client may negatively influence network traffic by 1189 requesting and withdrawing requests for mitigation for particular 1190 prefixes, leading to route or DNS flapping. 1192 Any attack targeting the availability of DOTS servers may disrupt the 1193 ability of the system to receive and process DOTS signals resulting 1194 in failure to fulfill a mitigation request. DOTS agents SHOULD be 1195 given adequate protections, again in accordance with best current 1196 practices for network and host security. 1198 5. Acknowledgments 1200 Thanks to Matt Richardson and Med Boucadair for their comments and 1201 suggestions. 1203 6. Change Log 1205 2016-03-18 Initial revision 1207 7. References 1209 7.1. Normative References 1211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1212 Requirement Levels", BCP 14, RFC 2119, 1213 DOI 10.17487/RFC2119, March 1997, 1214 . 1216 7.2. Informative References 1218 [I-D.ietf-dots-requirements] 1219 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1220 Denial of Service (DDoS) Open Threat Signaling 1221 Requirements", draft-ietf-dots-requirements-02 (work in 1222 progress), July 2016. 1224 [I-D.ietf-dots-use-cases] 1225 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 1226 Teague, N., and L. Xia, "Use cases for DDoS Open Threat 1227 Signaling", draft-ietf-dots-use-cases-01 (work in 1228 progress), March 2016. 1230 [I-D.ietf-dprive-dnsodtls] 1231 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 1232 over Datagram Transport Layer Security (DTLS)", draft- 1233 ietf-dprive-dnsodtls-12 (work in progress), September 1234 2016. 1236 [I-D.ietf-tls-tls13] 1237 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1238 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 1239 October 2016. 1241 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1242 DOI 10.17487/RFC0768, August 1980, 1243 . 1245 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1246 RFC 793, DOI 10.17487/RFC0793, September 1981, 1247 . 1249 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1250 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1251 . 1253 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1254 specifying the location of services (DNS SRV)", RFC 2782, 1255 DOI 10.17487/RFC2782, February 2000, 1256 . 1258 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1259 A., Peterson, J., Sparks, R., Handley, M., and E. 1260 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1261 DOI 10.17487/RFC3261, June 2002, 1262 . 1264 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1265 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1266 DOI 10.17487/RFC4271, January 2006, 1267 . 1269 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1270 Denial-of-Service Considerations", RFC 4732, 1271 DOI 10.17487/RFC4732, December 2006, 1272 . 1274 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1275 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1276 December 2006, . 1278 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1279 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1280 . 1282 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1283 Initiation Protocol (SIP) Back-to-Back User Agents", 1284 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1285 . 1287 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1288 "Architectural Considerations of IP Anycast", RFC 7094, 1289 DOI 10.17487/RFC7094, January 2014, 1290 . 1292 Authors' Addresses 1294 Andrew Mortensen 1295 Arbor Networks, Inc. 1296 2727 S. State St 1297 Ann Arbor, MI 48104 1298 United States 1300 EMail: amortensen@arbor.net 1301 Flemming Andreasen 1302 Cisco Systems, Inc. 1303 United States 1305 EMail: fandreas@cisco.com 1307 Tirumaleswar Reddy 1308 Cisco Systems, Inc. 1309 Cessna Business Park, Varthur Hobli 1310 Sarjapur Marathalli Outer Ring Road 1311 Bangalore, Karnataka 560103 1312 India 1314 EMail: tireddy@cisco.com 1316 Christopher Gray 1317 Comcast, Inc. 1318 United States 1320 EMail: Christopher_Gray3@cable.comcast.com 1322 Rich Compton 1323 Charter Communications, Inc. 1325 EMail: Rich.Compton@charter.com 1327 Nik Teague 1328 Verisign, Inc. 1329 United States 1331 EMail: nteague@verisign.com