idnits 2.17.1 draft-ietf-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.) == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 05, 2016) is 2823 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-01 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-01 -- 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: January 6, 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 July 05, 2016 15 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture 16 draft-ietf-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 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 January 6, 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.3. Triggering Requests for Mitigation . . . . . . . . . . . 21 85 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 21 86 3.3.2. Automated Threshold-Based Mitigation Request . . . . 22 87 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 23 88 4. Security Considerations . . . . . . . . . . . . . . . . . . . 24 89 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 90 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 7.1. Normative References . . . . . . . . . . . . . . . . . . 25 93 7.2. Informative References . . . . . . . . . . . . . . . . . 25 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 96 1. Context and Motivation 98 Signaling the need for help defending against an active distributed 99 denial of service (DDoS) attack requires a common understanding of 100 mechanisms and roles among the parties coordinating defensive 101 response. The signaling layer and supplementary messaging is the 102 focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of 103 coordinating defensive measures among willing peers to mitigate 104 attacks quickly and efficiently, enabling hybrid attack responses 105 coordinated locally at or near the target of an active attack, or 106 anywhere in-path between attack sources and target. 108 This document describes an architecture used in establishing, 109 maintaining or terminating a DOTS relationship within a domain or 110 between domains. 112 1.1. Terminology 114 1.1.1. Key Words 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 1.1.2. Definition of Terms 122 This document uses the terms defined in [I-D.ietf-dots-requirements]. 124 1.2. Scope 126 In this architecture, DOTS clients and servers communicate using the 127 DOTS signaling. As a result of signals from a DOTS client, the DOTS 128 server may modify the forwarding path of traffic destined for the 129 attack target(s), for example by diverting traffic to a mitigator or 130 pool of mitigators, where policy may be applied to distinguish and 131 discard attack traffic. Any such policy is deployment-specific. 133 The DOTS architecture presented here is applicable across network 134 administrative domains - for example, between an enterprise domain 135 and the domain of a third-party attack mitigation service - as well 136 as to a single administrative domain. DOTS is generally assumed to 137 be most effective when aiding coordination of attack response between 138 two or more participating network domains, but single domain 139 scenarios are valuable in their own right, as when aggregating intra- 140 domain DOTS client signals for inter-domain coordinated attack 141 response. 143 This document does not address any administrative or business 144 agreements that may be established between involved DOTS parties. 145 Those considerations are out of scope. Regardless, this document 146 assumes necessary authentication and authorization mechanism are put 147 in place so that only authorized clients can invoke the DOTS service. 149 1.3. Assumptions 151 This document makes the following assumptions: 153 o All domains in which DOTS is deployed are assumed to offer the 154 required connectivity between DOTS agents and any intermediary 155 network elements, but the architecture imposes no additional 156 limitations on the form of connectivity. 158 o Congestion and resource exhaustion are intended outcomes of a DDoS 159 attack [RFC4732]. Some operators may utilize non-impacted paths 160 or networks for DOTS, but in general conditions should be assumed 161 to be hostile and that DOTS must be able to function in all 162 circumstances, including when the signaling path is significantly 163 impaired. 165 o There is no universal DDoS attack scale threshold triggering a 166 coordinated response across administrative domains. A network 167 domain administrator, or service or application owner may 168 arbitrarily set attack scale threshold triggers, or manually send 169 requests for mitigation. 171 o Mitigation requests may be sent to one or more upstream DOTS 172 servers based on criteria determined by DOTS client 173 administrators. The number of DOTS servers with which a given 174 DOTS client has established signaling sessions is determined by 175 local policy and is deployment-specific. 177 o The mitigation capacity and/or capability of domains receiving 178 requests for coordinated attack response is opaque to the domains 179 sending the request. The domain receiving the DOTS client signal 180 may or may not have sufficient capacity or capability to filter 181 any or all DDoS attack traffic directed at a target. In either 182 case, the upstream DOTS server may redirect a request to another 183 DOTS server. Redirection may be local to the redirecting DOTS 184 server's domain, or may involve a third-party domain. 186 o DOTS client and server signals, as well as messages sent through 187 the data channel, are sent across any transit networks with the 188 same probability of delivery as any other traffic between the DOTS 189 client domain and the DOTS server domain. Any encapsulation 190 required for successful delivery is left untouched by transit 191 network elements. DOTS server and DOTS client cannot assume any 192 preferential treatment of DOTS signals. Such preferential 193 treatment may be available in some deployments, and the DOTS 194 architecture does not preclude its use when available. However, 195 DOTS itself does not address how that may be done. 197 o The architecture allows for, but does not assume, the presence of 198 Quality of Service (QoS) policy agreements between DOTS-enabled 199 peer networks or local QoS prioritization aimed at ensuring 200 delivery of DOTS messages between DOTS agents. QoS is an 201 operational consideration only, not a functional part of the DOTS 202 architecture. 204 o The signal channel and the data channel may be loosely coupled, 205 and need not terminate on the same DOTS server. 207 2. Architecture 209 The basic high-level DOTS architecture is illustrated in Figure 1: 211 +-----------+ +-------------+ 212 | Mitigator | ~~~~~~~~~~ | DOTS Server | 213 +-----------+ +-------------+ 214 | 215 | 216 | 217 +---------------+ +-------------+ 218 | Attack Target | ~~~~~~ | DOTS Client | 219 +---------------+ +-------------+ 221 Figure 1: Basic DOTS Architecture 223 A simple example instantiation of the DOTS architecture could be an 224 enterprise as the attack target for a volumetric DDoS attack, and an 225 upstream DDoS mitigation service as the Mitigator. The enterprise 226 (attack target) is connected to the Internet via a link that is 227 getting saturated, and the enterprise suspects it is under DDoS 228 attack. The enterprise has a DOTS client, which obtains information 229 about the DDoS attack, and signals the DOTS server for help in 230 mitigating the attack. The DOTS server in turn invokes one or more 231 mitigators, which are tasked with mitigating the actual DDoS attack, 232 and hence aim to suppress the attack traffic while allowing valid 233 traffic to reach the attack target. 235 The scope of the DOTS specifications is the interfaces between the 236 DOTS client and DOTS server. The interfaces to the attack target and 237 the mitigator are out of scope of DOTS. Similarly, the operation of 238 both the attack target and the mitigator are out of scope of DOTS. 240 Thus, DOTS neither specifies how an attack target decides it is under 241 DDoS attack, nor does DOTS specify how a mitigator may actually 242 mitigate such an attack. A DOTS client's request for mitigation is 243 advisory in nature, and may not lead to any mitigation at all, 244 depending on the DOTS server domain's capacity and willingness to 245 mitigate on behalf of the DOTS client's domain. 247 As illustrated in Figure 2, there are two interfaces between the DOTS 248 server and the DOTS client: 250 +---------------+ +---------------+ 251 | | <------- Signal Channel ------> | | 252 | DOTS Client | | DOTS Server | 253 | | <======= Data Channel ======> | | 254 +---------------+ +---------------+ 256 Figure 2: DOTS Interfaces 258 The DOTS client may be provided with a list of DOTS servers, each 259 associated with one or more IP addresses. These addresses may or may 260 not be of the same address family. The DOTS client establishes one 261 or more signaling sessions by connecting to the provided DOTS server 262 addresses. 264 [[EDITOR'S NOTE: We request feedback from the working group about the 265 mechanism of server discovery.]] 267 The primary purpose of the signal channel is for a DOTS client to ask 268 a DOTS server for help in mitigating an attack, and for the DOTS 269 server to inform the DOTS client about the status of such mitigation. 270 The DOTS client does this by sending a client signal, which contains 271 information about the attack target or targets. The client signal 272 may also include telemetry information about the attack, if the DOTS 273 client has such information available. The DOTS server in turn sends 274 a server signal to inform the DOTS client of whether it will honor 275 the mitigation request. Assuming it will, the DOTS server initiates 276 attack mitigation (by means outside of DOTS), and periodically 277 informs the DOTS client about the status of the mitigation. 278 Similarly, the DOTS client periodically informs the DOTS server about 279 the client's status, which at a minimum provides client (attack 280 target) health information, but it may also include telemetry 281 information about the attack as it is now seen by the client. At 282 some point, the DOTS client may decide to terminate the server-side 283 attack mitigation, which it indicates to the DOTS server over the 284 signal channel. A mitigation may also be terminated if a DOTS 285 client-specified mitigation time limit is exceeded; additional 286 considerations around mitigation time limits may be found below. 287 Note that the signal channel may need to operate over a link that is 288 experiencing a DDoS attack and hence is subject to severe packet loss 289 and high latency. 291 While DOTS is able to request mitigation with just the signal 292 channel, the addition of the DOTS data channel provides for 293 additional and more efficient capabilities; both channels are 294 required in the DOTS architecture. The primary purpose of the data 295 channel is to support DOTS related configuration and policy 296 information exchange between the DOTS client and the DOTS server. 297 Examples of such information include, but are not limited to: 299 o Creating identifiers, such as names or aliases, for resources for 300 which mitigation may be requested. Such identifiers may then be 301 used in subsequent signal channel exchanges to refer more 302 efficiently to the resources under attack, as seen in Figure 3 303 below, using JSON to serialize the data: 305 { 306 "https1": [ 307 "172.16.168.254:443", 308 "172.16.169.254:443", 309 ], 310 "proxies": [ 311 "10.0.0.10:3128", 312 "[2001:db9::1/128]:3128" 313 ], 314 "api_urls": "https://apiserver.local/api/v1", 315 } 317 Figure 3: Protected resource identifiers 319 o Black-list management, which enables a DOTS client to inform the 320 DOTS server about sources to suppress. 322 o White-list management, which enables a DOTS client to inform the 323 DOTS server about sources from which traffic should always be 324 accepted. 326 o Filter management, which enables a DOTS client to install or 327 remove traffic filters dropping or rate-limiting unwanted traffic. 329 o DOTS client provisioning. 331 Note that while it is possible to exchange the above information 332 before, during or after a DDoS attack, DOTS requires reliable 333 delivery of the this information and does not provide any special 334 means for ensuring timely delivery of it during an attack. In 335 practice, this means that DOTS deployments SHOULD NOT rely on such 336 information being exchanged during a DDoS attack. 338 2.1. DOTS Operations 340 The scope of DOTS is focused on the signaling and data exchange 341 between the DOTS client and DOTS server. DOTS does not prescribe any 342 specific deployment models, however DOTS is designed with some 343 specific requirements around the different DOTS agents and their 344 relationships. 346 First of all, a DOTS agent belongs to an domain, and that domain has 347 an identity which can be authenticated and authorized. DOTS agents 348 communicate with each other over a mutually authenticated signal 349 channel and data channel. However, before they can do so, a service 350 relationship needs to be established between them. The details and 351 means by which this is done is outside the scope of DOTS, however an 352 example would be for an enterprise A (DOTS client) to sign up for 353 DDoS service from provider B (DOTS server). This would establish a 354 (service) relationship between the two that enables enterprise A's 355 DOTS client to establish a signal channel with provider B's DOTS 356 server. A and B will authenticate each other, and B can verify that 357 A is authorized for its service. 359 From an operational and design point of view, DOTS assumes that the 360 above relationship is established prior to a request for DDoS attack 361 mitigation. In particular, it is assumed that bi-directional 362 communication is possible at this time between the DOTS client and 363 DOTS server. Furthermore, it is assumed that additional service 364 provisioning, configuration and information exchange can be performed 365 by use of the data channel, if operationally required. It is not 366 until this point that the mitigation service is available for use. 368 Once the mutually authenticated signal channel has been established, 369 it will remain in place. This is done to increase the likelihood 370 that the DOTS client can signal the DOTS server for help when the 371 attack target is being flooded, and similarly raise the probability 372 that DOTS server signals reach the client regardless of inbound link 373 congestion. This does not necessarily imply that the attack target 374 and the DOTS client have to be co-located in the same administrative 375 domain, but it is expected to be a common scenario. 377 DDoS mitigation service with the help of an upstream mitigator will 378 often involve some form of traffic redirection whereby traffic 379 destined for the attack target is diverted towards the mitigator, 380 e.g. by use of BGP [RFC4271] or DNS [RFC1034]. The mitigator in turn 381 inspects and scrubs the traffic, and forwards the resulting 382 (hopefully non-attack) traffic to the attack target. Thus, when a 383 DOTS server receives an attack mitigation request from a DOTS client, 384 it can be viewed as a way of causing traffic redirection for the 385 attack target indicated. 387 DOTS relies on mutual authentication and the pre-established service 388 relationship between the DOTS client's domain and the DOTS server's 389 domain to provide basic authorization. The DOTS server SHOULD 390 enforce additional authorization mechanisms to restrict the 391 mitigation scope a DOTS client can request, but such authorization 392 mechanisms are deployment-specific. 394 Although co-location of DOTS server and mitigator within the same 395 domain is expected to be a common deployment model, it is assumed 396 that operators may require alternative models. Nothing in this 397 document precludes such alternatives. 399 2.2. Components 401 2.2.1. DOTS Client 403 A DOTS client is a DOTS agent from which requests for help 404 coordinating attack response originate. The requests may be in 405 response to an active, ongoing attack against a target in the DOTS 406 client's domain, but no active attack is required for a DOTS client 407 to request help. Local operators may wish to have upstream 408 mitigators in the network path for an indefinite period, and are 409 restricted only by business relationships when it comes to duration 410 and scope of requested mitigation. 412 The DOTS client requests attack response coordination from a DOTS 413 server over the signal channel, including in the request the DOTS 414 client's desired mitigation scoping, as described in 415 [I-D.ietf-dots-requirements]. The actual mitigation scope and 416 countermeasures used in response to the attack are up to the DOTS 417 server and Mitigator operators, as the DOTS client may have a narrow 418 perspective on the ongoing attack. As such, the DOTS client's 419 request for mitigation should be considered advisory: guarantees of 420 DOTS server availability or mitigation capacity constitute service 421 level agreements and are out of scope for this document. 423 The DOTS client adjusts mitigation scope and provides available 424 attack details at the direction of its local operator. Such 425 direction may involve manual or automated adjustments in response to 426 feedback from the DOTS server. 428 To provide a metric of signal health and distinguish an idle 429 signaling session from a disconnected or defunct session, the DOTS 430 client sends a heartbeat over the signal channel to maintain its half 431 of the signaling session. The DOTS client similarly expects a 432 heartbeat from the DOTS server, and MAY consider a signaling session 433 terminated in the extended absence of a DOTS server heartbeat. 435 2.2.2. DOTS Server 437 A DOTS server is a DOTS agent capable of receiving, processing and 438 possibly acting on requests for help coordinating attack response 439 from one or more DOTS clients. The DOTS server authenticates and 440 authorizes DOTS clients as described in Signaling Sessions below, and 441 maintains signaling session state, tracking requests for mitigation, 442 reporting on the status of active mitigations, and terminating 443 signaling sessions in the extended absence of a client heartbeat or 444 when a session times out. 446 Assuming the preconditions discussed below exist, a DOTS client 447 maintaining an active signaling session with a DOTS server may 448 reasonably expect some level of mitigation in response to a request 449 for coordinated attack response. 451 The DOTS server enforces authorization of DOTS clients' signals for 452 mitigation. The mechanism of enforcement is not in scope for this 453 document, but is expected to restrict requested mitigation scope to 454 addresses, prefixes, and/or services owned by the DOTS client's 455 administrative domain, such that a DOTS client from one domain is not 456 able to influence the network path to another domain. A DOTS server 457 MUST reject requests for mitigation of resources not owned by the 458 requesting DOTS client's administrative domain. A DOTS server MAY 459 also refuse a DOTS client's mitigation request for arbitrary reasons, 460 within any limits imposed by business or service level agreements 461 between client and server domains. If a DOTS server refuses a DOTS 462 client's request for mitigation, the DOTS server SHOULD include the 463 refusal reason in the server signal sent to the client. 465 A DOTS server is in regular contact with one or more mitigators. If 466 a DOTS server accepts a DOTS client's request for help, the DOTS 467 server forwards a translated form of that request to the mitigator or 468 mitigators responsible for scrubbing attack traffic. Note that the 469 form of the translated request passed from the DOTS server to the 470 mitigator is not in scope: it may be as simple as an alert to 471 mitigator operators, or highly automated using vendor or open 472 application programming interfaces supported by the mitigator. The 473 DOTS server MUST report the actual scope of any mitigation enabled on 474 behalf of a client. 476 The DOTS server SHOULD retrieve available metrics for any mitigations 477 activated on behalf of a DOTS client, and SHOULD include them in 478 server signals sent to the DOTS client originating the request for 479 mitigation. 481 To provide a metric of signal health and distinguish an idle 482 signaling session from a disconnected or defunct session, the DOTS 483 server sends a heartbeat over the signal channel to maintain its half 484 of the signaling session. The DOTS server similarly expects a 485 heartbeat from the DOTS client, and MAY consider a signaling session 486 terminated in the extended absence of a DOTS client heartbeat. 488 2.2.3. DOTS Gateway 490 Traditional client to server relationships may be expanded by 491 chaining DOTS sessions. This chaining is enabled through "logical 492 concatenation" [RFC7092] of a DOTS server and a DOTS client, 493 resulting in an application analogous to the SIP logical entity of a 494 Back-to-Back User Agent (B2BUA) [RFC3261]. The term DOTS gateway 495 will be used here and the following text will describe some 496 interactions in relation to this application. 498 A DOTS gateway may be deployed client-side, server-side or both. The 499 gateway may terminate multiple discrete client connections and may 500 aggregate these into a single or multiple DOTS signaling sessions. 502 The DOTS gateway will appear as a server to its downstream agents and 503 as a client to its upstream agents, a functional concatenation of the 504 DOTS client and server roles, as depicted in Figure 4: 506 +-------------+ 507 | | D | | 508 +----+ | | O | | +----+ 509 | c1 |----------| s1 | T | c2 |---------| s2 | 510 +----+ | | S | | +----+ 511 | | G | | 512 +-------------+ 514 Figure 4: DOTS gateway 516 The DOTS gateway performs full stack DOTS session termination and 517 reorigination between its client and server side. The details of how 518 this is achieved are implementation specific. The DOTS protocol does 519 not include any special features related to DOTS gateways, and hence 520 from a DOTS perspective, whenever a DOTS gateway is present, the DOTS 521 session simply terminates/originates there. 523 2.3. DOTS Agent Relationships 525 So far, we have only considered a relatively simple scenario of a 526 single DOTS client associated with a single DOTS server, however DOTS 527 supports more advanced relationships. 529 A DOTS server may be associated with one or more DOTS clients, and 530 those DOTS clients may belong to different domains. An example 531 scenario is a mitigation provider serving multiple attack targets 532 (Figure 5): 534 DOTS Clients DOTS Server 535 +---+ 536 | c |----------- 537 +---+ \ 538 example.org \ 539 \ 540 +---+ \ +---+ 541 | c |----------------| S | 542 +---+ / +---+ 543 example.com / 544 / 545 +---+ / 546 | c |----------- 547 +---+ 548 example.com example.net 550 Figure 5: DOTS server with multiple clients 552 A DOTS client may be associated with one or more DOTS servers, and 553 those DOTS servers may belong to different domains. This may be to 554 ensure high availability or co-ordinate mitigation with more than one 555 directly connected ISP. An example scenario is for an enterprise to 556 have DDoS mitigation service from multiple providers, as shown in 557 Figure 6 below. Operational considerations relating to co-ordinating 558 multiple provider responses are beyond the scope of DOTS. 560 [[EDITOR'S NOTE: we request working group feedback and discussion of 561 operational considerations relating to coordinating multiple provider 562 responses to a mitigation request.]] 563 DOTS Client DOTS Servers 564 +---+ 565 ------------| S | 566 / +---+ 567 example.net 568 / 569 +---+/ +---+ 570 | c |---------------| S | 571 +---+\ +---+ 572 example.org 573 \ 574 \ +---+ 575 ------------| S | 576 +---+ 577 example.com example.xyz 579 Figure 6: Multi-Homed DOTS Client 581 2.3.1. Gatewayed signaling 583 As discussed above in Section 2.2.3, a DOTS gateway is a logical 584 function chaining signaling sessions through concatenation of a DOTS 585 server and DOTS client. 587 An example scenario, as shown in Figure 7 and Figure 8 below, is for 588 an enterprise to have deployed multiple DOTS capable devices which 589 are able to signal intra-domain using TCP [RFC0793] on un-congested 590 links to a DOTS gateway which may then transform these to a UDP 591 [RFC0768] transport inter-domain where connection oriented transports 592 may degrade; this applies to the signal channel only, as the data 593 channel requires a connection-oriented transport. The relationship 594 between the gateway and its upstream agents is opaque to the initial 595 clients. 597 +---+ 598 | c |\ 599 +---+ \ +---+ 600 \-----TCP-----| D | +---+ 601 +---+ | O | | | 602 | c |--------TCP-----| T |------UDP------| S | 603 +---+ | S | | | 604 /-----TCP-----| G | +---+ 605 +---+ / +---+ 606 | c |/ 607 +---+ 608 example.com example.com example.net 609 DOTS Clients DOTS Gateway (DOTSG) DOTS Server 611 Figure 7: Client-Side Gateway with Aggregation 613 +---+ 614 | c |\ 615 +---+ \ +---+ 616 \-----TCP-----| D |------UDP------+---+ 617 +---+ | O | | | 618 | c |--------TCP-----| T |------UDP------| S | 619 +---+ | S | | | 620 /-----TCP-----| G |------UDP------+---+ 621 +---+ / +---+ 622 | c |/ 623 +---+ 624 example.com example.com example.net 625 DOTS Clients DOTS Gateway (DOTSG) DOTS Server 627 Figure 8: Client-Side Gateway without Aggregation 629 This may similarly be deployed in the inverse scenario where the 630 gateway resides in the server-side domain and may be used to 631 terminate and/or aggregate multiple clients to single transport as 632 shown in figures Figure 9 and Figure 10 below. 634 +---+ 635 | c |\ 636 +---+ \ +---+ 637 \-----UDP-----| D | +---+ 638 +---+ | O | | | 639 | c |--------TCP-----| T |------TCP------| S | 640 +---+ | S | | | 641 /-----TCP-----| G | +---+ 642 +---+ / +---+ 643 | c |/ 644 +---+ 645 example.com example.net example.net 646 DOTS Clients DOTS Gateway (DOTSG) DOTS Server 648 Figure 9: Server-Side Gateway with Aggregation 650 +---+ 651 | c |\ 652 +---+ \ +---+ 653 \-----UDP-----| D |------TCP------+---+ 654 +---+ | O | | | 655 | c |--------TCP-----| T |------TCP------| S | 656 +---+ | S | | | 657 /-----UDP-----| G |------TCP------+---+ 658 +---+ / +---+ 659 | c |/ 660 +---+ 661 example.com example.net example.net 662 DOTS Clients DOTS Gateway (DOTSG) DOTS Server 664 Figure 10: Server-Side Gateway without Aggregation 666 3. Concepts 668 3.1. Signaling Sessions 670 In order for DOTS to be effective as a vehicle for DDoS mitigation 671 requests, one or more DOTS clients must establish ongoing 672 communication with one or more DOTS servers. While the preconditions 673 for enabling DOTS in or among network domains may also involve 674 business relationships, service level agreements, or other formal or 675 informal understandings between network operators, such 676 considerations are out of scope for this document. 678 An established communication layer between DOTS agents is a Signaling 679 Session. At its most basic, for a DOTS signaling session to exist 680 both signal channel and data channel must be functioning between DOTS 681 agents. That is, under nominal network conditions, signals actively 682 sent from a DOTS client are received by the specific DOTS server 683 intended by the client, and vice versa. 685 3.1.1. Preconditions 687 Prior to establishing a signaling session between agents, the owners 688 of the networks, domains, services or applications involved are 689 assumed to have agreed upon the terms of the relationship involved. 690 Such agreements are out of scope for this document, but must be in 691 place for a functional DOTS architecture. 693 It is assumed that as part of any DOTS service agreement, the DOTS 694 client is provided with all data and metadata required to establish 695 communication with the DOTS server. Such data and metadata would 696 include any cryptographic information necessary to meet the message 697 confidentiality, integrity and authenticity requirement in 698 [I-D.ietf-dots-requirements], and might also include the pool of DOTS 699 server addresses and ports the DOTS client should use for signal and 700 data channel messaging. 702 3.1.2. Establishing the Signaling Session 704 With the required business or service agreements in place, the DOTS 705 client initiates a signal session by contacting the DOTS server over 706 the signal channel and the data channel. To allow for DOTS service 707 flexibility, neither the order of contact nor the time interval 708 between channel creations is specified. A DOTS client MAY establish 709 signal channel first, and then data channel, or vice versa. 711 The methods by which a DOTS client receives the address and 712 associated service details of the DOTS server are not prescribed by 713 this document. For example, a DOTS client may be directly configured 714 to use a specific DOTS server address and port, and directly provided 715 with any data necessary to satisfy the Peer Mutual Authentication 716 requirement in [I-D.ietf-dots-requirements], such as symmetric or 717 asymmetric keys, usernames and passwords, etc. All configuration and 718 authentication information in this scenario is provided out-of-band 719 by the domain operating the DOTS server. 721 At the other extreme, the architecture in this document allows for a 722 form of DOTS client auto-provisioning. For example, the domain 723 operating the DOTS server or servers might provide the client domain 724 only with symmetric or asymmetric keys to authenticate the 725 provisioned DOTS clients. Only the keys would then be directly 726 configured on DOTS clients, but the remaining configuration required 727 to provision the DOTS clients could be learned through mechanisms 728 similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. 730 The DOTS client SHOULD successfully authenticate and exchange 731 messages with the DOTS server over both signal and data channel as 732 soon as possible to confirm that both channels are operational. 734 Once the DOTS client begins receiving DOTS server signals, the 735 signaling session is active. At any time during the signaling 736 session, the DOTS client MAY use the data channel to adjust initial 737 configuration, manage black- and white-listed prefixes or addresses, 738 leverage vendor-specific extensions, and so on. Note that unlike the 739 signal channel, there is no requirement that the data channel remain 740 operational in attack conditions (See Data Channel Requirements, 741 [I-D.ietf-dots-requirements]). 743 3.1.3. Maintaining the Signaling Session 745 DOTS clients and servers periodically send heartbeats to each other 746 over the signal channel, per Operational Requirements discussed in 747 [I-D.ietf-dots-requirements]. DOTS agent operators SHOULD configure 748 the heartbeat interval such that the frequency does not lead to 749 accidental denials of service due to the overwhelming number of 750 heartbeats a DOTS agent must field. 752 Either DOTS agent may consider a signaling session terminated in the 753 extended absence of a heartbeat from its peer agent. The period of 754 that absence will be established in the protocol definition. 756 3.2. Modes of Signaling 758 This section examines the modes of signaling between agents in a DOTS 759 architecture. 761 3.2.1. Direct Signaling 763 A signaling session may take the form of direct signaling between the 764 DOTS clients and servers, as shown in Figure 11 below: 766 +-------------+ +-------------+ 767 | DOTS client |<------signal session------>| DOTS server | 768 +-------------+ +-------------+ 770 Figure 11: Direct Signaling 772 In a direct signaling session, DOTS client and server are 773 communicating directly. A direct signaling session MAY exist inter- 774 or intra-domain. The signaling session is abstracted from the 775 underlying networks or network elements the signals traverse: in a 776 direct signaling session, the DOTS client and server are logically 777 peer DOTS agents. 779 3.2.2. Redirected Signaling 781 In certain circumstances, a DOTS server may want to redirect a DOTS 782 client to an alternative DOTS server for a signaling session. Such 783 circumstances include but are not limited to: 785 o Maximum number of signaling sessions with clients has been 786 reached; 788 o Mitigation capacity exhaustion in the Mitigator with which the 789 specific DOTS server is communicating; 791 o Mitigator outage or other downtime, such as scheduled maintenance; 793 o Scheduled DOTS server maintenance; 795 o Scheduled modifications to the network path between DOTS server 796 and DOTS client. 798 A basic redirected signaling session resembles the following, as 799 shown in Figure 12: 801 +-------------+ +---------------+ 802 | |<-(1)-- signal session 1 -->| | 803 | | | | 804 | |<=(2)== redirect to B ======| | 805 | DOTS client | | DOTS server A | 806 | |X-(4)-- signal session 1 --X| | 807 | | | | 808 | | | | 809 +-------------+ +---------------+ 810 ^ 811 | 812 (3) signal session 2 813 | 814 v 815 +---------------+ 816 | DOTS server B | 817 +---------------+ 819 Figure 12: Redirected Signaling 821 1. Previously established signaling session 1 exists between a DOTS 822 client and DOTS server with address A. 824 2. DOTS server A sends a server signal redirecting the client to 825 DOTS server B. 827 3. If the DOTS client does not already have a separate signaling 828 session with the redirection target, the DOTS client initiates 829 and establishes a signaling session with DOTS server B as 830 described above. 832 4. Having redirected the DOTS client, DOTS server A ceases sending 833 server signals. The DOTS client likewise stops sending client 834 signals to DOTS server A. Signal session 1 is terminated. 836 [[EDITOR'S NOTE: we request working group feedback and discussion of 837 the need for redirected signaling.]] 839 3.2.3. Recursive Signaling 841 DOTS is centered around improving the speed and efficiency of 842 coordinated response to DDoS attacks. One scenario not yet discussed 843 involves coordination among federated domains operating DOTS servers 844 and mitigators. 846 In the course of normal DOTS operations, a DOTS client communicates 847 the need for mitigation to a DOTS server, and that server initiates 848 mitigation on a mitigator with which the server has an established 849 service relationship. The operator of the mitigator may in turn 850 monitor mitigation performance and capacity, as the attack being 851 mitigated may grow in severity beyond the mitigating domain's 852 capabilities. 854 The operator of the mitigator has limited options in the event a DOTS 855 client-requested mitigation is being overwhelmed by the severity of 856 the attack. Out-of-scope business or service level agreements may 857 permit the mitigating domain to drop the mitigation and let attack 858 traffic flow unchecked to the target, but this is only encourages 859 attack escalation. In the case where the mitigating domain is the 860 upstream service provider for the attack target, this may mean the 861 mitigating domain and its other services and users continue to suffer 862 the incidental effects of the attack. 864 A recursive signaling model as shown in Figure 13 below offers an 865 alternative. In a variation of the primary use case "Successful 866 Automatic or Operator-Assisted CPE or PE Mitigators Request Upstream 867 DDoS Mitigation Services" described in [I-D.ietf-dots-use-cases], an 868 domain operating a DOTS server and mitigation also operates a DOTS 869 client. This DOTS client has an established signaling session with a 870 DOTS server belonging to a separate administrative domain. 872 With these preconditions in place, the operator of the mitigator 873 being overwhelmed or otherwise performing inadequately may request 874 mitigation for the attack target from this separate DOTS-aware 875 domain. Such a request recurses the originating mitigation request 876 to the secondary DOTS server, in the hope of building a cumulative 877 mitigation against the attack: 879 example.net domain 880 . . . . . . . . . . . . . . . . . 881 . Gn . 882 +----+ A . +----+ +-----------+ . 883 | Cc |<--------->| Sn |~~~~~~~| Mitigator | . 884 +----+ . +====+ | Mn | . 885 . | Cn | +-----------+ . 886 example.com . +----+ . 887 client . ^ . 888 . . .|. . . . . . . . . . . . . . 889 | 890 B | 891 | 892 . . .|. . . . . . . . . . . . . . 893 . v . 894 . +----+ +-----------+ . 895 . | So |~~~~~~~| Mitigator | . 896 . +----+ | Mo | . 897 . +-----------+ . 898 . . 899 . . . . . . . . . . . . . . . . . 900 example.org domain 902 Figure 13: Recursive Signaling 904 In Figure 13 above, client Cc signals a request for mitigation across 905 inter-domain signaling session A to the DOTS server Sn belonging to 906 the example.net domain. DOTS server Sn enables mitigation on 907 mitigator Mn. DOTS server Sn is half of DOTS gateway Gn, being 908 deployed logically back-to-back with DOTS client Cn, which has pre- 909 existing inter-domain signaling session B with the DOTS server So 910 belonging to the example.org domain. At any point, DOTS server Sn 911 MAY recurse an on-going mitigation request through DOTS client Cn to 912 DOTS server So, in the expectation that mitigator Mo will be 913 activated to aid in the defense of the attack target. 915 Recursive signaling is opaque to the DOTS client. To maximize 916 mitigation visibility to the DOTS client, however, the recursing 917 domain SHOULD provide recursed mitigation feedback in signals 918 reporting on mitigation status to the DOTS client. For example, the 919 recursing domain's mitigator should incorporate into mitigation 920 status messages available metrics such as dropped packet or byte 921 counts from the recursed mitigation. 923 DOTS clients involved in recursive signaling MUST be able to withdraw 924 requests for mitigation without warning or justification, per 925 [I-D.ietf-dots-requirements]. 927 Operators recursing mitigation requests MAY maintain the recursed 928 mitigation for a brief, protocol-defined period in the event the DOTS 929 client originating the mitigation withdraws its request for help, as 930 per the discussion of managing mitigation toggling in the operational 931 requirements ([I-D.ietf-dots-requirements]). Service or business 932 agreements between recursing domains are not in scope for this 933 document. 935 [[EDITOR'S NOTE: Recursive signaling raises questions about 936 operational and data privacy, as well as what level of visibility a 937 client has into the recursed mitigation. We ask the working group 938 for feedback and additional discussion of these issues to help settle 939 the way forward.]] 941 3.3. Triggering Requests for Mitigation 943 [I-D.ietf-dots-requirements] places no limitation on the 944 circumstances in which a DOTS client operator may request mitigation, 945 nor does it demand justification for any mitigation request, thereby 946 reserving operational control over DDoS defense for the domain 947 requesting mitigation. This architecture likewise does not prescribe 948 the network conditions and mechanisms triggering a mitigation request 949 from a DOTS client. 951 However, considering selected possible mitigation triggers from an 952 architectural perspective offers a model for alternative or 953 unanticipated triggers for DOTS deployments. In all cases, what 954 network conditions merit a mitigation request are at the discretion 955 of the DOTS client operator. 957 The interfaces required to trigger the mitigation request in the 958 following scenarios are implementation-specific. 960 3.3.1. Manual Mitigation Request 962 A DOTS client operator may manually prepare a request for mitigation, 963 including scope and duration, and manually instruct the DOTS client 964 to send the mitigation request to the DOTS server. In context, a 965 manual request is a request directly issued by the operator without 966 automated decision-making performed by a device interacting with the 967 DOTS client. Modes of manual mitigation requests include an operator 968 entering a command into a text interface, or directly interacting 969 with a graphical interface to send the request. 971 An operator might do this, for example, in response to notice of an 972 attack delivered by attack detection equipment or software, and the 973 alerting detector lacks interfaces or is not configured to use 974 available interfaces to translate the alert to a mitigation request 975 automatically. 977 In a variation of the above scenario, the operator may have 978 preconfigured on the DOTS client mitigation request for various 979 resources in the operator's domain. When notified of an attack, the 980 DOTS client operator manually instructs the DOTS client to send the 981 preconfigured mitigation request for the resources under attack. 983 A further variant involves recursive signaling, as described in 984 Section 3.2.3. The DOTS client in this case is the second half of a 985 DOTS gateway (back-to-back DOTS server and client). As in the 986 previous scenario, the scope and duration of the mitigation request 987 are pre-existing, but in this case are derived from the mitigation 988 request received from a downstream DOTS client by the DOTS server. 989 Assuming the preconditions required by Section 3.2.3 are in place, 990 the DOTS gateway operator may at any time manually request mitigation 991 from an upstream DOTS server, sending a mitigation request derived 992 from the downstream DOTS client's request. 994 The motivations for a DOTS client operator to request mitigation 995 manually are not prescribed by this architecture, but are expected to 996 include some of the following: 998 o Notice of an attack delivered via e-mail or alternative messaging 1000 o Notice of an attack delivered via phone call 1002 o Notice of an attack delivered through the interface(s) of 1003 networking monitoring software deployed in the operator's domain 1005 o Manual monitoring of network behavior through network monitoring 1006 software 1008 3.3.2. Automated Threshold-Based Mitigation Request 1010 Unlike manual mitigation requests, which depend entirely on the DOTS 1011 client operator's capacity to react with speed and accuracy to every 1012 detected or detectable attack, mitigation requests triggered by 1013 detected attack thresholds reduce the operational burden on the DOTS 1014 client operator, and minimize the latency between attack detection 1015 and the start of mitigation. 1017 Mitigation requests are triggered in this scenario by violations of 1018 operator-specified attack thresholds. Attack detection is 1019 deployment-specific, and not constrained by this architecture. 1020 Similarly the specifics of a threshold are left to the discretion of 1021 the operator, though common threshold types include the following: 1023 o Detected attack exceeding a rate in packets per second (pps). 1025 o Detected attack exceeding a rate in bytes per second (bps). 1027 o Detected resource exhaustion in an attack target. 1029 o Detected resource exhaustion in the local domain's mitigator. 1031 o Number of open connections to an attack target. 1033 o Number of attack sources in a given attack. 1035 o Number of active attacks against targets in the operator's domain. 1037 o Thresholds developed through arbitrary statistical analysis or 1038 deep learning techniques. 1040 When automated threshold-based mitigation requests are enabled, 1041 violations of any of the above thresholds, or any additional 1042 operator-defined threshold, will trigger a mitigation request from 1043 the DOTS client to the DOTS server. The interfaces between the 1044 application detecting the threshold violation and the DOTS client are 1045 implementation-specific. 1047 3.3.3. Automated Mitigation on Loss of Signal 1049 To maintain a signaling session, the DOTS client and the DOTS server 1050 exchange regular but infrequent messages across the signaling 1051 channel. In the absence of an attack, the probability of message 1052 loss in the signaling channel should be extremely low. Under attack 1053 conditions, however, some signal loss may be anticipated as attack 1054 traffic congests the link, depending on the attack type. 1056 While [I-D.ietf-dots-requirements] specifies the DOTS protocol be 1057 robust when signaling under attack conditions, there are nevertheless 1058 scenarios in which the DOTS signal is lost in spite of protocol best 1059 efforts. To handle such scenarios, a DOTS client operator may 1060 configure the signaling session to trigger mitigation when the DOTS 1061 server ceases receiving DOTS client signals (or vice versa) beyond 1062 the miss count or period permitted by the protocol. 1064 The impact of mitigating due to loss of signal in either direction 1065 must be considered carefully before enabling it. Signal loss is not 1066 caused by links congested with attack traffic alone, and as such 1067 mitigation requests triggered by signal channel degradation in either 1068 direction may incur unnecessary costs, in network performance and 1069 operational expense alike. 1071 4. Security Considerations 1073 This section describes identified security considerations for the 1074 DOTS architecture. 1076 DOTS is at risk from three primary attack vectors: agent 1077 impersonation, traffic injection and signal blocking. These vectors 1078 may be exploited individually or in concert by an attacker to 1079 confuse, disable, take information from, or otherwise inhibit DOTS 1080 agents. 1082 Any attacker with the ability to impersonate a legitimate client or 1083 server or, indeed, inject false messages into the stream may 1084 potentially trigger/withdraw traffic redirection, trigger/cancel 1085 mitigation activities or subvert black/whitelists. From an 1086 architectural standpoint, operators SHOULD ensure best current 1087 practices for secure communication are observed for data and signal 1088 channel confidentiality, integrity and authenticity. Care must be 1089 taken to ensure transmission is protected by appropriately secure 1090 means, reducing attack surface by exposing only the minimal required 1091 services or interfaces. Similarly, received data at rest SHOULD be 1092 stored with a satisfactory degree of security. 1094 As many mitigation systems employ diversion to scrub attack traffic, 1095 operators of DOTS agents SHOULD ensure signaling sessions are 1096 resistant to Man-in-the-Middle (MitM) attacks. An attacker with 1097 control of a DOTS client may negatively influence network traffic by 1098 requesting and withdrawing requests for mitigation for particular 1099 prefixes, leading to route or DNS flapping. 1101 Any attack targeting the availability of DOTS servers may disrupt the 1102 ability of the system to receive and process DOTS signals resulting 1103 in failure to fulfill a mitigation request. DOTS agents SHOULD be 1104 given adequate protections, again in accordance with best current 1105 practices for network and host security. 1107 5. Acknowledgments 1109 Thanks to Matt Richardson and Med Boucadair for their comments and 1110 suggestions. 1112 6. Change Log 1114 2016-03-18 Initial revision 1116 7. References 1118 7.1. Normative References 1120 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1121 Requirement Levels", BCP 14, RFC 2119, 1122 DOI 10.17487/RFC2119, March 1997, 1123 . 1125 7.2. Informative References 1127 [I-D.ietf-dots-requirements] 1128 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1129 Denial of Service (DDoS) Open Threat Signaling 1130 Requirements", draft-ietf-dots-requirements-01 (work in 1131 progress), March 2016. 1133 [I-D.ietf-dots-use-cases] 1134 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 1135 Teague, N., and L. Xia, "Use cases for DDoS Open Threat 1136 Signaling", draft-ietf-dots-use-cases-01 (work in 1137 progress), March 2016. 1139 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1140 DOI 10.17487/RFC0768, August 1980, 1141 . 1143 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1144 RFC 793, DOI 10.17487/RFC0793, September 1981, 1145 . 1147 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1148 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1149 . 1151 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1152 specifying the location of services (DNS SRV)", RFC 2782, 1153 DOI 10.17487/RFC2782, February 2000, 1154 . 1156 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1157 A., Peterson, J., Sparks, R., Handley, M., and E. 1158 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1159 DOI 10.17487/RFC3261, June 2002, 1160 . 1162 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1163 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1164 DOI 10.17487/RFC4271, January 2006, 1165 . 1167 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1168 Denial-of-Service Considerations", RFC 4732, 1169 DOI 10.17487/RFC4732, December 2006, 1170 . 1172 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1173 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1174 . 1176 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1177 Initiation Protocol (SIP) Back-to-Back User Agents", 1178 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1179 . 1181 Authors' Addresses 1183 Andrew Mortensen 1184 Arbor Networks, Inc. 1185 2727 S. State St 1186 Ann Arbor, MI 48104 1187 United States 1189 EMail: amortensen@arbor.net 1191 Flemming Andreasen 1192 Cisco Systems, Inc. 1193 United States 1195 EMail: fandreas@cisco.com 1196 Tirumaleswar Reddy 1197 Cisco Systems, Inc. 1198 Cessna Business Park, Varthur Hobli 1199 Sarjapur Marathalli Outer Ring Road 1200 Bangalore, Karnataka 560103 1201 India 1203 EMail: tireddy@cisco.com 1205 Christopher Gray 1206 Comcast, Inc. 1207 United States 1209 EMail: Christopher_Gray3@cable.comcast.com 1211 Rich Compton 1212 Charter Communications, Inc. 1214 EMail: Rich.Compton@charter.com 1216 Nik Teague 1217 Verisign, Inc. 1218 United States 1220 EMail: nteague@verisign.com