DOTS A. Mortensen Internet-Draft Arbor Networks Intended status: Informational F. Andreasen Expires: December 7, 2017 Cisco T. Reddy McAfee, Inc. C. Gray Comcast R. Compton Charter N. Teague Verisign June 05, 2017 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture draft-ietf-dots-architecture-03 Abstract This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 7, 2017. Mortensen, et al. Expires December 7, 2017 [Page 1] Internet-Draft DOTS Architecture June 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Context and Motivation . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2. Definition of Terms . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 2. DOTS Architecture . . . . . . . . . . . . . . . . . . . . . . 5 2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8 2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9 2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10 2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11 2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 12 2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 14 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 16 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 3.1.2. Establishing the Signaling Session . . . . . . . . . 16 3.1.3. Maintaining the Signaling Session . . . . . . . . . . 17 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18 3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 23 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 24 3.3.2. Automated Conditional Mitigation Request . . . . . . 25 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 Mortensen, et al. Expires December 7, 2017 [Page 2] Internet-Draft DOTS Architecture June 2017 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Context and Motivation Signaling the need for help defending against an active distributed denial of service (DDoS) attack requires a common understanding of mechanisms and roles among the parties coordinating defensive response. The signaling layer and supplementary messaging is the focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of coordinating defensive measures among willing peers to mitigate attacks quickly and efficiently, enabling hybrid attack responses coordinated locally at or near the target of an active attack, or anywhere in-path between attack sources and target. Sample DOTS use cases are elaborated in [I-D.ietf-dots-use-cases]. This document describes an architecture used in establishing, maintaining or terminating a DOTS relationship within a domain or between domains. 1.1. Terminology 1.1.1. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1.2. Definition of Terms This document uses the terms defined in [I-D.ietf-dots-requirements]. 1.2. Scope In this architecture, DOTS clients and servers communicate using DOTS signaling. As a result of signals from a DOTS client, the DOTS server may modify the forwarding path of traffic destined for the attack target(s), for example by diverting traffic to a mitigator or pool of mitigators, where policy may be applied to distinguish and discard attack traffic. Any such policy is deployment-specific. The DOTS architecture presented here is applicable across network administrative domains - for example, between an enterprise domain and the domain of a third-party attack mitigation service - as well as to a single administrative domain. DOTS is generally assumed to Mortensen, et al. Expires December 7, 2017 [Page 3] Internet-Draft DOTS Architecture June 2017 be most effective when aiding coordination of attack response between two or more participating networks, but single domain scenarios are valuable in their own right, as when aggregating intra-domain DOTS client signals for inter-domain coordinated attack response. This document does not address any administrative or business agreements that may be established between involved DOTS parties. Those considerations are out of scope. Regardless, this document assumes necessary authentication and authorization mechanisms are put in place so that only authorized clients can invoke the DOTS service. A detailed set of DOTS requirements are discussed in [I-D.ietf-dots-requirements], and the DOTS architecture is assumed to follow those requirements. Only new behavioral requirements are described in this document. 1.3. Assumptions This document makes the following assumptions: o All domains in which DOTS is deployed are assumed to offer the required connectivity between DOTS agents and any intermediary network elements, but the architecture imposes no additional limitations on the form of connectivity. o Congestion and resource exhaustion are intended outcomes of a DDoS attack [RFC4732]. Some operators may utilize non-impacted paths or networks for DOTS, but in general conditions should be assumed to be hostile and that DOTS must be able to function in all circumstances, including when the signaling path is significantly impaired. o There is no universal DDoS attack scale threshold triggering a coordinated response across administrative domains. A network domain administrator, or service or application owner may arbitrarily set attack scale threshold triggers, or manually send requests for mitigation. o Mitigation requests may be sent to one or more upstream DOTS servers based on criteria determined by DOTS client administrators and the underlying network configuration. The number of DOTS servers with which a given DOTS client has established signaling sessions is determined by local policy and is deployment-specific. For example, a DOTS client of a multi-homed network may support built-in policies to establish DOTS relationships with DOTS servers located upstream of each interconnection link. Mortensen, et al. Expires December 7, 2017 [Page 4] Internet-Draft DOTS Architecture June 2017 o The mitigation capacity and/or capability of domains receiving requests for coordinated attack response is opaque to the domains sending the request. The domain receiving the DOTS client signal may or may not have sufficient capacity or capability to filter any or all DDoS attack traffic directed at a target. In either case, the upstream DOTS server may redirect a request to another DOTS server. Redirection may be local to the redirecting DOTS server's domain, or may involve a third-party domain. o DOTS client and server signals, as well as messages sent through the data channel, are sent across any transit networks with the same probability of delivery as any other traffic between the DOTS client domain and the DOTS server domain. Any encapsulation required for successful delivery is left untouched by transit network elements. DOTS server and DOTS client cannot assume any preferential treatment of DOTS signals. Such preferential treatment may be available in some deployments (e.g., intra-domain scenarios), and the DOTS architecture does not preclude its use when available. However, DOTS itself does not address how that may be done. o The architecture allows for, but does not assume, the presence of Quality of Service (QoS) policy agreements between DOTS-enabled peer networks or local QoS prioritization aimed at ensuring delivery of DOTS messages between DOTS agents. QoS is an operational consideration only, not a functional part of the DOTS architecture. o The signal and data channels may be loosely coupled, and may not terminate on the same DOTS server. 2. DOTS Architecture The basic high-level DOTS architecture is illustrated in Figure 1: +-----------+ +-------------+ | Mitigator | ~~~~~~~~~~ | DOTS Server | +-----------+ +-------------+ | | | +---------------+ +-------------+ | Attack Target | ~~~~~~ | DOTS Client | +---------------+ +-------------+ Figure 1: Basic DOTS Architecture Mortensen, et al. Expires December 7, 2017 [Page 5] Internet-Draft DOTS Architecture June 2017 A simple example instantiation of the DOTS architecture could be an enterprise as the attack target for a volumetric DDoS attack, and an upstream DDoS mitigation service as the mitigator. The enterprise (attack target) is connected to the Internet via a link that is getting saturated, and the enterprise suspects it is under DDoS attack. The enterprise has a DOTS client, which obtains information about the DDoS attack, and signals the DOTS server for help in mitigating the attack. The DOTS server in turn invokes one or more mitigators, which are tasked with mitigating the actual DDoS attack, and hence aim to suppress the attack traffic while allowing valid traffic to reach the attack target. The scope of the DOTS specifications is the interfaces between the DOTS client and DOTS server. The interfaces to the attack target and the mitigator are out of scope of DOTS. Similarly, the operation of both the attack target and the mitigator is out of scope of DOTS. Thus, DOTS neither specifies how an attack target decides it is under DDoS attack, nor does DOTS specify how a mitigator may actually mitigate such an attack. A DOTS client's request for mitigation is advisory in nature, and may not lead to any mitigation at all, depending on the DOTS server domain's capacity and willingness to mitigate on behalf of the DOTS client's domain. As illustrated in Figure 2, there are two interfaces between the DOTS server and the DOTS client. +---------------+ +---------------+ | | <------- Signal Channel ------> | | | DOTS Client | | DOTS Server | | | <======= Data Channel ======> | | +---------------+ +---------------+ Figure 2: DOTS Interfaces The DOTS client may be provided with a list of DOTS servers, each associated with one or more IP addresses. These addresses may or may not be of the same address family. The DOTS client establishes one or more signaling sessions by connecting to the provided DOTS server addresses. The primary purpose of the signal channel is for a DOTS client to ask a DOTS server for help in mitigating an attack, and for the DOTS server to inform the DOTS client about the status of such mitigation. The DOTS client does this by sending a client signal, which contains information about the attack target(s). The client signal may also include telemetry information about the attack, if the DOTS client has such information available. The DOTS server in turn sends a server signal to inform the DOTS client of whether it will honor the Mortensen, et al. Expires December 7, 2017 [Page 6] Internet-Draft DOTS Architecture June 2017 mitigation request. Assuming it will, the DOTS server initiates attack mitigation, and periodically informs the DOTS client about the status of the mitigation. Similarly, the DOTS client periodically informs the DOTS server about the client's status, which at a minimum provides client (attack target) health information, but it may also include telemetry information about the attack as it is now seen by the client. At some point, the DOTS client may decide to terminate the server-side attack mitigation, which it indicates to the DOTS server over the signal channel. A mitigation may also be terminated if a DOTS client-specified mitigation lifetime is exceeded. Note that the signal channel may need to operate over a link that is experiencing a DDoS attack and hence is subject to severe packet loss and high latency. While DOTS is able to request mitigation with just the signal channel, the addition of the DOTS data channel provides for additional and more efficient capabilities; both channels are required in the DOTS architecture. The primary purpose of the data channel is to support DOTS related configuration and policy information exchange between the DOTS client and the DOTS server. Examples of such information include, but are not limited to: o Creating identifiers, such as names or aliases, for resources for which mitigation may be requested. Such identifiers may then be used in subsequent signal channel exchanges to refer more efficiently to the resources under attack, as seen in Figure 3, using JSON to serialize the data: { "https1": [ "192.0.2.1:443", "198.51.100.2:443", ], "proxies": [ "203.0.113.3:3128", "[2001:db8:ac10::1]:3128" ], "api_urls": "https://apiserver.example.com/api/v1", } Figure 3: Protected resource identifiers o Black-list management, which enables a DOTS client to inform the DOTS server about sources to suppress. o White-list management, which enables a DOTS client to inform the DOTS server about sources from which traffic is always accepted. Mortensen, et al. Expires December 7, 2017 [Page 7] Internet-Draft DOTS Architecture June 2017 o Filter management, which enables a DOTS client to install or remove traffic filters dropping or rate-limiting unwanted traffic. o DOTS client provisioning. Note that while it is possible to exchange the above information before, during or after a DDoS attack, DOTS requires reliable delivery of this information and does not provide any special means for ensuring timely delivery of it during an attack. In practice, this means that DOTS deployments should not rely on such information being exchanged during a DDoS attack. 2.1. DOTS Operations DOTS does not prescribe any specific deployment models, however DOTS is designed with some specific requirements around the different DOTS agents and their relationships. First of all, a DOTS agent belongs to a domain that has an identity which can be authenticated and authorized. DOTS agents communicate with each other over a mutually authenticated signal channel and data channel. However, before they can do so, a service relationship needs to be established between them. The details and means by which this is done is outside the scope of DOTS, however an example would be for an enterprise A (DOTS client) to sign up for DDoS service from provider B (DOTS server). This would establish a (service) relationship between the two that enables enterprise A's DOTS client to establish a signal channel with provider B's DOTS server. A and B will authenticate each other, and B can verify that A is authorized for its service. From an operational and design point of view, DOTS assumes that the above relationship is established prior to a request for DDoS attack mitigation. In particular, it is assumed that bi-directional communication is possible at this time between the DOTS client and DOTS server. Furthermore, it is assumed that additional service provisioning, configuration and information exchange can be performed by use of the data channel, if operationally required. It is not until this point that the mitigation service is available for use. Once the mutually authenticated signal channel has been established, it will remain active. This is done to increase the likelihood that the DOTS client can signal the DOTS server for help when the attack target is being flooded, and similarly raise the probability that DOTS server signals reach the client regardless of inbound link congestion. This does not necessarily imply that the attack target and the DOTS client have to be co-located in the same administrative domain, but it is expected to be a common scenario. Mortensen, et al. Expires December 7, 2017 [Page 8] Internet-Draft DOTS Architecture June 2017 DDoS mitigation with the help of an upstream mitigator may involve some form of traffic redirection whereby traffic destined for the attack target is steered towards the mitigator. Common mechanisms to achieve this redirection depend on BGP [RFC4271] and DNS [RFC1035]. The mitigator in turn inspects and scrubs the traffic, and forwards the resulting (hopefully non-attack) traffic to the attack target. Thus, when a DOTS server receives an attack mitigation request from a DOTS client, it can be viewed as a way of causing traffic redirection for the attack target indicated. DOTS relies on mutual authentication and the pre-established service relationship between the DOTS client's domain and the DOTS server's domain to provide basic authorization. The DOTS server should enforce additional authorization mechanisms to restrict the mitigation scope a DOTS client can request, but such authorization mechanisms are deployment-specific. Although co-location of DOTS server and mitigator within the same domain is expected to be a common deployment model, it is assumed that operators may require alternative models. Nothing in this document precludes such alternatives. 2.2. Components 2.2.1. DOTS Client A DOTS client is a DOTS agent from which requests for help coordinating attack response originate. The requests may be in response to an active, ongoing attack against a target in the DOTS client's domain, but no active attack is required for a DOTS client to request help. Operators may wish to have upstream mitigators in the network path for an indefinite period, and are restricted only by business relationships when it comes to duration and scope of requested mitigation. The DOTS client requests attack response coordination from a DOTS server over the signal channel, including in the request the DOTS client's desired mitigation scoping, as described in [I-D.ietf-dots-requirements]. The actual mitigation scope and countermeasures used in response to the attack are up to the DOTS server and mitigator operators, as the DOTS client may have a narrow perspective on the ongoing attack. As such, the DOTS client's request for mitigation should be considered advisory: guarantees of DOTS server availability or mitigation capacity constitute service level agreements and are out of scope for this document. The DOTS client adjusts mitigation scope and provides available attack details at the direction of its local administrator. Such Mortensen, et al. Expires December 7, 2017 [Page 9] Internet-Draft DOTS Architecture June 2017 direction may involve manual or automated adjustments in response to feedback from the DOTS server. To provide a metric of signal health and distinguish an idle signaling session from a disconnected or defunct session, the DOTS client sends a heartbeat over the signal channel to maintain its half of the signaling session. The DOTS client similarly expects a heartbeat from the DOTS server, and may consider a signaling session terminated in the extended absence of a DOTS server heartbeat. 2.2.2. DOTS Server A DOTS server is a DOTS agent capable of receiving, processing and possibly acting on requests for help coordinating attack response DOTS clients. The DOTS server authenticates and authorizes DOTS clients as described in Section 3.1, and maintains signaling session state, tracking requests for mitigation, reporting on the status of active mitigations, and terminating signaling sessions in the extended absence of a client heartbeat or when a session times out. Assuming the preconditions discussed below exist, a DOTS client maintaining an active signaling session with a DOTS server may reasonably expect some level of mitigation in response to a request for coordinated attack response. The DOTS server enforces authorization of DOTS clients' signals for mitigation. The mechanism of enforcement is not in scope for this document, but is expected to restrict requested mitigation scope to addresses, prefixes, and/or services owned by the DOTS client's administrative domain, such that a DOTS client from one domain is not able to influence the network path to another domain. A DOTS server MUST reject requests for mitigation of resources not owned by the requesting DOTS client's administrative domain. A DOTS server MAY also refuse a DOTS client's mitigation request for arbitrary reasons, within any limits imposed by business or service level agreements between client and server domains. If a DOTS server refuses a DOTS client's request for mitigation, the DOTS server SHOULD include the refusal reason in the server signal sent to the client. A DOTS server is in regular contact with one or more mitigators. If a DOTS server accepts a DOTS client's request for help, the DOTS server forwards a translated form of that request to the mitigator(s) responsible for scrubbing attack traffic. Note that the form of the translated request passed from the DOTS server to the mitigator is not in scope: it may be as simple as an alert to mitigator operators, or highly automated using vendor or open application programming interfaces supported by the mitigator. The DOTS server MUST report the actual scope of any mitigation enabled on behalf of a client. Mortensen, et al. Expires December 7, 2017 [Page 10] Internet-Draft DOTS Architecture June 2017 The DOTS server SHOULD retrieve available metrics for any mitigations activated on behalf of a DOTS client, and SHOULD include them in server signals sent to the DOTS client originating the request for mitigation. To provide a metric of signal health and distinguish an idle signaling session from a disconnected or defunct session, the DOTS server MUST send a heartbeat over the signal channel to maintain its half of the signaling session. The DOTS server similarly expects a heartbeat from the DOTS client, and MAY consider a signaling session terminated in the extended absence of a DOTS client heartbeat. 2.2.3. DOTS Gateway Traditional client/server relationships may be expanded by chaining DOTS sessions. This chaining is enabled through "logical concatenation" of a DOTS server and a DOTS client, resulting in an application analogous to the SIP logical entity of a Back-to-Back User Agent (B2BUA) [RFC7092]. The term DOTS gateway is used here in the descriptions of selected scenarios involving this application. A DOTS gateway may be deployed client-side, server-side or both. The gateway may terminate multiple discrete client connections and may aggregate these into a single or multiple DOTS signaling sessions. The DOTS gateway will appear as a server to its downstream agents and as a client to its upstream agents, a functional concatenation of the DOTS client and server roles, as depicted in Figure 4: +-------------+ | | D | | +----+ | | O | | +----+ | c1 |----------| s1 | T | c2 |---------| s2 | +----+ | | S | | +----+ | | G | | +-------------+ Figure 4: DOTS gateway The DOTS gateway MUST perform full stack DOTS session termination and reorigination between its client and server side. The details of how this is achieved are implementation specific. The DOTS protocol does not include any special features related to DOTS gateways, and hence from a DOTS perspective, whenever a DOTS gateway is present, the DOTS session simply terminates/originates there. Mortensen, et al. Expires December 7, 2017 [Page 11] Internet-Draft DOTS Architecture June 2017 2.3. DOTS Agent Relationships So far, we have only considered a relatively simple scenario of a single DOTS client associated with a single DOTS server, however DOTS supports more advanced relationships. A DOTS server may be associated with one or more DOTS clients, and those DOTS clients may belong to different domains. An example scenario is a mitigation provider serving multiple attack targets (Figure 5). DOTS clients DOTS server +---+ | c |----------- +---+ \ c1.example.org \ \ +---+ \ +---+ | c |----------------| S | +---+ / +---+ c1.example.com / dots1.example.net / +---+ / | c |----------- +---+ c2.example.com Figure 5: DOTS server with multiple clients A DOTS client may be associated with one or more DOTS servers, and those DOTS servers may belong to different domains. This may be to ensure high availability or co-ordinate mitigation with more than one directly connected ISP. An example scenario is for an enterprise to have DDoS mitigation service from multiple providers, as shown in Figure 6. Mortensen, et al. Expires December 7, 2017 [Page 12] Internet-Draft DOTS Architecture June 2017 DOTS client DOTS servers +---+ -----------| S | / +---+ / dots1.example.net / +---+/ +---+ | c |---------------| S | +---+\ +---+ \ dots.example.org \ \ +---+ -----------| S | +---+ c.example.com dots2.example.net Figure 6: Multi-Homed DOTS Client Deploying a multi-homed client requires extra care and planning, as the DOTS servers with which the multi-homed client communicates may not be affiliated. Should the multi-homed client simultaneously request for mitigation from all servers with which it has established signal channels, the client may unintentionally inflict additional network disruption on the resources it intends to protect. In one of the worst cases, a multi-homed DOTS client could cause a permanent routing loop of traffic destined for the client's protected protected services, as the uncoordinated DOTS servers' mitigators all try to divert that traffic to their own scrubbing centers. The DOTS protocol itself provides no fool-proof method to prevent such self-inflicted harms as a result deploying multi-homed DOTS clients. If DOTS client implementations nevertheless include support for multi-homing, they are expected to be aware of the risks, and consequently to include measures aimed at reducing the likelihood of negative outcomes. Simple measures might include: o Requesting mitigation serially, ensuring only one mitigation request for a given address space is active at any given time; o Dividing the protected resources among the DOTS servers, such that no two mitigators will be attempting to divert and scrub the same traffic; o Using multi-homing for redundancy only. In this case, the DOTS servers would be affiliated, and through shared communications ensure that the redundant mitigation requests do not result in overlapping traffic diversion announcements. Mortensen, et al. Expires December 7, 2017 [Page 13] Internet-Draft DOTS Architecture June 2017 2.3.1. Gatewayed Signaling As discussed in Section 2.2.3, a DOTS gateway is a logical function chaining signaling sessions through concatenation of a DOTS server and DOTS client. An example scenario, as shown in Figure 7 and Figure 8, is for an enterprise to have deployed multiple DOTS capable devices which are able to signal intra-domain using TCP [RFC0793] on un-congested links to a DOTS gateway which may then transform these to a UDP [RFC0768] transport inter-domain where connection oriented transports may degrade; this applies to the signal channel only, as the data channel requires a connection-oriented transport. The relationship between the gateway and its upstream agents is opaque to the initial clients. +---+ | c |\ +---+ \ +---+ \-----TCP-----| D | +---+ +---+ | O | | | | c |--------TCP-----| T |------UDP------| S | +---+ | S | | | /-----TCP-----| G | +---+ +---+ / +---+ | c |/ +---+ example.com example.com example.net DOTS clients DOTS gateway (DOTSG) DOTS server Figure 7: Client-Side Gateway with Aggregation +---+ | c |\ +---+ \ +---+ \-----TCP-----| D |------UDP------+---+ +---+ | O | | | | c |--------TCP-----| T |------UDP------| S | +---+ | S | | | /-----TCP-----| G |------UDP------+---+ +---+ / +---+ | c |/ +---+ example.com example.com example.net DOTS clients DOTS gateway (DOTSG) DOTS server Figure 8: Client-Side Gateway without Aggregation Mortensen, et al. Expires December 7, 2017 [Page 14] Internet-Draft DOTS Architecture June 2017 This may similarly be deployed in the inverse scenario where the gateway resides in the server-side domain and may be used to terminate and/or aggregate multiple clients to single transport as shown in figures Figure 9 and Figure 10. +---+ | c |\ +---+ \ +---+ \-----UDP-----| D | +---+ +---+ | O | | | | c |--------TCP-----| T |------TCP------| S | +---+ | S | | | /-----TCP-----| G | +---+ +---+ / +---+ | c |/ +---+ example.com example.net example.net DOTS clients DOTS gateway (DOTSG) DOTS server Figure 9: Server-Side Gateway with Aggregation +---+ | c |\ +---+ \ +---+ \-----UDP-----| D |------TCP------+---+ +---+ | O | | | | c |--------TCP-----| T |------TCP------| S | +---+ | S | | | /-----UDP-----| G |------TCP------+---+ +---+ / +---+ | c |/ +---+ example.com example.net example.net DOTS clients DOTS gateway (DOTSG) DOTS server Figure 10: Server-Side Gateway without Aggregation This document anticipates scenarios involving multiple DOTS gateways. An example is a DOTS gateway at the network client's side, and another one at the server side. The first gateway can be located at a CPE to aggregate requests from multiple DOTS clients enabled in an enterprise network. The second DOTS gateway is deployed on the provider side. This scenario can be seen as a combination of the client-side and server-side scenarios. Mortensen, et al. Expires December 7, 2017 [Page 15] Internet-Draft DOTS Architecture June 2017 3. Concepts 3.1. Signaling Sessions In order for DOTS to be effective as a vehicle for DDoS mitigation requests, one or more DOTS clients must establish ongoing communication with one or more DOTS servers. While the preconditions for enabling DOTS in or among network domains may also involve business relationships, service level agreements, or other formal or informal understandings between network operators, such considerations are out of scope for this document. An established communication layer between DOTS agents is a signaling session. At its most basic, for a DOTS signaling session to exist both signal channel and data channel must be functioning between DOTS agents. That is, under nominal network conditions, signals actively sent from a DOTS client are received by the specific DOTS server intended by the client, and vice versa. 3.1.1. Preconditions Prior to establishing a signaling session between agents, the owners of the networks, domains, services or applications involved are assumed to have agreed upon the terms of the relationship involved. Such agreements are out of scope for this document, but must be in place for a functional DOTS architecture. It is assumed that as part of any DOTS service agreement, the DOTS client is provided with all data and metadata required to establish communication with the DOTS server. Such data and metadata would include any cryptographic information necessary to meet the message confidentiality, integrity and authenticity requirement in [I-D.ietf-dots-requirements], and might also include the pool of DOTS server addresses and ports the DOTS client should use for signal and data channel messaging. 3.1.2. Establishing the Signaling Session With the required business agreements in place, the DOTS client initiates a signal session by contacting its DOTS server(s) over the signal channel and the data channel. To allow for DOTS service flexibility, neither the order of contact nor the time interval between channel creations is specified. A DOTS client MAY establish signal channel first, and then data channel, or vice versa. The methods by which a DOTS client receives the address and associated service details of the DOTS server are not prescribed by this document. For example, a DOTS client may be directly configured Mortensen, et al. Expires December 7, 2017 [Page 16] Internet-Draft DOTS Architecture June 2017 to use a specific DOTS server IP address and port, and directly provided with any data necessary to satisfy the Peer Mutual Authentication requirement in [I-D.ietf-dots-requirements], such as symmetric or asymmetric keys, usernames and passwords, etc. All configuration and authentication information in this scenario is provided out-of-band by the domain operating the DOTS server. At the other extreme, the architecture in this document allows for a form of DOTS client auto-provisioning. For example, the domain operating the DOTS server or servers might provide the client domain only with symmetric or asymmetric keys to authenticate the provisioned DOTS clients. Only the keys would then be directly configured on DOTS clients, but the remaining configuration required to provision the DOTS clients could be learned through mechanisms similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. The DOTS client SHOULD successfully authenticate and exchange messages with the DOTS server over both signal and data channel as soon as possible to confirm that both channels are operational. As described in [I-D.ietf-dots-requirements], the DOTS client can configure preferred values for acceptable signal loss, mitigation lifetime, and heartbeat intervals when establishing the signaling session. A signaling session is not active until DOTS agents have agreed on the values for these signaling session parameters, a process defined by the protocol. Once the DOTS client begins receiving DOTS server signals, the signaling session is active. At any time during the signaling session, the DOTS client may use the data channel to adjust initial configuration, manage black- and white-listed prefixes or addresses, leverage vendor-specific extensions, and so on. Note that unlike the signal channel, there is no requirement that the data channel remain operational in attack conditions (See Data Channel Requirements, [I-D.ietf-dots-requirements]). 3.1.3. Maintaining the Signaling Session DOTS clients and servers periodically send heartbeats to each other over the signal channel, per Operational Requirements discussed in [I-D.ietf-dots-requirements]. DOTS agent operators SHOULD configure the heartbeat interval such that the frequency does not lead to accidental denials of service due to the overwhelming number of heartbeats a DOTS agent must field. Either DOTS agent may consider a signaling session terminated in the extended absence of a heartbeat from its peer agent. The period of that absence will be established in the protocol definition. Mortensen, et al. Expires December 7, 2017 [Page 17] Internet-Draft DOTS Architecture June 2017 3.2. Modes of Signaling This section examines the modes of signaling between agents in a DOTS architecture. 3.2.1. Direct Signaling A signaling session may take the form of direct signaling between the DOTS clients and servers, as shown in Figure 11. +-------------+ +-------------+ | DOTS client |<------signal session------>| DOTS server | +-------------+ +-------------+ Figure 11: Direct Signaling In a direct signaling session, DOTS client and server are communicating directly. A direct signaling session may exist inter- or intra-domain. The signaling session is abstracted from the underlying networks or network elements the signals traverse: in a direct signaling session, the DOTS client and server are logically adjacent. 3.2.2. Redirected Signaling In certain circumstances, a DOTS server may want to redirect a DOTS client to an alternative DOTS server for a signaling session. Such circumstances include but are not limited to: o Maximum number of signaling sessions with clients has been reached; o Mitigation capacity exhaustion in the mitigator with which the specific DOTS server is communicating; o Mitigator outage or other downtime, such as scheduled maintenance; o Scheduled DOTS server maintenance; o Scheduled modifications to the network path between DOTS server and DOTS client. A basic redirected signaling session resembles the following, as shown in Figure 12. Mortensen, et al. Expires December 7, 2017 [Page 18] Internet-Draft DOTS Architecture June 2017 +-------------+ +---------------+ | |<-(1)-- signal session 1 -->| | | | | | | |<=(2)== redirect to B ======| | | DOTS client | | DOTS server A | | |X-(4)-- signal session 1 --X| | | | | | | | | | +-------------+ +---------------+ ^ | (3) signal session 2 | v +---------------+ | DOTS server B | +---------------+ Figure 12: Redirected Signaling 1. Previously established signaling session 1 exists between a DOTS client and DOTS server A. 2. DOTS server A sends a server signal redirecting the client to DOTS server B. 3. If the DOTS client does not already have a separate signaling session with the redirection target, the DOTS client initiates and establishes a signaling session with DOTS server B. 4. Having redirected the DOTS client, DOTS server A ceases sending server signals. The DOTS client likewise stops sending client signals to DOTS server A. Signal session 1 is terminated. 3.2.3. Recursive Signaling DOTS is centered around improving the speed and efficiency of coordinated response to DDoS attacks. One scenario not yet discussed involves coordination among federated domains operating DOTS servers and mitigators. In the course of normal DOTS operations, a DOTS client communicates the need for mitigation to a DOTS server, and that server initiates mitigation on a mitigator with which the server has an established service relationship. The operator of the mitigator may in turn monitor mitigation performance and capacity, as the attack being mitigated may grow in severity beyond the mitigating domain's capabilities. Mortensen, et al. Expires December 7, 2017 [Page 19] Internet-Draft DOTS Architecture June 2017 The operator of the mitigator has limited options in the event a DOTS client-requested mitigation is being overwhelmed by the severity of the attack. Out-of-scope business or service level agreements may permit the mitigating domain to drop the mitigation and let attack traffic flow unchecked to the target, but this is only encourages attack escalation. In the case where the mitigating domain is the upstream service provider for the attack target, this may mean the mitigating domain and its other services and users continue to suffer the incidental effects of the attack. A recursive signaling model as shown in Figure 13 offers an alternative. In a variation of the use case "Enterprise with an upstream transit provider DDoS mitigation service" described in [I-D.ietf-dots-use-cases], a domain operating a DOTS server and mitigator also operates a DOTS client. This DOTS client has an established signaling session with a DOTS server belonging to a separate administrative domain. With these preconditions in place, the operator of the mitigator being overwhelmed or otherwise performing inadequately may request mitigation for the attack target from this separate DOTS-aware domain. Such a request recurses the originating mitigation request to the secondary DOTS server, in the hope of building a cumulative mitigation against the attack. Mortensen, et al. Expires December 7, 2017 [Page 20] Internet-Draft DOTS Architecture June 2017 example.net domain . . . . . . . . . . . . . . . . . . Gn . +----+ A . +----+ +-----------+ . | Cc |<--------->| Sn |~~~~~~~| Mitigator | . +----+ . +====+ | Mn | . . | Cn | +-----------+ . example.com . +----+ . client . ^ . . . .|. . . . . . . . . . . . . . | B | | . . .|. . . . . . . . . . . . . . . v . . +----+ +-----------+ . . | So |~~~~~~~| Mitigator | . . +----+ | Mo | . . +-----------+ . . . . . . . . . . . . . . . . . . . . example.org domain Figure 13: Recursive Signaling In Figure 13, client Cc signals a request for mitigation across inter-domain signaling session A to the DOTS server Sn belonging to the example.net domain. DOTS server Sn enables mitigation on mitigator Mn. DOTS server Sn is half of DOTS gateway Gn, being deployed logically back-to-back with DOTS client Cn, which has pre- existing inter-domain signaling session B with the DOTS server So belonging to the example.org domain. At any point, DOTS server Sn MAY recurse an on-going mitigation request through DOTS client Cn to DOTS server So, in the expectation that mitigator Mo will be activated to aid in the defense of the attack target. Recursive signaling is opaque to the DOTS client. To maximize mitigation visibility to the DOTS client, however, the recursing domain SHOULD provide recursed mitigation feedback in signals reporting on mitigation status to the DOTS client. For example, the recursing domain's mitigator should incorporate into mitigation status messages available metrics such as dropped packet or byte counts from the recursed mitigation. DOTS clients involved in recursive signaling must be able to withdraw requests for mitigation without warning or justification, per [I-D.ietf-dots-requirements]. Mortensen, et al. Expires December 7, 2017 [Page 21] Internet-Draft DOTS Architecture June 2017 Operators recursing mitigation requests MAY maintain the recursed mitigation for a brief, protocol-defined period in the event the DOTS client originating the mitigation withdraws its request for help, as per the discussion of managing mitigation toggling in the operational requirements ([I-D.ietf-dots-requirements]). [[EDITOR'S NOTE: Recursive signaling raises questions about operational and data privacy, as well as what level of visibility a client has into the recursed mitigation. We ask the working group for feedback and additional discussion of these issues to help settle the way forward.]] 3.2.4. Anycast Signaling The DOTS architecture does not assume the availability of anycast within a DOTS deployment, but neither does the architecture exclude it. Domains operating DOTS servers MAY deploy DOTS servers with an anycast Service Address as described in BCP 126 [RFC4786]. In such a deployment, DOTS clients connecting to the DOTS Service Address may be communicating with distinct DOTS servers, depending on the network configuration at the time the DOTS clients connect. Among other benefits, anycasted signaling potentially offers the following: o Simplified DOTS client configuration, including service discovery through the methods described in [RFC7094]. In this scenario, the "instance discovery" message would be a DOTS client initiating a signaling session to the DOTS server anycast Service Address, to which the DOTS server would reply with a redirection to the DOTS server unicast address the client should use for DOTS. o Region- or customer-specific deployments, in which the DOTS Service Addresses route to distinct DOTS servers depending on the client region or the customer network in which a DOTS client resides. o Operational resiliency, spreading DOTS signaling traffic across the DOTS server domain's networks, and thereby also reducing the potential attack surface, as described in BCP 126 [RFC4786]. 3.2.4.1. Anycast Signaling Considerations As long as network configuration remains stable, anycast DOTS signaling is to the individual DOTS client indistinct from direct signaling. However, the operational challenges inherent in anycast signaling are anything but negligible, and DOTS server operators must carefully weigh the risks against the benefits before deploying. Mortensen, et al. Expires December 7, 2017 [Page 22] Internet-Draft DOTS Architecture June 2017 While the DOTS signal channel primarily operates over UDP per [I-D.ietf-dots-requirements], the signal channel also requires mutual authentication between DOTS agents, with associated security state on both ends. The resulting considerations therefore superficially resemble the deployment of anycast DNS over DTLS, as described in [RFC8094], but the similarities only go so far. Network instability is of particular concern with anycast signaling, as DOTS signaling sessions are expected to be long-lived, and potentially operating under congested network conditions caused by a volumetric DDoS attack. For example, a network configuration altering the route to the DOTS server during active anycast signaling may cause the DOTS client to send messages to a DOTS server other than the one with which it initially established a signaling session. That second DOTS server may not have the security state of the existing session, forcing the DOTS client to initialize a new signaling session. This challenge may in part be mitigated by use of pre-shared keys, as described in [I-D.ietf-tls-tls13], but keying material must be available to all DOTS servers sharing the anycast Service Address in that case. While the DOTS client will try to establish a new signaling session with the DOTS server now acting as the anycast DOTS Service Address, the link between DOTS client and server may be congested with attack traffic, making signal session establishment difficult. In such a scenario, anycast Service Address instability becomes a sort of signal session flapping, with obvious negative consequences for the DOTS deployment. Anycast signaling deployments similarly must also take into account active mitigations. Active mitigations initiated through a signaling session may involve diverting traffic to a scrubbing center. If the signaling session flaps due to anycast changes as described above, mitigation may also flap as the DOTS servers sharing the anycast DOTS service address toggles mitigation on detecting signaling session loss, depending on whether the client has configured mitigation on loss of signal. 3.3. Triggering Requests for Mitigation [I-D.ietf-dots-requirements] places no limitation on the circumstances in which a DOTS client operator may request mitigation, nor does it demand justification for any mitigation request, thereby reserving operational control over DDoS defense for the domain requesting mitigation. This architecture likewise does not prescribe the network conditions and mechanisms triggering a mitigation request from a DOTS client. Mortensen, et al. Expires December 7, 2017 [Page 23] Internet-Draft DOTS Architecture June 2017 However, considering selected possible mitigation triggers from an architectural perspective offers a model for alternative or unanticipated triggers for DOTS deployments. In all cases, what network conditions merit a mitigation request are at the discretion of the DOTS client operator. The interfaces required to trigger the mitigation request in the following scenarios are implementation-specific. 3.3.1. Manual Mitigation Request A DOTS client operator may manually prepare a request for mitigation, including scope and duration, and manually instruct the DOTS client to send the mitigation request to the DOTS server. In context, a manual request is a request directly issued by the operator without automated decision-making performed by a device interacting with the DOTS client. Modes of manual mitigation requests include an operator entering a command into a text interface, or directly interacting with a graphical interface to send the request. An operator might do this, for example, in response to notice of an attack delivered by attack detection equipment or software, and the alerting detector lacks interfaces or is not configured to use available interfaces to translate the alert to a mitigation request automatically. In a variation of the above scenario, the operator may have preconfigured on the DOTS client mitigation request for various resources in the operator's domain. When notified of an attack, the DOTS client operator manually instructs the DOTS client to send the preconfigured mitigation request for the resources under attack. A further variant involves recursive signaling, as described in Section 3.2.3. The DOTS client in this case is the second half of a DOTS gateway (back-to-back DOTS server and client). As in the previous scenario, the scope and duration of the mitigation request are pre-existing, but in this case are derived from the mitigation request received from a downstream DOTS client by the DOTS server. Assuming the preconditions required by Section 3.2.3 are in place, the DOTS gateway operator may at any time manually request mitigation from an upstream DOTS server, sending a mitigation request derived from the downstream DOTS client's request. The motivations for a DOTS client operator to request mitigation manually are not prescribed by this architecture, but are expected to include some of the following: o Notice of an attack delivered via e-mail or alternative messaging Mortensen, et al. Expires December 7, 2017 [Page 24] Internet-Draft DOTS Architecture June 2017 o Notice of an attack delivered via phone call o Notice of an attack delivered through the interface(s) of networking monitoring software deployed in the operator's domain o Manual monitoring of network behavior through network monitoring software 3.3.2. Automated Conditional Mitigation Request Unlike manual mitigation requests, which depend entirely on the DOTS client operator's capacity to react with speed and accuracy to every detected or detectable attack, mitigation requests triggered by detected attack conditions reduce the operational burden on the DOTS client operator, and minimize the latency between attack detection and the start of mitigation. Mitigation requests are triggered in this scenario by operator- specified network conditions. Attack detection is deployment- specific, and not constrained by this architecture. Similarly the specifics of a condition are left to the discretion of the operator, though common conditions meriting mitigation include the following: o Detected attack exceeding a rate in packets per second (pps). o Detected attack exceeding a rate in bytes per second (bps). o Detected resource exhaustion in an attack target. o Detected resource exhaustion in the local domain's mitigator. o Number of open connections to an attack target. o Number of attack sources in a given attack. o Number of active attacks against targets in the operator's domain. o Conditional detection developed through arbitrary statistical analysis or deep learning techniques. o Any combination of the above. When automated conditional mitigation requests are enabled, violations of any of the above conditions, or any additional operator-defined conditions, will trigger a mitigation request from the DOTS client to the DOTS server. The interfaces between the application detecting the condition violation and the DOTS client are implementation-specific. Mortensen, et al. Expires December 7, 2017 [Page 25] Internet-Draft DOTS Architecture June 2017 3.3.3. Automated Mitigation on Loss of Signal To maintain a signaling session, the DOTS client and the DOTS server exchange regular but infrequent messages across the signaling channel. In the absence of an attack, the probability of message loss in the signaling channel should be extremely low. Under attack conditions, however, some signal loss may be anticipated as attack traffic congests the link, depending on the attack type. While [I-D.ietf-dots-requirements] specifies the DOTS protocol be robust when signaling under attack conditions, there are nevertheless scenarios in which the DOTS signal is lost in spite of protocol best efforts. To handle such scenarios, a DOTS client operator may configure the signaling session to trigger mitigation when the DOTS server ceases receiving DOTS client signals (or vice versa) beyond the miss count or period permitted by the protocol. The impact of mitigating due to loss of signal in either direction must be considered carefully before enabling it. Signal loss is not caused by links congested with attack traffic alone, and as such mitigation requests triggered by signal channel degradation in either direction may incur unnecessary costs, in network performance and operational expense alike. 4. Security Considerations This section describes identified security considerations for the DOTS architecture. DOTS is at risk from three primary attack vectors: agent impersonation, traffic injection and signal blocking. These vectors may be exploited individually or in concert by an attacker to confuse, disable, take information from, or otherwise inhibit DOTS agents. Any attacker with the ability to impersonate a legitimate client or server or, indeed, inject false messages into the stream may potentially trigger/withdraw traffic redirection, trigger/cancel mitigation activities or subvert black/whitelists. From an architectural standpoint, operators SHOULD ensure best current practices for secure communication are observed for data and signal channel confidentiality, integrity and authenticity. Care must be taken to ensure transmission is protected by appropriately secure means, reducing attack surface by exposing only the minimal required services or interfaces. Similarly, received data at rest SHOULD be stored with a satisfactory degree of security. Mortensen, et al. Expires December 7, 2017 [Page 26] Internet-Draft DOTS Architecture June 2017 As many mitigation systems employ diversion to scrub attack traffic, operators of DOTS agents SHOULD ensure signaling sessions are resistant to Man-in-the-Middle (MitM) attacks. An attacker with control of a DOTS client may negatively influence network traffic by requesting and withdrawing requests for mitigation for particular prefixes, leading to route or DNS flapping. Any attack targeting the availability of DOTS servers may disrupt the ability of the system to receive and process DOTS signals resulting in failure to fulfill a mitigation request. DOTS agents SHOULD be given adequate protections, again in accordance with best current practices for network and host security. 5. Contributors Mohamed Boucadair Orange mohamed.boucadair@orange.com 6. Acknowledgments Thanks to Matt Richardson and Med Boucadair for their comments and suggestions. 7. Change Log 2016-03-18 Initial revision 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [I-D.ietf-dots-requirements] Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements", draft-ietf-dots-requirements-04 (work in progress), March 2017. Mortensen, et al. Expires December 7, 2017 [Page 27] Internet-Draft DOTS Architecture June 2017 [I-D.ietf-dots-use-cases] Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling (DDoS) Open Threat Signaling", draft-ietf-dots-use-cases-05 (work in progress), May 2017. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-20 (work in progress), April 2017. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, . [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . Mortensen, et al. Expires December 7, 2017 [Page 28] Internet-Draft DOTS Architecture June 2017 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, . [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, . [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, . Authors' Addresses Andrew Mortensen Arbor Networks 2727 S. State St Ann Arbor, MI 48104 United States EMail: amortensen@arbor.net Flemming Andreasen Cisco United States EMail: fandreas@cisco.com Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India EMail: tireddy@cisco.com Christopher Gray Comcast United States EMail: Christopher_Gray3@cable.comcast.com Mortensen, et al. Expires December 7, 2017 [Page 29] Internet-Draft DOTS Architecture June 2017 Rich Compton Charter EMail: Rich.Compton@charter.com Nik Teague Verisign United States EMail: nteague@verisign.com Mortensen, et al. Expires December 7, 2017 [Page 30]