idnits 2.17.1 draft-mortensen-dots-architecture-00.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 == Line 395 has weird spacing: '...om/.org exam...' -- The document date (March 19, 2016) is 2959 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-00 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 4 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: September 20, 2016 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 March 19, 2016 15 Distributed-Denial-of-Service (DDoS) Open Threat Signaling Architecture 16 draft-mortensen-dots-architecture-00 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 networks. The document makes no 23 attempt to suggest protocols or protocol extensions, instead focusing 24 on architectural relationships, components and concepts used in a 25 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 September 20, 2016. 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 . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . 7 69 2.2. DOTS Agent Relationships . . . . . . . . . . . . . . . . 9 70 3. Components . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 3.1. DOTS client . . . . . . . . . . . . . . . . . . . . . . . 13 72 3.2. DOTS server . . . . . . . . . . . . . . . . . . . . . . . 14 73 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 15 75 4.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 15 76 4.1.2. Establishing the Signaling Session . . . . . . . . . 15 77 4.1.3. Maintaining the Signaling Session . . . . . . . . . . 16 78 4.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 17 79 4.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 17 80 4.2.2. Relayed Signaling . . . . . . . . . . . . . . . . . . 17 81 4.2.3. Redirected Signaling . . . . . . . . . . . . . . . . 18 82 4.2.4. Recursive Signaling . . . . . . . . . . . . . . . . . 19 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 84 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 85 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 8.2. Informative References . . . . . . . . . . . . . . . . . 23 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Context and Motivation 93 Signaling the need for help defending against an active distributed 94 denial of service (DDoS) attack requires a common understanding of 95 mechanisms and roles among the parties coordinating attack response. 96 The proposed signaling layer and supplementary messaging is the focus 97 of DDoS Open Threat Signaling (DOTS). DOTS proposes to standardize a 98 method of coordinating defensive measures among willing peers to 99 mitigate attacks quickly and efficiently. 101 This document describes an architecture used in establishing, 102 maintaining or terminating a DOTS relationship in a network or 103 between networks. DOTS enables hybrid attack responses, coordinated 104 locally at or near the target of an active attack, as well as closer 105 to attack sources in the network path. 107 1.1. Terminology 109 1.1.1. Key Words 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 1.1.2. Definition of Terms 117 This document uses the terms defined in [I-D.ietf-dots-requirements]. 119 1.2. Scope 121 This document defines an architecture for the proposed DOTS standard 122 in the IETF. 124 In this architecture, DOTS clients and servers communicate using the 125 signaling mechanism established in the proposed DOTS standard. As a 126 result of signals from a DOTS client, the DOTS server may modify the 127 network path of traffic destined for the attack target or targets, 128 for example by diverting traffic to a scrubbing center. Packets 129 deemed part of an active attack may be dropped. 131 The architecture presented here is assumed to be applicable across 132 network administrative domains - for example, between an enterprise 133 domain and the domain of a third-party attack scrubbing service - as 134 well as to a single administrative domain. DOTS is generally assumed 135 to be most effective when aiding coordination of attack response 136 between two or more participating network domains, but single domain 137 scenarios are valuable in their own right, as when aggregating intra- 138 domain DOTS client signals for inter-domain coordinated attack 139 response. 141 1.3. Assumptions 143 This document makes the following assumptions: 145 o The network or networks in which DOTS is deployed are assumed to 146 offer the required connectivity between DOTS agents and any 147 intermediary network elements, but the architecture imposes no 148 additional limitations on the form of connectivity. 150 o Congestion and resource exhaustion are intended outcomes of a DDoS 151 attack [RFC4732]. Some operators may utilize non-impacted paths 152 or networks for DOTS, however, it should be assumed that, in 153 general, conditions will be hostile and that DOTS must be able to 154 function in all circumstances, including when the signaling path 155 is significantly impaired. 157 o There is no universal DDoS attack scale threshold triggering a 158 coordinated response across network administrative domains. A 159 network domain administrator, or service or application owner may 160 arbitrarily set attack scale threshold triggers, or manually send 161 requests for mitigation. 163 o The mitigation capacity and/or capability of networks receiving 164 requests for coordinated attack response is opaque to the network 165 sending the request. The entity receiving the DOTS client signal 166 may or may not have sufficient capacity or capability to filter 167 any or all DDoS attack traffic directed at a target. 169 o DOTS client and server signals, as well as messages sent through 170 the data channel, are sent across any transit networks with the 171 same probability of delivery as any other traffic between the DOTS 172 client network and the DOTS server network. Any encapsulation 173 required for successful delivery is left untouched by transit 174 network elements. DOTS server and DOTS client cannot assume any 175 preferential treatment of DOTS signals. 177 o The architecture allows for, but does not assume, the presence of 178 Quality of Service (QoS) policy agreements between DOTS-enabled 179 peer networks or local QoS prioritization aimed at ensuring 180 delivery of DOTS messages between DOTS agents. QoS is an 181 operational consideration only, not a functional part of a DOTS 182 architecture. 184 o There is no assumption that the signal channel and the data 185 channel should terminate on the same DOTS server: they may be 186 loosely coupled. 188 2. Architecture 190 DOTS enables a target that is under a Distributed Denial-of-Service 191 (DDoS) attack to signal another entity for help in mitigating the 192 DDoS attack. The basic high-level DOTS architecture is illustrated 193 in Figure 1: 195 +-----------+ +-------------+ 196 | Mitigator | ~~~~~~~~~~ | DOTS Server | 197 +-----------+ +-------------+ 198 | | 199 | | 200 | | 201 | +------------+ 202 | | DOTS Relay | 203 | +------------+ 204 | | 205 | | 206 | | 207 +---------------+ +-------------+ 208 | Attack Target | ~~~~~~~ | DOTS Client | 209 +---------------+ +-------------+ 211 Figure 1: Basic DOTS Architecture 213 A simple example instantiation of the DOTS architecture could be an 214 enterprise as the attack target for a volumetric DDoS attack, and an 215 upstream DDoS mitigation service as the Mitigator. The enterprise 216 (attack target) is connected to the Internet via a link that is 217 getting saturated, and the enterprise suspects it is under DDoS 218 attack. The enterprise has a DOTS client, which obtains information 219 about the DDoS attack, and signals the DOTS server for help in 220 mitigating the attack. The communication may be direct from the DOTS 221 client to the DOTS Server, or it may traverse one or more DOTS 222 Relays, which act as intermediaries. The DOTS Server in turn invokes 223 one or more mitigators, which are tasked with mitigating the actual 224 DDoS attack, and hence aim to suppress the attack traffic while 225 allowing valid traffic to reach the attack target. 227 The scope of the DOTS specifications is the interfaces between the 228 DOTS client, DOTS server, and DOTS relay. The interfaces to the 229 attack target and the mitigator are out of scope of DOTS. Similarly, 230 the operation of both the attack target and the mitigator are out of 231 scope of DOTS. Thus, DOTS neither specifies how an attack target 232 decides it is under DDoS attack, nor does DOTS specify how a 233 mitigator may actually mitigate such an attack. Indeed, a DOTS 234 client's request for mitigation is advisory in nature, and may not 235 lead to any mitigation at all, depending on the DOTS server entity's 236 capacity and willingness to mitigate on behalf of the DOTS client's 237 entity. 239 As illustrated in Figure 2, there are two interfaces between the DOTS 240 Server and the DOTS Client (and possibly the DOTS Relay): 242 +---------------+ +---------------+ 243 | | <------- Signal Channel ------> | | 244 | DOTS Client | | DOTS Server | 245 | | <======= Data Channel ======> | | 246 +---------------+ +---------------+ 248 Figure 2: DOTS Interfaces 250 The primary purpose of the signal channel is for the DOTS client to 251 ask the DOTS server for help in mitigating an attack, and for the 252 DOTS server to inform the DOTS client about the status of such 253 mitigation. The DOTS client does this by sending a client signal, 254 which contains information about the attack target or targets. The 255 client signal may also include telemetry information about the 256 attack, if the DOTS client has such information available. The DOTS 257 Server in turn sends a server signal to inform the DOTS client of 258 whether it will honor the mitigation request. Assuming it will, the 259 DOTS Server initiates attack mitigation (by means outside of DOTS), 260 and periodically informs the DOTS client about the status of the 261 mitigation. Similarly, the DOTS client periodically informs the DOTS 262 server about the client's status, which at a minimum provides client 263 (attack target) health information, but it may also include telemetry 264 information about the attack as it is now seen by the client. At 265 some point, the DOTS client may decide to terminate the server-side 266 attack mitigation, which it indicates to the DOTS server over the 267 signal channel. A mitigation may also be terminated if a DOTS 268 client-specified mitigation time limit is exceeded; additional 269 considerations around mitigation time limits may be found below. 270 Note that the signal channel may need to operate over a link that is 271 experiencing a DDoS attack and hence is subject to severe packet loss 272 and high latency. 274 While DOTS is able to request mitigation with just the signal 275 channel, the addition of the DOTS data channel provides for 276 additional and more efficient capabilities; both channels are 277 required in the DOTS architecture. The primary purpose of the data 278 channel is to support DOTS related configuration and policy 279 information exchange between the DOTS client and the DOTS server. 280 Examples of such information include 281 o Defining names or aliases for attack targets (resources). Those 282 names can be used in subsequent signal channel exchanges to more 283 efficiently refer to the resources (attack targets) in question. 285 o Black-list management, which enables a DOTS client to inform the 286 DOTS server about sources to suppress. 288 o White-list management, which enables a DOTS client to inform the 289 DOTS server about sources from which traffic should always be 290 accepted. 292 o DOTS client provisioning. 294 o Vendor-specific extensions, supplementing or in some other way 295 facilitating mitigation when the mitigator relies on particular 296 proprietary interfaces. 298 Note that while it is possible to exchange the above information 299 before, during or after a DDoS attack, DOTS requires reliable 300 delivery of the above information and does not provide any special 301 means for ensuring timely delivery of it during an attack. In 302 practice, this means that DOTS entities SHOULD NOT rely on such 303 information being exchanged during a DDoS attack. 305 2.1. DOTS Operations 307 The scope of DOTS is focused on the signaling and data exchange 308 between the DOTS client, DOTS server and (possibly) the DOTS relay. 309 DOTS does not prescribe any specific deployment models, however DOTS 310 is designed with some specific requirements around the different DOTS 311 agents and their relationships. 313 First of all, a DOTS agent belongs to an entity, and that entity has 314 an identity which can be authenticated. DOTS agents communicate with 315 each other over a mutually authenticated signal channel and bulk data 316 channel. However, before they can do so, a service relationship 317 needs to be established between them. The details and means by which 318 this is done is outside the scope of DOTS, however an example would 319 be for an enterprise A (DOTS client) to sign up for DDoS service from 320 provider B (DOTS server). This would establish a (service) 321 relationship between the two that enables enterprise A's DOTS client 322 to establish a signal channel with provider B's DOTS server. A and B 323 will authenticate each other, and B can verify that A is authorized 324 for its service. A and B may each have one or more DOTS relays in 325 front of their DOTS client and DOTS server. 327 [[EDITOR'S NOTE: we request working group feedback and discussion of 328 considerations of end-to-end signaling and agent authentication/ 329 authorization with relays in the signaling path.]] 331 From an operational and design point of view, DOTS assumes that the 332 above relationship is established prior to a request for DDoS attack 333 mitigation. In particular, it is assumed that bi-directional 334 communication is possible at this time between the DOTS client and 335 DOTS server. Furthermore, it as assumed that additional service 336 provisioning, configuration and information exchange can be performed 337 by use of the data channel, if operationally required. It is not 338 until this point that the mitigation service is available for use. 340 Once the mutually authenticated signal channel has been established, 341 it will remain in place. This is done to increase the likelihood 342 that the DOTS client can signal the DOTS server for help when the 343 attack target is being flooded, and similarly raise the probability 344 that DOTS server signals reach the client regardless of inbound link 345 congestion. This does not necessarily imply that the attack target 346 and the DOTS client have to be co-located in the same administrative 347 domain, but it is expected to be a common scenario. 349 DDoS mitigation service with the help of an upstream mitigator will 350 often involve some form of traffic redirection whereby traffic 351 destined for the attack target is diverted towards the mitigator, 352 e.g. by use of BGP [RFC4271] or DNS [RFC1034]. The mitigator in turn 353 inspects and scrubs the traffic, and forwards the resulting 354 (hopefully non-attack) traffic to the attack target, e.g. via a GRE 355 tunnel. Thus, when a DOTS server receives an attack mitigation 356 request from a DOTS client, it can be viewed as a way of causing 357 traffic redirection for the attack target indicated. Note that DOTS 358 does not consider any authorization aspects around who should be 359 allowed to issue such requests for what attack targets. Instead, 360 DOTS merely relies on the mutual authentication and the pre- 361 established (service) relationship between the entity owning the DOTS 362 client and the entity owning the DOTS server. The entity owning the 363 DOTS server SHOULD limit the attack targets that a particular DOTS 364 client can request mitigation for as part of establishing this 365 relationship. The method of such limitation is not in scope for this 366 document. 368 Although co-location of DOTS server and mitigator within the same 369 entity is expected to be a common deployment model, it is assumed 370 that operators may require alternative models. Nothing in this 371 document precludes such alternatives. 373 2.2. DOTS Agent Relationships 375 So far, we have only considered a relatively simple scenario of a 376 single DOTS client associated with a single DOTS server, however DOTS 377 supports more advanced relationships. 379 A DOTS server may be associated with one or more DOTS clients, and 380 those DOTS clients may belong to different entities. An example 381 scenario is a mitigation provider serving multiple attack targets 382 (Figure 3): 384 +---+ 385 | c |----------- 386 +---+ \ 387 \ 388 +---+ \ +---+ 389 | c |---------------| S | 390 +---+ / +---+ 391 / 392 +---+ / 393 | c |----------- 394 +---+ 395 example.com/.org example.net 396 DOTS Clients DOTS Server 398 Figure 3: Multiple DOTS clients for a DOTS server 400 A DOTS client may be associated with one or more DOTS servers, and 401 those DOTS servers may belong to different entities. This may be to 402 ensure high availability or co-ordinate mitigation with more than one 403 directly connected ISP. An example scenario is for an enterprise to 404 have DDoS mitigation service from multiple providers, as shown in 405 Figure 4 below. Operational considerations relating to co-ordinating 406 multiple provider responses are beyond the scope of DOTS. 408 [[EDITOR'S NOTE: we request working group feedback and discussion of 409 operational considerations relating to coordinating multiple provider 410 responses to a mitigation request.]] 411 +---+ 412 ------------| S | 413 / +---+ 414 / 415 +---+/ +---+ 416 | c |---------------| S | 417 +---+\ +---+ 418 \ 419 \ +---+ 420 ------------| S | 421 +---+ 422 example.com example.net/.org 423 DOTS Client DOTS Servers 425 Figure 4: Multi-Homed DOTS Client 427 DOTS Relays may be either server-side or client-side, or both. A 428 DOTS server-side relay belongs to the entity owning the DOTS server. 429 A relay will terminate multiple discrete client connections as if it 430 were a server and may aggregate these into a single (Figure 5) or 431 multiple DOTS signaling sessions (Figure 6) depending upon locally 432 applied policy. A relay will function as a server to its downstream 433 agents and as a client to its upstream agents. Aside from the 434 exceptions discussed in Section 4.2.2 below, the relationship between 435 the relay and its upstream agents is opaque to the relayed clients. 436 An example scenario is for an enterprise to have deployed multiple 437 DOTS capable devices which are able to signal intra-domain using TCP 438 [RFC0793] on un-congested links to a relay which may then transform 439 these to a UDP [RFC0768] transport inter-domain where connection 440 oriented transports may degrade; this applies to the signal channel 441 only, as the data channel requires a connection-oriented transport. 442 The relationship between the relay and its upstream agents is opaque 443 to the relayed clients. 445 +---+ 446 | c |\ 447 +---+ \ +---+ 448 \-----TCP-----| r | +---+ 449 +---+ | e | | | 450 | c |--------TCP-----| l |------UDP-----| S | 451 +---+ | a | | | 452 /-----TCP-----| y | +---+ 453 +---+ / +---+ 454 | c |/ 455 +---+ 456 example.com example.com example.net 457 DOTS Clients DOTS Relay DOTS Server 459 Figure 5: Client-Side Relay with Aggregation 461 +---+ 462 | c |\ 463 +---+ \ +---+ 464 \-----TCP-----| r |------UDP-----+---+ 465 +---+ | e | | | 466 | c |--------TCP-----| l |------UDP-----| S | 467 +---+ | a | | | 468 /-----TCP-----| y |------UDP-----+---+ 469 +---+ / +---+ 470 | c |/ 471 +---+ 472 example.com example.com example.net 473 DOTS Clients DOTS Relay DOTS Server 475 Figure 6: Client-Side Relay without Aggregation 477 A variation of this scenario would be a DDoS mitigation provider 478 deploying relays at their perimeter to consume signals across 479 multiple transports and to consolidate these into a single transport 480 suitable for the providers deployment, as shown in Figure 7 and 481 Figure 8 below. The relationship between the relay and its upstream 482 agents is opaque to the relayed clients. 484 [[EDITOR'S NOTE: we request working group feedback and discussion of 485 DOTS client visibility into relayed signaling.]] 486 +---+ 487 | c |\ 488 +---+ \ +---+ 489 \-----UDP-----| r | +---+ 490 +---+ | e | | | 491 | c |--------TCP-----| l |------TCP-----| S | 492 +---+ | a | | | 493 /-----TCP-----| y | +---+ 494 +---+ / +---+ 495 | c |/ 496 +---+ 497 example.com example.net example.net 498 DOTS Clients DOTS Relay DOTS Server 500 Figure 7: Server-Side Relay with Aggregation 502 +---+ 503 | c |\ 504 +---+ \ +---+ 505 \-----UDP-----| r |------TCP-----+---+ 506 +---+ | e | | | 507 | c |--------TCP-----| l |------TCP-----| S | 508 +---+ | a | | | 509 /-----UDP-----| y |------TCP-----+---+ 510 +---+ / +---+ 511 | c |/ 512 +---+ 513 example.com example.net example.net 514 DOTS Clients DOTS Relay DOTS Server 516 Figure 8: Server-Side Relay without Aggregation 518 In the context of relays, sessions are established directly between 519 peer DOTS agents and may not be end-to-end. In spite of this 520 distinction a method must exist to uniquely identify the originating 521 DOTS client. The relay should identify itself as such to any clients 522 or servers it interacts with. Greater abstraction by way of 523 additional layers of relays may introduce undesired complexity in 524 regard to authentication and authorization and should be avoided. 526 [[EDITOR'S NOTE: we request working group feedback and discussion of 527 the many-to-one and one-to-many client/server, client/relay, and 528 relay/server relationships described above. We additionally request 529 working group feedback and discussion of end-to-end signaling 530 considerations in the context of relayed signaling.]] 532 3. Components 534 The architecture in this document is comprised of a few basic 535 components on top of the assumed underlay network or networks 536 described above. When connected to one another, the components 537 represent an operational DOTS architecture. 539 This section describes the components themselves. Section 4 below 540 describes the architectural concepts involved. 542 3.1. DOTS client 544 A DOTS client is a DOTS agent from which requests for help 545 coordinating attack response originate. The requests may be in 546 response to an active, ongoing attack against a target in the DOTS 547 client's domain, but no active attack is required for a DOTS client 548 to request help. Local operators may wish to have upstream traffic 549 scrubbers in the network path for an indefinite period, and are 550 restricted only by business relationships when it comes to duration 551 and scope of requested mitigation. 553 The DOTS client requests attack response coordination from a DOTS 554 server over the signal channel, including in the request the DOTS 555 client's desired mitigation scoping, as described in 556 [I-D.ietf-dots-requirements]. The actual mitigation scope and 557 countermeasures used in response to the attack are up to the DOTS 558 server and Mitigator operators, as the DOTS client may have a narrow 559 perspective on the ongoing attack. As such, the DOTS client's 560 request for mitigation should be considered advisory: guarantees of 561 DOTS server availability or mitigation capacity constitute service 562 level agreements and are out of scope for this document. 564 The DOTS client adjusts mitigation scope and provides available 565 attack details at the direction of its local operator. Such 566 direction may involve manual or automated adjustments in response to 567 feedback from the DOTS server. 569 To provide a metric of signal health and distinguish an idle 570 signaling session from a disconnected or defunct session, the DOTS 571 client sends a heartbeat over the signal channel to maintain its half 572 of the signaling session. The DOTS client similarly expects a 573 heartbeat from the DOTS server, and MAY consider a signaling session 574 terminated in the extended absence of a DOTS server heartbeat. 576 3.2. DOTS server 578 A DOTS server is a DOTS agent capable of receiving, processing and 579 possibly acting on requests for help coordinating attack response 580 from one or more DOTS clients. The DOTS server authenticates and 581 authorizes DOTS clients as described in Signaling Sessions below, and 582 maintains signaling session state, tracking requests for mitigation, 583 reporting on the status of active mitigations, and terminating 584 signaling sessions in the extended absence of a client heartbeat or 585 when a session times out. 587 Assuming the preconditions discussed below exist, a DOTS client 588 maintaining an active signaling session with a DOTS server may 589 reasonably expect some level of mitigation in response to a request 590 for coordinated attack response. 592 The DOTS server enforces authorization of DOTS clients' signals for 593 mitigation. The mechanism of enforcement is not in scope for this 594 document, but is expected to restrict requested mitigation scope to 595 addresses, prefixes, and/or services owned by the DOTS client's 596 administrative entity, such that a DOTS client from one entity is not 597 able to influence the network path to another entity. A DOTS server 598 MUST reject requests for mitigation of resources not owned by the 599 requesting DOTS client's administrative entity. A DOTS server MAY 600 also refuse a DOTS client's mitigation request for arbitrary reasons, 601 within any limits imposed by business or service level agreements 602 between client and server domains. If a DOTS server refuses a DOTS 603 client's request for mitigation, the DOTS server SHOULD include the 604 refusal reason in the server signal sent to the client. 606 A DOTS server is in regular contact with one or more mitigators. If 607 a DOTS server accepts a DOTS client's request for help, the DOTS 608 server forwards a translated form of that request to the mitigator or 609 mitigators responsible for scrubbing attack traffic. Note that the 610 form of the translated request passed from the DOTS server to the 611 mitigator is not in scope: it may be as simple as an alert to 612 mitigator operators, or highly automated using vendor or open 613 application programming interfaces supported by the mitigator. The 614 DOTS server MUST report the actual scope of any mitigation enabled on 615 behalf of a client. 617 The DOTS server SHOULD retrieve available metrics for any mitigations 618 activated on behalf of a DOTS client, and SHOULD include them in 619 server signals sent to the DOTS client originating the request for 620 mitigation. 622 To provide a metric of signal health and distinguish an idle 623 signaling session from a disconnected or defunct session, the DOTS 624 server sends a heartbeat over the signal channel to maintain its half 625 of the signaling session. The DOTS server similarly expects a 626 heartbeat from the DOTS client, and MAY consider a signaling session 627 terminated in the extended absence of a DOTS client heartbeat. 629 4. Concepts 631 4.1. Signaling Sessions 633 In order for DOTS to be effective as a vehicle for DDoS mitigation 634 requests, one or more DOTS clients must establish ongoing 635 communication with one or more DOTS servers. While the preconditions 636 for enabling DOTS in or among network domains may also involve 637 business relationships, service level agreements, or other formal or 638 informal understandings between network operators, such 639 considerations are out of scope for this document. 641 An established communication layer between DOTS agents is a Signaling 642 Session. At its most basic, for a DOTS signaling session to exist 643 both signal channel and data channel must be functioning between DOTS 644 agents. That is, under nominal network conditions, signals actively 645 sent from a DOTS client are received by the specific DOTS server 646 intended by the client, and vice versa. 648 4.1.1. Preconditions 650 Prior to establishing a signaling session between agents, the owners 651 of the networks, domains, services or applications involved are 652 assumed to have agreed upon the terms of the relationship involved. 653 Such agreements are out of scope for this document, but must be in 654 place for a functional DOTS architecture. 656 It is assumed that as part of any DOTS service agreement, the DOTS 657 client is provided with all data and metadata required to establish 658 communication with the DOTS server. Such data and metadata would 659 include any cryptographic information necessary to meet the message 660 confidentiality, integrity and authenticity requirement in 661 [I-D.ietf-dots-requirements], and might also include the pool of DOTS 662 server addresses and ports the DOTS client should use for signal and 663 data channel messaging. 665 4.1.2. Establishing the Signaling Session 667 With the required business or service agreements in place, the DOTS 668 client initiates a signal session by contacting the DOTS server over 669 the signal channel and the data channel. To allow for DOTS service 670 flexibility, neither the order of contact nor the time interval 671 between channel creations is specified. A DOTS client MAY establish 672 signal channel first, and then data channel, or vice versa. 674 The methods by which a DOTS client receives the address and 675 associated service details of the DOTS server are not prescribed by 676 this document. For example, a DOTS client may be directly configured 677 to use a specific DOTS server address and port, and directly provided 678 with any data necessary to satisfy the Peer Mutual Authentication 679 requirement in [I-D.ietf-dots-requirements], such as symmetric or 680 asymmetric keys, usernames and passwords, etc. All configuration and 681 authentication information in this scenario is provided out-of-band 682 by the entity operating the DOTS server. 684 At the other extreme, the architecture in this document allows for a 685 form of DOTS client auto-provisioning. For example, the entity 686 operating the DOTS server or servers might provide the client entity 687 only with symmetric or asymmetric keys to authenticate the 688 provisioned DOTS clients. Only the keys would then be directly 689 configured on DOTS clients, but the remaining configuration required 690 to provision the DOTS clients could be learned through mechanisms 691 similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. 693 The DOTS client SHOULD successfully authenticate and exchange 694 messages with the DOTS server over both signal and data channel as 695 soon as possible to confirm that both channels are operational. 697 Once the DOTS client begins receiving DOTS server signals, the 698 signaling session is active. At any time during the signaling 699 session, the DOTS client MAY use the data channel to adjust initial 700 configuration, manage black- and white-listed prefixes or addresses, 701 leverage vendor-specific extensions, and so on. Note that unlike the 702 signal channel, there is no requirement that the data channel remain 703 operational in attack conditions (See Data Channel Requirements, 704 [I-D.ietf-dots-requirements]). 706 4.1.3. Maintaining the Signaling Session 708 DOTS clients, servers and relays periodically send heartbeats to each 709 other over the signal channel, per Operational Requirements discussed 710 in [I-D.ietf-dots-requirements]. DOTS agent operators SHOULD 711 configure the heartbeat interval such that the frequency does not 712 lead to accidental denials of service due to the overwhelming number 713 of heartbeats a DOTS agent must field. 715 Either DOTS agent may consider a signaling session terminated in the 716 extended absence of a heartbeat from its peer agent. The period of 717 that absence will be established in the protocol definition. 719 4.2. Modes of Signaling 721 This section examines the modes of signaling between agents in a DOTS 722 architecture. 724 4.2.1. Direct Signaling 726 A signaling session may take the form of direct signaling between the 727 DOTS clients and servers, as shown in Figure 9 below: 729 +-------------+ +-------------+ 730 | DOTS client |<------signal session------>| DOTS server | 731 +-------------+ +-------------+ 733 Figure 9: Direct Signaling 735 In a direct signaling session, DOTS client and server are 736 communicating directly, with no relays in the signaling path. A 737 direct signaling session MAY exist inter- or intra-domain. The 738 signaling session is abstracted from the underlying networks or 739 network elements the signals traverse: in a direct signaling session, 740 the DOTS client and server are logically peer DOTS agents. 742 4.2.2. Relayed Signaling 744 A signaling session may also include one or more DOTS relays in the 745 signaling path between the clients and servers, as shown in 746 Figure 10: 748 +-------------+ +-------------+ 749 | DOTS client | | DOTS server | 750 +-------------+ +-------------+ 751 ^ ^ 752 | +------------+ +------------+ | 753 +--->| DOTS relay |<----->| DOTS relay |<---+ 754 +------------+ +------------+ 756 Figure 10: Relayed Signaling 758 To allow for maximum architectural flexibility, no restriction is 759 placed on the number of relays in the signaling path. Operators of 760 DOTS agents should consider the impact on signal latency incurred by 761 each additional DOTS relay in the signaling path, as well as the 762 increased operational complexity, when deploying DOTS relays. 764 [[EDITOR'S NOTE: we request working group feedback and discussion of 765 operational considerations related to DOTS relays, particularly with 766 respect to the implications of multiple relays in the signal path.]] 767 As discussed above in Section 2.2, relays may be client-side or 768 server-side. In either case, the relay appears to the peer agent as 769 its logical opposite. That is, a DOTS relay appears to a DOTS client 770 or downstream relay as a DOTS server. Conversely, a DOTS relay 771 appears to a DOTS server or upstream DOTS relay as a DOTS client. 772 Thus relayed signaling may be thought of as chained direct signaling 773 sessions. 775 4.2.3. Redirected Signaling 777 In certain circumstances, a DOTS server may want to redirect a DOTS 778 client to an alternative DOTS server for a signaling session. Such 779 circumstances include but are not limited to: 781 o Maximum number of signaling sessions with clients has been 782 reached; 784 o Mitigation capacity exhaustion in the Mitigator with which the 785 specific DOTS server is communicating; 787 o Mitigator outage or other downtime, such as scheduled maintenance; 789 o Scheduled DOTS server maintenance; 791 o Scheduled modifications to the network path between DOTS server 792 and DOTS client. 794 A basic redirected signaling session resembles the following, as 795 shown in Figure 11: 797 +-------------+ +---------------+ 798 | |<-(1)-- signal session 1 -->| | 799 | | | | 800 | |<=(2)== redirect to B ======| | 801 | DOTS client | | DOTS server A | 802 | |X-(4)-- signal session 1 --X| | 803 | | | | 804 | | | | 805 +-------------+ +---------------+ 806 ^ 807 | 808 (3) signal session 2 809 | 810 v 811 +---------------+ 812 | DOTS server B | 813 +---------------+ 815 Figure 11: Redirected Signaling 817 1. Previously established signaling session 1 exists between a DOTS 818 client and DOTS server with address A. 820 2. DOTS server A sends a server signal redirecting the client to 821 DOTS server B. 823 3. If the DOTS client does not already have a separate signaling 824 session with the redirection target, the DOTS client initiates 825 and establishes a signaling session with DOTS server B as 826 described above. 828 4. Having redirected the DOTS client, DOTS server A ceases sending 829 server signals. The DOTS client likewise stops sending client 830 signals to DOTS server A. Signal session 1 is terminated. 832 [[EDITOR'S NOTE: we request working group feedback and discussion of 833 the need for redirected signaling.]] 835 4.2.4. Recursive Signaling 837 DOTS is centered around improving the speed and efficiency of 838 coordinated response to DDoS attacks. One scenario not yet discussed 839 involves coordination among federated entities operating DOTS servers 840 and mitigators. 842 In the course of normal DOTS operations, a DOTS client communicates 843 the need for mitigation to a DOTS server, and that server initiates 844 mitigation on a mitigator with which the server has an established 845 service relationship. The operator of the mitigator may in turn 846 monitor mitigation performance and capacity, as the attack being 847 mitigated may grow in severity beyond the mitigating entity's 848 capabilities. 850 The operator of the mitigator has limited options in the event a DOTS 851 client-requested mitigation is being overwhelmed by the severity of 852 the attack. Out-of-scope business or service level agreements may 853 permit the mitigating entity to drop the mitigation and let attack 854 traffic flow unchecked to the target, but this is only encourages 855 attack escalation. In the case where the mitigating entity is the 856 upstream service provider for the attack target, this may mean the 857 mitigating entity and its other services and users continue to suffer 858 the incidental effects of the attack. 860 A recursive signaling model as shown in Figure 12 below offers an 861 alternative. In a variation of the primary use case "Successful 862 Automatic or Operator-Assisted CPE or PE Mitigators Request Upstream 863 DDoS Mitigation Services" described in [I-D.ietf-dots-use-cases], an 864 entity operating a DOTS server and mitigation has a mitigator that is 865 itself capable of acting as a DOTS client. The mitigator with DOTS 866 client capabilities has an established signaling session with a DOTS 867 server belonging to a separate administrative entity. 869 With these preconditions in place, the operator of the mitigator 870 being overwhelmed or otherwise performing inadequately may request 871 mitigation for the attack target from this separate DOTS-aware 872 entity. Such a request recurses the originating mitigation request 873 to the secondary DOTS server, in the hope of building a cumulative 874 mitigation against the attack: 876 example.net entity 877 . . . . . . . . . . . . . . . . . 878 . . 879 +----+ A . +----+ +-----------+ . 880 | Cc |<--------->| Sn |~~~~~~~| Mitigator | . 881 +----+ . +----+ | Mn | . 882 . | +----+ | . 883 example.com . +---| Cn |--+ . 884 client . +----+ . 885 . ^ . 886 . . . . . . . . . . . | . . . . . 887 | 888 | B 889 | 890 . . . . . . . . . . . | . . . . . 891 . v . 892 . +-----------+ +----+ . 893 . | Mitigator |~~~~| So | . 894 . | Mo | +----+ . 895 . +-----------+ . 896 . . 897 . . . . . . . . . . . . . . . . . 898 example.org entity 900 Figure 12: Recursive Signaling 902 In Figure 12 above, client Cc signals a request for mitigation across 903 inter-domain signaling session A to the DOTS server Sn belonging to 904 the example.net entity. DOTS server Sn enables mitigation on 905 mitigator Mn, which, acting as DOTS client Cn, has pre-existing 906 inter-domain signaling session B with the DOTS server So belonging to 907 the example.org entity. At any point, DOTS client Cn MAY recurse an 908 on-going mitigation request to DOTS server So, in the expectation 909 that mitigator Mo will be activated to aid in the defense of the 910 attack target. 912 Recursive signaling is opaque to the DOTS client. To maximize 913 mitigation visibility to the DOTS client, however, the recursing 914 entity SHOULD provide recursed mitigation feedback in signals 915 reporting on mitigation status to the DOTS client. For example, the 916 recursing entity's mitigator should incorporate into mitigation 917 status messages available metrics such as dropped packet or byte 918 counts from the recursed mitigation. 920 DOTS clients involved in recursive signaling MUST be able to withdraw 921 requests for mitigation without warning or justification, per 922 [I-D.ietf-dots-requirements]. 924 Operators of recursing mitigators MAY maintain the recursed 925 mitigation for a brief, protocol-defined period in the event the DOTS 926 client originating the mitigation withdraws its request for help, as 927 per the discussion of managing mitigation toggling in the operational 928 requirements ([I-D.ietf-dots-requirements]). Service or business 929 agreements between recursing entities are not in scope for this 930 document. 932 [[EDITOR'S NOTE: Recursive signaling raises questions about how to 933 authenticate and authorize the recursed request, how end-to-end 934 signaling functions in such a scenario, and implications for 935 operational and data privacy, as well as what level of visibility a 936 client has into the recursed mitigation. We ask the working group 937 for feedback and additional discussion of these issues to help settle 938 the way forward.]] 940 5. Security Considerations 942 This section describes identified security considerations for the 943 DOTS architecture. 945 DOTS is at risk from three primary attack vectors: agent 946 impersonation, traffic injection and signal blocking. These vectors 947 may be exploited individually or in concert by an attacker to 948 confuse, disable, take information from, or otherwise inhibit the 949 DOTS system. 951 Any attacker with the ability to impersonate a legitimate client or 952 server or, indeed, inject false messages into the stream may 953 potentially trigger/withdraw traffic redirection, trigger/cancel 954 mitigation activities or subvert black/whitelists. From an 955 architectural standpoint, operators SHOULD ensure best current 956 practices for secure communication are observed for data and signal 957 channel confidentiality, integrity and authenticity. Care must be 958 taken to ensure transmission is protected by appropriately secure 959 means, reducing attack surface by exposing only the minimal required 960 services or interfaces. Similarly, received data at rest SHOULD be 961 stored with a satisfactory degree of security. 963 As many mitigation systems employ diversion to scrub attack traffic, 964 operators of DOTS agents SHOULD ensure signaling sessions are 965 resistant to Man-in-the-Middle (MitM) attacks. An attacker with 966 control of a DOTS client or relay may negatively influence network 967 traffic by requesting and withdrawing requests for mitigation for 968 particular prefixes, leading to route or DNS flapping. 970 Any attack targeting the availability of DOTS servers may disrupt the 971 ability of the system to receive and process DOTS signals resulting 972 in failure to fulfill a mitigation request. Similarly, DOTS relays 973 represent high-value targets in a DOTS architecture. Disrupting any 974 DOTS relay in a signaling path represents a denial-of-service against 975 DOTS in general. DOTS systems SHOULD be given adequate protections, 976 again, in accordance with best current practices for network and host 977 security. 979 6. Acknowledgments 981 Thanks to Matt Richardson for last minute comments and suggestions. 983 7. Change Log 985 2016-03-18 Initial revision 987 8. References 989 8.1. Normative References 991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 992 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 993 RFC2119, March 1997, 994 . 996 8.2. Informative References 998 [I-D.ietf-dots-requirements] 999 Mortensen, A., Moskowitz, R., and T. Reddy, "DDoS Open 1000 Threat Signaling Requirements", draft-ietf-dots- 1001 requirements-00 (work in progress), October 2015. 1003 [I-D.ietf-dots-use-cases] 1004 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 1005 Teague, N., and L. Xia, "Use cases for DDoS Open Threat 1006 Signaling", draft-ietf-dots-use-cases-00 (work in 1007 progress), October 2015. 1009 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 1010 10.17487/RFC0768, August 1980, 1011 . 1013 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1014 793, DOI 10.17487/RFC0793, September 1981, 1015 . 1017 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1018 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1019 . 1021 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1022 specifying the location of services (DNS SRV)", RFC 2782, 1023 DOI 10.17487/RFC2782, February 2000, 1024 . 1026 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1027 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 1028 10.17487/RFC4271, January 2006, 1029 . 1031 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1032 Denial-of-Service Considerations", RFC 4732, DOI 10.17487/ 1033 RFC4732, December 2006, 1034 . 1036 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1037 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1038 . 1040 Authors' Addresses 1042 Andrew Mortensen 1043 Arbor Networks, Inc. 1044 2727 S. State St 1045 Ann Arbor, MI 48104 1046 United States 1048 EMail: amortensen@arbor.net 1050 Flemming Andreasen 1051 Cisco Systems, Inc. 1052 United States 1054 EMail: fandreas@cisco.com 1056 Tirumaleswar Reddy 1057 Cisco Systems, Inc. 1058 Cessna Business Park, Varthur Hobli 1059 Sarjapur Marathalli Outer Ring Road 1060 Bangalore, Karnataka 560103 1061 India 1063 EMail: tireddy@cisco.com 1064 Christopher Gray 1065 Comcast, Inc. 1066 United States 1068 EMail: Christopher_Gray3@cable.comcast.com 1070 Rich Compton 1071 Charter Communications, Inc. 1073 EMail: Rich.Compton@charter.com 1075 Nik Teague 1076 Verisign, Inc. 1077 United States 1079 EMail: nteague@verisign.com