draft-ietf-dots-architecture-02.txt   draft-ietf-dots-architecture-03.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks, Inc. Internet-Draft Arbor Networks
Intended status: Informational F. Andreasen Intended status: Informational F. Andreasen
Expires: November 2, 2017 T. Reddy Expires: December 7, 2017 Cisco
Cisco Systems, Inc. T. Reddy
McAfee, Inc.
C. Gray C. Gray
Comcast, Inc. Comcast
R. Compton R. Compton
Charter Communications, Inc. Charter
N. Teague N. Teague
Verisign, Inc. Verisign
May 01, 2017 June 05, 2017
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-02 draft-ietf-dots-architecture-03
Abstract Abstract
This document describes an architecture for establishing and This document describes an architecture for establishing and
maintaining Distributed Denial of Service (DDoS) Open Threat maintaining Distributed Denial of Service (DDoS) Open Threat
Signaling (DOTS) within and between domains. The document does not Signaling (DOTS) within and between domains. The document does not
specify protocols or protocol extensions, instead focusing on specify protocols or protocol extensions, instead focusing on
defining architectural relationships, components and concepts used in defining architectural relationships, components and concepts used in
a DOTS deployment. a DOTS deployment.
skipping to change at page 1, line 43 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 2, 2017. This Internet-Draft will expire on December 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Context and Motivation . . . . . . . . . . . . . . . . . . . 3 1. Context and Motivation . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Definition of Terms . . . . . . . . . . . . . . . . . 3 1.1.2. Definition of Terms . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 2. DOTS Architecture . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8 2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8
2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11 2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11
2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 11 2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 12
2.3.1. Gatewayed signaling . . . . . . . . . . . . . . . . . 13 2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 14
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 15 3.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 16
3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Establishing the Signaling Session . . . . . . . . . 16 3.1.2. Establishing the Signaling Session . . . . . . . . . 16
3.1.3. Maintaining the Signaling Session . . . . . . . . . . 17 3.1.3. Maintaining the Signaling Session . . . . . . . . . . 17
3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 17 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18
3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 17 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18
3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18
3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19 3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19
3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 21 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22
3.3. Triggering Requests for Mitigation . . . . . . . . . . . 23 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 23
3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 23 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 24
3.3.2. Automated Conditional Mitigation Request . . . . . . 24 3.3.2. Automated Conditional Mitigation Request . . . . . . 25
3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 25 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 26
4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Context and Motivation 1. Context and Motivation
Signaling the need for help defending against an active distributed Signaling the need for help defending against an active distributed
denial of service (DDoS) attack requires a common understanding of denial of service (DDoS) attack requires a common understanding of
mechanisms and roles among the parties coordinating defensive mechanisms and roles among the parties coordinating defensive
response. The signaling layer and supplementary messaging is the response. The signaling layer and supplementary messaging is the
focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of
coordinating defensive measures among willing peers to mitigate coordinating defensive measures among willing peers to mitigate
attacks quickly and efficiently, enabling hybrid attack responses attacks quickly and efficiently, enabling hybrid attack responses
coordinated locally at or near the target of an active attack, or coordinated locally at or near the target of an active attack, or
anywhere in-path between attack sources and target. 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, This document describes an architecture used in establishing,
maintaining or terminating a DOTS relationship within a domain or maintaining or terminating a DOTS relationship within a domain or
between domains. between domains.
1.1. Terminology 1.1. Terminology
1.1.1. Key Words 1.1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 3, line 47 skipping to change at page 4, line 5
server may modify the forwarding path of traffic destined for the server may modify the forwarding path of traffic destined for the
attack target(s), for example by diverting traffic to a mitigator or attack target(s), for example by diverting traffic to a mitigator or
pool of mitigators, where policy may be applied to distinguish and pool of mitigators, where policy may be applied to distinguish and
discard attack traffic. Any such policy is deployment-specific. discard attack traffic. Any such policy is deployment-specific.
The DOTS architecture presented here is applicable across network The DOTS architecture presented here is applicable across network
administrative domains - for example, between an enterprise domain administrative domains - for example, between an enterprise domain
and the domain of a third-party attack mitigation service - as well and the domain of a third-party attack mitigation service - as well
as to a single administrative domain. DOTS is generally assumed to as to a single administrative domain. DOTS is generally assumed to
be most effective when aiding coordination of attack response between be most effective when aiding coordination of attack response between
two or more participating network domains, but single domain two or more participating networks, but single domain scenarios are
scenarios are valuable in their own right, as when aggregating intra- valuable in their own right, as when aggregating intra-domain DOTS
domain DOTS client signals for inter-domain coordinated attack client signals for inter-domain coordinated attack response.
response.
This document does not address any administrative or business This document does not address any administrative or business
agreements that may be established between involved DOTS parties. agreements that may be established between involved DOTS parties.
Those considerations are out of scope. Regardless, this document Those considerations are out of scope. Regardless, this document
assumes necessary authentication and authorization mechanisms are put assumes necessary authentication and authorization mechanisms are put
in place so that only authorized clients can invoke the DOTS service. 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 1.3. Assumptions
This document makes the following assumptions: This document makes the following assumptions:
o All domains in which DOTS is deployed are assumed to offer the o All domains in which DOTS is deployed are assumed to offer the
required connectivity between DOTS agents and any intermediary required connectivity between DOTS agents and any intermediary
network elements, but the architecture imposes no additional network elements, but the architecture imposes no additional
limitations on the form of connectivity. limitations on the form of connectivity.
o Congestion and resource exhaustion are intended outcomes of a DDoS o Congestion and resource exhaustion are intended outcomes of a DDoS
skipping to change at page 4, line 34 skipping to change at page 4, line 43
circumstances, including when the signaling path is significantly circumstances, including when the signaling path is significantly
impaired. impaired.
o There is no universal DDoS attack scale threshold triggering a o There is no universal DDoS attack scale threshold triggering a
coordinated response across administrative domains. A network coordinated response across administrative domains. A network
domain administrator, or service or application owner may domain administrator, or service or application owner may
arbitrarily set attack scale threshold triggers, or manually send arbitrarily set attack scale threshold triggers, or manually send
requests for mitigation. requests for mitigation.
o Mitigation requests may be sent to one or more upstream DOTS o Mitigation requests may be sent to one or more upstream DOTS
servers based on criteria determined by DOTS client servers based on criteria determined by DOTS client administrators
administrators. The number of DOTS servers with which a given and the underlying network configuration. The number of DOTS
DOTS client has established signaling sessions is determined by servers with which a given DOTS client has established signaling
local policy and is deployment-specific. 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.
o The mitigation capacity and/or capability of domains receiving o The mitigation capacity and/or capability of domains receiving
requests for coordinated attack response is opaque to the domains requests for coordinated attack response is opaque to the domains
sending the request. The domain receiving the DOTS client signal sending the request. The domain receiving the DOTS client signal
may or may not have sufficient capacity or capability to filter may or may not have sufficient capacity or capability to filter
any or all DDoS attack traffic directed at a target. In either any or all DDoS attack traffic directed at a target. In either
case, the upstream DOTS server may redirect a request to another case, the upstream DOTS server may redirect a request to another
DOTS server. Redirection may be local to the redirecting DOTS DOTS server. Redirection may be local to the redirecting DOTS
server's domain, or may involve a third-party domain. server's domain, or may involve a third-party domain.
o DOTS client and server signals, as well as messages sent through o DOTS client and server signals, as well as messages sent through
the data channel, are sent across any transit networks with the the data channel, are sent across any transit networks with the
same probability of delivery as any other traffic between the DOTS same probability of delivery as any other traffic between the DOTS
client domain and the DOTS server domain. Any encapsulation client domain and the DOTS server domain. Any encapsulation
required for successful delivery is left untouched by transit required for successful delivery is left untouched by transit
network elements. DOTS server and DOTS client cannot assume any network elements. DOTS server and DOTS client cannot assume any
preferential treatment of DOTS signals. Such preferential preferential treatment of DOTS signals. Such preferential
treatment may be available in some deployments, and the DOTS treatment may be available in some deployments (e.g., intra-domain
architecture does not preclude its use when available. However, scenarios), and the DOTS architecture does not preclude its use
DOTS itself does not address how that may be done. 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 o The architecture allows for, but does not assume, the presence of
Quality of Service (QoS) policy agreements between DOTS-enabled Quality of Service (QoS) policy agreements between DOTS-enabled
peer networks or local QoS prioritization aimed at ensuring peer networks or local QoS prioritization aimed at ensuring
delivery of DOTS messages between DOTS agents. QoS is an delivery of DOTS messages between DOTS agents. QoS is an
operational consideration only, not a functional part of the DOTS operational consideration only, not a functional part of the DOTS
architecture. architecture.
o The signal channel and the data channel may be loosely coupled, o The signal and data channels may be loosely coupled, and may not
and need not terminate on the same DOTS server. terminate on the same DOTS server.
2. Architecture 2. DOTS Architecture
The basic high-level DOTS architecture is illustrated in Figure 1: The basic high-level DOTS architecture is illustrated in Figure 1:
+-----------+ +-------------+ +-----------+ +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server | | Mitigator | ~~~~~~~~~~ | DOTS Server |
+-----------+ +-------------+ +-----------+ +-------------+
| |
| |
| |
+---------------+ +-------------+ +---------------+ +-------------+
| Attack Target | ~~~~~~ | DOTS Client | | Attack Target | ~~~~~~ | DOTS Client |
+---------------+ +-------------+ +---------------+ +-------------+
Figure 1: Basic DOTS Architecture Figure 1: Basic DOTS Architecture
A simple example instantiation of the DOTS architecture could be an A simple example instantiation of the DOTS architecture could be an
enterprise as the attack target for a volumetric DDoS attack, and an enterprise as the attack target for a volumetric DDoS attack, and an
upstream DDoS mitigation service as the Mitigator. The enterprise upstream DDoS mitigation service as the mitigator. The enterprise
(attack target) is connected to the Internet via a link that is (attack target) is connected to the Internet via a link that is
getting saturated, and the enterprise suspects it is under DDoS getting saturated, and the enterprise suspects it is under DDoS
attack. The enterprise has a DOTS client, which obtains information attack. The enterprise has a DOTS client, which obtains information
about the DDoS attack, and signals the DOTS server for help in about the DDoS attack, and signals the DOTS server for help in
mitigating the attack. The DOTS server in turn invokes one or more mitigating the attack. The DOTS server in turn invokes one or more
mitigators, which are tasked with mitigating the actual DDoS attack, mitigators, which are tasked with mitigating the actual DDoS attack,
and hence aim to suppress the attack traffic while allowing valid and hence aim to suppress the attack traffic while allowing valid
traffic to reach the attack target. traffic to reach the attack target.
The scope of the DOTS specifications is the interfaces between the The scope of the DOTS specifications is the interfaces between the
DOTS client and DOTS server. The interfaces to the attack target and DOTS client and DOTS server. The interfaces to the attack target and
the mitigator are out of scope of DOTS. Similarly, the operation of the mitigator are out of scope of DOTS. Similarly, the operation of
both the attack target and the mitigator are out of scope of DOTS. 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 Thus, DOTS neither specifies how an attack target decides it is under
DDoS attack, nor does DOTS specify how a mitigator may actually DDoS attack, nor does DOTS specify how a mitigator may actually
mitigate such an attack. A DOTS client's request for mitigation is mitigate such an attack. A DOTS client's request for mitigation is
advisory in nature, and may not lead to any mitigation at all, advisory in nature, and may not lead to any mitigation at all,
depending on the DOTS server domain's capacity and willingness to depending on the DOTS server domain's capacity and willingness to
mitigate on behalf of the DOTS client's domain. mitigate on behalf of the DOTS client's domain.
As illustrated in Figure 2, there are two interfaces between the DOTS As illustrated in Figure 2, there are two interfaces between the DOTS
server and the DOTS client: server and the DOTS client.
+---------------+ +---------------+ +---------------+ +---------------+
| | <------- Signal Channel ------> | | | | <------- Signal Channel ------> | |
| DOTS Client | | DOTS Server | | DOTS Client | | DOTS Server |
| | <======= Data Channel ======> | | | | <======= Data Channel ======> | |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 2: DOTS Interfaces Figure 2: DOTS Interfaces
The DOTS client may be provided with a list of DOTS servers, each 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 associated with one or more IP addresses. These addresses may or may
not be of the same address family. The DOTS client establishes one not be of the same address family. The DOTS client establishes one
or more signaling sessions by connecting to the provided DOTS server or more signaling sessions by connecting to the provided DOTS server
addresses. addresses.
The primary purpose of the signal channel is for a DOTS client to ask 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 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. server to inform the DOTS client about the status of such mitigation.
The DOTS client does this by sending a client signal, which contains The DOTS client does this by sending a client signal, which contains
information about the attack target or targets. The client signal information about the attack target(s). The client signal may also
may also include telemetry information about the attack, if the DOTS include telemetry information about the attack, if the DOTS client
client has such information available. The DOTS server in turn sends has such information available. The DOTS server in turn sends a
a server signal to inform the DOTS client of whether it will honor server signal to inform the DOTS client of whether it will honor the
the mitigation request. Assuming it will, the DOTS server initiates mitigation request. Assuming it will, the DOTS server initiates
attack mitigation (by means outside of DOTS), and periodically attack mitigation, and periodically informs the DOTS client about the
informs the DOTS client about the status of the mitigation. status of the mitigation. Similarly, the DOTS client periodically
Similarly, the DOTS client periodically informs the DOTS server about informs the DOTS server about the client's status, which at a minimum
the client's status, which at a minimum provides client (attack provides client (attack target) health information, but it may also
target) health information, but it may also include telemetry include telemetry information about the attack as it is now seen by
information about the attack as it is now seen by the client. At the client. At some point, the DOTS client may decide to terminate
some point, the DOTS client may decide to terminate the server-side the server-side attack mitigation, which it indicates to the DOTS
attack mitigation, which it indicates to the DOTS server over the server over the signal channel. A mitigation may also be terminated
signal channel. A mitigation may also be terminated if a DOTS if a DOTS client-specified mitigation lifetime is exceeded. Note
client-specified mitigation time limit is exceeded; additional that the signal channel may need to operate over a link that is
considerations around mitigation time limits may be found below.
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 experiencing a DDoS attack and hence is subject to severe packet loss
and high latency. and high latency.
While DOTS is able to request mitigation with just the signal While DOTS is able to request mitigation with just the signal
channel, the addition of the DOTS data channel provides for channel, the addition of the DOTS data channel provides for
additional and more efficient capabilities; both channels are additional and more efficient capabilities; both channels are
required in the DOTS architecture. The primary purpose of the data required in the DOTS architecture. The primary purpose of the data
channel is to support DOTS related configuration and policy channel is to support DOTS related configuration and policy
information exchange between the DOTS client and the DOTS server. information exchange between the DOTS client and the DOTS server.
Examples of such information include, but are not limited to: Examples of such information include, but are not limited to:
o Creating identifiers, such as names or aliases, for resources for o Creating identifiers, such as names or aliases, for resources for
which mitigation may be requested. Such identifiers may then be which mitigation may be requested. Such identifiers may then be
used in subsequent signal channel exchanges to refer more used in subsequent signal channel exchanges to refer more
efficiently to the resources under attack, as seen in Figure 3 efficiently to the resources under attack, as seen in Figure 3,
below, using JSON to serialize the data: using JSON to serialize the data:
{ {
"https1": [ "https1": [
"192.0.2.1:443", "192.0.2.1:443",
"198.51.100.2:443", "198.51.100.2:443",
], ],
"proxies": [ "proxies": [
"203.0.113.3:3128", "203.0.113.3:3128",
"[2001:DB8:AC10::1]:3128" "[2001:db8:ac10::1]:3128"
], ],
"api_urls": "https://apiserver.example.com/api/v1", "api_urls": "https://apiserver.example.com/api/v1",
} }
Figure 3: Protected resource identifiers Figure 3: Protected resource identifiers
o Black-list management, which enables a DOTS client to inform the o Black-list management, which enables a DOTS client to inform the
DOTS server about sources to suppress. DOTS server about sources to suppress.
o White-list management, which enables a DOTS client to inform the o White-list management, which enables a DOTS client to inform the
DOTS server about sources from which traffic should always be DOTS server about sources from which traffic is always accepted.
accepted.
o Filter management, which enables a DOTS client to install or o Filter management, which enables a DOTS client to install or
remove traffic filters dropping or rate-limiting unwanted traffic. remove traffic filters dropping or rate-limiting unwanted traffic.
o DOTS client provisioning. o DOTS client provisioning.
Note that while it is possible to exchange the above information Note that while it is possible to exchange the above information
before, during or after a DDoS attack, DOTS requires reliable before, during or after a DDoS attack, DOTS requires reliable
delivery of this information and does not provide any special means delivery of this information and does not provide any special means
for ensuring timely delivery of it during an attack. In practice, for ensuring timely delivery of it during an attack. In practice,
this means that DOTS deployments SHOULD NOT rely on such information this means that DOTS deployments should not rely on such information
being exchanged during a DDoS attack. being exchanged during a DDoS attack.
2.1. DOTS Operations 2.1. DOTS Operations
The scope of DOTS is focused on the signaling and data exchange DOTS does not prescribe any specific deployment models, however DOTS
between the DOTS client and DOTS server. DOTS does not prescribe any is designed with some specific requirements around the different DOTS
specific deployment models, however DOTS is designed with some agents and their relationships.
specific requirements around the different DOTS agents and their
relationships.
First of all, a DOTS agent belongs to an domain, and that domain has First of all, a DOTS agent belongs to a domain that has an identity
an identity which can be authenticated and authorized. DOTS agents which can be authenticated and authorized. DOTS agents communicate
communicate with each other over a mutually authenticated signal with each other over a mutually authenticated signal channel and data
channel and data channel. However, before they can do so, a service channel. However, before they can do so, a service relationship
relationship needs to be established between them. The details and needs to be established between them. The details and means by which
means by which this is done is outside the scope of DOTS, however an this is done is outside the scope of DOTS, however an example would
example would be for an enterprise A (DOTS client) to sign up for be for an enterprise A (DOTS client) to sign up for DDoS service from
DDoS service from provider B (DOTS server). This would establish a provider B (DOTS server). This would establish a (service)
(service) relationship between the two that enables enterprise A's relationship between the two that enables enterprise A's DOTS client
DOTS client to establish a signal channel with provider B's DOTS to establish a signal channel with provider B's DOTS server. A and B
server. A and B will authenticate each other, and B can verify that will authenticate each other, and B can verify that A is authorized
A is authorized for its service. for its service.
From an operational and design point of view, DOTS assumes that the From an operational and design point of view, DOTS assumes that the
above relationship is established prior to a request for DDoS attack above relationship is established prior to a request for DDoS attack
mitigation. In particular, it is assumed that bi-directional mitigation. In particular, it is assumed that bi-directional
communication is possible at this time between the DOTS client and communication is possible at this time between the DOTS client and
DOTS server. Furthermore, it is assumed that additional service DOTS server. Furthermore, it is assumed that additional service
provisioning, configuration and information exchange can be performed provisioning, configuration and information exchange can be performed
by use of the data channel, if operationally required. It is not by use of the data channel, if operationally required. It is not
until this point that the mitigation service is available for use. until this point that the mitigation service is available for use.
Once the mutually authenticated signal channel has been established, Once the mutually authenticated signal channel has been established,
it will remain in place. This is done to increase the likelihood it will remain active. This is done to increase the likelihood that
that the DOTS client can signal the DOTS server for help when the the DOTS client can signal the DOTS server for help when the attack
attack target is being flooded, and similarly raise the probability target is being flooded, and similarly raise the probability that
that DOTS server signals reach the client regardless of inbound link DOTS server signals reach the client regardless of inbound link
congestion. This does not necessarily imply that the attack target congestion. This does not necessarily imply that the attack target
and the DOTS client have to be co-located in the same administrative and the DOTS client have to be co-located in the same administrative
domain, but it is expected to be a common scenario. domain, but it is expected to be a common scenario.
DDoS mitigation service with the help of an upstream mitigator will DDoS mitigation with the help of an upstream mitigator may involve
often involve some form of traffic redirection whereby traffic some form of traffic redirection whereby traffic destined for the
destined for the attack target is diverted towards the mitigator, attack target is steered towards the mitigator. Common mechanisms to
e.g. by use of BGP [RFC4271] or DNS [RFC1034]. The mitigator in turn achieve this redirection depend on BGP [RFC4271] and DNS [RFC1035].
inspects and scrubs the traffic, and forwards the resulting The mitigator in turn inspects and scrubs the traffic, and forwards
(hopefully non-attack) traffic to the attack target. Thus, when a the resulting (hopefully non-attack) traffic to the attack target.
DOTS server receives an attack mitigation request from a DOTS client, Thus, when a DOTS server receives an attack mitigation request from a
it can be viewed as a way of causing traffic redirection for the DOTS client, it can be viewed as a way of causing traffic redirection
attack target indicated. for the attack target indicated.
DOTS relies on mutual authentication and the pre-established service DOTS relies on mutual authentication and the pre-established service
relationship between the DOTS client's domain and the DOTS server's relationship between the DOTS client's domain and the DOTS server's
domain to provide basic authorization. The DOTS server SHOULD domain to provide basic authorization. The DOTS server should
enforce additional authorization mechanisms to restrict the enforce additional authorization mechanisms to restrict the
mitigation scope a DOTS client can request, but such authorization mitigation scope a DOTS client can request, but such authorization
mechanisms are deployment-specific. mechanisms are deployment-specific.
Although co-location of DOTS server and mitigator within the same Although co-location of DOTS server and mitigator within the same
domain is expected to be a common deployment model, it is assumed domain is expected to be a common deployment model, it is assumed
that operators may require alternative models. Nothing in this that operators may require alternative models. Nothing in this
document precludes such alternatives. document precludes such alternatives.
2.2. Components 2.2. Components
2.2.1. DOTS Client 2.2.1. DOTS Client
A DOTS client is a DOTS agent from which requests for help A DOTS client is a DOTS agent from which requests for help
coordinating attack response originate. The requests may be in coordinating attack response originate. The requests may be in
response to an active, ongoing attack against a target in the DOTS 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 client's domain, but no active attack is required for a DOTS client
to request help. Local operators may wish to have upstream to request help. Operators may wish to have upstream mitigators in
mitigators in the network path for an indefinite period, and are the network path for an indefinite period, and are restricted only by
restricted only by business relationships when it comes to duration business relationships when it comes to duration and scope of
and scope of requested mitigation. requested mitigation.
The DOTS client requests attack response coordination from a DOTS The DOTS client requests attack response coordination from a DOTS
server over the signal channel, including in the request the DOTS server over the signal channel, including in the request the DOTS
client's desired mitigation scoping, as described in client's desired mitigation scoping, as described in
[I-D.ietf-dots-requirements]. The actual mitigation scope and [I-D.ietf-dots-requirements]. The actual mitigation scope and
countermeasures used in response to the attack are up to the DOTS countermeasures used in response to the attack are up to the DOTS
server and Mitigator operators, as the DOTS client may have a narrow server and mitigator operators, as the DOTS client may have a narrow
perspective on the ongoing attack. As such, the DOTS client's perspective on the ongoing attack. As such, the DOTS client's
request for mitigation should be considered advisory: guarantees of request for mitigation should be considered advisory: guarantees of
DOTS server availability or mitigation capacity constitute service DOTS server availability or mitigation capacity constitute service
level agreements and are out of scope for this document. level agreements and are out of scope for this document.
The DOTS client adjusts mitigation scope and provides available The DOTS client adjusts mitigation scope and provides available
attack details at the direction of its local operator. Such attack details at the direction of its local administrator. Such
direction may involve manual or automated adjustments in response to direction may involve manual or automated adjustments in response to
feedback from the DOTS server. feedback from the DOTS server.
To provide a metric of signal health and distinguish an idle To provide a metric of signal health and distinguish an idle
signaling session from a disconnected or defunct session, the DOTS signaling session from a disconnected or defunct session, the DOTS
client sends a heartbeat over the signal channel to maintain its half client sends a heartbeat over the signal channel to maintain its half
of the signaling session. The DOTS client similarly expects a of the signaling session. The DOTS client similarly expects a
heartbeat from the DOTS server, and MAY consider a signaling session heartbeat from the DOTS server, and may consider a signaling session
terminated in the extended absence of a DOTS server heartbeat. terminated in the extended absence of a DOTS server heartbeat.
2.2.2. DOTS Server 2.2.2. DOTS Server
A DOTS server is a DOTS agent capable of receiving, processing and A DOTS server is a DOTS agent capable of receiving, processing and
possibly acting on requests for help coordinating attack response possibly acting on requests for help coordinating attack response
from one or more DOTS clients. The DOTS server authenticates and DOTS clients. The DOTS server authenticates and authorizes DOTS
authorizes DOTS clients as described in Signaling Sessions below, and clients as described in Section 3.1, and maintains signaling session
maintains signaling session state, tracking requests for mitigation, state, tracking requests for mitigation, reporting on the status of
reporting on the status of active mitigations, and terminating active mitigations, and terminating signaling sessions in the
signaling sessions in the extended absence of a client heartbeat or extended absence of a client heartbeat or when a session times out.
when a session times out.
Assuming the preconditions discussed below exist, a DOTS client Assuming the preconditions discussed below exist, a DOTS client
maintaining an active signaling session with a DOTS server may maintaining an active signaling session with a DOTS server may
reasonably expect some level of mitigation in response to a request reasonably expect some level of mitigation in response to a request
for coordinated attack response. for coordinated attack response.
The DOTS server enforces authorization of DOTS clients' signals for The DOTS server enforces authorization of DOTS clients' signals for
mitigation. The mechanism of enforcement is not in scope for this mitigation. The mechanism of enforcement is not in scope for this
document, but is expected to restrict requested mitigation scope to document, but is expected to restrict requested mitigation scope to
addresses, prefixes, and/or services owned by the DOTS client's addresses, prefixes, and/or services owned by the DOTS client's
skipping to change at page 10, line 37 skipping to change at page 10, line 45
MUST reject requests for mitigation of resources not owned by the MUST reject requests for mitigation of resources not owned by the
requesting DOTS client's administrative domain. A DOTS server MAY requesting DOTS client's administrative domain. A DOTS server MAY
also refuse a DOTS client's mitigation request for arbitrary reasons, also refuse a DOTS client's mitigation request for arbitrary reasons,
within any limits imposed by business or service level agreements within any limits imposed by business or service level agreements
between client and server domains. If a DOTS server refuses a DOTS between client and server domains. If a DOTS server refuses a DOTS
client's request for mitigation, the DOTS server SHOULD include the client's request for mitigation, the DOTS server SHOULD include the
refusal reason in the server signal sent to the client. 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 is in regular contact with one or more mitigators. If
a DOTS server accepts a DOTS client's request for help, the DOTS a DOTS server accepts a DOTS client's request for help, the DOTS
server forwards a translated form of that request to the mitigator or server forwards a translated form of that request to the mitigator(s)
mitigators responsible for scrubbing attack traffic. Note that the responsible for scrubbing attack traffic. Note that the form of the
form of the translated request passed from the DOTS server to the translated request passed from the DOTS server to the mitigator is
mitigator is not in scope: it may be as simple as an alert to not in scope: it may be as simple as an alert to mitigator operators,
mitigator operators, or highly automated using vendor or open or highly automated using vendor or open application programming
application programming interfaces supported by the mitigator. The interfaces supported by the mitigator. The DOTS server MUST report
DOTS server MUST report the actual scope of any mitigation enabled on the actual scope of any mitigation enabled on behalf of a client.
behalf of a client.
The DOTS server SHOULD retrieve available metrics for any mitigations The DOTS server SHOULD retrieve available metrics for any mitigations
activated on behalf of a DOTS client, and SHOULD include them in activated on behalf of a DOTS client, and SHOULD include them in
server signals sent to the DOTS client originating the request for server signals sent to the DOTS client originating the request for
mitigation. mitigation.
To provide a metric of signal health and distinguish an idle To provide a metric of signal health and distinguish an idle
signaling session from a disconnected or defunct session, the DOTS signaling session from a disconnected or defunct session, the DOTS
server sends a heartbeat over the signal channel to maintain its half server MUST send a heartbeat over the signal channel to maintain its
of the signaling session. The DOTS server similarly expects a half of the signaling session. The DOTS server similarly expects a
heartbeat from the DOTS client, and MAY consider a signaling session heartbeat from the DOTS client, and MAY consider a signaling session
terminated in the extended absence of a DOTS client heartbeat. terminated in the extended absence of a DOTS client heartbeat.
2.2.3. DOTS Gateway 2.2.3. DOTS Gateway
Traditional client to server relationships may be expanded by Traditional client/server relationships may be expanded by chaining
chaining DOTS sessions. This chaining is enabled through "logical DOTS sessions. This chaining is enabled through "logical
concatenation" [RFC7092] of a DOTS server and a DOTS client, concatenation" of a DOTS server and a DOTS client, resulting in an
resulting in an application analogous to the SIP logical entity of a application analogous to the SIP logical entity of a Back-to-Back
Back-to-Back User Agent (B2BUA) [RFC3261]. The term DOTS gateway User Agent (B2BUA) [RFC7092]. The term DOTS gateway is used here in
will be used here and the following text will describe some the descriptions of selected scenarios involving this application.
interactions in relation to this application.
A DOTS gateway may be deployed client-side, server-side or both. The A DOTS gateway may be deployed client-side, server-side or both. The
gateway may terminate multiple discrete client connections and may gateway may terminate multiple discrete client connections and may
aggregate these into a single or multiple DOTS signaling sessions. aggregate these into a single or multiple DOTS signaling sessions.
The DOTS gateway will appear as a server to its downstream agents and 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 as a client to its upstream agents, a functional concatenation of the
DOTS client and server roles, as depicted in Figure 4: DOTS client and server roles, as depicted in Figure 4:
+-------------+ +-------------+
| | D | | | | D | |
+----+ | | O | | +----+ +----+ | | O | | +----+
| c1 |----------| s1 | T | c2 |---------| s2 | | c1 |----------| s1 | T | c2 |---------| s2 |
+----+ | | S | | +----+ +----+ | | S | | +----+
| | G | | | | G | |
+-------------+ +-------------+
Figure 4: DOTS gateway Figure 4: DOTS gateway
The DOTS gateway performs full stack DOTS session termination and The DOTS gateway MUST perform full stack DOTS session termination and
reorigination between its client and server side. The details of how reorigination between its client and server side. The details of how
this is achieved are implementation specific. The DOTS protocol does this is achieved are implementation specific. The DOTS protocol does
not include any special features related to DOTS gateways, and hence not include any special features related to DOTS gateways, and hence
from a DOTS perspective, whenever a DOTS gateway is present, the DOTS from a DOTS perspective, whenever a DOTS gateway is present, the DOTS
session simply terminates/originates there. session simply terminates/originates there.
2.3. DOTS Agent Relationships 2.3. DOTS Agent Relationships
So far, we have only considered a relatively simple scenario of a So far, we have only considered a relatively simple scenario of a
single DOTS client associated with a single DOTS server, however DOTS single DOTS client associated with a single DOTS server, however DOTS
supports more advanced relationships. supports more advanced relationships.
A DOTS server may be associated with one or more DOTS clients, and A DOTS server may be associated with one or more DOTS clients, and
those DOTS clients may belong to different domains. An example those DOTS clients may belong to different domains. An example
scenario is a mitigation provider serving multiple attack targets scenario is a mitigation provider serving multiple attack targets
(Figure 5): (Figure 5).
DOTS Clients DOTS Server DOTS clients DOTS server
+---+ +---+
| c |----------- | c |-----------
+---+ \ +---+ \
example.org \ c1.example.org \
\ \
+---+ \ +---+ +---+ \ +---+
| c |----------------| S | | c |----------------| S |
+---+ / +---+ +---+ / +---+
example.com / c1.example.com / dots1.example.net
/ /
+---+ / +---+ /
| c |----------- | c |-----------
+---+ +---+
example.com example.net c2.example.com
Figure 5: DOTS server with multiple clients Figure 5: DOTS server with multiple clients
A DOTS client may be associated with one or more DOTS servers, and 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 those DOTS servers may belong to different domains. This may be to
ensure high availability or co-ordinate mitigation with more than one ensure high availability or co-ordinate mitigation with more than one
directly connected ISP. An example scenario is for an enterprise to directly connected ISP. An example scenario is for an enterprise to
have DDoS mitigation service from multiple providers, as shown in have DDoS mitigation service from multiple providers, as shown in
Figure 6 below. Operational considerations relating to co-ordinating Figure 6.
multiple provider responses are beyond the scope of DOTS.
[[EDITOR'S NOTE: we request working group feedback and discussion of DOTS client DOTS servers
operational considerations relating to coordinating multiple provider
responses to a mitigation request.]]
DOTS Client DOTS Servers
+---+ +---+
------------| S | -----------| S |
/ +---+ / +---+
dots1.example.net / dots1.example.net
/ /
+---+/ +---+ +---+/ +---+
| c |---------------| S | | c |---------------| S |
+---+\ +---+ +---+\ +---+
dots.example.org \ dots.example.org
\ \
\ +---+ \ +---+
------------| S | -----------| S |
+---+ +---+
example.com dots2.example.net c.example.com dots2.example.net
Figure 6: Multi-Homed DOTS Client Figure 6: Multi-Homed DOTS Client
2.3.1. Gatewayed signaling 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.
As discussed above in Section 2.2.3, a DOTS gateway is a logical The DOTS protocol itself provides no fool-proof method to prevent
function chaining signaling sessions through concatenation of a DOTS such self-inflicted harms as a result deploying multi-homed DOTS
server and DOTS client. 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:
An example scenario, as shown in Figure 7 and Figure 8 below, is for o Requesting mitigation serially, ensuring only one mitigation
an enterprise to have deployed multiple DOTS capable devices which request for a given address space is active at any given time;
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 o Dividing the protected resources among the DOTS servers, such that
[RFC0768] transport inter-domain where connection oriented transports no two mitigators will be attempting to divert and scrub the same
may degrade; this applies to the signal channel only, as the data traffic;
channel requires a connection-oriented transport. The relationship
between the gateway and its upstream agents is opaque to the initial o Using multi-homing for redundancy only. In this case, the DOTS
clients. servers would be affiliated, and through shared communications
ensure that the redundant mitigation requests do not result in
overlapping traffic diversion announcements.
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 |\ | c |\
+---+ \ +---+ +---+ \ +---+
\-----TCP-----| D | +---+ \-----TCP-----| D | +---+
+---+ | O | | | +---+ | O | | |
| c |--------TCP-----| T |------UDP------| S | | c |--------TCP-----| T |------UDP------| S |
+---+ | S | | | +---+ | S | | |
/-----TCP-----| G | +---+ /-----TCP-----| G | +---+
+---+ / +---+ +---+ / +---+
| c |/ | c |/
+---+ +---+
example.com example.com example.net example.com example.com example.net
DOTS Clients DOTS Gateway (DOTSG) DOTS Server DOTS clients DOTS gateway (DOTSG) DOTS server
Figure 7: Client-Side Gateway with Aggregation Figure 7: Client-Side Gateway with Aggregation
+---+ +---+
| c |\ | c |\
+---+ \ +---+ +---+ \ +---+
\-----TCP-----| D |------UDP------+---+ \-----TCP-----| D |------UDP------+---+
+---+ | O | | | +---+ | O | | |
| c |--------TCP-----| T |------UDP------| S | | c |--------TCP-----| T |------UDP------| S |
+---+ | S | | | +---+ | S | | |
/-----TCP-----| G |------UDP------+---+ /-----TCP-----| G |------UDP------+---+
+---+ / +---+ +---+ / +---+
| c |/ | c |/
+---+ +---+
example.com example.com example.net example.com example.com example.net
DOTS Clients DOTS Gateway (DOTSG) DOTS Server DOTS clients DOTS gateway (DOTSG) DOTS server
Figure 8: Client-Side Gateway without Aggregation Figure 8: Client-Side Gateway without Aggregation
This may similarly be deployed in the inverse scenario where the This may similarly be deployed in the inverse scenario where the
gateway resides in the server-side domain and may be used to gateway resides in the server-side domain and may be used to
terminate and/or aggregate multiple clients to single transport as terminate and/or aggregate multiple clients to single transport as
shown in figures Figure 9 and Figure 10 below. shown in figures Figure 9 and Figure 10.
+---+ +---+
| c |\ | c |\
+---+ \ +---+ +---+ \ +---+
\-----UDP-----| D | +---+ \-----UDP-----| D | +---+
+---+ | O | | | +---+ | O | | |
| c |--------TCP-----| T |------TCP------| S | | c |--------TCP-----| T |------TCP------| S |
+---+ | S | | | +---+ | S | | |
/-----TCP-----| G | +---+ /-----TCP-----| G | +---+
+---+ / +---+ +---+ / +---+
| c |/ | c |/
+---+ +---+
example.com example.net example.net example.com example.net example.net
DOTS Clients DOTS Gateway (DOTSG) DOTS Server DOTS clients DOTS gateway (DOTSG) DOTS server
Figure 9: Server-Side Gateway with Aggregation Figure 9: Server-Side Gateway with Aggregation
+---+ +---+
| c |\ | c |\
+---+ \ +---+ +---+ \ +---+
\-----UDP-----| D |------TCP------+---+ \-----UDP-----| D |------TCP------+---+
+---+ | O | | | +---+ | O | | |
| c |--------TCP-----| T |------TCP------| S | | c |--------TCP-----| T |------TCP------| S |
+---+ | S | | | +---+ | S | | |
/-----UDP-----| G |------TCP------+---+ /-----UDP-----| G |------TCP------+---+
+---+ / +---+ +---+ / +---+
| c |/ | c |/
+---+ +---+
example.com example.net example.net example.com example.net example.net
DOTS Clients DOTS Gateway (DOTSG) DOTS Server DOTS clients DOTS gateway (DOTSG) DOTS server
Figure 10: Server-Side Gateway without Aggregation 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.
3. Concepts 3. Concepts
3.1. Signaling Sessions 3.1. Signaling Sessions
In order for DOTS to be effective as a vehicle for DDoS mitigation In order for DOTS to be effective as a vehicle for DDoS mitigation
requests, one or more DOTS clients must establish ongoing requests, one or more DOTS clients must establish ongoing
communication with one or more DOTS servers. While the preconditions communication with one or more DOTS servers. While the preconditions
for enabling DOTS in or among network domains may also involve for enabling DOTS in or among network domains may also involve
business relationships, service level agreements, or other formal or business relationships, service level agreements, or other formal or
informal understandings between network operators, such informal understandings between network operators, such
considerations are out of scope for this document. considerations are out of scope for this document.
An established communication layer between DOTS agents is a Signaling An established communication layer between DOTS agents is a signaling
Session. At its most basic, for a DOTS signaling session to exist session. At its most basic, for a DOTS signaling session to exist
both signal channel and data channel must be functioning between DOTS both signal channel and data channel must be functioning between DOTS
agents. That is, under nominal network conditions, signals actively agents. That is, under nominal network conditions, signals actively
sent from a DOTS client are received by the specific DOTS server sent from a DOTS client are received by the specific DOTS server
intended by the client, and vice versa. intended by the client, and vice versa.
3.1.1. Preconditions 3.1.1. Preconditions
Prior to establishing a signaling session between agents, the owners Prior to establishing a signaling session between agents, the owners
of the networks, domains, services or applications involved are of the networks, domains, services or applications involved are
assumed to have agreed upon the terms of the relationship involved. assumed to have agreed upon the terms of the relationship involved.
skipping to change at page 16, line 26 skipping to change at page 16, line 43
client is provided with all data and metadata required to establish client is provided with all data and metadata required to establish
communication with the DOTS server. Such data and metadata would communication with the DOTS server. Such data and metadata would
include any cryptographic information necessary to meet the message include any cryptographic information necessary to meet the message
confidentiality, integrity and authenticity requirement in confidentiality, integrity and authenticity requirement in
[I-D.ietf-dots-requirements], and might also include the pool of DOTS [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 server addresses and ports the DOTS client should use for signal and
data channel messaging. data channel messaging.
3.1.2. Establishing the Signaling Session 3.1.2. Establishing the Signaling Session
With the required business or service agreements in place, the DOTS With the required business agreements in place, the DOTS client
client initiates a signal session by contacting the DOTS server over initiates a signal session by contacting its DOTS server(s) over the
the signal channel and the data channel. To allow for DOTS service signal channel and the data channel. To allow for DOTS service
flexibility, neither the order of contact nor the time interval flexibility, neither the order of contact nor the time interval
between channel creations is specified. A DOTS client MAY establish between channel creations is specified. A DOTS client MAY establish
signal channel first, and then data channel, or vice versa. signal channel first, and then data channel, or vice versa.
The methods by which a DOTS client receives the address and The methods by which a DOTS client receives the address and
associated service details of the DOTS server are not prescribed by associated service details of the DOTS server are not prescribed by
this document. For example, a DOTS client may be directly configured this document. For example, a DOTS client may be directly configured
to use a specific DOTS server address and port, and directly provided to use a specific DOTS server IP address and port, and directly
with any data necessary to satisfy the Peer Mutual Authentication provided with any data necessary to satisfy the Peer Mutual
requirement in [I-D.ietf-dots-requirements], such as symmetric or Authentication requirement in [I-D.ietf-dots-requirements], such as
asymmetric keys, usernames and passwords, etc. All configuration and symmetric or asymmetric keys, usernames and passwords, etc. All
authentication information in this scenario is provided out-of-band configuration and authentication information in this scenario is
by the domain operating the DOTS server. provided out-of-band by the domain operating the DOTS server.
At the other extreme, the architecture in this document allows for a At the other extreme, the architecture in this document allows for a
form of DOTS client auto-provisioning. For example, the domain form of DOTS client auto-provisioning. For example, the domain
operating the DOTS server or servers might provide the client domain operating the DOTS server or servers might provide the client domain
only with symmetric or asymmetric keys to authenticate the only with symmetric or asymmetric keys to authenticate the
provisioned DOTS clients. Only the keys would then be directly provisioned DOTS clients. Only the keys would then be directly
configured on DOTS clients, but the remaining configuration required configured on DOTS clients, but the remaining configuration required
to provision the DOTS clients could be learned through mechanisms to provision the DOTS clients could be learned through mechanisms
similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763].
skipping to change at page 17, line 18 skipping to change at page 17, line 33
As described in [I-D.ietf-dots-requirements], the DOTS client can As described in [I-D.ietf-dots-requirements], the DOTS client can
configure preferred values for acceptable signal loss, mitigation configure preferred values for acceptable signal loss, mitigation
lifetime, and heartbeat intervals when establishing the signaling lifetime, and heartbeat intervals when establishing the signaling
session. A signaling session is not active until DOTS agents have session. A signaling session is not active until DOTS agents have
agreed on the values for these signaling session parameters, a agreed on the values for these signaling session parameters, a
process defined by the protocol. process defined by the protocol.
Once the DOTS client begins receiving DOTS server signals, the Once the DOTS client begins receiving DOTS server signals, the
signaling session is active. At any time during the signaling signaling session is active. At any time during the signaling
session, the DOTS client MAY use the data channel to adjust initial session, the DOTS client may use the data channel to adjust initial
configuration, manage black- and white-listed prefixes or addresses, configuration, manage black- and white-listed prefixes or addresses,
leverage vendor-specific extensions, and so on. Note that unlike the leverage vendor-specific extensions, and so on. Note that unlike the
signal channel, there is no requirement that the data channel remain signal channel, there is no requirement that the data channel remain
operational in attack conditions (See Data Channel Requirements, operational in attack conditions (See Data Channel Requirements,
[I-D.ietf-dots-requirements]). [I-D.ietf-dots-requirements]).
3.1.3. Maintaining the Signaling Session 3.1.3. Maintaining the Signaling Session
DOTS clients and servers periodically send heartbeats to each other DOTS clients and servers periodically send heartbeats to each other
over the signal channel, per Operational Requirements discussed in over the signal channel, per Operational Requirements discussed in
skipping to change at page 17, line 46 skipping to change at page 18, line 13
that absence will be established in the protocol definition. that absence will be established in the protocol definition.
3.2. Modes of Signaling 3.2. Modes of Signaling
This section examines the modes of signaling between agents in a DOTS This section examines the modes of signaling between agents in a DOTS
architecture. architecture.
3.2.1. Direct Signaling 3.2.1. Direct Signaling
A signaling session may take the form of direct signaling between the A signaling session may take the form of direct signaling between the
DOTS clients and servers, as shown in Figure 11 below: DOTS clients and servers, as shown in Figure 11.
+-------------+ +-------------+ +-------------+ +-------------+
| DOTS client |<------signal session------>| DOTS server | | DOTS client |<------signal session------>| DOTS server |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 11: Direct Signaling Figure 11: Direct Signaling
In a direct signaling session, DOTS client and server are In a direct signaling session, DOTS client and server are
communicating directly. A direct signaling session MAY exist inter- communicating directly. A direct signaling session may exist inter-
or intra-domain. The signaling session is abstracted from the or intra-domain. The signaling session is abstracted from the
underlying networks or network elements the signals traverse: in a underlying networks or network elements the signals traverse: in a
direct signaling session, the DOTS client and server are logically direct signaling session, the DOTS client and server are logically
peer DOTS agents. adjacent.
3.2.2. Redirected Signaling 3.2.2. Redirected Signaling
In certain circumstances, a DOTS server may want to redirect a DOTS In certain circumstances, a DOTS server may want to redirect a DOTS
client to an alternative DOTS server for a signaling session. Such client to an alternative DOTS server for a signaling session. Such
circumstances include but are not limited to: circumstances include but are not limited to:
o Maximum number of signaling sessions with clients has been o Maximum number of signaling sessions with clients has been
reached; reached;
o Mitigation capacity exhaustion in the Mitigator with which the o Mitigation capacity exhaustion in the mitigator with which the
specific DOTS server is communicating; specific DOTS server is communicating;
o Mitigator outage or other downtime, such as scheduled maintenance; o Mitigator outage or other downtime, such as scheduled maintenance;
o Scheduled DOTS server maintenance; o Scheduled DOTS server maintenance;
o Scheduled modifications to the network path between DOTS server o Scheduled modifications to the network path between DOTS server
and DOTS client. and DOTS client.
A basic redirected signaling session resembles the following, as A basic redirected signaling session resembles the following, as
shown in Figure 12: shown in Figure 12.
+-------------+ +---------------+ +-------------+ +---------------+
| |<-(1)-- signal session 1 -->| | | |<-(1)-- signal session 1 -->| |
| | | | | | | |
| |<=(2)== redirect to B ======| | | |<=(2)== redirect to B ======| |
| DOTS client | | DOTS server A | | DOTS client | | DOTS server A |
| |X-(4)-- signal session 1 --X| | | |X-(4)-- signal session 1 --X| |
| | | | | | | |
| | | | | | | |
+-------------+ +---------------+ +-------------+ +---------------+
skipping to change at page 19, line 6 skipping to change at page 19, line 26
(3) signal session 2 (3) signal session 2
| |
v v
+---------------+ +---------------+
| DOTS server B | | DOTS server B |
+---------------+ +---------------+
Figure 12: Redirected Signaling Figure 12: Redirected Signaling
1. Previously established signaling session 1 exists between a DOTS 1. Previously established signaling session 1 exists between a DOTS
client and DOTS server with address A. client and DOTS server A.
2. DOTS server A sends a server signal redirecting the client to 2. DOTS server A sends a server signal redirecting the client to
DOTS server B. DOTS server B.
3. If the DOTS client does not already have a separate signaling 3. If the DOTS client does not already have a separate signaling
session with the redirection target, the DOTS client initiates session with the redirection target, the DOTS client initiates
and establishes a signaling session with DOTS server B as and establishes a signaling session with DOTS server B.
described above.
4. Having redirected the DOTS client, DOTS server A ceases sending 4. Having redirected the DOTS client, DOTS server A ceases sending
server signals. The DOTS client likewise stops sending client server signals. The DOTS client likewise stops sending client
signals to DOTS server A. Signal session 1 is terminated. signals to DOTS server A. Signal session 1 is terminated.
3.2.3. Recursive Signaling 3.2.3. Recursive Signaling
DOTS is centered around improving the speed and efficiency of DOTS is centered around improving the speed and efficiency of
coordinated response to DDoS attacks. One scenario not yet discussed coordinated response to DDoS attacks. One scenario not yet discussed
involves coordination among federated domains operating DOTS servers involves coordination among federated domains operating DOTS servers
skipping to change at page 19, line 45 skipping to change at page 20, line 15
The operator of the mitigator has limited options in the event a DOTS The operator of the mitigator has limited options in the event a DOTS
client-requested mitigation is being overwhelmed by the severity of client-requested mitigation is being overwhelmed by the severity of
the attack. Out-of-scope business or service level agreements may the attack. Out-of-scope business or service level agreements may
permit the mitigating domain to drop the mitigation and let attack permit the mitigating domain to drop the mitigation and let attack
traffic flow unchecked to the target, but this is only encourages traffic flow unchecked to the target, but this is only encourages
attack escalation. In the case where the mitigating domain is the attack escalation. In the case where the mitigating domain is the
upstream service provider for the attack target, this may mean the upstream service provider for the attack target, this may mean the
mitigating domain and its other services and users continue to suffer mitigating domain and its other services and users continue to suffer
the incidental effects of the attack. the incidental effects of the attack.
A recursive signaling model as shown in Figure 13 below offers an A recursive signaling model as shown in Figure 13 offers an
alternative. In a variation of the primary use case "Successful alternative. In a variation of the use case "Enterprise with an
Automatic or Operator-Assisted CPE or PE Mitigators Request Upstream upstream transit provider DDoS mitigation service" described in
DDoS Mitigation Services" described in [I-D.ietf-dots-use-cases], an [I-D.ietf-dots-use-cases], a domain operating a DOTS server and
domain operating a DOTS server and mitigation also operates a DOTS mitigator also operates a DOTS client. This DOTS client has an
client. This DOTS client has an established signaling session with a established signaling session with a DOTS server belonging to a
DOTS server belonging to a separate administrative domain. separate administrative domain.
With these preconditions in place, the operator of the mitigator With these preconditions in place, the operator of the mitigator
being overwhelmed or otherwise performing inadequately may request being overwhelmed or otherwise performing inadequately may request
mitigation for the attack target from this separate DOTS-aware mitigation for the attack target from this separate DOTS-aware
domain. Such a request recurses the originating mitigation request domain. Such a request recurses the originating mitigation request
to the secondary DOTS server, in the hope of building a cumulative to the secondary DOTS server, in the hope of building a cumulative
mitigation against the attack: mitigation against the attack.
example.net domain example.net domain
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Gn . . Gn .
+----+ A . +----+ +-----------+ . +----+ A . +----+ +-----------+ .
| Cc |<--------->| Sn |~~~~~~~| Mitigator | . | Cc |<--------->| Sn |~~~~~~~| Mitigator | .
+----+ . +====+ | Mn | . +----+ . +====+ | Mn | .
. | Cn | +-----------+ . . | Cn | +-----------+ .
example.com . +----+ . example.com . +----+ .
client . ^ . client . ^ .
skipping to change at page 20, line 37 skipping to change at page 21, line 30
. +----+ +-----------+ . . +----+ +-----------+ .
. | So |~~~~~~~| Mitigator | . . | So |~~~~~~~| Mitigator | .
. +----+ | Mo | . . +----+ | Mo | .
. +-----------+ . . +-----------+ .
. . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
example.org domain example.org domain
Figure 13: Recursive Signaling Figure 13: Recursive Signaling
In Figure 13 above, client Cc signals a request for mitigation across In Figure 13, client Cc signals a request for mitigation across
inter-domain signaling session A to the DOTS server Sn belonging to inter-domain signaling session A to the DOTS server Sn belonging to
the example.net domain. DOTS server Sn enables mitigation on the example.net domain. DOTS server Sn enables mitigation on
mitigator Mn. DOTS server Sn is half of DOTS gateway Gn, being mitigator Mn. DOTS server Sn is half of DOTS gateway Gn, being
deployed logically back-to-back with DOTS client Cn, which has pre- deployed logically back-to-back with DOTS client Cn, which has pre-
existing inter-domain signaling session B with the DOTS server So existing inter-domain signaling session B with the DOTS server So
belonging to the example.org domain. At any point, DOTS server Sn belonging to the example.org domain. At any point, DOTS server Sn
MAY recurse an on-going mitigation request through DOTS client Cn to MAY recurse an on-going mitigation request through DOTS client Cn to
DOTS server So, in the expectation that mitigator Mo will be DOTS server So, in the expectation that mitigator Mo will be
activated to aid in the defense of the attack target. activated to aid in the defense of the attack target.
Recursive signaling is opaque to the DOTS client. To maximize Recursive signaling is opaque to the DOTS client. To maximize
mitigation visibility to the DOTS client, however, the recursing mitigation visibility to the DOTS client, however, the recursing
domain SHOULD provide recursed mitigation feedback in signals domain SHOULD provide recursed mitigation feedback in signals
reporting on mitigation status to the DOTS client. For example, the reporting on mitigation status to the DOTS client. For example, the
recursing domain's mitigator should incorporate into mitigation recursing domain's mitigator should incorporate into mitigation
status messages available metrics such as dropped packet or byte status messages available metrics such as dropped packet or byte
counts from the recursed mitigation. counts from the recursed mitigation.
DOTS clients involved in recursive signaling MUST be able to withdraw DOTS clients involved in recursive signaling must be able to withdraw
requests for mitigation without warning or justification, per requests for mitigation without warning or justification, per
[I-D.ietf-dots-requirements]. [I-D.ietf-dots-requirements].
Operators recursing mitigation requests MAY maintain the recursed Operators recursing mitigation requests MAY maintain the recursed
mitigation for a brief, protocol-defined period in the event the DOTS mitigation for a brief, protocol-defined period in the event the DOTS
client originating the mitigation withdraws its request for help, as client originating the mitigation withdraws its request for help, as
per the discussion of managing mitigation toggling in the operational per the discussion of managing mitigation toggling in the operational
requirements ([I-D.ietf-dots-requirements]). Service or business requirements ([I-D.ietf-dots-requirements]).
agreements between recursing domains are not in scope for this
document.
[[EDITOR'S NOTE: Recursive signaling raises questions about [[EDITOR'S NOTE: Recursive signaling raises questions about
operational and data privacy, as well as what level of visibility a operational and data privacy, as well as what level of visibility a
client has into the recursed mitigation. We ask the working group client has into the recursed mitigation. We ask the working group
for feedback and additional discussion of these issues to help settle for feedback and additional discussion of these issues to help settle
the way forward.]] the way forward.]]
3.2.4. Anycast Signaling 3.2.4. Anycast Signaling
The DOTS architecture does not assume the availability of anycast The DOTS architecture does not assume the availability of anycast
skipping to change at page 22, line 18 skipping to change at page 23, line 10
signaling is to the individual DOTS client indistinct from direct signaling is to the individual DOTS client indistinct from direct
signaling. However, the operational challenges inherent in anycast signaling. However, the operational challenges inherent in anycast
signaling are anything but negligible, and DOTS server operators must signaling are anything but negligible, and DOTS server operators must
carefully weigh the risks against the benefits before deploying. carefully weigh the risks against the benefits before deploying.
While the DOTS signal channel primarily operates over UDP per While the DOTS signal channel primarily operates over UDP per
[I-D.ietf-dots-requirements], the signal channel also requires mutual [I-D.ietf-dots-requirements], the signal channel also requires mutual
authentication between DOTS agents, with associated security state on authentication between DOTS agents, with associated security state on
both ends. The resulting considerations therefore superficially both ends. The resulting considerations therefore superficially
resemble the deployment of anycast DNS over DTLS, as described in resemble the deployment of anycast DNS over DTLS, as described in
[I-D.ietf-dprive-dnsodtls], but the similiarities only go so far. [RFC8094], but the similarities only go so far.
Network instability is of particular concern with anycast signaling, Network instability is of particular concern with anycast signaling,
as DOTS signaling sessions are expected to be long-lived, and as DOTS signaling sessions are expected to be long-lived, and
potentially operating under congested network conditions caused by a potentially operating under congested network conditions caused by a
volumetric DDoS attack. volumetric DDoS attack.
For example, a network configuration altering the route to the DOTS For example, a network configuration altering the route to the DOTS
server during active anycast signaling may cause the DOTS client to server during active anycast signaling may cause the DOTS client to
send messages to a DOTS server other than the one with which it send messages to a DOTS server other than the one with which it
initially established a signaling session. That second DOTS server initially established a signaling session. That second DOTS server
skipping to change at page 26, line 30 skipping to change at page 27, line 18
control of a DOTS client may negatively influence network traffic by control of a DOTS client may negatively influence network traffic by
requesting and withdrawing requests for mitigation for particular requesting and withdrawing requests for mitigation for particular
prefixes, leading to route or DNS flapping. prefixes, leading to route or DNS flapping.
Any attack targeting the availability of DOTS servers may disrupt the Any attack targeting the availability of DOTS servers may disrupt the
ability of the system to receive and process DOTS signals resulting ability of the system to receive and process DOTS signals resulting
in failure to fulfill a mitigation request. DOTS agents SHOULD be in failure to fulfill a mitigation request. DOTS agents SHOULD be
given adequate protections, again in accordance with best current given adequate protections, again in accordance with best current
practices for network and host security. practices for network and host security.
5. Acknowledgments 5. Contributors
Mohamed Boucadair
Orange
mohamed.boucadair@orange.com
6. Acknowledgments
Thanks to Matt Richardson and Med Boucadair for their comments and Thanks to Matt Richardson and Med Boucadair for their comments and
suggestions. suggestions.
6. Change Log 7. Change Log
2016-03-18 Initial revision 2016-03-18 Initial revision
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References 8.2. Informative References
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-04 (work in Requirements", draft-ietf-dots-requirements-04 (work in
progress), March 2017. progress), March 2017.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., Dobbins, R., Fouant, S., Migault, D., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-04 (work Open Threat Signaling (DDoS) Open Threat Signaling",
in progress), March 2017. draft-ietf-dots-use-cases-05 (work in progress), May 2017.
[I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "Specification for DNS
over Datagram Transport Layer Security (DTLS)", draft-
ietf-dprive-dnsodtls-15 (work in progress), December 2016.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-20 (work in progress), Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
April 2017. April 2017.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1035] Mockapetris, P., "Domain names - implementation and
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
<http://www.rfc-editor.org/info/rfc1034>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>. <http://www.rfc-editor.org/info/rfc2782>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <http://www.rfc-editor.org/info/rfc4271>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732, Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006, DOI 10.17487/RFC4732, December 2006,
<http://www.rfc-editor.org/info/rfc4732>. <http://www.rfc-editor.org/info/rfc4732>.
skipping to change at page 28, line 33 skipping to change at page 29, line 15
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013, RFC 7092, DOI 10.17487/RFC7092, December 2013,
<http://www.rfc-editor.org/info/rfc7092>. <http://www.rfc-editor.org/info/rfc7092>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094, "Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014, DOI 10.17487/RFC7094, January 2014,
<http://www.rfc-editor.org/info/rfc7094>. <http://www.rfc-editor.org/info/rfc7094>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017,
<http://www.rfc-editor.org/info/rfc8094>.
Authors' Addresses Authors' Addresses
Andrew Mortensen Andrew Mortensen
Arbor Networks, Inc. Arbor Networks
2727 S. State St 2727 S. State St
Ann Arbor, MI 48104 Ann Arbor, MI 48104
United States United States
EMail: amortensen@arbor.net EMail: amortensen@arbor.net
Flemming Andreasen Flemming Andreasen
Cisco Systems, Inc. Cisco
United States United States
EMail: fandreas@cisco.com EMail: fandreas@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Systems, Inc. McAfee, Inc.
Cessna Business Park, Varthur Hobli Embassy Golf Link Business Park
Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560071
Bangalore, Karnataka 560103
India India
EMail: tireddy@cisco.com EMail: tireddy@cisco.com
Christopher Gray Christopher Gray
Comcast, Inc. Comcast
United States United States
EMail: Christopher_Gray3@cable.comcast.com EMail: Christopher_Gray3@cable.comcast.com
Rich Compton Rich Compton
Charter Communications, Inc. Charter
EMail: Rich.Compton@charter.com EMail: Rich.Compton@charter.com
Nik Teague Nik Teague
Verisign, Inc. Verisign
United States United States
EMail: nteague@verisign.com EMail: nteague@verisign.com
 End of changes. 94 change blocks. 
233 lines changed or deleted 265 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/